📄️ The USoft Rules Engine
To understand more advanced properties of USoft constraints, the best starting point is the Rules Engine.
📄️ Where are the rules?
Data integrity rules executed by a Rules Engine are expressed in USoft Definer.
📄️ Constraint conceptual model
To understand how a network of USoft constraints is implemented in a runtime Rules Engine, you need an understanding at 3 different levels.
📄️ Constraint activation events
Constraints in USoft are activated when field-validation events, store-record events, and commit events occur. These events are discussed individually at the end of this help topic.
📄️ Store-record event overview
The table below affords an overview of all the possible constraint validations that could take place at store-record event time.
📄️ Constraint evaluation order
A Rules Engine in USoft executes, against application data in a data model, a non-ordered collection of constraints: domain constraints and table constraints.
📄️ Chained corrections
Chained corrections are SQL manipulations that you want to postpone to the next transaction (chained transaction) but that are a direct result of manipulations that have occurred in the current transaction. This applies if the postponed manipulations consist of passing data on to third-party software, perhaps a mail server for outgoing e-mails, and you want to make sure this happens only if your entire current transaction including all transaction checks completes successfully.
📄️ Transaction checks
Transaction checks are checks applied to manipulated records when the transaction commits, that is, at a later time than the store-record events for these records. This later evaluation time is necessary because, to do the check, any corrections to other records must have taken place first.
📄️ Cascade-to-other corrections
Cascade-to-other corrections are corrections of column values in one or more records that are different from the record being processed. These may be different records in the same table instance, records in a different table instance of the same table, or records in a different table altogether.
📄️ Driving table
When constraints are evaluated, the SQL that is sent to the database in most cases is not the literal constraint SQL Statement. The Rules Engine attempts to add WHERE conditions to the SQL statements in which column values for only one record are substituted. This is called row binding.
📄️ Constraint key query
At store-record time, in an operation known as a constraint key query, the Rules Engine may attempt to get primary key information of records being processed. This is because database values needed during later transaction checks will be retrieved faster if primary key values can be used.
📄️ Transaction checklist signals
A transaction checklist signal consist of adding, at store-record time, an entry to an internal list or transaction checklist of all the records that must be subjected to a transaction check at commit time.
📄️ Row checks
Row checks are checks applied to the record being processed. To do a row check, values from multiple fields within the record may be needed, but no values from other records are needed.
📄️ Update-on-self corrections
Update-on-self corrections are corrections of column values within the record being processed. To do an update-on-self correction, values from other records (within the same table instance, or from a different instance of the same table, or from a different table altogether) may be needed, but no values in other records are in danger of being affected.
📄️ Field corrections and field checks
Field corrections and field checks are corrections and checks applied to a column value being processed.
📄️ Preconditions and postconditions
The Rules Engine uses preconditions and postconditions in some optimisation techniques. These are used in UPDATE constraints.
📄️ Lock and commit management
To minimize potential lock conflicts, the Rules Engine tries to have records locked for a minimum of time. For restrictive checks where locking is necessary, the main strategy is that records are locked no sooner than at commit time, and that commit follows as soon as possible after the lock. The situations in which the Rules Engine locks records are:
📄️ Startup constraints
You can write constraints that are evaluated when a Rules Engine is started. This happens for example when you start an application, run a batch job, or connect to the USoft Remote Rules Serice. This allows you to define a restrictive rule that prevents a user from starting a USoft application after a certain time, or a productive rule that keeps track of which users use the application and at what time.
📄️ Time constraints
USoft Production has an application timer that allows scheduled constraint execution. The timer consists of an application table TAPPTIME, and an executable USCLOCK.EXE that updates TAPPTIME with the current database time at regular intervals.