Technical Overview

Owned by Former user (Deleted)
Last updated: Jan 28, 2016
2 min read

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

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