Join the Digital Economy without rewriting code

Behind the Digital Economy is the rapidly growing API Economy. APIs are the digital interfaces that enable organizations to provide their application data and functions to different parties internally or externally.

By Juergen Lind, Director, Product Management, Adabas & Natural, and Bernhard Fricke, Sr. Lead Software Specialist, Software AG

Issue 4, 2018	Download PDF

A simple example that demonstrates how the API Economy works is how restaurants, banks and retail shops help their customers find their location by adding mapping services from Google Maps™ to their mobile apps or web pages. In this win-win exchange, the mapping service companies earn money by contracting out their mapping expertise to other organizations that can then provide their users the best-in-market mapping services without having to invest in a capability that is not part of their core competence. In a true Digital Economy, you will get paid by others using your APIs.

Fig 1: The API Economy

APIs can be used by other developers inside large organizations, among organizational units and externally. It is the new way of interacting in a 100 percent Digital Economy. APIs can be used by other developers inside large organizations, among organizational units and externally. It is the new way of interacting in a 100 percent Digital Economy.

The secret of how mainframe apps participate in the Digital Economy: REST

So how can you meet the demands of the Digital Economy? How can you be agile and quickly turn around new functions on new devices, when you have a legacy system on the back-end? Fortunately, your mainframe applications can easily play a role in Digital Economy without requiring application rewrites or cumbersome service creation thanks to a new architectural style called Representational State Transfer (REST).

Of course in principle, you could rewrite your mainframe applications to participate in the Digital Economy. Unfortunately, for most companies, this is a non-starter. Not only is the pressure for fast time to market incompatible with the development time required to reprogram mainframe applications, but the cost and risk associated with a rewrite are too high for this to be a viable option.

With EntireX generated REST APIs, the undeniable value of the data and functions that sit within your mainframe applications can easily be exploited and brought to the forefront of the Digital Economy. COBOL, Natural mainframe programs and REST— those irreconcilable technologies, originating from different decades—will work together seamlessly.

Natural hands-on example

Let’s take a closer look at a concrete example: Imagine an existing Natural server called EMPLOYEE. It implements the access logic for a LIST and DETAILS function to a database view EMPLOYEE:

Fig 2: API extraction of Natural Server EMPLOYEE with EntireX

With EntireX, you basically develop the scenario in three phases as shown in Fig. 2: 1 extract the server interface, 2 the REST resource, 3 test REST resource.

Extract the server interface

Switch to EntireX perspective, invoke the IDL Extractor for Natural and select the Natural server EMPLOYEE. Check Redesign the interfaces to shape the Natural server to produce a user-defined mapping. Extract two interfaces out from the single Natural server EMPLOYEE: getListOfEmployees and getDetailsOfEmployee.

For details see EntireX documentation: Common Integration Scenarios > REST Scenarios > Calling Natural from REST. Another useful source is the earlier TECHniques article “How to shape a call to Natural from webMethods Integration Server – the modern way” (see (1) under related articles).

Generate the REST resource

In the context menu of a Software AG IDL file, choose Integration Server > Generate webMethods IS Connection; select radio button Create a new EntireX Adapter connection ; in the drop- down box choose EntireX RPC Connection ; mark the Create or Update REST resource check-box; press Next and define the properties for the Adapter Service, such as Package, Connection name etc; press Next and specify the REST resource name ; press Finish. That’s it...

Fig 3: Generation of REST Resource with EntireX

Test REST resource

Use an appropriate REST client, specify URL, method and headers and invoke your REST resource:

Fig 4: Test REST Resources

Provide COBOL assets as REST resources

Even COBOL can play a part in the Digital Economy and can be provided as a REST resource with EntireX: For the purposes of REST Resource generation, it does not matter whether the API extracted originates from a Natural or COBOL source. To extract the API from a COBOL source refer to EntireX documentation: Common Integration Scenarios > REST Scenarios > Calling COBOL from REST or the earlier TECHniques article “How to shape a call to COBOL from webMethods Integration Server – the modern way” (see (2) under related articles).

Summary

As we have seen, with EntireX only a few clicks are required to provide your Natural or COBOL mainframe assets as REST resources. With REST APIs, your mainframe services can be used in the same way as any API from a recent start-up or established internet business. Users will not even notice whether it came from a mainframe or not. Your mainframe application can play a central role in the API Economy by hosting the most valuable data and business services in your organization. Thanks to EntireX and REST, every modern tool set can work with it. Your mainframe data and services will no longer be considered proprietary.

REST support is available with EntireX 10.3 (GA: 2018Oct). To learn more, read Common Integration Scenarios from the webMethods EntireX documentation.

Related articles

“How to shape a call to Natural from webMethods Integration Server – the modern way" TECHniques, July 2016 (Issue 3).

“How to shape a call to COBOL from webMethods Integration Server – the modern way" TECHniques January 2018 (Issue 1).

Glossary of terms

*API * – Application Programming Interface

*User-defined mapping * - advanced extractions to shape a call to COBOL

*CVM * - client-side server mapping file resulting from user-defined mapping.

*IDL * – Interface Description Language

*REST *– Representational State Transfer an architecture style to model the structure behavior of the World Wide Web

*IS * – webMethods Integration Server