The introduction of CICS in 1969 began a transaction processing revolution, the impact of which is still felt today. Mainframe applications written decades ago continue to deliver value and reliability at scale. Indeed, many of the largest enterprises in the world still rely on CICS to run their core business applications. The IT industry often refers to these as “legacy” applications. IBM now refers to them as “heritage” applications. Some HostBridge customers bristle at these designations, preferring to call them “systems of record” because without them, they can’t do business. Regardless of what you call them, these applications continue to provide value. That value is often contingent on allowing them to participate fully as part of a hybrid IT strategy. A major challenge to this strategy is integrating screen-based CICS applications.

Effectively and efficiently enabling this participation begins with understanding the two major types of CICS applications:

1. Business-logic applications designed for invocation by other applications. These applications do not output data to screens. Instead, they exchange as input/output a data structure that is usually defined by a copybook. Such programs are often referred to as “COMMAREA programs” and they are the easiest to integrate.
2. Screen-based (terminal-oriented) applications originally designed for use by a human operator using a 3270 terminal. Historically, integrations scraped data from screens based on row/column coordinates. These screen-scraping methods are notoriously unreliable and increase latency. Integrating these CICS applications, in a resilient and performant manner, is challenging. These are the hardest applications to integrate.

The types of CICS applications and their relative integration difficulty.

Most organizations have both types of CICS applications in their portfolios. By far, the biggest challenge in letting them participate in hybrid IT environments is integrating screen-based CICS applications. Indeed, assuming that the same integration approaches work well for all CICS integration projects is the source of many failed integration efforts.

Throwing the Baby Out with the Bathwater

Using suboptimal approaches for integrating screen-based CICS applications usually results in slow performing, unreliable integrations. When organizations experience this outcome, some are quick to blame the CICS application. They assume it has outlived its usefulness. Plans are often made to begin expensive and time-consuming migrations of applications off the mainframe. When this happens, organizations end up throwing the CICS baby out with the integration bathwater. The problem isn’t usually the platform where the applications run, but the integration pathways to the applications. The applications themselves are still quite capable of delivering value.

The problem instead is the approach. It assumes the application’s 3270 interface is the only point of integration for these terminal-based apps. That assumption is incorrect, but more on that shortly. The flawed assumption that drives so many poor integrations is this: the only way to interact with a screen-based CICS app is through its user interface (UI). On the surface, it’s easy to see why this assumption drives integration approaches. These applications were made to interact using a 3270 device or emulator. It stands to reason that to integrate these applications, we must first scrape data off the screen. Sometimes, these 3270 data streams are expressed as HTML in a browser. This approach enables making the interface more graphical, more visual. Or as we’ve heard it described, “putting lipstick on a pig.” Either way, you end up scraping data off of 3270 screens or web pages.

The Problems with UI Integrations

When creating CICS application integrations on the basis of a user interface, you end up with some predictable problems:

1. Application changes break integrations. Since screen scraping integrations are based on row and column coordinates, anything that shifts the location of fields on the screen can break the integration. They are notoriously brittle.
   
   The implication of this brittleness is what we call application rigor mortis. The fear that changes to the mainframe application will break the downstream integration forces organizations to place a moratorium on changes.
   
2. Performance. Screen scraping integration solutions usually run in the middle tier. Because of this, they add milliseconds, and sometimes seconds, to the integration response time. Adding this latency may not seem like a big thing, until you consider that we measure mainframe response times in microseconds.
   
   A recent HostBridge benchmark shows the stark performance difference of integrating screen-based CICS applications using the UI. An automation that executed a sequence of CICS transactions via an RPA bot took almost a full minute to run. The same sequence orchestrated and executed via a HostBridge created API took just one second to complete. As this example shows, it’s not uncommon for exponential performance penalties to come from screen scraping.

Regardless of how the interface appears – as a 3270 screen or a “modernized” graphical interface – scraping data from it doesn’t provide the scalability, performance, or reliability that enterprises need for high-volume, mission-critical applications. Fortunately, UI integrations are not the only option for screen-based CICS applications.

Creating APIs for Screen-Based CICS Applications

A well-kept secret is you don’t have to integrate screen-based CICS applications using the 3270-interface. A far better approach is to access the application field name and value pairs, before the application generates a screen. How can this occur? The HostBridge JavaScript Engine (HB.js) runs within CICS on the mainframe. Developers can use HB.js to create an interface to any type of CICS application. This API makes these apps available as callable web services from any other application, on or off the mainframe. Invoking the API is as simple as sending an HTTP request to HB.js to run the integration script. The script runs and returns JSON, REST, SOAP, XML, or whatever standard format the hybrid application requires.

This API integration approach for screen-based CICS apps is possible because of where HB.js runs – within CICS. It can exploit System z and CICS architectural features, the practical result of which is access to CICS application field name and value pairs, without scraping them off a screen. Since HB.js APIs never screen scrape, changes to the CICS application do not affect the integration. Need to move CICS data around on the screen or add a field? These changes don’t break HB.js integrations. Furthermore, because the integration layer runs in CICS, everything happens at mainframe, microsecond speeds.

In addition to the performance and reliability of API integration, there’s another significant benefit: orchestration. The design of many CICS apps calls for an “operator” to execute a sequence of transactions to complete a business process. HB.js is essentially a lightweight, federated automation engine running within CICS. An API script can efficiently execute the full series of transactions a business process requires. In one case, the customer service representatives of a bank call center were manually executing a 20-screen CICS transaction sequence. Using HB.js to orchestrate this sequence, the CSRs now invoke the business process with a single click, and it completes 95% faster. The benefit of this orchestration goes well beyond performance to favorably impact the customer experience.

Advantage APIs

Those who understand the perils of screen scraping might assume 3270 CICS apps have no value. Or those who understand it’s possible to integrate screen-based CICS apps may assume screen scraping is the only mechanism. These assumptions are wrong on both counts. Using JavaScript, it’s possible to create high performing, reliable integrations to allow CICS apps to fully participate in and contribute to hybrid application deployments. Furthermore, it’s a quick and easy process to develop CICS APIs with HB.js. Contact us to inquire about a free HB.js trial and support to develop your first integration script.Search