Introduction to event processing and CICS event processing support
This chapter describes the concept of event processing and explains the various elements of an event processing solution. It explains why event processing is useful to your business, and includes a summary of IBM products for event processing solutions.
Also introduced in this chapter are the capabilities of CICS Events, and a description of the evolution of those capabilities over a number of CICS releases.
This chapter includes the following topics:
1.1 What is an event?
An event is something that happens that is significant to a system. Events include the following examples:
•Open a bank account.
•Sense a temperature change.
•Click a mouse button.
•Detect loss of connectivity to a database.
•Browse an inventory without making a purchase.
•An unusual history of purchases on a credit card.
•An increasing frequency of application failures.
For this book, event is the term that is used to describe an electronic message that indicates a change in the state of some aspect of a system. An event has a name and usually some data, which sometimes referred to as the event payload.
Events are generated and processed independently and in near real time. The processing of an event is de-coupled from the computer operations that cause it to be emitted.
1.2 What is event processing?
Event processing is the capture, enrichment, formatting, and emission of events; the subsequent routing and any further processing of emitted events (sometimes in combination with other events), and the usage of the processed events.
Events can be produced throughout a business enterprise. At the edges of the enterprise, events can be detected by sensors. In the enterprise network, events can be produced when business processes start and then complete or fail. The activity of the enterprise and its business can be monitored and changed as a result of events. Event processing consists of the following main tasks:
•Event sources emit events into the event processing system. Examples of event sources are simple Radio Frequency Identification (RFID) sensors and actuators, business flows, and CICS applications.
•Some processing is carried out on one or more events. An event processing system can perform the following various actions on events:
– Simple enriching of the event (for example, adding a time stamp to the event data).
– Adding information about the source of the event, such as the context in which the event occurred.
– Processing multiple simple events, from multiple event sources, against event patterns to produce a new derived event. Processing of this kind is often referred to as complex event processing.
The event that results from event processing is made available for consumption.
•Event consumers react to events. The event consumer might be simple and only update a database or a visual dashboard with the data that is carried with the event, or it might carry out new business processing that is based on the event.
An event source or event consumer might carry out some of the simple types of event processing, while more complex event processing (such as looking for patterns across multiple events) is carried out by some separate event processing component.
Figure 1-1 on page 6 is a simplified version of the conceptual model for Event Processing, which is described in the IBM Redguide™ A Conceptual Model for Event Processing Systems, REDP-4642-00, which is available at this website:
http://www.redbooks.ibm.com/abstracts/redp4642.html?Open
The conceptual model defines the various components that can be involved in an event processing solution. However, the only required components are some kind of Event Emitter to emit events that are generated by event producers, an Event Handler layer to handle events for consumption by event consumers, and an Event Bus to deliver events from producers to consumers and potentially carry out event processing and other services with the events.
Figure 1-1 Event Processing conceptual model
CICS can act as an Event Emitter and can carry out simple event processing such as filtering, capture, enrichment, formatting, and routing of those single business events. The event producers in this case are CICS applications or the CICS system.
The following section introduces the concepts of simple and complex event processing, and events are sometimes categorized into simple and complex events.
1.2.1 Simple events
The first four examples in the list in section 1.1, “What is an event?” on page 4 are called simple events. For many years, organizations used simple event processing to detect and respond to discrete events (for example, when customers open a new account sending them a welcome letter that explains other facilities that are provided by the bank).
1.2.2 Complex events
The last three examples in the list in section 1.1, “What is an event?” on page 4 describe what are often called complex or derived events, which are obtained by looking at the patterns of simple events over time. To detect customers browsing an inventory without making a purchase, a system could emit events when customers perform the following actions:
•Browse an item in the inventory.
•Buy an item.
Detecting the patterns from these simple events can produce the complex event Browse an inventory without making a purchase, as shown in section 1.1, “What is an event?” on page 4.
In large organizations, countless events occur every day, but not all events are of equal importance. Greater insight can be obtained when a pattern of related or seemingly unrelated events from one or more sources is detected, and responses to that pattern are coordinated. Considerable complexity, time, and cost are involved in writing custom code for such a solution. This can be replaced by general software technology that is designed to detect event patterns and coordinate responses, sometimes known as complex event processing software.
1.3 Why you need events
Events make it possible to identify and react to situations as they occur. An event-driven approach, where changes are detected as they happen, enable an application or an Enterprise to respond in a much more timely fashion. Events can give insight into what is happening within an application or within a computing system. Event processing also can provide a way of extending an existing application in a flexible and noninvasive manner.
By using events to drive certain actions or more processing, it is easy to change those actions or to change the situations in which they are carried out without affecting the underlying application processing that produces the events.
An aspect of event processing that is gaining considerable momentum is a focus on the business value that can be obtained from events based on the growing need to react and make decisions much closer to real time, and to gain insight into business processing. The drivers behind this momentum include the introduction of compliance regulations that require real-time responses to situations, and the desire to respond rapidly to changes in the business without entailing long development cycles.
An important aspect of Events is the 'Principle of Decoupling': the producer of an event (the event source) and the consumer (or consumers) of an event are decoupled from each other. The event producer does not rely on the event consumer that is carrying out any particular processing (or any processing at all) and does not need to wait for a response from the consumer. Similarly, the event consumer does not depend on any processing that is carried out by the event producer, apart from producing the actual event. This decoupling enables a more flexible and agile approach to building and extending applications.
1.4 Business application events and system events
All events in an enterprise can be seen as having a business consequence and so can be described as business events. Whether the event and event processing are specified by a line-of-business manager or an IT programmer, the event relates to the business application or system that is running. Therefore, it has business relevance. For example, an event that implies imminent failure of a system that is running an order-processing application could be considered relevant to the line-of-business manager in the same way that an event about the processing of an order is relevant. This book regards all events as having the potential to be business events, but makes a distinction between system and application events.
System events generally have a technical focus and relate to monitoring the operating system, running applications, and middleware that is running on the system. The event data is usually equally technical, specifying the identifiers of the resources under observation. In CICS terms, system events are captured from processing that is carried out by the CICS system.
Application events are usually related to higher-level business processes. They specify conditions in terms of what the application is doing for the business. For example, contrast the business event “a new order has been placed” with the system events that are used to assess the compute time for processing the order: inventory file opened, order information storage released, and so forth. In CICS terms, application events are captured from processing that is carried out by business applications.
The consumers of business events are often required to be independent of the implementation specifics of the systems that emit the events. For example, it is possible for one event consumer to process events from several disparate ordering systems and provide a single consolidated view of the business application’s state.
CICS event processing produces application and system events, but the audience and uses for these two classes of events might differ.
1.5 IBM solutions for business event processing
The IBM software portfolio enables a range of options for integrated processing of business events. The following options are described in this section:
1.5.1 CICS Transaction Server
IBM CICS Transaction Server (TS) business applications are the main source of business information in most large enterprises. The CICS run time detects instances of events that are enabled and captures the events and payload without the need to make application code changes or to provide system code.
CICS event processing is a core component of the CICS run time and provides all the qualities of service you would expect of CICS. It is possible to emit events in formats that are suitable for use by IBM Operational Decision Manager Events, IBM Business Monitor, and other users.
CICS Event Processing support is extensible, with options for customization.
For more information, see CICS Transaction Server for z/OS, Version 5 Release 1 at this website:
1.5.2 CICS Explorer
IBM CICS Explorer® provides a modern, powerful interface for managing CICS systems and resources and is an integration point for CICS and other tooling. The CICS Explorer provides a common, intuitive, and Eclipse-based environment for architects, developers, administrators, system programmers, and operators.
CICS Explorer includes the following features:
•Task-oriented views that provide integrated access to a broad range of data and control capabilities.
•Powerful, context-sensitive resource editors.
•An integration point for CICS TS, CICS Tools, CICS Transaction Gateway, Problem Determination Tools, and IBM Rational® Tools. It is included in Rational Developer for IBM System z.
For CICS event processing, the CICS Explorer provides the CICS event binding editors, which are used to perform the following tasks:
•Define events to be emitted and their payload data.
•Specify to the CICS run time how to detect when the events occur.
•Indicate how events are to be formatted and routed.
•Deploy the event definitions to zFS for installation into CICS, by using CICS Bundle support.
CICS Explorer V5.1 includes full support for the event processing capabilities that are described in this Redbooks publication. For more information, see this website:
1.5.3 TXSeries Events SDK
IBM TXSeries for Multiplatforms is a transaction-processing monitor that runs on distributed platforms and supports CICS APIs. SupportPac CB01 provides a software development kit for emitting events from applications that are running in TXSeries. It emits application events in the event format that is used by the events component of IBM Operational Decision Manager and supports WebSphere MQ or HTTP as the event transport. Unlike CICS TS application events, TXSeries event support does require a small application change, but is easy to use and handles all of the event formatting and routing for you.
This IBM Redbooks publication does not describe the TXSeries support for events further.
SupportPac CB01 can be downloaded from the following website:
1.5.4 IBM Operational Decision Manager
IBM Operational Decision Manager (ODM) integrates business events with business rules to enable decision making in real time. IBM ODM provides the power to intelligently automate a wide range of decisions across business processes and applications, which unites market-leading IBM capabilities for business rules management and business event processing to enable more responsive actions to business opportunities or risk conditions.
The event processing component of ODM supports business event processing by meeting the high-volume demands and processing that is required across industries and application domains. ODM provides graphical, codeless user interfaces that simplify implementation and empower business users to develop and maintain event pattern detection logic.
Based on user definitions, the ODM event server engine detects and sifts though the mass of events that occur across the information infrastructure and identifies only those events and patterns of interest.
For more information, see this website:
1.5.5 IBM Business Monitor
IBM Business Monitor is a comprehensive business activity monitoring (BAM) product that provides business users and managers with a real-time and end-to-end view of business processes, events, and operations. IBM Business Monitor aggregates and correlates events into metrics that give objective measurements on the status of business processes.
IBM Business Monitor shows business users real-time information about the performance of critical business processes. It offers customizable dashboards that enable complete insight into the business flowing through the system. These dashboards can calculate and display key performance indicators (KPIs) and metrics derived from the following sources:
•Business processes
•Business activity data
•Business events
Business users can view these KPIs, metrics, events, and alerts through various means, including lightweight web interfaces, smartphones, corporate portals, and on desktops. These options give business users immediate actionable information and insight into their business operations to mitigate risk and take advantage of opportunities.
For more information, see this website:
1.5.6 Cognos Real-time Monitoring
IBM Cognos® Real-time Monitoring is an operational Business Intelligence solution that provides easy access to consistent data, which allows you to react quickly to revenue and cost-saving opportunities. Cognos Real-time Monitoring features self-service, interactive dashboards with operational key performance indicator measures for frontline business users, executives, managers, and analysts.
For more information about Cognos Real-time Monitoring and IBM Business Intelligence solutions, see this website:
1.5.7 WebSphere Message Broker
IBM WebSphere Message Broker is a lightweight, advanced Enterprise Service Bus (ESB) that enables the integration of data sources from various platforms across service-oriented architecture (SOA) and non-SOA environments.
IBM WebSphere Message Broker is built for universal connectivity and transformation in heterogeneous IT environments, and makes use of the power and reliability of IBM WebSphere MQ. It distributes information and data generated by business events in real time to people, applications, and devices throughout your extended enterprise and beyond.
With WebSphere Message Broker, organizations of any size can eliminate point-to-point connections and batch processing to increase business flexibility and smart interoperability of systems regardless of platform, protocol, or data format.
For more information, see this website:
1.5.8 WebSphere Enterprise Service Bus
IBM WebSphere Enterprise Service Bus provides integration for new and composite service-oriented architecture (SOA) and Business Process Management (BPM) applications, optimized for the WebSphere Application Server platform. It decouples complex integration logic from applications and can provide consistency in connectivity across a diverse infrastructure.
WebSphere Enterprise Service Bus can provide service mediation and hosting on common internet-standard application infrastructures that are based on WebSphere Application Server.
WebSphere Enterprise Service Bus provides a smart approach to SOA, which delivers a standards-based connectivity and integration solution that allows you to create and deploy interactions quickly and easily between applications and services, with a reduced number and complexity of interfaces.
For more information, see this website:
1.5.9 Tivoli OMEGAMON XE for CICS on z/OS
IBM Tivoli® OMEGAMON® XE for CICS on z/OS enables monitoring and management of CICS transactions and resources. It quickly detects and isolates problems when they occur on your complex CICS systems to minimize or eliminate any effect on your customers and business.
Tivoli OMEGAMON XE for CICS provides events for a broader and more advanced range of state changes and system situations than the CICS system events that are described in this Redbooks publication. However, it uses a polling mechanism to discover state changes, which implies a bigger effect on CICS system performance and a less timely reporting of events. CICS system events are a targeted set of event conditions that particularly benefit from not using polling.
Tivoli OMEGAMON also enables integration with system events from other systems.
For more information about IBM Tivoli OMEGAMON XE for CICS, see this website:
1.5.10 CICS SupportPac CA1Y: Send email from CICS TS for z/OS
SupportPac CA1Y provides an SMTP client to emit events that are captured in CICS as emails. Use the CICS Explorer event adapter or event binding editors to define the SupportPac transaction CA1Y as the custom event processing adapters (EP adapters), and specify the email headers, content, attachments, and server details. Information from the event can be merged in with predefined content templates for added flexibility.
The SupportPac runs in the CICS JavaServer environment and is eligible for offloading onto a System z Application Assist Processor (zAAP) speciality engine, which might be cost-effective compared to alternatives.
For more information, see this website:
1.5.11 Solutions reviewed
This section provides a review of the products and the situations in which they should be used.
If your business processing is running within CICS, that is the source of your events and forms the subject of this IBM Redbooks publication. There are situations in which the actions to be taken as a result of the events also involve processing within CICS. In other situations, you want to involve other products.
If you want to monitor the processing that is happening within CICS, look at key performance indicators, provide a dashboard to allow business users to understand the behavior of the business, and receive alerts, you could use IBM Business Monitor or IBM Cognos Real-time Monitoring.
If you want to derive more information from combinations of events, potentially including events from other sources in addition to CICS, or consider events over time, you can use IBM Operational Decision Manager.
You might also want to monitor processing based on some of these derived events, in which case IBM Operational Decision Manager can look for the patterns of interest and can send the resulting events to IBM Business Monitor.
If you want to transform and enrich events from CICS and make them available to a range of consumers, you could use WebSphere Message Broker or WebSphere Enterprise Service Bus to provide transformation and mediation.
For more information, see Leveraging CICS Events with an ESB, SG24-7863-00, which is available at this website:
1.6 Introduction to CICS event processing support
Figure 1-2 provides an overview of CICS event processing support.
Figure 1-2 Overview of CICS event processing support
CICS Transaction Server for z/OS can act as a source of application and system events. In both cases, the events that are to be produced are specified to CICS by installing and enabling event bindings by using development and deployment tools. An event binding specifies the situations in which the events are to be captured, the data to be included in the events, and how the events are to be emitted. An event binding is an XML document that can be created and edited by using the Event Binding Editor, a component of the CICS Explorer.
Events can be captured from existing applications without requiring any changes to the application, or from CICS system processing without the need to poll for changes in stage. CICS carries out some simple event processing on the captured event, such as filtering and enrichment, and the event can then be formatted and routed (emitted) to a range of event consumers. CICS event processing provides all the expected CICS qualities of service, including security, performance, diagnostics and monitoring. Events from CICS can be used by many different kinds of event consumers, ranging from transactions that are running within CICS to external event monitors and decision servers.
A capture specification within an event binding provides the information about the situation in which an event is to be captured. An EP adapter that is referenced by an event binding (or embedded within an event binding) provides the information about how the events are to be emitted.
A capture specification includes a capture point (the point in CICS processing where the event can be detected), some filtering information (to identify the particular circumstances in which the event occurs), and information sources (to specify how the information to be included in the event can be obtained from data available at the capture point). The sets of capture points which can be specified depend on whether this is an application or a system event.
1.6.1 CICS application events
Application events represent interesting business situations that arise during processing that is carried out by CICS applications. Examples of application events include an order being received, a deposit being made into a bank account, or a stock trade being carried out.
Application events are noninvasive, meaning that events can be captured from a CICS application without the need to change or recompile the application, and with minimal if any overhead in the performance of the application.
The capture points for application events are a subset of the CICS API commands. They also are a capture point when a program is initiated and the SIGNAL EVENT command which can be coded in an application as an explicit, and in this case invasive, capture point. The CICS API commands that can be specified as capture points represent the points in application processing where business events are most likely to occur, such as when data is input or output by the application. For more information about the application event capture points, see Chapter 2, “Capturing application and system events” on page 23.
1.6.2 CICS system events
System events represent significant system changes that arise during the running of a CICS system. Examples of system events include an IBM DB2® system changing from being connected to the CICS system to not being connected, the number of tasks in a transaction class increasing to more than 90% of the limit for that class, or an unhandled application abend occurring.
CICS system events are also non-invasive in that they do not require you to write any code and the system overhead is minimal. System events are detected by the CICS system as the system changes are processed and are therefore more efficient than other technologies that rely on polling.
The capture points for system events are a subset of some of the state changes that can occur in CICS. In addition to the set of predefined state changes, the Message capture point allows events to be captured when most of the CICS messages are issued, which enables system events to be captured for any of the state changes that result in such messages. Later chapters in this book provide more information about system event capture points.
1.6.3 CICS event emission
The way in which an event is to be emitted is specified by an EP adapter. The EP adapter specifies the transport over which the event is emitted (such as WebSphere MQ, HTTP, or transaction start of a CICS transaction), the format in which the event should be emitted (such as a predefined XML format or a structured data format), and some advanced emission options (such as whether the event is transactional, or should it be emitted synchronously to the task in which it was captured). Several of the advanced options apply only to application events.
Later chapters in this book provide more information about EP adapters, including how you can write your own custom EP adapter to support any transport or formatting.
1.7 Evolution of CICS event processing support
This IBM Redbooks publication assumes the level of event functionality that is available in CICS Transaction Server for z/OS V5.1. CICS Event support was first introduced in CICS Transaction Server for z/OS (CICS TS) V4.1 and was further enhanced in versions CICS TS 4.2 and CICS TS V5.1. This section explains the levels of functionality that were introduced in each of those releases.
If you are using CICS TS V4.2 or V4.1, not all of the event functions that are described in this Redbooks publication are available to you. You are advised to use the Event Binding Editor that is included in CICS Explorer V5.1. This is compatible with previous levels of event processing support in CICS, but note that if you select options in an event binding that are only available in later releases, the event binding fails to install into an earlier CICS run time.
1.7.1 CICS event capabilities in CICS TS V4.1
The following broad set of capabilities formed the initial CICS event support in CICS TS V4.1:
•Application events captured non-invasively from a subset of the CICS API and on program initiation.
•SIGNAL EVENT application programming command.
•Event bindings, containing event specifications, event capture specifications, and EP adapters.
•Event Binding Editor in the CICS Explorer for creating and manipulating event bindings.
•EP adapters supplied by CICS for emitting events to CICS TS queues, WebSphere MQ queues and to CICS transactions.
•EP adapter emitting events over HTTP once APAR PK94205 is applied.
•SPI commands and CICS Explorer views for event bindings and capture specifications.
For more information, see the What’s New section of the CICS TS V4.1 Information Center that has a topic on Support for event processing, which is available at this website:
1.7.2 CICS event capabilities in CICS TS V4.2
The initial event support was extended in CICS TS V4.2 to add the following capabilities:
•System events captured from a subset of state changes that can occur in the system, including DB2 connection status, file enable and open status, task threshold, tranclass task threshold, and transaction abends.
• Assured event emission with a new synchronous event emission mode, enabling events to be emitted in-line with the application from which the event was captured (in addition to the original asynchronous emission mode).
• New EP adapter resource that is independent of the event binding (embedded EP adapters also are still supported but are less flexible).
• New HTTP EP adapter to emit events to HTTP servers.
•EP Search capability to help identify potential effect of application changes on capture specifications.
•Extended SPI and CICS Explorer views to provide more detail about capture specifications and for EP adapters.
• Enhancements to the TS queue EP adapter to emit events to TS queues in XML formats.
• The custom EP adapter interface is passed the configuration in a character container for easier code page conversion.
•Event capture global user exit, XEPCAP.
•New support for capturing data in other data types, including floating point and COBOL zoned data types.
For more information, see the What’s New section of the CICS TS V4.2 Information Center that has a topic on Improvements to event processing, which is available at this website:
1.7.3 CICS event capabilities in CICS TS V5.1
The event support was further extended in CICS TS V5.1 with the following other capabilities:
•New application capture point that allows events to be captured when the WRITE OPERATOR command is issued.
•New system event capture point that allows events to be captured when CICS messages are issued (for most CICS messages).
•New capture points when threshold policy rules are exceeded. For more information, see “CICS events and CICS threshold policies” on page 20.
•Static data can be defined in the event specification and included in the captured and emitted events.
•New EP adapter set resource to route one event to multiple EP adapters, and hence to emit to multiple event consumers.
•Updates to event emission advanced options.
•Security changes to the processing captured events.
For more information, see the What’s New section of the CICS TS V5.1 Information Center that has a topic on Improvements to event processing, which is available at this website:
CICS events and CICS threshold policies
CICS TS V5.1 introduces support for threshold policies. These policies provide a way of controlling resource usage. A policy rule defines the action to be taken when tasks that are running in a specified scope in a CICS platform exceed a certain threshold usage of a particular resource. One of the actions that can be specified when a task exceeds the policy threshold is to emit an event via a specified EP adapter.
CICS system events indicate that something interesting has happened in the CICS system. Threshold policies can be thought of as a way of specifying a predefined event that indicates that the usage of a resource has exceeded a certain threshold. The event action for a threshold policy causes an event to be emitted in exactly the same way as other system events in that the event is formatted and routed by the specified EP adapter. Therefore, events that are generated from threshold policies can drive other processing or be sent to other event consumers.
1.8 Summary
This chapter described the concepts and value of business events and event processing, reviewed some of the IBM products that can provide event processing solutions, and introduced the event processing support that is provided by CICS Transaction Server for z/OS. This support includes the capability to capture and emit application and system events.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.