Rules best practices

USoft Definer lets you define restrictive rules and corrective rules. With a restrictive rule, at runtime, if a user attempts to manipulate data in such a way that the new data violates the rule, the transaction is blocked and an error is raised.

In a traditional USoft application, where humans have an interactive role, this behaviour often works well: it makes the user understand the role, or prompts her to supply different data that does fit the rule, or to take an altogether different course of action.

In an event processing context, restrictive rules typically do not work well. Data flows without user interaction are involved. It is more often important that data can continue to flow without transactions being blocked or warnings or errors being raised. For this reason, it is often better to choose corrective rules. A typical way of converting restrictive into corrective behaviour is to react to an error by writing error information to a log table as part of the standard operation, as opposed to blocking the transaction and issuing an error by way of exception.

Of course, even in an event processing context you may occasionally want to abort a process when a rule is violated, and in this case a restrictive implementation is called for.

Use transitional constraints when working with master data tables. Master data is data that rarely changes and when it does change, this does not affect the history of transactional data. As an example of master data, imagine system configuration data such as an admin e-mail address that is different for each physical machine or environment to which the application is deployed. To such an e-mail address, a message is sent if an exception occurs. Implement rules that lookup this e-mail address as transitional constraints. Make sure that the constraint's Transition Table is not the master data table where the e-mail address is stored, but the transactional table(s) that make(s) use of the e-mail address.

For how-to instructions on how to create transitional constraints, see the USoft Model And Rules Guide in USoft Definer Help.

For advanced tips on transitional constraints, see the USoft Rules Engine Guide, equally in USoft Definer Help.

Use post-commit constraints when you want to control the flow of event processing, for example, in a design pattern for synchronous input processing, when you want to start processing input events from a queue. Or, in a design pattern with synchronous result, when you want to add messages to the output queue.

Run the processing of events as a sequence of short-time transactions. Processing data in smaller chunks is more reliable. Use post-commit constraints to create a transaction chain.

For how-to instructions on how to create post-commit constraints, see the USoft Model And Rules Guide in USoft Definer Help.

For advanced tips on post-commit constraints, see the USoft Rules Engine Guide, equally in USoft Definer Help.

Processing rules may also be classified depending on the type of trigger:

•Time-based rules - The business function executes on a recurring basis, running at pre-determined schedules. Use a timer service in Service Framework to implement time-based rules.

•State-based rules - An action will execute when the system reaches a specific state. Use constraints to implement state-based rules.