This article describes a design that distributes BRMS projects in three layers, with projects in each layer depending on those in the previous layer, which enables sharing of rules and vocabularies across the layers.
In this design, projects are distributed across the following three layers:
- Base layer: Extends the default vocabulary provided by the BRMS.
- Functional layer: Defines the vocabulary of each functional area, and the adjacent rules grouped by topic and by authors' role (access rights) to partition the authors' work.
- Orchestration layer: Defines the rules-based decision services.
This design uses three powerful standard features of IBM ODM:
- Merging of rules folders
- Folders with the same name defined in two related BRMS projects are seen in the child project as a single folder, merging their content.
- (available in the enterprise console, but not yet in the business
One or more categories can be associated with vocabulary items and with rules, in order to filter the visible vocabulary when editing a rule, and to filter rules in queries (see below).
- (available in the enterprise console, but not yet in the business
console). Queries are the basis of many filtering capabilities
available in ODM, including:
- Smart folders configured for displaying rules in the enterprise console of Decision Center
- Extractors defined for filtering rules to deploy in a ruleset
The following sections describe the contents of those three layers and provide example customer contexts that are different in nature but similar in their ambition to set up a generalized BRMS. For simplicity, it is assumed than an existing decision service is tied to a single ruleset. The decision service and rulest therefore work interchangeably in the following chapters.
Figure 1 shows the distribution of the rules projects across the three layers.
Figure 1. Distribution of BRMS projects in three layers
Figure 2. Legend
Common vocabulary project (first layer)
This section treats the problem of sharing vocabulary between different decision services. The root project should be seen as an extension of the generic vocabulary provided by ODM (the default shipped Business Object Model (BOM)). You can define the following:
- Extensions of the core types, such as class
- Utility IRL (ILOG Rule Language) functions and their associated
vocabularies defined in a dedicated class
Util. This may be, for example, to determine the maximum or minimum of two numbers, the rounded or absolute value of a number, the number of days, months, or years between two dates, and so on.
- A base class
Propertiesto dynamically create and evaluate new data in the rules. For example, in order to estimate the relevance of new data through simulation tests, before requesting integration into the workflow of the system information.
- Vocabulary items specific to the company but common to all functional areas, such as dynamic domains related to the corporate repository.
It's also possible to define part of the business vocabulary, but this is limited by the fact that the part of the business vocabulary could not reference the business vocabulary defined in the next layer, the functional layer.
Projects of a functional area (second layer)
This section treats the problem of sharing vocabulary and rules between different decision services.
Splitting and filtering the vocabulary
A functional area is characterized by a specific business vocabulary and a dedicated team of rules writers. Each term has only one meaning. A decision service may have to use only a part of the vocabulary of its functional area. To restrict editing rules to this part of the vocabulary, the solution is:
- To create in each vocabulary project a category by ruleset (Figure 3).
- To associate items of vocabulary with the right categories. The items of the vocabulary used by all decision services of the functional area are not of concern (Figure 4).
- To associate each rule with the right categories. This is facilitated using rule templates (available in the enterprise console, not yet in the business console) defined in the vocabulary project (Figure 5).
This filtering mechanism is further reduced as the functional domain is specialized.
An alternative is to split the vocabulary of a functional domain into several projects. However, this solution is limited as data references are possible only to the data of a parent project, not to a child project or a sibling project.
Figure 3. Create categories in Rule Designer
Figure 4. Apply categories to specific business items in Rule Designer
Figure 5. Apply categories to specific rules in Decision Center
Enriching the vocabulary
The functional vocabulary can be enriched by relationships or additional data, such as using virtual shortcuts using existing relationships and data to hide their paths, and thus make easier to write rules.
Avoid the use of automatic variables, which may make sense for some decision services, but not for others.
The functional vocabulary must be extended to allow it to be tested in Decision Center:
- Each list for which you want to compare an expected result must be split into a virtual sorted list not visible from the rules, so that sorting is not exercised when running in production.
- Each list of heterogeneous objects as input should be split into virtual lists of homogeneous objects not visible from the rules, to be driven by test scenarios.
Splitting and filtering the rules
This section is treats the problem of organizing the rules to facilitate the rules governance.
For each functional area, the rules on the same topic and under the same right of access (role) are combined in a single project in order to facilitate the set-up of roles in Decision Center, and to allow rules sharing between decision services.
It is tempting to group the rules in as many folders as services, with shared rules being placed in common directories. However, the inclusion of new services using some of these rules requires a reorganization of the shared directories, plus a combinatorial growing of them.
Instead, it's is recommended:
- To allocate the rules in as many folders as decision points (rule tasks), so they can be used by one or more rule flows, in one or more rulesets.
- To associate each rule with the categories of the rulesets that it operates on, in order to be able to deploy the relevant rules of each ruleset (see Orchestration projects (third layer)).
- To set a smart folder for each decision service, by assigning it the name of the ruleset and associating it with a query to filter the rules according to the ruleset category (Figure 6). This allows the author to concentrate only on the rules of the ruleset.
Figure 6. Smart folders
- Default smart folder of all rules
- Smart folder defined with the query :
Find all business rules such that each business rule uses the category "eligibility"
- Smart folder defined with the query :
Find all business rules such that each business rule usesthecategory "loanTerms"
Orchestration projects (third layer)
This section is treats the problem of orchestrating into decision services the rules defined in the previous layer.
Local BOM for the ruleset parameters
Each orchestration project defines the elements of a ruleset, including the ruleset parameters. This data is encapsulated in an input entity called Request and an output entity called Reply, and is particularly adapted to technical service interfaces as WSDL.
Figure 7. Ruleset parameters in Rule Designer
To allow the execution of a ruleset in transation processing mode and batch
mode, for example for mass simulation, it's actually better to encapsulate
the data respectively in two entities called
themselves grouped in a table respectively in the
Reply entities. The main rule flow iterates on these tables
to allow the rules to treat each item of data one by one.
Figure 8. Local BOM in Rule Designer
The rules in the functional area projects (second layer) do not see the ruleset parameters defined in the orchestration projects (third layer). The solution is to insert the encapsulated data in working memory at the beginning of each iteration, retracting it just before the next iteration.
The use of global variables is not a suitable alternative because they are visible from all the rules, without any filtering, even though they are specific to a ruleset.
The association of the ruleflows of the orchestration projects with the rules of the projects of the functional areas that they depend on is automatic through the association of their rule tasks with the local folders of rules. Indeed, these folders locally defined as empty, merge with the same named folders from the projects of the functional areas.
In order to facilitate governance by reducing the number of projects to maintain, orchestration projects can be merged as soon as they share the same ruleset parameters. Their ruleflows can then be orchestrated by a main ruleflow. Such a merger makes even more sense when the two ruleflows have common steps. If they do not, this merger is purely technical and therefore may confuse users.
Branches and baselines
The branches and the baselines are created from the orchestration projects, and propagated to the projects they depend on. They have to incorporate the suites of tests consistent with the ruleset parameters in order to share the same branch with the rules and thus be consistent with the versions of the rules.
Warning: The use of deployment baselines is not compatible with the use of the branches because the definition of a ruleset is frozen as soon as a deployment baseline is created, thus preventing it from associating with another branch.
Tests suites and rulesets
The test suites are triggered from an orchestration project using an extractor defined on a query identical to that defined in a smart folder (Figure 6). Unfortunately, the same query cannot be shared because the one defined in a smart folder is internal. Thus, only the rules of a ruleset, or a functional subset of these rules, are tested by adding a filter on folders to the query.
First, create a query selecting a subset of rules.
Figure 9. Creation of a query in Decision Center
Next associate this query with a new extractor.
Figure 10. Query of an extractor in Decision Center
The extractor can be used by a test suite definition.
Figure 11. Extractor of a test suite in Decision Center
Note that the extractor can be reused to associate the definition of a ruleset with the rules to deploy, as shown in Figure 12.
Figure 12. Extractor of a ruleset in Decision Center
This section provides example customer contexts that are different in nature but similar in their goal of setting up a generalized BRMS.
Insurance quote services
This example implements services in residential and vehicle insurance quotes (two topics), ensuring greater responsiveness to the market, including car insurance.
Figure 13 shows the schema of the rule projects split in three layers.
Figure 13. Insurance quote repository
The rulesets Car and Van share the same orchestration project because they have the same ruleset parameters and the same ruleflow. But the rulesets are separated because they have different life cycles, and therefore different deployment. This is also true for the rulesets Moto and Cyclo. All of them share eligibility rules from the second layer (same topic). The ruleset Home has a specific ruleflow and does not share any rules with the other rulesets (separate topic).
Most of the vocabulary is common to all those rules, except the Vehicle entity and the Property entity, and is filtered using categories.
Various insurance services
This example implements services, some of which relate to the Property and Casualty (P&C) domain and the other to the legal field (two functional areas).
Figure 14 shows the schema of the rule projects split in three layers.
Figure 14. Various insurance services
As see in Figure 14:
- One service for Legal Protection is identified.
- One service for Risk Acceptance is identified.
- Three services for Car quotation are identified: Enrichment, Pricing
and Valuation (concatenation of the previous ones). These services
trigger the same ruleset whose the ruleflow chained rules enrichment
or rules of pricing as appropriate.
Enrichment and Valuation services have the same input parameters, and Pricing and Valuation services have the same output parameters. These parameters are unified in the ruleset and informed as appropriate.
Product recommendation service
This example implements a product recommendation service during a customer contact, and the granting of a product upon receipt of the contract signed by the customer service. What does it mean the granting of a product? Is it shipped/downloaded? Or is it the granting of a product license? Target: ODM 8.0.1.
Categories are used in the functional vocabulary because some data used by the ruleset Grant are not indicated for the ruleset Recos. The authors of rules are common to two rulesets. These two rulesets share some rules but do not have the same deployment cycle or the same parameters.
Figure 15. Product recommendation service
You've seen that the IBM ODM categories feature is simple to implement and provides many services. Because it facilitates sharing of vocabulary and rules between rulesets and reducing the number of projects to define and manage, the categories feature is the foundation of for the proposed organization of business rules repositories into three layers. You have also seen that queries are needed to select the rules to work on among all the shared rules. The most important thing is that such a design is based on the capacity of ODM to merge folders with the same name in inherited rule projects.
Defining the rules and vocabularies in rule projects split in three layers of dependencies is a simple and sytematic way to prepare the future expansion of business rules technology in your organization.
- BPM Voices: Organize your rule projects for flexible rule valisation: The author shows that project organization is key to supporting complex rule testing activities using IBM Operational Decision Manager Decision Validation Services (DVS). This pattern is useful if the branching capabilities of ODM are not used in rules governance.
- Governing Operational Decisions in an Enterprise Scalable Way, IBM Redbooks
- Mapping rule-based decision services to rulesets: The author addresses a recurring question for the solution architect using a BRMS: how should I structure the rule repository and then carve out the rulesets from this repository in order to support the needed rule services? We explore different alternatives for mapping the rule repository and the rulesets to rule services, and provide the pros and cons of each approach. We then illustrate the use of one alternative for the design of a risk assessment decision service, typically occurring in financial services type of applications.
- Iterating over Input Parameters: The author explains how to iterate over a collection accessible from an input parameter.
- IBM BPM Journal: Get the latest articles and columns on BPM solutions in this quarterly journal.
- developerWorks BPM zone: Get the latest technical resources on IBM BPM solutions, including downloads, demos, articles, tutorials, events, webcasts, and more.
- IBM Software Services for WebSphere: Find out how IBM expertise in cutting-edge and proven technologies can help you achieve your business and IT goals.