Business Event Processing for z/TPF System

By Madhur Arya and Ashok Bhardwaj

What is a Business Event?

A business event is an occurrence of certain state in a system or software application that may be important to other sub-systems within the system or external systems or agents.

Distributed systems have quite mature capabilities for business events that help a business to take agile decisions. Consider an inventory management system where critical levels of inventory need a trigger to take corrective measures – both in case of high levels or low levels. Such scenarios can be easily managed in distributed systems by virtue of mature tooling available.

TPF based systems were lacking such features till recent past. But with the advent of zTPF and its new features we now have new capabilities that can help develop systems with more intelligence by using business events handling.

Tracking business events and then taking business decisions on these events can bring huge benefit to a business with dynamic markets. Business event processing can be done to enhance governance for standards compliance, and to monitor business processing. Business event processing enables detection of business situations, providing early and intelligent insight to assist in making timely and effective business decisions.

General Business Event Processing Model

A typical business event model with event sources, event processors and event consumers as the three core participants is shown below:

Business Events-1

Event Source: This releases business events into the business event processing system. Examples of event sources include simple Radio Frequency Identification (RFID) sensors & actuators, business flows, applications, and system components.

Event Processor: The processor can perform various actions on events released by the Event source:
• Enriching a single business event in a simple manner; for example, adding a timestamp to the event data.
• Adding information about the source of the event.
• Processing multiple single business events, from multiple event sources against event patterns to produce a new derived or compound event.

The processed event is then available to an event consumer.

Event Consumer: The event consumer reacts to the business event. It can be as simple as updating a database or business dashboard, or as complex as required, carrying out new business processing as a result of the event.

Solution Architecture

Following is IBM’s business event processing high level architecture for zTPF. The framework uncovers the potential issues & risks involved in using zTPF business events and is also intended to define a reference implementation that can later serve as a model for follow up works in this area.

zTPF now has features that can be used to specify, capture and transmit business events from zTPF system. On the occurrence of such a business event, the zTPF system collects the data related to business event, and then formats and emits the data to a specified event consumer. The event is dispatched via a dispatch adapter.

Business Events-2

The diagram represents the following flow:

• TPF application calls tpf_bev_signal function when a specified business event occurs.
• If an enricher program is defined then the event control passes to it. On completion the program calls tpf_bev_signal_enrichment_complete function.
• Tpf_bev_signal function processes the event and then dispatches event information to business event dispatch queue.
• The dispatch queue handler listening to business event dispatch queue pulls the message off queue and sends information to business event adapter defined for that particular business event.
• Each business event dispatcher formats the event data before transmitting to the event consumer.

Conclusion:

Business event processing, if done efficiently, can help the business in multiple ways:

• Getting the right information at the right level of detail to the right person at the right time.
• Facilitating quick observation of exceptional business behaviour and notifying the appropriate people.
• Diagnosing problems based on symptoms and resolving them.
• Providing data for dashboard display of real-time business service availability.
• Monitoring the health of a system.

_____________________________________________________________________________

About the Authors

Madhur Arya is the CoE practice head for the TPF practice at IGT. Madhur holds a Bachelor of Technology degree from the University of Kurukshetra and has 15+ years of IT experience. He has been focussing on continuous improvement and implementing accelerators for development, maintenance and migration projects in the ALCS/TPF area. He can be reached at Mktg@www.igtsolutions.com

Ashok Bhardwaj is a member of the Architecture CoE at IGT. With a Masters in Computer Applications, Ashok has 13+ years of experience in software development. Having worked in the past both with large companies like General Electric as well as start-ups like NextBrick Solutions prior to joining IGT, Ashok has deep interest in modern architectures with Cloud, Microservices, Mobility and Containers, and at the same time is mesmerized with hugely successful platforms like zTPF. He is a voracious reader of classic English literature in his spare time. Ashok can be reached at mktg@www.igtsolutions.com.

Leave a Reply

Your email address will not be published. Required fields are marked *