IBM Operational Decision Manager is one of the best products on the market for business rules because it allows you to author rules in the everyday language of your business and create rules that are "under business jurisdiction" (SBVR).
Rules authored in ODM Rule Designer and Decision Center often involve reference and master data. In this article I describe the different types of reference data used in authoring ODM rules, the features ODM provides, and propose domains and value editors using external sources as the choice to use.
Reference Data and ODM Rules
When considering ODM rules it is important to understand the different types of reference data that may be involved in a rule.
Flat Data
If you want to create a rule about a country, you will probably use a flat list of countries. For example, if you are using ISO 3166 Country Codes and the country is France, the English language name will be "France" and the value "FR" .
Such data is flat and non-hierarchical. When the data list is long, it is only usable in graphical interfaces with scrolling and filtering.
Hierarchical Data
If you want to create a rule involving cities, localities or streets, then you will need a more complex structure of hierarchical data.
A hierarchical structure of data can be both complex, involving many parent-child relationships, and extensive, running into hundreds and even thousands of values. You can find them in products, commodities, business organization and many other places.
Creating lookup mechanisms for these kinds of data can be very challenging as they may require filtering parameters, paging, scrolling, ordering and sorting, and tree navigations both in data access services and UI widgets.
ODM Features for using Reference Data
ODM offers three options for using reference data in rule authoring:
Option 1. Literals
The first option is to use literals. For example, a rule author could enter the free-text string value "FR" in the rule for the country France.
Literals can be used for both hierarchical and flat reference data. For example, you can enter "FR" and the value for Paris, for a rule where the country is France, and the city is Paris.
Limitations
- When using literals, the rule cannot be understood by business users and is difficult to validate.
- Free-text is inherently error prone when authoring rules due to the possibility of typing, or copy and paste errors.
- Using literals results in poor adoption of rule authoring in Decision Center.
- ODM tools do not work correctly when you use literals such as strings. For example, in a decision table the ODM Decision Center and Rule Designer editors cannot perform gap and overlap checks on values.
Option2. ODM Enumerated Domains
The second option is to use ODM Enumerated Domains.
A domain is useful in the case of short lists of flat data, such as a list of ISO3166 Country Codes. When the domain is created by a developer in the BOM, a rule author can pick an item from a complete ordered list of name-value pairs in a rule.
Types of Domains
An enumerated domain must be implemented by a developer in any of the following ways:
- Static Domains - created directly in the BOM from an enumeration of static references, or indirectly from a Java Enum or XSD enumerated type in the XOM.
- Dynamic Domains from Excel Spreadsheets - created using data stored in an Excel file and dynamically added to the BOM by the ODM Excel domain provider.
- Dynamic Domains from External Sources - created using data from an external source, such as a database or web service, and dynamically added to the BOM using code based on the ODM APIs.
Limitations
Enumerated domains are a good solution for short lists of flat reference data. When a domain is used in a decision table, the editor can enforce gap and overlap checks. However, they have some drawbacks:
- Static domains are a poor choice as the domain data must be hard coded in the BOM or the XOM by a developer. Changing them always has a maintenance overhead.
- Static domains created indirectly from the XOM result in fragile decision services when using Hosted Transparent Decision Services (HTDS). Adding an enumerated value in the XOM has the possibility of breaking service contracts with decision service consumers.
- Static and dynamic domains from Excel always duplicate reference data. Decision service consumers must duplicate the data as the consumer and the rules do not share the same data source.
- Domains cannot handle long lists of data or hierarchical data. They only provide half the reference data solution.
Option 3. Create ODM Value Editors
The third option is to use the ODM Value Editor feature.
A value editor is a custom UI Rule Designer and Decision Center graphical component, which a developer creates using code and ODM APIs. It is a good choice for long flat lists and structures of hierarchical reference data. A lookup mechanism for hierarchical data can be quite sophisticated, depending on the hierarchical structure of the reference data itself. A value editor, and the data access service behind it, should allow a rule author to not only navigate the entire structure, but also accept parameters to filter out the data to a branch of the reference tree.
Limitations
- Value editors are hard to implement. They always uses data from external sources and so must be integrated with web services and databases. You must create them for both Decision Center and Rule Designer and have a good understanding of technologies involved.
- Values created in rules are not enumerated, so gap and overlap checks cannot be enforced in decision tables.
The Right Choice
Implementing reference data in ODM can be challenging and the choices confusing. Using literals is quick and dirty. Using static or Excel domains duplicates data and provides only half the solution. All can result in unreliable execution.
The only sure route to success is to use dynamic domains from external sources and value editors.
Benefits
- External data provides a 'single source of truth' which, when used by both Decision Service consumers and providers, will ensure correct rule execution and decision outcomes.
- Only value editors can handle long lists of flat or hierarchical data.
- Both value editors and domains are a one time setup and, if correctly designed, relatively maintenance free. Changes to data can be handled by database administrators.
Implementing Domains from External Sources and Value Editors
ODM provides no single integrated and configurable way for handling reference data in rule authoring.
The ODM installation provides 2 separate samples for dynamic domains from external sources and value editors. The samples are duplicated for both Decision Center and Designer.
Each has a separate ANT build and little code re-use. To use the samples you need to have an in-depth understanding of the ODM APIs and of a variety of technologies, such as Eclipse Plugin development, JEE web application, javax.Swing, and the Dojo Toolkit.
If you base your approach using the samples, you will find development extremely challenging to near impossible when dealing with a large number of domains and value editors, and the results difficult to maintain.
An alternative solution is to use the Reference Data Starter Kit (RDSK) from ODM Accelerator which provides this missing piece of the ODM jigsaw puzzle with a single configurable ready-to-use solution to implement domains and value editors from external data in both Rule Designer and Decision Center. It does not require an understanding of the ODM Java APIs, Swing or Dojo. The only code required is plain old Java - the rest is done by configuration. It implements value editors with cascading select boxes.
Finally the kit allows you to create all your domains and value editors for both Rule Designer and Decision Center in three projects with a single Maven build.
You can then implement your domains in an ODM Virtual BOM, and link them and your value editors to the XOM and BOM using ODM Java annotations.
Conclusion
Here is a simple list of rules to consider when using reference data in your ODM projects.
Do
- Use dynamic domains from external sources and value editors. They will pay off in the long run with greater usability for rule authors, more accurate rule execution and reduced maintenance.
- Carry out analysis up-front to scope the project and understand the effort required. Identify all reference data and their sources that will be used in the project from the start.
- Take the hit at the beginning and set everything up as much as possible before rule authoring. You will get the benefit of both creating a factory process and future proofing your ODM implementations.
- Design and create a single solution for both domains and values editors that produces the Rule Designer Eclipse plugins and the Decision Center jars. You will avoid a piece-meal implementation that is difficult to maintain. Allow plenty of time.
- If access to the external data source is not available, or the data does not exist, create a temporary database as a tactical solution. You can easily migrate the data providers of your implementation at a later stage without affecting your rules.
Don't
- Use literals, static domains and dynamic domains from Excel spreadsheets. Literals are error prone. Static and dynamic domains duplicate data held elsewhere and are only half the solution.
- Use strings, double sets of domains, etc. as a workaround for hierarchical reference data. They are all highly error prone and result in resistance to Decision Center use by analysts, rule authors and business people. The problem becomes more extreme when using Decision Tables with hundreds of rows.
- Mix external with non-external reference data implementations, such as dynamic domains from excel spreadsheets and value editors, string literals and domains etc.
- Bury your head in the sand and pretend you do not have hierarchical reference data - you will have it in all but the simplest project, and if not, as your project grows, you will discover that you do.
- Start rule authoring with strings, and try migrating to external data later. You cannot begin rule authoring using strings and move to domains and value editors with external sources without re-writing all the rules.
About
Peter Warde has created the ODM Accelerator for IBM Operational Decision Manager - a collection of resources for designing and building richer, better, more maintainable and higher quality ODM rule applications.
If you like this article, you can read his other ODM articles:
You can also find this article on LinkedIn with viewer comments.
#OperationalDecisionManager(ODM)