Opening Mainframe Transactions Through an API Layer

An anonymous public-service engagement adding request and response mapping around CICS transactions while retaining the mainframe as the primary business system.

Open an interface around the retained business system

A public-service organization relied on a mainframe for citizen-service transactions. Staff used terminal screens, while new mobile, web and partner integrations needed programmatic access to the same business functions. Replacing the core system would have combined an interface project with a much larger change to established transaction behavior.

Ampity developed an API layer around the mainframe's CICS transaction interfaces. Request mapping translated the external API contract into the transaction representation, and response mapping produced JSON for consumers. The mainframe remained the primary business system. The customer's identity is withheld.

Keep transaction access separate from screen automation

The existing integration problem included screen scraping. That approach tied a consumer to a presentation intended for an operator, including the sequence and layout of screens. The chosen design instead addressed transaction interfaces, with the API layer responsible for the external representation.

The distinction shaped the engineering boundary. A gateway could receive and route a request, but the mapping layer still had to represent the business operation correctly. Field names, identifiers, missing values and transaction outcomes could not be inferred merely from a successful HTTP exchange.

Continuity of the citizen-service workflow, controlled changes and auditable data access were requirements. Retaining the mainframe limited the scope of replacement; it did not establish that every new API path met those requirements automatically.

Choose an additive layer over a replacement programme

The alternatives were a full core replacement, APIs built around screen automation, and a transaction-level interface. A replacement would have moved business behavior and its operating responsibilities as well as access. The selected transaction layer kept the integration work focused on the retained core's capabilities.

This choice also created a component to operate. The API contract, mapper, gateway and read caching needed ownership alongside the mainframe. Adding a modern interface did not remove the existing system's support needs or make its transaction behavior interchangeable with a new application.

For another organization, retaining a core system is an option to evaluate, not a rule. An unsupported transaction interface or a required business change inside the core can alter the decision. A wrapper should not conceal a dependency that the organization can no longer maintain.

Map requests without moving business authority

The work separated consumer-facing REST requests from mainframe transaction formats. Responses crossed the reverse mapping into JSON. Read caching was part of the design for read-heavy endpoints; its presence did not move transaction authority into the cache.

A similar implementation needs a declared meaning for each mapped field and outcome. An empty value, an absent field and a rejected transaction may need different external responses. A date or identifier should retain its business meaning across the translation, including any leading characters or formatting the consumer depends on.

Caching needs its own scope. Identify which reads may be reused, which caller permissions still apply and how freshness is represented. A cached representation cannot stand in for confirmation that a new transaction completed. These are review conditions for reuse, not additional controls or test results attributed to this engagement.

Build consumers against the transaction contract

APIs were developed incrementally around selected transactions, with comparison against mainframe behavior before release. Mobile application work proceeded alongside the API work. The sequence kept the consumer contract and the retained business operation in the same delivery conversation.

For a comparable review, start with permitted interface definitions and existing sanitized examples. The worksheet below is a proposed acceptance record, not a completed test report from this project. A reviewer should be able to explain one mapped operation without depending on a screen recording or an undocumented conversation.

Any later rehearsal requires an approved isolated environment, synthetic or authorized sanitized inputs and transaction substitutes that cannot change real citizen records. Bound load and access before sending requests. Stop on an unexpected data disclosure, an unexplained mapping difference or a path reaching live writes.

Returning to an earlier API release affects future requests. It cannot undo a transaction already committed by the core. If a response is lost after submission, preserve the operation context and use the approved reconciliation path before repeating it. A timeout alone does not establish that nothing happened.

Scope without an adoption or availability benchmark

The engagement covered transaction-facing APIs, request and response mapping, read caching and incremental consumer integration around a retained mainframe. No numerical adoption, office-demand reduction, performance, delivery-duration or uninterrupted-operation result is published here.

Begin with the operation that needs a new consumer

This approach is useful to evaluate when a supported transaction interface can serve a required consumer without replacing the core business system. It is less suitable when the intended behavior is absent from that interface or when maintaining the retained system is itself the unresolved problem.

Take one proposed operation and identify its consumer contract, mainframe outcome and uncertain-response policy. Use the legacy modernization guide to compare retaining, refactoring and replacing the affected capability. The live modernization paper addresses authority and coexistence beyond this interface boundary.

Technical reference

AWS's anti-corruption layer guidance describes translating between systems with different semantics and the additional operating and latency responsibilities of that layer. Its strangler fig guidance discusses incremental replacement and proxy risks. A retained-core API wrapper does not imply eventual replacement, microservices or an AWS deployment. These references explain general design considerations, not this engagement's CICS configuration or measured results.