...
- 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 the samesimilar. How it's done is differentdifferent.
- 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
...
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
- Application discovers structure
- 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 relationshiprelationships
- 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
- In User Interface:
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
- In UI, authorized to:
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)