z/OS Connect scenarios

Consolidating or grouping separate requests (Financial services company scenario)

A financial services firm that recently completed a merger with another firm is looking for a way to provide a secure and fast way to open up several critical business applications and tie them together to form a single result and make the result available from inside a web application. One z/OS application, called ACCTINFO runs in the CICS® environment and provides access to internal account data for customers. A second application, ACCTHSTY, runs in the IMS™ environment. The data managed by the CICS® application is stored in Virtual Storage Access Method (VSAM) files. The IMS data is in DL/I tables.

The company has a requirement to unify the security for accessing these applications and be able to identify when and how many calls to these two applications occur, the number of bytes received and returned, as well as the response time.

z/OS Connect offers a simple solution that hides the complexity of these environments behind its configuration. The solution provides the ability to contact a single server running on a z/OS operating system to call in to both applications using REST-based calls and JSON for the message payloads. The data transformation support that is provided in z/OS Connect handles the mapping both to and from JSON and byte arrays for each request. In addition, z/OS Connect provides the single point for security checking to ensure any ID systems requesting access are authorized to reach these applications and it records each REST call in the z/OS system management facility (SMF). For unifying these requests, z/OS Connect service definitions use the serviceGroupingName string when each of these services are defined in the z/OS Connect configuration. You can set up the serviceGroupingName data to be common for each service, such as 'ACCOUNT_INFO_HISTORY' and the result appears in the z/OS SMF records for each request enabling them to be correlated together for analysis or chargeback purposes.

Separating mobile or web requests scenario (Retail scenario)

A retailer wants to separate web requests to applications on z/OS systems out from requests that are coming from their new mobile platforms. You can easily accomplish this task by defining and configuring distinct z/OS Connect service definitions to use the same service provider configuration which enables multiple REST services to call the same assets, but the calls are recorded and secured with different criteria. Requesters from mobile platforms are authorized to use one set of services using REST, while calls from non-mobile, web-based requesters are authorized to use a separate set, both accessing the same assets but tracked separately. All the data is recorded in the z/OS Connect SMF 120 subtype 11 records and are accessible by using standard z/OS auditing and tracking mechanisms.

Reaching traditional z/OS batch assets by using REST and JSON (Insurance company scenario)

A large insurance firm wants to reach a set of Cobol batch applications that contains some sophisticated business logic that was developed over many years. Conversion of this application to a newer language and runtime environment would be costly and high risk. A solution to access the business logic in this application from mobile and web-based requesters is much less risk and enables other business systems to take advantage of the established applications.

With the WebSphere® Optimized Local Adapters support in Liberty and the z/OS Connect WOLA feature activated, this application can be reached using REST calls and JSON content with little effort. The target Cobol application program requires updates to use the WOLA APIs to register with the Liberty server and start accepting requests. A z/OS Connect service definition is required, as well as the binding file that contains the information about the data it expects to receive. You must copy the return data to the path of the binding file of the z/OS Connect server. After enabling the use of the z/OS Connect and the WOLA APIs, this batch asset is effectively online and available for authorized z/OS Connect REST clients.

Discovery of z/OS assets and information about request and response payloads

You want your cloud provisioning or API management tool needs to generate a catalog of assets that are published on a specific z/OS system. This tool needs to inquire about these assets and store them, along with some context associated with each asset. The tool also must include information about what is required to create request data that is passed to the service and information about what the service returns as the response.

z/OS Connect offers a way to discover all the services in its configuration with a simple REST call. When an HTTP GET request arrives for https://host:port/zosConnect/services, a list in JSON form is returned and contains all the services that the current authenticated user is permitted to see. From this list, you can retrieve the URLs for each service and query each service by using an HTTP GET to return the request and response JSON schema information. You can save the service reference (URL for the service), service textual description, and the JSON request and response schemas in the tool's catalog for retrieval at a later time. Enabling access to the JSON schema means that the tool might easily be configured to generate a REST call to pass to z/OS Connect, with an appropriate JSON-based parameter list, for use by the target z/OS Connect service.