Introducing the Generic Ruleset Signature pattern for WebSphere Operational Decision Management V7.5, Part 1: A framework for achieving agility in rules projects

This two-part article series introduces the Generic Ruleset Signature pattern. This pattern can be applied to business rules in IBM® WebSphere® Operational Decision Management V7.5 to improve productivity and maintainability of rules projects using a flat business model. Part 1 presents a basic implementation of the pattern; Part 2 will present a more sophisticated, "battle-hardened" example used in real consultancy projects. This content is part of the IBM Business Process Management Journal.

Nigel T. Crowther (nigelcro@uk.ibm.com), Senior IT Consultant, IBM

Nigel Crowther photoNigel T. Crowther is a Senior IT Consultant in the IBM Software Services for WebSphere BPM Practice specializing in business rules. He has over 10 years experience in designing and developing business rules and business process management systems and 25 years experience in IT. Nigel has experience across all business sectors with his greatest focus on financial systems. Nigel joined IBM as part of the ILOG acquisition in 2009.



Kallol Ghosh (kallol.ghosh@uk.ibm.com), Solution Architect, IBM

Kallol Ghosh photoKallol Ghosh is a Solution Architect in the IBM Software Services for WebSphere BPM Practice. He has 20 years of IT experience in designing and developing systems, and has been working with business rules management systems for over 7 years. Kallol has worked in a wide variety of business sectors and joined IBM as part of the ILOG acquisition in 2009.



Jonathon Carr (jonathon.carr@uk.ibm.com), Staff IT Consultant, IBM

Jonathon Carr photoJonathon Carr is a Staff IT Consultant in the IBM Software Services for WebSphere BPM Practice specializing in business rules and visualization. Jonathon has over 10 years of experience in designing, building and documenting business rules and GUI applications. He joined IBM as part of the ILOG acquisition in 2009.



15 February 2012

Introduction

This article is intended for developers and architects embarking on rule projects requiring flexible ruleset parameters. It introduces a design pattern called the Generic Ruleset Signature pattern, or GRS.

GRS is based on a Java™ Map and supports flat attributes of native Java type. Using a Map allows flexibility in adding new parameters without changing the rule engine interface. This enables agile prototyping, maintenance and testing of rules.

A flat structure is one with no concept of hierarchy or relationship between attributes, as shown in Figure 1. The framework supports primitive wrapper classes such as Date, Integer, Float, Double, Decimal, Boolean and String.

Figure 1. Flat attributes
Flat attributes

When should the framework be used?

The framework works with business rules applications having a simple object model with flat attributes. It is particularly suited for situations in which:

  1. Attribute changes are frequent both during and after development.
  2. The business wants to add attributes.
  3. Rapid prototyping is required; for example, pre-sales activity or a pilot.

The table shown Figure 2 in helps the reader decide when to use the GRS XOM over the traditional XOM.

Figure 2. When to use GRS XOM over a traditional XOM
When to use GRS XOM over a traditional XOM

Framework advantages

The strengths of GRS are rapid development and ease of change. Specifically, some of the advantages of the GRS framework are as follows:

  • Projects can be developed quickly because there is no need to continually go back to the object model to add new attributes.
  • The interface is based on a Map, which does not change. Instead the objects within the Map change so the interface never changes and is compatible with all future projects using the framework.
  • Testing is easier, particularly with Decision Validation Services (DVS) because the test object model does not have to be regenerated whenever attributes are added.

Framework disadvantages

Some of the disadvantages of the GRS framework are as follows:

  • The framework is only capable of handling native Java types.
  • The built-in refactoring features of WebSphere Operational Decision Management (hereafter Decision Management) do not come into play.
  • In its raw form, the framework is only suitable for the stateless sequential algorithm.
  • The compiler can't check whether you've passed in the right parameters with the right type. This can lead to runtime errors. This limitation will be addressed in Part 2 of this series.

An overview of the GRS pattern

Traditional business object models (BOMs) translate to concrete Java classes or XSDs, as shown in Figure 3.

Figure 3. Conventional object model
Conventional object model

The GRS parameter extends a Java Map, as shown in Figure 4. Parameters are now generic in that any primitive wrapper class can be placed in the Map using BOM verbalisation.

Figure 4. Generic object model
Generic object model

Java syntax

The Map contains one or more key/value pairs. The key is the name of the parameter and the value is the content. A Java Map is created using the following syntax:
java.util.Map params = new java.util.HashMap();

To store a parameter stockName containing IBM in the map, the syntax is:
params.put("stockName", "IBM");

To extract the same parameter from the map, the syntax is:
String stockName = (String)params.get("stockName");

Rule syntax

In order to be used in business rules, the Java syntax is verbalized. To add a parameter to the verbalization, the syntax is:
set <parameter name> to <parameter value>

For example:
set "response" as "SELL";

To get a parameter from the map, the verbalization is:
get the <type> <parameter name>

For example:
get the string "stockName"

You can add other primitive wrapper classes, such as Integer, Float and Date. For example, to set or get an Integer use the following verbalizations:
set "price" to 312
get the integer "price"

Calling sequence

