Dynamic Decision Glossaries

OpenRules decisions use business glossaries that are usually presented in Excel tables that may look like this table “glossary”:

The column “Variable Name” refers to decision variables mentioned in all rules (decision tables) under these names (any combination of words in plain English). The column “Business Concepts” refers to business concepts, to which the variables belong. Business users do not worry about how these concepts are defined – the same decision should continue to work in the same way independently whether these concepts are associated with Java objects or with Excel Data tables (used for testing). The column “Attributes” specify technical names of the attributes that represent variable names (no spaces allowed). For example, attributes may correspond to members of Java classes associated with business concepts.

The objective of this post is to explain the use of the OpenRules Glossary API for more complex practical situations. In large, real-world projects the actual content of business concepts such as the above “Customer” can be defined in external applications using Java-based Business Object Models or they may come from XML files, a database table, etc. The list of attributes inside business objects can be very large and/or to be defined dynamically.

In such cases, you do not want to repeat all attributes in your Excel-based glossary and then worry about keeping the glossary synchronized with an IT implementation. However, it is possible to programmatically define/extend the definition of the Glossary. For example, we may leave in the Excel’s glossary only statically defined business concepts and their decision variables, e.g. in the above table we may keep only the variables of the concept “Response” and remove all rows related to the concept “Customer”. Then in the Java module that creates an object “decision” of the predefined type Decision we may add the following code:

Decision decision = new Decision(fileName);
String[] attributes = getCustomerAttributes();
String businessConcept = “Customer”;
for (int i = 0; i < attributes.length; i++) {
      String varName = attributes[i].getName();

decision.put(“customer”, customer);

Here we assume that the method getCustomerAttributes() returns the names of attributes defined in the class Customer. The variable name and the attribute name are the same for simplicity – of course you may defined them differently.

You may add multiple concepts to the Glossary in a similar way. In  all cases keep in mind that the table “Glossary glossary” always has to be present in your Excel repository even when it contain no rows. You also may find that the same method “put(varName, businessConcept, attributeName)” of the class Glossary is used in the Glossary Template definition in the standard file “DecisionTemplates.xls”.


About jacobfeldman

CTO at www.openrules.com http://www.linkedin.com/in/jacobfeldmanopenrules
This entry was posted in Decision Management, OpenRules Specific and tagged , . Bookmark the permalink.

4 Responses to Dynamic Decision Glossaries

  1. Mahnaz Ebrahimi says:

    I have a question about this topic
    How we can define aggregated data type in excel
    for example I want to map “deposit.customer.customerName” by “Customer Name” variabale in glossary. I have Customer object inside of Deposit Object.
    When I try to do this, I get this exception
    ERROR in Glossary: cannot find property for object hello.Deposit@19ce47a

  2. jacobfeldman says:

    In general, the business(!) glossary should represent only those decision variables that are actually used in decision tables. The glossary is supposed to be created by business analysts and used by developers for mapping to the actual business object model (BOM). So, you do not want business people to be overloaded with details of the actual BOM with all O-O principles or, even worse, with an actual data model as defined in a database. You certainly do not want to publish internal details of your BOM implementation inside Excel – one of the worse approach I’ve seen occurred when developers tried to use a very complex ACORD XML schema (an insurance standard) directly in their business rules. They ended up with absolutely unreadable names that had 5 and more dots inside. Then maintenance of such “business” rules becomes a nightmare.

    Solution? You always may create an intermediate Java interface(s) that fits your glossary. All nesting issues can be easily resolved when you map your actual objects to the interface objects. However, if you have only 2-3 levels of nesting and do not want to bother with intermediate interfaces, you still may want to use nested names directly in glossary (but not in rules). The oncoming release 6.2.3 will allow you to do exactly that. For example, if your Java class Customer has an attribute “spouse” of the same type Customer, you may simply write in the glossary:

    glossary with nested attributes

    Then you may use the variable “Spouse Name” exactly as all other variables. Our support will send you a beta release with this feature being implemented. Of course, if somebody else is interested to try it now, simply send an request to support@openrules.com.

  3. Yavana Prakash G says:

    Hi, I am trying this nested option with your sandbox, should it work as expected, or has it not been released yet ? Also the above example mentions that spouse is of type Customer. What if its of a different type(contact.phone), will it still work?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s