The latest OpenRules Release 8.0.0 comes with a new, very simple Java API for incorporation of business decision models created by business people in Excel into Java applications. It corresponds to the simple view of a decision model as “a Business Glossary surrounded by Decision Tables that specify decision logic for Goals and Sub-Goals“. OpenRules 8.0.0 explicitly introduced Java concepts “DecisionModel” and  “Goal” to support the Goal-Oriented Decision Modeling approach described in this book.

Here is what you should usually do to invoke a decision model from Java:

• Create an instance of the class DecisionModel, e.g.
  DecisionModel model = new DecisionModel(“file:rules/Goals.xls”);
• Ask the model to create an instance of the class Goal, e.g.
  Goal goal = model.createGoal(“Vacations Days”); 
• Direct the goal to use your own business objects, e.g.
  goal.use(“Employee”,employee);
• Execute the goal using the standard Goal’s method
  goal.execute();

Let’s consider the standard decision model “VacationDays” described here. This decision model consists of the glossary surrounded by 4 decision tables:

When we built this model, OpenRules BRDMS automatically generated the file “rules/Goals.xls” that contains the execution path for this model (it defines which goals and sub-goals should be executed in which order). We can use the following Java snippet to invoke this decision model from a Java application:
———————————————————————————————–
DecisionModel model = new DecisionModel(“file:rules/Goals.xls”);
Goal goal = model.createGoal(“Vacation Days”);
goal.put(“FEEL”,”On”);
Employee employee = new Employee();
employee.setId(“Robinson”);
employee.setAge(57);
employee.setService(30);
goal.use(“Employee”, employee);
goal.execute();
model.log(“Results: ” + employee);
———————————————————————————————–
Now, we even don’t need to define an Excel table of the type “DecisionObject” that was required in previous releases.

If you build the same decision model using the new OpenRules Decision Manager, the invocation interface will look very similar:

———————————————————————————————–
DecisionModel model = new DecisionModelVacationDays();
Goal goal = model.createGoal(“Vacation Days”);
Employee employee = new Employee();
employee.setId(“Robinson”);
employee.setAge(57);
employee.setService(30);
goal.use(“Employee”, employee);
goal.execute();
model.log(“Results: ” + employee);
———————————————————————————————–

Note that this API uses the already generated Java class DecisionModelVacationDays. It means with Decision Manager you don’t need to access the Excel files in run-time anymore. Our Java application doesn’t need to know that this model is using FEEL as the generated class is already aware of this fact. So, we omitted goal.put(“FEEL”,”On”) as well. Everything else is the same.

Thus, both the traditional OpenRules Engine and the new Decision Manager can use the same business decision model as its input. They both can execute it using a very similar API while the internal execution mechanisms are quite different. The model’s designers don’t care about the execution mechanism as both tools report all explanations and possible errors in the same business terms that were used in Excel. In particular, when the Decision Manager generates Java code based on Excel tables, it saves all information about the original locations to report them later on by pointing to Excel files, sheets, and cells inside them. A user should never even look at the generated code, but it opens tremendous opportunities for the decision service deployment.

Hope, our customers will find the new OpenRules API to be very simple and intuitive while providing them with new valuable options.