Figure 5 shows the calling sequence between client, business rule, BOM and XOM.

Figure 5. Calling sequence
Calling sequence

The sequence for setting and getting parameters is as follows:

  1. The Java client sets the parameter stockName to IBM.
  2. In Decision Management a business rule gets stockName using BAL verbalization.
  3. The BAL translates to the Java Map implementation.
  4. In Decision Management a business rule sets response using BAL verbalization.
  5. The BAL translates to the Java Map implementation.
  6. The client gets response.

Implementing the GRS pattern

This section is a step-by-step guide to how to implement a GRS pattern in WebSphere Operation Decision Management. It uses an example called ShareTrader, which is included for download with this article. The example takes as input a stock symbol and its output is a decision as to whether the stock should be sold.

  1. Open Rule Designer and create a Standard Rule project with no BOM called ShareTrader.
  2. Create a Generic Parameter Map by doing the following:
    • In the Rule Explorer window, right-click the shareTrader project and select properties => Ruleset Parameters.
    • Click Add and create an input/output parameter called params with a type of Map.
    • Initialize the Map in the Default Value section. There is no verbalization. See Figure 6.
      Figure 6. Defining a Generic Parameter Map
      Defining a Generic Parameter Map
  3. Now create a BOM wrapper over the Java Map. To do this, right-click bom in the Rule Explorer and select New => BOM Entry. In the New BOM Entry dialog, shown in Figure 7, leave the default name as model, select Create an empty BOM entry, and click Finish.
    Figure 7. Create a new BOM
    Creaccdr1te a new BOM
  4. The wrapper is implemented as a virtual BOM class called Parameters. To create this virtual class, double-click the model you created in the previous step. In the BOM Entry dialog, shown in Figure 8, click New Class.
    Figure 8. Define a new class
    Define a new class
  5. Give the class the name Parameters and click Finish, as shown in Figure 9.
    Figure 9. Define the BOM class mame
    Define the BOM class name
  6. Double-click the class you just created to open its details. Under BOM to XOM Mapping specify an execution name of java.lang.Object, as shown in Figure 10.
    Figure 10. Define the Execution Name
    Define the Execution Name
  7. Now add the getter and setter methods on the class as follows:
    • Under the Members section in the Parameters class, click New, as shown in Figure 11.
      Figure 11. Create a new member
      Create a new member
    • Create a method called getString that takes a String parameter called paramName and returns a String, as shown in Figure 12.
      Figure 12. Create a getString method
      Create a getString method
  8. To define the method implementation, do the following:
    • Double-click the method created in the previous step to edit it.
    • Check Static and Final
    • Under Member Verbalization, set the Template to: get the string {0}.
    • In the BOM to XOM Mapping section, enter the following code:
      java.util.Map params = (java.util.Map)getParameterValue("params");
      return (String)params.get(paramName);
      Figure 13 shows the complete implementation of the getString method.
      Figure 13. Complete getString implementation
      Complete getString implementation
  9. Now create the other method called setString.
    • Specify void for the type.
    • Check Static and Final.
    • Under Arguments, add two String parameters: paramName and paramValue.
    • Under Member Verbalization, set the Template to: set {0} as {1}
    • In the BOM to XOM Mapping section enter the following code:
      java.util.Map params =(java.util.Map)getParameterValue("params");
      params.put(paramName, paramValue);
    Figure 14 shows the complete implementation of the setString method.
    Figure 14. Complete setString implementation
    Complete setString implementation
  10. Create a business rule called Sell as follows:
    • In the Rule Explorer, right-click Rules folder and select New => Action Rule.
    • Name the rule Sell with the following content:
      Listing 1. Sell rule
      Definitions
      set stockName to get the string "stockName";
      if stockName is “IBM” then
         set "response" as "SELL " + stockName;
         print get string "response";
  11. To run the shareTrader project from Rule Studio, do the following:
    • Select Run Configurations and right-click Rule Project, then select New.
    • For Project, select ShareTrader, and click Apply, as shown in Figure 15.
      Figure 15. Run configurations
      Run configurations
    • On the Parameters & Arguments tab, select Function Body and specify the following code for the params parameter:
      Listing 2. stockName parameter
      java.util.Map parameters = new java.util.HashMap();
      parameters.put("stockName", "IBM");
      return parameters;
    • Click OK and then Run. The Sell rule should fire and the output should be SELL IBM.

Congratulations! You have successfully implemented a generic ruleset signature pattern!


Next steps

At this point you have mastered a basic implementation of the GRS pattern. The limitation of this framework is that there is no compile or run-time checking. In Part 2, we'll address this limitation by using the new Excel dynamic domain feature of WebSphere Operational Decision Management. We'll also discuss how to test with Decision Validation Services (DVS) and invoke via Hosted Transparent Decision Services (HTDS).


Download

DescriptionNameSize
ShareTrader project sampleShareTrader.zip4KB

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Business process management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Business process management, WebSphere
ArticleID=792956
ArticleTitle=Introducing the Generic Ruleset Signature pattern for WebSphere Operational Decision Management V7.5, Part 1: A framework for achieving agility in rules projects
publish-date=02152012