IBM z/OS® Connect Enterprise Edition is IBM’s strategic REST gateway that enables valuable IBM z applications to participate in the API economy. This IBM solution is used to transform z assets into APIs that make it possible to include the mainframe into hybrid IT strategies. Using APIs to make mainframe assets available as REST/JSON services is an ideal way to enable the digital transformation taking place within almost every enterprise. Well designed and implemented RESTful APIs can implement quickly and optimally utilize expensive computing and scarce human resources.
There is one class of z applications, however, that resists quick, easy, reliable, and high-performing integration: screen-based (3270) CICS applications. And, despite the fact that many of these applications are decades old, there’s a reason they are still around: they are mission-critical. And because they are core business applications, it’s imperative for the organizations that rely on them to integrate them with non-mainframe applications.
These legacy, screen-based applications are difficult to integrate via an API because their business and presentation logic are intertwined. Historically, the most common approach for integrating them is to use terminal emulation and screen scraping to access the business logic and data locked within these applications. This approach works, but has serious limitations.
To Scrape, or Not to Scrape Screens, That is the Question
ZCEE does not support native integration with screen-based CICS apps. It must therefore rely on an ancillary solution to do so. The HostBridge JavaScript Engine (HB.js), however, is perfectly positioned to fill this ZCEE functional gap. We have written extensively on the complementary nature of HB.js and ZCEE, including creating a Redbook-like how-to guide to getting the job done. HB.js enables ZCEE to access 3270 CICS applications without screen scraping. To better understand why it’s such a big deal to integrate screen-based applications without having to screen scrape, read our blog post on the topic.
It’s understandable that IBM sales representatives like to sell “all blue” solutions. With this in mind, IBM promotes Host Access Transformation Services (HATS) as the avenue for letting ZCEE interact with screen-based CICS applications. HATS, however, has been around for a long time and enjoys a lot of mindshare as the mother of all screen scraping integration solutions. When it comes to integrating 3270 CICS applications, it gets the job done, right? It does, but there are limitations.
A far better approach is to create services running inside CICS that are invoked via APIs. Because these services run inside of CICS, they can exploit the CICS 3270 bridge interface. The advantage of this approach is accessing CICS field values by name before the application outputs a screen. The benefits of this loose coupling integration approach are significant:
- It’s resilient. Because integrations don’t rely the row-column position of fields on a screen, application changes don’t break the integration. This loose coupling overcomes the most significant flaw of screen scraping’s tight coupling: a reliance on row-column coordinates that makes the integration highly vulnerable to changes in screen geometry. That well-meaning developer who decided to add a requested field of data to a particular CICS screen can do so with the confidence of knowing the change won’t cause the integration to fail.
- It scales well. When the integration layer to any type of mainframe application resides off the mainframe, latency is introduced. The time required for a CICS transaction to run is a fraction of the time for the request to reach the mainframe and return the response. Even simple requests to run a single transaction can cause response times to balloon when there are thousands or tens of thousands of requests. Latency worsens when requests that require multiple CICS transactions to run to satisfy them. In such cases, if those requests are not orchestrated, a full request-response exchange occurs for each transaction in the sequence. By contrast, services that run within CICS experience no network latency. The time required to complete a full request-response is usually an order-of-magnitude faster.
- It’s easy to add new logic without changing the CICS application. JavaScript is now the most widely used programming language on earth. The HB.js scripts that enable integration can also include any additional logic that is helpful. Often, the additional logic is for orchestration: allowing one call from outside to run an entire, orchestrated sequence of CICS transactions. However, as our technical services team has recently demonstrated, there’s no limit to the logic you can embed in an HB.js integration script.
HostBridge extends ZCEE to screen-based CICS applications without screen scraping.
Faster ZCEE ROI
When integrating screen-based CICS applications, ZCEE users can experience a faster and greater return on their investment by using CICS web services. ZCEE is pluggable and extensible, allowing third party providers like HostBridge to participate in expanding the z/OS assets you can expose with an API. HB.js is a solution for creating RESTful APIs for all types of CICS applications. It is particularly good at making screen-based CICS applications available, and doing so without screen scraping. Because HB.js runs within CICS, it leverages the 3270 Bridge interface.
Architects can use HB.js to develop APIs that reference CICS application fields by name, regardless of where those fields reside on a screen. Because HB.js APIs and services run within CICS, latency is not an issue, even for high-volume CICS transactions. The result is a highly responsive, resilient integration that complements ZCEE, scales extremely well, and uses mainframe resources in the most optimal way.
Want to better leverage your investment in ZCEE using the approach this article discusses? Reach out to HostBridge using the contact information found at the bottom of this page to speak with a HostBridge CICS integration consultant.