Table of Contents
Status Processor
A Status Processor is a background process running within PASI that runs validation rules against a set of records. Where these validation rules fail, Core Alerts will be captured in the Validation Status for the specific records that they apply to. The status processor is responsible for keeping the Validation Status up to date based on changes to the underlying data.
PASI includes the following status processors:
Terminology
Data Structures
The following diagram outlines the data structure generically used by Status Processors.
status_processor_relationship_diagram.vsdx
Using the Student School Enrolment status processor as an example:
- A trigger record applies to one Student School Enrolment record and a Student School Enrolment may have a trigger record.
- That trigger record may result in 1 or more Core Alerts being generated specific to a Student School Enrolment record.
From an implementation point of view, each Status Processor has a corresponding Source Record, Validation Status, and Trigger table.
Core Alert
Core Alerts Overview identify a real or potential issue with the data submitted to PASI.
Trigger
Each status processor has a status processor trigger table to store individual records that should be evaluated:
Validation Status
Used to identify Core Alerts Overview associated to specific student, course enrolment, evaluated mark, section, and student school enrolment records:
Processing
Status processors apply validation rules against a record asynchronously, meaning that the data is updated and saved before the validation rules are applied. This separation is managed using Status Processor Triggers.
Triggering the Status Processor
To add a reference to starting the processor based on Next Scan Date
Where information relating to/impacting a validation rule is changed, a trigger is produced to indicate that the corresponding Status Processor should be run for that particular record (also known as the source record). This means that if an existing trigger record does not exist for the source record, it is created. If a trigger record already exists for the source record, it is updated in order to increase the version of the trigger record.
When the status processor runs, it looks for any triggers in its trigger table that require processing. This is done by comparing the version of each trigger record against the maximum source version in the corresponding Validation Status record. If the version of the trigger record is greater than the max source version, the validation status is considered out of date and needs to be reassessed.
Evaluating the Rules
Once the status processor identifies an out of date Validation Status record, it applies all of the validation rules for that status processor against the information contained within source record.
Each validation rule is assessed individually and in no particular order. Refer to each status processor for a listing of their validation rules:
Rules are independent of each other
Rules are not chained together and the output of one rule does not affect another.
Every rule is run every time
If rule A fails, rule B will still run. There are, however, certain constraints that can be placed in a rule attribute that cause it not to be run (i.e. school year.)
Rules are run in no particular order
Although usually the results are output in order by rule #, because the rule are independent of each other any assumption made about the order in which the rules are run is not useful.
Schema validation occurs before any rejection rules are run
This means that inside a rejection rule, we can assume that schema validation has been applied. If, for example, there is a schema validation attribute on a state province id property that says the value must be a 9-digit integer then the rule can assume that the state province id is a valid 9-digit integer.
An invalid assumption to make is that the 9-digit state province id actually references a student that exists. There is Rule 9002 - Invalid ASN that checks that the state province id exists. But inside of a rule, if student data is needed, you cannot assume that the student exists. The only thing you can assume about the state province id is that it is a valid 9-digit integer.
Storing the Results
The Core Alerts produced (if any) from each validation rule are collected and captured as part of the updated Validation Status record. If no core alerts are produced then a ‘clean’ Validation Status record is stored.
The update to the Validation Status record also changes the max source version to be equal to the version of the trigger record. Therefore, the next time the status processor checks for validation status records to reprocess, this record won’t be processed.
Example
The following is a sample of the flow/logic for the SSE Status Processor:
