Within a rule project you organize rule artifacts into rule packages. Any application may have several aspects: business function (pricing, scoring), geography, product, responsibility, and so on. As a best practice, you should use a simple rule package structure to capture one of these aspects, and use custom rule properties to map other aspects. Rule packages are also a useful way of preparing ruleflow tasks. Each rule package may correspond to a task.

Defining the Ruleset Execution Flow

The ruleflow defines the execution order of rule artifacts within the context of a larger decision. To the calling application, the ruleset is invoked to make a single business decision. However, that business decision may break down into a series of smaller decisions. There may also be a routing logic that determines the appropriate sequence of smaller decisions from a set of possible paths through the ruleset. Using a ruleflow, you identify the smaller decisions as tasks and the routing logic as transitions. The transitions between tasks can have a transition condition that must be true in order to move to the next task.

For example, if your decision is made of two activities, one for validating the information about the borrower and the requested loan, and another one for deciding whether the borrower is eligible for the loan, you can create two rule packages called validation and eligibility. You store the rules and other artifacts related to each activity in the corresponding rule package. When you create the ruleflow, you create two rule tasks, validation and eligibility, by dragging and dropping the packages into the ruleflow diagram. Between the two rule tasks, you define the transitions so that the eligibility rules are only executed when the data processed by the validation rules has been approved.

With properties set on a rule task, you can specify execution information, such as the algorithm to be used in the rule engine for executing the task.

Selecting and Extracting the Rule Artifacts for a Ruleset

Ruleset extraction uses queries to select rule artifacts for a ruleset.

For example, you can write a query that finds all business rules that have the status defined, as follows:

Find all business rules 
   such that the status of each business rule is defined

Then you use this query to define a ruleset extractor. When you extract the ruleset from the rule project, only the rules that have the status defined will be included in the ruleset.

When you extract a ruleset you create a ruleset archive. Each ruleset archive represents a complete decision implemented as rules in IRL, the BOM, and BOM to XOM mapping. In addition, if the XOM for the project is an XML schema, this is packaged into the ruleset archive.

Depending on your design, you decide how many rulesets you need to extract from one rule project. For example, if you know you can handle large rulesets, you can extract a single ruleset and specify mechanisms to dynamically select the rules of a ruleset at runtime. You specify this runtime rule selection in the ruleflow.

For example, you write the following runtime rule selection statement to make sure only the rules with the status defined are treated by the rule engine. These rules are in the ruleset however, and may be used in another rule task.

If you need to make sure the ruleset is small, for example to minimize parsing time or memory footprint, you can define several ruleset extractors in order to produce several rulesets from the same rule project.

Related Concepts

Related Tasks