Philosophy & Design Goals

• Prepare applications for the next 30 Years

• Don't Rewrite.  Re-Think, Re-Invent and Re-design

• Reproduce the capabilities of Classic.  

  • The "What", not the "How".  What it does is similar. How it's done is different.

  • Implement minimum business rules.  Leave the rest to customization.

• Design to be agnostic regarding:

  • Server Location

  • Operating System and Platform

  • Existence of ITCs

Technical Architecture

• One Database per District per Application

• One installation of the software per District

• Ready for the "Cloud"

Application Architecture

Modules

• Independent Installable Features

• Types of Modules:

  • Infrastructure (database, email)

  • Behavioral (business logic)

  • Required

  • Optional (authentication)

Data Model

• Object Oriented

  • Abstraction of underlying Database tables

  • Simplifies "tables"

  • Correctly linked to related objects

• Dynamic

  • Application discovers structure
    
    

    • Reporting Service

    • Form layout

  • Custom Fields appear as if part of system

• Primary key/Database Id

  • Automatically assigned by system

  • Immutable

  • Random UUID

  • Used in relationships between objects

  • Rarely seen in UI

• Natural Id

  • User or Auto assigned identifier

  • Human-readable reference number

  • Unique

  • May be mutable

  • Not used in relationships

  • e.g. Vendor.number, PO.number, Disbursement.transactionNumber + physicalCheck.number

• https://usas.docs.ssdt.io/current/model/

• https://usps.docs.ssdt.io/current/model/

Bad Habits caused by Classic

• "Miss-using" fields for other purposes

  • Interesting uses of Vendor Email address

• Using identifiers to create semantic meaning:

  • Vendor number ranges

  • prefixing transaction numbers with code or Fiscal Year

• Caused by Classic (e.g. lack of filtering)

Redesign Solution

• Custom Fields can be created to add meaning

  • Accurate label

  • Viewable, filterable, reportable

• Combined with Rules:

  • Validation

  • Custom behavior

Database Transactions

The Classic Problem

• If operation fails (due to crash):

  • USxS transaction can be partial posted

  • Files left in inconsistent state (out of balance)

• Example: Post Purchase Order steps:

  • Write PO header record

  • Loop for each PO Item:

    • Write item record

    • Update encumbrances on budget

    • Update encumbrances on appropriation

    • Update encumbrances on cash

  • If any of the steps fail, files can be out of balance

Redesign Solution

• SQL Databases provide "Transactional Scope"

• All operations within scope guaranteed to, either:

  • Succeed completely (commit) 

  • Fail completely (rollback)

• Any error causes rollback:

  • Duplicate key

  • Validation error

  • Security violation

  • System failure

Security, Permissions and Roles

• Each Application has separate User profiles

• An "ITC User" must have a profile in each instance

  • Can be externally authenticated (Windows Domain)

  • No special privileges assigned to ITC user

• Permissions:

  • Defined by application

  • Fine-grained operations the software can perform

  • Not analogous to file level protections or ACL's in Classic

• Roles

  • Set of permissions granted to a role

  • Defined per district per application

  • May represent:

    • Group of users

    • Job Function

  • One or more roles granted to Users

• Predefined Roles:

  • ADMINISTRATORS (required)

  • Classic compatibility: (If imported from Classic)

    • SYSMAN_USER like OECN_SYSMAN

    • USAS_MANAGER like OECN_USAS_GM

    • USAS_REQ like OECN_USAS_REQ

    • USAS_RO like OECN_USAS_RO

    • USAS_STANDARD like OECN_USAS

    • Similar for USPS

• Security in Application

  • In User Interface:

    • Hides Menu Options 

    • Hides or disables buttons and controls

  • Application Layer

    • Services verify users access

    • If UI inadvertently allows user access, Model protects authorized access

See Authentication and Authorization for additional details.

Transactions, Events, Processing, Listeners  & Rules

Understanding Permission Check

• If user is authorized to "Create" a Purchase Order, then:

  • In UI, authorized to:

    • search and select Vendor's

    • search and select Expenditure Accounts

  • In Data Model, authorized to:

    • Post Encumbrance Ledgers

    • All side effects caused by Listeners and Rules

3rd Party Integration

• SOAP Service

  • Exists in Preview

  • Simulates Classic data module

  • Near 100% compatibility with Classic

• Batch Integrations

  • Most currently missing

  • Report Engine may be able match most exports

  • Generic import will be coming

  • Specific imports/exports based on feedback

• Also missing: transfer mechanism

• Future: Redesigned based web service (REST instead of SOAP)