...

• One Database per District per Application
• One installation of the software per District
• Ready for the "Cloud"

Application Architecture

Modules

...

Data Model

• Object Oriented
  • Abstraction of underlying Database tables
  • Simplifies "tables"
  • Correctly linked  to 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 /wiki/spaces/rtd/pages/2752614 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)