The XYZ company has various CICS application, which implements key business processes. As part of Case Install Release 5, the Business Process Management software is required to integrate with these CICS applications to automate process integration as well as ease up manual processes.
This presentation explores various CICS integration approaches within XYZ company environment.
In XYZ company there are many options available using home-grown as well as off-shelf components to integrate z/OS CICS applications:
CICS Transaction Gateway (ESM - Enterprise Service Manager)
TIBCO Substation ES
z/OS DB2 Stored Procedure
All these approaches assume that the CICS application is a pure application logic code. If any presentation logic in intertwined with application logic it needs CICS application reengineering to separate the application logic with presentation logic.
Supports only 32k Data Exchange as the wrapper needs to be upgraded for Container/Channel support.
The wrapper does not relate reply message with request message. Which means in high volume transactions, all Reply message land in the same queue and hence the client program has to query through this one queue for each of their request. This can result in a significant performance issue with many clients/requests. Error handling design becomes complicated due to this inherent limitation.
Supports only External Call Interface (ECI using EXEC CICS LINK) and not the External CICS Interface, which is needed for transaction support (EXCI using EXTERNAL CICS INTERFACE).
Configuration of multiple policies is required for supporting request reply scenario through the use of policy name. By default the inbound and outbound interface are correlated using MQ, this additional configuration ensures that they are related by the facility of Policy
Policy are stored as Process definition in MQ Queue Manager and need to be backed up periodically
Monitoring, logging and trace abilities not available to limited capabilities.
Wrapper support team is very small and support can be slow to development/run time can be slow.
ESM is a group of web services that wrap z/OS application interface and exposes them as web services interface. ESM uses IBM’s CICS Transaction Gateway software for integrating CICS Application with java or web service compatible code.
CICS Transaction Gateway (CTG) is a set of ‘ client and server ’ components in JCA architecture that enable Java application to invoke services in an attached CICS server. Java application can be a servlet or EJB or plain java code.
Performance is the quickest of all the three available options as experienced in XYZ company environment.
Interface can be configured in as little as two hours. Any Mainframe savvy developer is good enough to configure the interface.
Very quick and easy configuration leading reducing development time as well as easier maintenance.
Changes to the interface can be done in-flight (at runtime) with no downtime
Supports Commarea, TSQ, TDQ and hence virtually unlimited data exchange possible
CICS programs can be executed as a link program or as an execute transaction. Substation can mirror whatever transaction id is required to invoke the CICS program through execute transaction command.
Provides superior Monitoring, logging and tracing capabilities
Under the hood, Substation makes calls to CICS using EXCI (External CICS Call Interface), which supports transaction capability. Other options use ECI (External Call Interface). EXCI is a facility of CICS Transaction that allows non-CICS address space on z/OS systems to link to CICS program in a CICS transaction server region.
The interface can be exposed as a service (SOAP/HTTP or XML/JMS)
Substation can communicate with multiple CICS regions.
Package product and hence requires maintenance licenses and fees