The company adds event processing to capture information
about the business transactions that are occurring in the application.
The captured information is presented as a dashboard to the business
analysts.
The delivered IT configuration includes several components that
an administrator configures or uses, as shown in Figure 1.Figure 1. Delivered logical topology.
Terminal-owning region (TOR)
The TOR contains the presentation layer for the CICS® application. The system administrator has
configured the CICS region
to support event processing and deployed the event and event processing
(EP) adapter. When the application returns information to the business
user, for example to add a customer or inquire on a policy, this information
is captured in an event. The EP adapter emits the event; in this solution,
the event starts a transaction named LGST.
The LGST transaction is defined in the TOR and is the event consumer.
The transaction runs every time an event is emitted from the EP adapter.
The transaction runs a program that updates the named counter server
in the coupling facility.
The advantage of using
event processing is that you can capture information about what is
happening in an application without changing any application code.
Events are defined and controlled independently of the business logic,
providing flexibility in what events are emitted and how often they
are updated. The emitted events can be consumed by a variety of products,
including complex event processing engines such as WebSphere® Business Events. For more information about events,
see Event processing overview.
Capture point
The capture point for the event occurs in the terminal-owning
region when the business logic layer returns the results of an application
request to the business user. The information is returned in a COMMAREA
in an EXEC CICS LINK PROGRAM command. The business
information that is captured indicates the type of request that occurred
and whether the request was successful. The following types of requests
can occur:
Adding a customer
Inquiring on a customer
Adding a policy
Inquiring on a policy
Deleting a policy
Updating a policy
EP adapter
The event processing (EP) adapter emits the event to the event
consumer. CICS supports different
types of adapter; for example, you can emit events over WebSphere MQ or HTTP to be consumed by
other products or send the event to a temporary storage queue. In
this solution, the event uses a transaction start EP adapter. The
adapter starts a transaction called LGST.
LGST transaction
The event processing adapter calls the LGST transaction every
time an event is emitted. The LGST transaction runs the LGASTAT1 program,
which uses the business information from the event to increment a
named counter based on the business function; for example, an inquiry
on a customer or an update to a motor policy.
Named counter server
The solution extends the existing named counter server support
that is used by the application. The application updates counters
when a business user adds or inquires about a policy or customer.
The LGST transaction updates event counters in the named counter server
when a business user interacts with the application. One event counter
is updated if the interaction is successful and another event counter
is updated if the request is unsuccessful.
To make the information available to the dashboard application,
a self-timing transaction named SSST runs a program to read the event
counters and copy the values into an equivalent temporary storage
queue.
Event counters
Each business function has two corresponding event counters in
the named counter server, one for a successful request and another
for a request failure. These event counters are updated every time
an event occurs for that business function. Every named counter is
prefixed with GENA01 and follows the naming convention GENA01actiontypereturn_code:
action is the letter representing the request:
A=Add, D=Delete, I=Inquire, and U=Update
type is the first three letters of the policy
type or CUS for customer
return_code is 00 for success or 99 for failure
For example, the named counter GENA01ICUS00 contains the count
for successful inquiries on customer records in the application.
SSST transaction
The SSST transaction is a self-timing transaction that runs every
minute. This transaction copies the values in the event counters to
shared temporary storage queues for the appropriate business function,
to expose the data through the dashboard. Named counter servers cannot
be accessed directory through a dynamic scripting application.
Shared temporary storage queues
The solution extends the existing temporary storage queues that
are shared by the different regions in the topology. The application
uses shared temporary storage queues to add application error and
audit information. Two additional queues, that contain information
about the application, are updated by the SSST transaction every minute.
This information is available to the dashboard application.
Application-owning region (AOR)
The AOR contains the business logic for the CICS application. The CICS region is also configured to run the dashboard
application. The dashboard application is written in a scripting language
that can use the JCICS API to access data in the temporary storage
queues. The application was developed using the Dynamic Scripting
Feature Pack, which dynamically creates a JVM server to run the application
in the appropriate region.
The advantage of using
the Dynamic Scripting Feature Pack is that you can quickly create
a Web 2.0 application using the latest web technologies. You can present
information in a consumable way to business users by creating PHP
or Groovy applications, and use Rich Asynchronous JavaScript and XML (Ajax) web user interfaces.
Although this solution has the dashboard application running in
the AOR, it can run in any region. The TOR uses less resource than
the AOR, and with a heavy workload it might be more appropriate to
run the JVM server in the TOR or its own region.
