Jun 1 ’09

Event Processing With CICS Transaction Server and WebSphere business Events

by Editor in z/Journal

IBM’s December 2008 release of CICS SupportPac CB11—CICS Events for WebSphere Business Events (WBE)—provides an introduction to the world of event processing with CICS Transaction Server for z/OS. (This SupportPac is available at no charge to all licensed users of the CICS family of products on the platforms specified in the SupportPac description, which is accessible at www- 01.ibm.com/support/docview.wss?rs=1 083&uid=swg24021039.)

This article documents an event processing scenario to illustrate an example of potential fraudulent activity in a banking environment. Account data is held in CICS TS V3.2 on the mainframe.

Events and Event Processing

Currently, an explosion in event volumes is taking place, driving the need for massive scale and speed to process these events. Upward of 72 quadrillion (1015) business events occur every day, nearly 4 trillion Radio Frequency Identification (RFID) events are emitted daily, and 190 billion emails are sent each day; each of these represents an event, and in many cases, CICS is involved in the event chain.

Simple event processing applies to single events; complex event processing applies to events that are generated by disparate resources. Business event processing, which CICS and WBE participate in, is the next generation of event processing. It extends complex event processing capabilities to the business user to define real-time, actionable event patterns in business terms for rapid response to opportunities and threats. An example of responding to an opportunity is identifying customer preferences and cross-selling additional products to these customers. An example of responding to a threat is the discovery of potential fraudulent activity associated with a personal banking account (see Figure 1).


CICS SupportPac CB11

This SupportPac introduces the concept of CICS as a source of events to WBE. When using CB11, you make a small change to your existing CICS business application to pass event details on a CICS channel to link to a program supplied with the SupportPac. Note that CICS TS 3.1, 3.2, or 4.1 is required.

CB11 transforms event information from CICS into XML that conforms to the WBE format. CB11 then emits the event for consumption by WBE (or other consumers) using the WebSphere MQ transport.

Scenario Overview

In this scenario, an event is caused by an account holder attempting to change his PIN number and incorrectly entering his current PIN number (see Figure 2). WBE ensures that if this “bad pin change” event occurs against the same account three times within a 24- hour period, then a “suspicious activity” action occurs. Upon receipt of a suspicious activity, two actions occur:

• A Web service request is sent to CICS to suspend the account.

• The account administrator receives an email with the account number of the potentially fraudulent activity.


Event Source

The event source in this scenario is an existing CICS COBOL application that processes PIN change requests. This application is equipped with a few extra statements to cause an event to be emitted each time an incorrect original PIN is entered during a PIN change request.

COBOL statements are used to set up the containers that CICS will populate and send to a CB11-supplied program, EPSEMIT; one name-value pair that represents the details associated with the event is sent. The code fragment in Figure 3 places the name “Bad_ Pin_Change” into the correct container to name the event.

The single name-value pair containing the details of the event will contain the string “AccountNumber” and an account number of “1234567890” which is hard-coded as the value of the account number for this scenario. In reality, this data would come from a variable used in the program, probably on an EXEC CICS command. Figure 4 shows the code fragment that populates these containers. The SupportPac also needs information regarding on which WebSphere MQ queue to place the outgoing event. This example uses a local (TYPE(QLOCAL)) queue called EP. TEST.EMITQ. This and the code fragment that does the actual link to the SupportPac are shown in Figure 5.

Conversion: SupportPac Processing

The SupportPac program EPSEMIT reads the containers the application sent and reformats the contents into XML. The SupportPac program uses the WebSphere MQ queue name provided by the CICS application, and the CICSWebSphere MQ bridge (supplied with CICS) is used to place the XML data on this queue.

Business Action: WBE The WBE server component is a WebSphere Application Server (WAS) application. WBE comes with two core tools. The “Design Data” tool is used to define external business systems (known as “touchpoints”) that will interact with WBE, as well as the data objects required, and the “Design” tool is used to define the business event rules, which describe what happens when events come into WBE and certain patterns are identified.

