Oct 11 ’11
CICS Event Processing: Meeting the Needs of Your Business
Information is everywhere. Anything we could possibly want to know about the world around us is at our fingertips, just a click, tap, or swipe away, consumable and available continuously. The unknown is becoming known, and we regularly use this newfound knowledge to make more intelligent, informed decisions.
Gaining insight through knowledge is the core value of business Event Processing (EP). By emitting events from within business processes, it’s possible to achieve a level of visibility that lets a business react intelligently to its environment, maximizing opportunities and minimizing risk. Events can be used to monitor business performance, detect and respond to situations of interest in real-time, and even drive additional business processing.
CICS TS V4.1
For many companies, CICS Transaction Server (TS) is where core business logic runs and where some of the most interesting business events occur. In 2009, CICS TS V4.1 delivered the capability to non-invasively capture and emit events from within business applications (see Figure 1). The article “CICS: The Critical Enabler for the Event-Driven Enterprise” (z/Journal February/March 2011 available at www.mainframezone.com/it-management/cics-the-critical-enabler-for-the-event-driven-enterprise) highlighted the capabilities and explained why they’re essential for adopting business EP across the enterprise.
During development of EP in CICS TS V4.1, there were few EP-related requirements since customers had yet to consider using EP. However, without EP in CICS, many companies wouldn’t be able to extract key events of interest, reducing the compulsion to pursue business EP.
Having few requirements made it difficult for the CICS TS V4.1 development team to deliver everything customers would need for EP. The team delivered some core capabilities with three goals:
- Raise awareness of EP
- Help customers adopt business EP in their enterprise
- Generate requirements for future releases.
EP in CICS TS V4.1 has been a great success; CICS customers are finding they can easily extract data from their applications that previously would have taken months of development to expose. Moreover, customers perceive EP differently. When CICS TS V4.1 launched in 2009, a common question was: “What value is EP really going to give me?” By the IBM IMPACT conference in April 2011, customers increasingly were asking questions such as: “I have an application I need to extract events from. What’s the best way to approach it?”
Businesses now clearly see the value of EP and are seeking the best way to use it.
CICS TS V4.2
In April 2011, IBM announced CICS TS V4.2, which provides many enhancements to EP. Due to the increased interest in EP that CICS TS V4.1 sparked, these enhancements were almost entirely driven by customer requirements; the development team has worked closely with beta customers to ensure what has been delivered is what they need. This article looks at some requirements for EP and the corresponding features of CICS TS V4.2.
Separate EP Adapters
In CICS TS V4.1, every event binding had an EP adapter specification containing the format and transport that should be used to emit the events it described. Figure 2 shows several event bindings (purple) in a bundle (blue), each with their own EP adapter specification (orange).
As customers started to use EP in CICS TS V4.1, we saw that, typically, all events from CICS would be sent to a single event consumer. Despite this, they wouldn’t use a single event binding; rather they would have many event bindings so events could be managed in logical groups. As a result, information in the EP adapter specification was being duplicated in each event binding. This led to concern that, if the event consumer changed, there would be considerable work needed to change the EP adapter specification in every binding.
The solution CICS TS V4.2 provides is to let EP adapter specifications be defined as a separate bundle resource, which can then be referenced from multiple event bindings. EP adapters can be referenced by event bindings across bundles, and there can be multiple EP adapters per bundle (see Figure 3). Once installed, EP adapters can be inquired upon just like any other CICS resource. Separate EP adapter specifications let you share, rather than duplicate, the information in them, so now a change requires updating just one resource.
Event Binding Search
Non-invasive capture of events from applications will, inherently, introduce affinities between event bindings and programs. Customers were concerned that if they had many events defined to CICS, it would be difficult to determine whether an application change could unintentionally cause extra events to be emitted or somehow break existing events.
CICS TS V4.2, with CICS Explorer V1.1, provides EP search, a feature that addresses this issue. EP search lets a user search for event bindings that may be affected by an application change. EP search can be performed against event bindings, both in the CICS Explorer workspace and in connected CICS regions. To use EP search, the user types the name of the application asset being changed (e.g., CICS resource, program, language structure, variable field, etc.) into the search dialog and CICS Explorer will find all event bindings that may be affected (see Figure 4).
Search results are displayed in a convenient tree view to show precisely which parts of the event binding are affected and, when clicked, will open up the appropriate tab in the event binding editor or CICS Explorer. The search understands the filter operators in an event binding so if, for example, you’re changing file ABC12 and you have a filter for a WRITE FILE event where FILENAME “Does not start with” “C”, then EP search will know that the filter would evaluate true for file ABC12 and include it in the results.
In CICS TS V4.1, all events were processed asynchronously to the application thread from which they were captured. The benefit is that application response time isn’t affected by formatting or emission of the event. Also, if an event fails to format or emit for some reason (e.g., the event consumer is unresponsive), then the application will continue unaffected with its behavior unchanged. Asynchronous emission is desirable for non-invasive event capture since it doesn’t affect application behavior. Unfortunately, there’s the potential to “lose” events if a failure occurs.
Generally, this isn’t a problem. Failures aren’t likely to happen and a rare lost event isn’t disastrous when events are being used for monitoring or business intelligence. However, there could be a problem if events are being used to drive further business processes. For example, if an “order placed” event is sent to a warehouse to start the picking and packing processes for that order, the consequence of losing the event is that the order will never be processed.
CICS TS V4.2 introduces the option to use synchronous emission. When synchronous emission is used, event formatting and emission processing are performed on the application thread as part of the unit of work from which the event was captured. If the event fails to be formatted or emitted, then the application backs out at syncpoint. This effectively makes the success of the application dependent on the successful emission of the event. Event emission is assured since the event is either emitted or the action that caused the event is backed out. This behavior makes synchronous emission ideal for event-driven processes.
Synchronous emission, unlike asynchronous emission, will have a more noticeable impact on application response time and can affect application behavior if an event fails to be emitted. Also, there are more things that need to be considered during setup, such as ensuring the transport is recoverable when used with transactional EP adapters. For a full list of considerations, see the CICS Information Center. The greater performance impact combined with the extra setup considerations means synchronous emission should be used only if the event is a critical part of the capturing application. The emission mode is selected in the advanced options on the EP adapter tab of the event binding editor and, by default, is set to asynchronous emission.
System Capture Points
The original goal of EP was to provide a way to extract business events from CICS processing non-invasively. Since business logic resides in business applications, all event capture points CICS TS V4.1 supports were application capture points. Customers liked the way events could be captured, formatted, and routed to a destination of their choice without having to write code. In summer 2010, they suggested it would be useful to be able to use the EP infrastructure to capture events when certain system conditions were met. With less than a year until the release of CICS TS V4.2, the fact that system capture points were provided is a testament to the CICS development team’s ability to work closely and rapidly with beta customers.
The six system capture points that were provided are the ones deemed the most interesting by feedback from beta customers:
- FILE ENABLESTATUS change
- FILE OPENSTATUS change
- DB2 connection status change
- Unhandled transaction abends
- Current active tasks for a TRANCLASS go above or below a certain percentage of MAXACTIVE.
- Current active tasks in a region go above or below a certain percentage of MAXTASKs.
System capture points are configured via a capture specification in an event binding. They support the same kind of filtering as application capture points, letting you specify exactly when a situation of interest occurs. So, for example, it’s possible to capture an event every time a FILE starting with “ABC” moves to DISABLED state or when the number of active tasks for TRANCLASS “XYZ” goes above 80 percent of its MAXACTIVE. Any fields that can be filtered on can be captured and used to populate the event in the same ways as the event options on application capture points. Once an event is captured, it’s processed in the same way as any other event from CICS and can be formatted and emitted using any of the EP adapters (see Figure 5).
System capture points provide a way to generate real-time notifications about the state of a CICS region without the need to continuously poll for information. They can be used to provide a basic systems monitoring solution, augment existing solutions, or improve performance by removing the need to poll for certain state changes.
Event Driven Architecture (EDA) is a vibrant, evolving technology that can bring tremendous value to an enterprise. Many businesses are beginning to realize this value by using CICS EP. Besides the new features discussed here, the latest release brings a host of minor enhancements to improve capability and usability. Two examples are filter and capture support for floating point data types and improved copy/paste/undo capabilities in the event binding editor.
The CICS development team is dedicated to delivering what customers need to achieve their EP strategies. If you’re using EP and have enhancement suggestions, please raise a requirement via your local account representative. You might also consider participating in the CICS beta program.
With a growing number of customers using EP to do everything from easily extracting data from applications to fully event-enabling their enterprise, you can expect to see more innovation in future releases.
You can gain further information via these links:
- EP in CICS V4.1 demo: www.youtube.com/user/CICSfluff#p/u/2/KomUEHfCnoo or at IBM site: ftp://public.dhe.ibm.com/software/htp/cics/EP_Demo_FLV.flv
- EP in CICS V4.2 demo: www.youtube.com/user/CICSfluff#p/u/3/sPbF56BevG4 or at IBM site: ftp://public.dhe.ibm.com/software/htp/cics/cics_v42_EP_FLV.flv
- System capture point demo: www.youtube.com/user/CICSfluff#p/u/4/-tbV3R3x1YA or at IBM site: ftp://public.dhe.ibm.com/software/htp/cics/system_events_FLV.flv.