Function Assignment

For a ruleset to be processed, a function has to be assigned to the ruleset. The mode of operation setting of the assigned function must be either Event Mode or Functional and Event Mode. A ruleset can be assigned to only one function, whereas one function may have any number of rulesets assigned.

If a function has more than one ruleset assigned, the question arises how you can influence the execution order of the different rulesets. To control the execution order, you can assign a priority to a ruleset that is evaluated at runtime when the assigned function is executed. To set the ruleset priority, open the Detail section and enter the desired value (from 00 to 99) in the Priority field. For more information, see Function, section Ruleset Execution Priority.

Rule Assignment

The rules contained in a ruleset can be either named or unnamed:

In addition to the trigger function, a ruleset also defines the precondition and validity period for each rule. The precondition and validity period determine if the rule is triggered or not. Given that, the system provides numerous conditional levels to determine whether the activities defined in a rule are to be carried out or not:

Variables

If you need to exchange additional data between the function assigned to a ruleset and the rules inside of the ruleset, you can extend the ruleset's signature by adding variables to it. You can use any of the data objects available in the application as variables. Inside of the ruleset, the variables are treated very much like context elements and can therefore be accessed by most of the context-related actions like Assign Value to Context or Initialize Context. The near relationship between context data and variables is also illustrated by the fact that for a ruleset, the Context Overview function displays not only the context data objects of the assigned functions but also the ruleset variables.

Deferred Ruleset Processing

As described above, you can define exit conditions for a ruleset that let you stop ruleset processing at a defined point in the process flow if a condition is fulfilled. The default behavior here is that all data changes that were applied during processing of the preceding rules are kept in the system, while any potential changes that would result from processing the remaining rules are of course missing. Depending on the circumstances of a given business case, this may lead to data inconsistencies.

To overcome this potential problem, you can define that a ruleset may be restarted at the point where processing stopped in a previous run. With this option set, you can continue an interrupted processing run, which helps you to complete the data changes that result from the rule processing. This is helpful in cases where the exit conditions that you define for a ruleset are likely to be fulfilled in your particular business case, that is, when a fulfilled exit condition is the rule rather than the exception.

To enable deferred ruleset processing for a BRFplus application, proceed as follows:

Once you have gone through these preparatory steps at application level, you can start using the additional features that are available for deferred ruleset processing. You can access these features in the BRFplus workbench in the form of additional settings for exit conditions in a ruleset.