The Design Data tool to define a “Bad_Pin_Change” event under a “CICS over MQ” touchpoint is used and a single WBE “Intermediate Object” to represent the bank account is defined. When an event arrives at the WBE server, it is mapped to the “Bad_Pin_ Change” event by a WBE connector. WBE connectors pass data payloads between touchpoints and the Java Message Service (JMS) message topic the WBE run-time uses. Event connectors recognize an event in a touchpoint and pass data either directly or indirectly through protocols such as HTTP to an internal JMS topic for evaluation by a set of defined interaction policies.

WBE Actions and Connectors

This scenario uses the SOAP action connector and email action connector. The Design Data tool was designed to define a SOAP action connector to call a CICS Web service to suspend the account. Creating the SOAP action requires importing the Web Services Description Language (WSDL) that describes the CICS Web service into the Design Data tool and mapping the input to the Web service to the AccountNumber from your Intermediate Object field.

Email Action

In addition to suspending the account, WBE is instructed to send an email to the account manager indicating that a potential fraud has happened so appropriate action can be taken.

JavaScript in the action object field allows the account number to be copied from the account intermediate object to the body of the email. Figure 6 shows the JavaScript to add the account number to an email alert.

At this point, the actions that should occur in this sample scenario have been defined, but not when and under what circumstances these actions should occur. This is achieved by defining WBE filters and interaction sets.

Defining a Filter

In this scenario, it’s necessary to suspend an account if (and only if) there have already been two incorrect PINs entered in the last 24 hours. The Design tool is first used to add a new filter called “Two bad PIN changes already” to match as “true” after two “Bad_Pin_Change” events have occurred in the last 24 hours. Figure 7 shows a WBE filter to record two bad PIN changes.

Defining an Interaction Set

Now we want to invoke two actions if three bad PIN changes are attempted within a 24-hour period. To do this, we create an interaction set called “Suspend account due to bad PIN changes.” Figure 8 shows a WBE interaction for suspend/ email actions.

As with filter definitions, interaction set logic can be read in natural language. The image shows that the interaction set instructs WBE to invoke two actions after the third bad PIN change request and those actions are to suspend the account and send an email.

Putting It All Together

This scenario can be tested by issuing three “bad pin change request” transactions in CICS on the z/OS system. Each time this transaction runs, the SupportPac is invoked to format the event and place it on a local z/OS WebSphere MQ on which WBE is listening. On the first two occurrences of the bad pin change request, WBE notes the events, but takes no action. On the third occurrence of the bad pin change request, WBE takes the SOAP action and fires off the email previously defined.

The result of the SOAP action connector being invoked is a message sent to run a CICS Web service to suspend the account. The Web service issues a message showing the suspension of the account (line 7 in Figure 9). The bad pin change request transaction logs errors when the user fails to enter the correct password during PIN change attempts. Figure 9 shows the CICS logging of events. The result of the email action connector being invoked is an email sent to the account manager (see Figure 10).



This article examined how to set up an existing CICS application to issue events via the CICS CB11 SupportPac. This SupportPac lets CICS TS emit events to WBE and serves as an introduction to a future capability in which CICS will emit events to WBE without the need to change existing applications. The CB11 SupportPac also runs on CICS TS V4.1. For migration purposes, a CB11 compatibility option ensures that events emitted using the SupportPac will be compatible with events emitted to WebSphere Business Events using the “non-invasive” event support in CICS TS V4.1. We recommend you take advantage of this compatibility option.

For More Information

• CICS CB11 SupportPac: www-01.ibm.com/support/ docview.wss?rs=1083&uid=swg24021039

• WebSphere Business Events V6.2 Information Center: http://publib.boulder.ibm.com/infocenter/wbevents/ v6r2m0/index.jsp

• WebSphere Business Events Product: www-01.ibm. com/software/integration/wbe/

• DeveloperWorks WBE introduction (search DeveloperWorks for WebSphere Business Events for further articles): www.ibm.com/developerworks/ websphere/library/techarticles/0809_crocker/0809_ crocker.html

• WBE discussion forum: www.ibm.com/ developerworks/forums/forum.jspa?forumID=1301& start=0

• WebSphere Business Events Support: www-01.ibm. com/software/integration/wbe/support/