This article has been authored by Pierre Feillet, one of the lead IBM ODM Product architects. The article is designed for Rule Architects and Developers.

Introduction

IBM Operational Decision Manager (IBM ODM) is a rule based decision management platform with capability to provide decision services for applications and processes to improve solution agility, governance, re-use and automation. It also empowers business analysts and IT to author and deploy rule-based decision services across distributed Unix, Windows, Cloud and z/OS environments. The same business rules can be authored, tested, deployed, and integrated to be run on these platforms.
Businesses can derive value in authoring their business logic once and invoking it from different applications and processes. Let’s consider an insurance company with multiple underwriting applications, one for online quotes and the other for renewals and updates to policies. They may have eligibility, risk and pricing decision services to support the processes. In some cases these applications may be deployed to different platforms. As the business policy is defined once in the company, the decision services can be implemented and deployed across the platforms to meet the different application needs. To demonstrate such different application implementations might be:

• Online quoting application is implemented as a application running on J2EE platform with ODM decisions implemented as a dynamic web service with both hosted in a distributed environment
• Policy Renewals and Updates application is implemented on z/OS and decisions are hosted in ODM Decision Server for z/OS. The quoting application uses a COBOL program to read the applicant’s data also stored centrally on z/OS and invokes the same eligibility and pricing decisions.

In this short article, we will present the best practices and precautions to take to deliver this decision automation portability.

Creating business models based on COBOL, Java, or XSD

Business modeling in IBM ODM remains the very same whatever method of decision service invocation is performed in batch or transactional mode.. Although there are different eXecutable Object Models like COBOL copybook, Java classes, or XSD which are imported in ODM Rule Designer they are transformed into a Business Object Model (BOM) which is interface neutral that will be verbalized to support the authoring of the business rules.

At run time, COBOL or XML data, or Java objects will flow as parameters that are passed to the decision service to support decision making and have to fit with the rules.
But these various languages have different levels in data expressiveness and type modeling capabilities. The concept of inheritance, for example, exists in Java but not in COBOL. Based on the chosen eXecutable Object Model and its language, IBM ODM builds the best Business Object Model possible, and gives the possibility to extend or reduce classes and fields.
From COBOL and PLI applications, ODM zRule Execution Server (zRES) for z/OS executes decision services that rely internally on a Java eXecutable Object Model. These Java classes can be

• generated in Rule Designer from a COBOL or PLI data definition
• developed and brought as primary executable model to run the rules. In this case, you will deduce the COBOL and PLI data definitions from the Java XOM.

XSD eXecutable Object Model allows invocations from Java and from any Web Service client but not through the zRES stub.

Recommendation 1 – Check the COBOL to Java model generation and reverse

When targeting a portable decision service, it is recommended that you review the Java XOM generated from COBOL, or the COBOL copybook generated from the Java XOM.
Invoking the same business rules by passing COBOL data or Java objects implies that the service signature meets IT compliance in both languages.
So before writing rules, you should check that the COBOL and Java signatures fit with your data needs to automate the decision, and are natural in their language on both z/OS and distributed. Such an early check avoids refactoring costs in the models and rules if a change occurs later in the project.
If there are mismatches in typed parameters the following information in ODM v8.7.1 product documentation about COBOL and Java typed parameters may help

Recommendation 2 – Scope the decision service signature

A set of typed parameters that are passed to make the decision is necessary to support the business logic. It is recommended to cut any heavy and unnecessary parts of the eXecutable Object Model and Business Object Model. It provides the least complexity in business rule authoring, and reduces the service signature that is invoked in the various environments and languages, thus helping cross platform portability.

Recommendation 3 – Do not use external callouts

A decision service logic has to rely exclusively on its parameters to be portable across environments. IBM ODM allows you in the middle of rule based decisions to call subsystems from the rules but with some dependency.. Although it is possible to call a COBOL subprogram through JCICS from business rules that are executed in CICS this is limited to only working on a mainframe environment and it definitely does not work on distributed environments like Linux or Windows.
A reverse example consists in a decision service that runs in WebSphere Application Server on distributed Linux or Windows environment and in calling JEE services deployed in the application server classpath. As these JEE services are not accessible from the eXecutable Object Model deployed in zRule Execution Server (zRES) for z/OS, the decision service will be tightly coupled with the platform and so will miss the portability.
So we recommend designing for portability and not using external callouts for re-useable decision services.

Conclusion

In short, the recommendations to make cross-platform decision services with IBM ODM are to:

• chose to start from COBOL, PLI data definition, or Java classes for your eXecutable Object Model but not from an XSD if you target to execute in Rule Execution Server on z/OS
• check early in the project the generated COBOL copybook or Java classes based on your original executable model. You will detect early in the process if the decision service signature is cross platform compliant and types are supported across both COBOL and Java
• tailor the service signature to decision making needs. Don’t keep too large models that would be harder to make portable across z/OS and distributed
• prefer decision services which pass and provide all needed data as parameters as inputs or outputs and don’t call external platform-specific subsystems from the rules

Author rules once. Deploy and run decisions everywhere.
Useful Links
Developing Business Rules based decisions on ODM for z/OS V8.7.1