This chapter describes implementing decision management in an IBM CICS integration scenario that is based on a messaging infrastructure that uses IBM WebSphere MQ. We review how business decisions are implemented, deployed, and executed within an IBM CICS Transaction Server for z/OS Value Unit Edition region. The scenario is basd on a loan approval process.

Many banks have CICS based core banking services, such as loan approval processes, that require real-time, nearly instant decisions. The competitive nature of the banking industry means that banks must quickly adapt to changes in the marketplace. This often poses challenges when business decisions are embedded in application code. Any changes take a long time and might cause a financial impact, especially during peak holiday seasons.

IBM Operational Decision Manager for z/OS enables a business to respond to real-time data with intelligent, automated decisions. IT and business users alike can manage the business decision logic that is used by operational systems within an organization. The business decisions are developed and deployed to a Decision Server that runs with the CICS JVM server. CICS based COBOL and PL/I applications can easily invoke the deployed decisions in CICS with the use of simple APIs. Business decisions are changed and deployed without the need for application changes. Using the Operational Decision Manager enables this type of loan processing solution to be highly agile, available, and scalable.

Table 9-1 shows how the use of IBM Operational Decision Manager server deployed in a CICS JVM server meets the major requirements of the loan processing project.

The key feature of running the Decision Server within the CICS JVM server is its availability across the sysplex. This enables CICS transactions to run in multiple application-owning regions (AORs) and to access the rules that are running in multiple rule-owning regions (RORs). This is illustrated in the high-level architecture for this project shown in Figure 9-1.

In Figure 9-1, you can see how multiple instances of the loan processing application can be running in AORs across the sysplex, with all of them processing messages from the same shared-request queue to maximize throughput by using a request-reply messaging pattern. The scenario consists of the loan processing request arriving from multiple channels in a shared queue. It triggers the loan processing CICS transaction in the AOR.

The loan processing transaction needs to call a decision service to determine loan eligibility. The decision service has been deployed in the Operational Decision Manager Decision Server in the CICS VUE region identified as an ROR. The transaction in the AOR dynamically routes the request to the ROR by using CICSPlex System Manager (SM) Workload Manager (WLM). The use of WLM allows the decision request to be routed dynamically to the ROR. This provides a highly available workload managed solution.

The configuration consists of a set of cloned CICS application-owning regions spread across two LPARs in a parallel sysplex environment. The configuration also consists of a set of cloned CICS rule-owning regions in zNALC LPARs. The CICS AORs share access to a request queue that is held in the coupling facility.

There were multiple phases in the implementation of a rule-based system for the bank:

The first phase consisted of harvesting , analysis, and design of rules. The eligibility rules are embedded in the IBM client’s CICS COBOL application. The application team and the business analysts worked together in this phase. A sample code snippet of eligibility rules is shown in Figure 9-2.

During the discovery phase, duplicate rules were found embedded in the application code. The business team validated the rules and worked in conjunction with the information technology (IT) team.

The existing program used a generic copybook for the entire application and was 5 KB long. The loan processing rules use only certain attributes to make a decision, and it is not a good practice to send unwanted data to the rules engine. A new copybook was built for the loan processing rule set. The COBOL copybook layout was designed for parameters to Operational Decision Manager.

The layout of the newly designed COBOL copybook is shown in Figure 9-3.

After the rules are designed, authoring is done through Rules Designer or Decision Center. The rules are then arranged in a rule flow to be exposed as a loan eligibility decision service. Business rules can be authored with any of these:

See “Authoring business rules” in the IBM Knowledge Center for a detailed explanation:

A sample of the “Minimum Credit Score” rule is shown in Figure 9-4. This is an example of an action rule.

After the rules are developed and packaged, they are arranged in a rule flow, as shown in Figure 9-5. This shows how a loan eligibility decision service is written.

The next step is testing the rule set to be sure that it gives the results that you expect. Decision Validation Services (DVS) are used for testing the accuracy of the rules. The tests are executed in either the Decision Center or Rule Designer, which provides added debugging capabilities. Test scenarios are built with input variables and expected results. A scenario represents the values of the input parameters of a rule set, which include the input data to rule set execution plus any expectations on the execution results that you want to test. The scenarios are built in a Microsoft Excel worksheet, as shown in Figure 9-6.

This section describes the runtime configuration.

This topology uses two different types of CICS regions to run rules:

The rule-owning region hosts a zRule Execution Server for z/OS instance that runs locally in a CICS JVM server. The application-owning region uses a CICS distributed program link (DPL) or WLM to run rules in a rule-owning region. The rule-owning region requires a Rule Execution Server console that runs in a separate address space from the CICS region and has a unique subsystem identifier (HBRSSID). A DB2 database provides the persistence layer. The rule-owning region must be run in CICS Transaction Server V4.2 or later. The application-owning region must be on CICS Transaction Server V3.2 or later. Figure 9-7 depicts the topology.

You can find a detailed CICS setup description for ROR and AOR in “Configuring topologies 2 and 3: CICS rule and application-owning regions” in the IBM Knowledge Center:

From a CICS TS infrastructure standpoint, the following tasks were completed to configure the topology:

A Rule Execution Server console is a started task on IBM z/OS, and there is only one console for the topology described. The Rule Execution Server console provides a web-based graphical interface that you use for managing and monitoring RuleApps, rule set archives, and Java execution object models (XOMs). It can also be used to monitor execution traces from the Decision Warehouse, test rule set execution, and view server information. Figure 9-8 on page 92 shows a screen capture of the Rule Execution Server console.

After the RuleApp is packaged, it is deployed to all of the zRES servers through the console. There are many ways to deploy the RuleApp. For additional documentation, see “Overview: Deployment options” in the IBM Operational Decision Manager section of the IBM Knowledge Center:

The next step is to integrate the rule execution within the CICS COBOL program. The existing code was remediated and an API call was introduced, as shown in Figure 9-9.

The benefit with the Operational Decision Manager approach is the agility. If the business rules are modified and deployed to the Decision Server, the piece of code remains the same.

Figure 9-10 shows the bank’s chosen implementation of the CICS AOR and ROR in a CICSPlex environment.

The configuration used in Figure 9-8 on page 92 consists of these components:

The use of Operational Decision Manager within a CICS JVM server with a queue-sharing group provides a scalable solution for loan processing and ensures maximum availability for planned and unplanned outages.