Skip to end of metadata
Go to start of metadata

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"

 

USxS Instances

Application Architecture

Software 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
  • 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

Data Model Example

 

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

Transaction-Event Processing

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)

 

 

  • No labels