Populating Decision Tables with external data sources
One of the most used artifacts in IBM ODM is the decision table. In this post I will show how to populate your Decision Table in the Rule Designer with external data sources like a .txt file or an excel spreadsheet. Business users can have their logic in multiple sources (mostly in Excel files), that they need to dump in a decision table to create rules and business logic behavior in IBM ODM. We are going to achieve this by using a combination of Java, Ant builds and ilog rule designer-plug ins embedded in our suite. This is a very technical tutorial and it might be a little difficult to get it done quickly but feel free to contact me with any problems or if you get stuck at some point.
Steps:
- Setting up environment
- Create a new folder (in my case “dt-populate”) in your Rule project with a “data” subfolder and with an Ant Build file.
- Tip: You can also create and manage the ant and data configuration in a new external Java project.
- Create an environment variable ECLIPSE_HOME with the location of your IBM ODM installation.
- Insert the txt or the excel file with the data you want to import in the data folder. In my example I am using both, please have this considerations:
- Txt:
- Separate each cell of the decision table by the semicolon “;”.
- Separate each row of the decision table with a space.
- Excel:
- Separate each cell of the decision table in each excel cell starting in A1.
- Separate each row of the decision table in each excel row.
- Tip: Remember the version of Excel and the file extension because you will need it later on.
- Txt:
- Create a new folder (in my case “dt-populate”) in your Rule project with a “data” subfolder and with an Ant Build file.
- Creating the Ant Build file
- Add the project tag with a name, basedir and a default target attributes.
- Tip: For more about Ant Tasks review my previous post here.
- Inside the project tag we are going to add the properties, conditions, echo messages, definitions and our targets. For each of you will be different depending in your environment and ODM installation.
- Tip: Remember to change the values according to your workspace and installation folders.
- Now let’s add the definitions the includes the properties and connection parameters.
- Finally, we add the targets.
- Remember to change the values according to your environment and also review the excel file extension.
- Add the project tag with a name, basedir and a default target attributes.
- Running the Ant build file targets
- Right click the build.xml file and select Run As –> Ant build…
- Select the target you want, in this sample I will run the Excel file target, and click Run.
- You will see the console messages and at the end BUILD SUCCESSFUL.
- Right click the build.xml file and select Run As –> Ant build…
Results:
Now you can refresh and open your Decision Table and visualize all the values!
I hope you enjoy this tutorial, there are many more automation and integration to be done with Ant Tasks, please let me know what you wish to see next, and as always feel free to comment or contact me with any feedback or support! Thank you!
- Published in Ant Tasks, Decision Table, Java, Rule Authoring, Rule Designer
Connecting to external Database with ODM API
The IBM ODM Decision Center and the Rule Execution Server values are stored, by default, in a Derby database that comes with the IBM ODM suite installation. During a rules development project we sometimes need to access these values and insert them on an external database or update this external database accordingly. In this post I will show you how to connect to an external Datase with the ODM API in java and execute a simple query after collecting Decision Center values. You can use this method in your project with any values you need from the Decision Center.
To understand the basics of the ODM API, please refer to my previous post about the IBM ODM API here.
- Preparing Decision Center Values
- In our Java project make sure you can connect successfully to the Decision Center.
- Personalize the values you need from the Decision Center. For example the Rule project name:
- In our Java project make sure you can connect successfully to the Decision Center.
- Connecting to an External DB
- Let’s create a new Java class with the Connection details.
- It is a good practice to have the value of the connection datasource in a properties file.
- Create a getConnection() method in the DBConnection class and add the following structure:
- Return the con variable and call this method from the main ODM API java class:
- Let’s create a new Java class with the Connection details.
Now you are ready to execute any statement in the external DB using the Decision Center variables. Query statement sample: ps = con.prepareStatement(“INSERT INTO db.dt VALUES (‘”+ruleProject.getName())
I hope you enjoy this tutorial and please feel free to contact me with any query or feedback, thank you!
- Published in Debug, Decision Center, Decision Table, Java, ODM API, Rule Designer
Custom log file with ODM API
Given the positive feedback from previous post we will continue to work further on with the ODM API and discover new possibilities and features to implement in our Rule projects. In this tutorial we will see how to create a custom log file, focusing on obtaining the values from Deployments of Decision Services within the Business Console.
To understand the basics of the IBM ODM, please refer to my previous post about the IBM ODM API here.
- Creating a custom log file
- In our Java ODM API project let’s create a global variable to define the output file.
- Now create a constructor method to add the values you want in your custom log file. In this example we are obtaining the deployment time stamp when a business user deploys a Decision Service from the Business Console:
- Tip: Remember we need to throw an IOException class for our constructor.
- We can continue adding the values we require in our outfile variable. In this code example we are getting the following values:
- The timestamp an element changed (for example the deployment report)
- Who changed the element and who deployed it (business user who deploys the Decision Service)
- Rule project name
- Tip: Remember to format the log file with methods like newLine() and flush().
- Now we need to repackage and reinstall the teamserver.ear with our custom jar file and it will automatically start generating the log file when we make a Decision Service deployment. I will make a post explaining this process in detail in the future.
- In our Java ODM API project let’s create a global variable to define the output file.
If we did not specify an output location for the log file you will find it in <Your WAS Installation Path>\logs. I hope you enjoy this tutorial it helps you, please feel free to contact me with any feedback or questions! Thank you!
- Published in Decision Center, Java, ODM API, Rule Authoring, Rule Designer
Working with Lists in the XOM / BOM
The XOM (Execution Object Model) and BOM (Business Object Model) are key artifacts of our Rule project. The execution object model (XOM) is the model against which you run rules, it references the application objects and data, and is the base implementation of the business object model (BOM). For more information about XOM/BOM visit the IBM Knowledge Center here.
We can generate our BOM entries from a XOM (Java or XSD) and get the objects we will verbalize for our rules. A very common requirement in a project is to work with Lists and return a populated List with values from a Rule Action or Decision Table. You will notice that after you create your BOM entry from an XOM with Lists (maxOccurs=”unbounded”) you will get an object of type java.util.Vector but with no direct relationship between the elements. Please review the following problem example and a workaround on how to fix it and implement Lists correctly.
Problem:
Let’s say you have an XSD with an element like this:
<complexType name=”RecruitsList”>
<sequence>
<element name=”recruits” type=”tns:Recruit” maxOccurs=”unbounded” minOccurs=”0″></element>
</sequence>
</complexType>
After you create the BOM entry, you will get an object like this:
With no proper verbalization and without a way to use it in a Rule Action, Decision Table or Decision Tree correctly. In this example we want to add objects of type Recruit to our RecruitsList and display this list in the output of our Decision Service. Follow the steps below to implement a workaround and accomplish our goal.
Steps:
- Creating a new Method member
- Let’s remove this verbalization and navigate to the Class tab.
- We are going to create a new method to add our Objects. Click “New…” in the Members section.
- Select “Method”, give a proper Name and “void” for Type.
- Now add Arguments according to the Object you are going to add to your list, in our example the Recruit’s attributes. At the end you should have something like this:
- Tip: Remember that the types have to match, if you are using a virtual value assign the corresponding type like the example. For more information about dynamic domains and virtual values read my previous post here.
- Now we need to create a proper verbalization for our new method and implement the BOM to XOM Mapping logic.
- Navigate to the Member Verbalization section and click “Create”. Modify the Action phrase according to your Object. In this sample:
- The last and most important step is to define our BOM to XOM Mapping logic. We need to map our method arguments with the attributes of our Object, in this sample with the Recruit’s age, country, name and sex:
Tip: Don’t forget to initialize the response list variable in your ruleflow or variableSet.
Results:
Now we are ready to use our method in any Rule and return a list structure schema in our Decision Service response!
Decision Table demonstration sample:
After we test our rules we will see this list structure in the response (Testing with SoapUI):
Please feel free to comment or contact me with any doubts or feedback. Thank you!
- Published in Java, Rule Authoring, Rule Designer, Rule Execution Server (RES)
Debugging a simple Ruleflow in Rule Designer
There are many ways to test our rules, we can use Excel DVS testsuites, decision operations, web services applications like SoapUI and more, but sometimes we need to debug our ruleflow to find a particular bug that is preventing us to continue. When developing a new rule project in Rule Designer we often need to see the output of our rules without having to deploy our solution and see the behavior of the ruleflow to compare the variables values.
In this article I am going to show how to debug a simple ruleflow using a decision operation to test your Rules.
Steps:
Let’s assume we already have the ruleflow, variables and rules.
- Creating the Decision Operation
- Right click the “deployment” folder in your Rule Project and select New -> Decision Operation.
- Give a proper name, select the Rule Project and select the Ruleflow inside your Rule Project.
- Now open your Decision Operation and you should have one like this:
- Click “Define” or to the “Signature” tab.
- Expand your varible set and drag and drop the corresponding variables to the Input and Output Parameters.
- Tip: Is a good practice to name your input variable with “Request” at the end and “Response” for your output.
- Setting the breakpoints
- There a many places where we can define our breakpoints, it depends on what you need to test and where do you want the flow to stop execution. I will show some examples of places where you can put your breakpoints next.
- Action Rule:
- Open your Action Rule, right click in the gray space of any Action line and select “Toggle Breakpoint”
- Open your Action Rule, right click in the gray space of any Action line and select “Toggle Breakpoint”
- Decision Table:
- Open your Decision Table, right click in any cell of an Action column and select “Toggle Breakpoint”
- Open your Decision Table, right click in any cell of an Action column and select “Toggle Breakpoint”
- BOM member
- Open a BOM member with BOM to XOM mapping logic, locate the Setter code, right click in the gray space and select “Toggle Breakpoint”
- Open a BOM member with BOM to XOM mapping logic, locate the Setter code, right click in the gray space and select “Toggle Breakpoint”
- Ruleflow artifacts
- This is the most common way to debug our Rules, in the ruleflow you can add breakpoints to any task. Select any task, right click and select “Toggle Breakpoint”
- This is the most common way to debug our Rules, in the ruleflow you can add breakpoints to any task. Select any task, right click and select “Toggle Breakpoint”
- Creating the Debug Configuration
- Navigate to Run -> Debug Configurations… in your Rule Designer top bar.
- Locate the Decision Operation artifact, right click and select New.
- Give a proper name and Browse for your Decision Operation.
- Tip: The checkbox “Stop at first rule statement” guarantees you enter debug mode if you didn’t set any breakpoints.
- Now the most important step is to define the “Parameters and Arguments” for this configuration, select the tab and click “Edit Value”.
- You have to create and return a new object of your Input Parameter class, you can also assign testing values. Click “Function body” and add the proper code. Take a look at my sample:
- Click Apply and Debug.
Results:
Now you are in Debug mode, watch your variables and step through your code and rules!
I hope you enjoy this article, as always please feel free to contact me about any question or feedback. Thank you!
- Published in Debug, Decision Operation, Java, Rule Authoring, Rule Designer, Ruleflow