API Strategy for Terminal-Based Applications
API Strategy for Terminal-Based Applications
In this article, see how to quickly build APIs for any terminal-based environment (IBM i, VT, HPE NonStop, IBM Z) in five simple steps.
Join the DZone community and get the full member experience.Join For Free
How to quickly build APIs for any terminal-based environment (IBM i, VT, HPE NonStop, IBM Z) in five simple steps.
By Jeroen van Dun, Senior Manager of Product Management at Rocket Software.
“Can you expose this functionality as an API by the end of this week? Thanks!”
If you work in the IT department of a large organization, that question might sound very familiar to you. “This functionality” typically refers to a workflow or function that is available in one of the older, terminal-based applications that your department supports. Initially, your answer to that question would be “Yes, of course!” After all, in the end it is all just all bits and bytes, right?
The only thing you need is time. Time to find out whether the vendor offers a newer version of the application that offers APIs out of the box - and time to test that version and time to deploy it to production. If the vendor doesn’t have a version that offers APIs, you need time to find out whether there is source code available or time to do some research to find the optimal integration point. And that is where the challenge lies: time. There just does not seem to be enough of that. You need to deliver that API by the end of the week or else you will show up as an impediment on the team’s agile board. And no one wants to be on the “wall of shame.”
So how do you meet an aggressive deadline while doing the right thing? How do you buy yourself time? The good news is that even though you can’t magically add more hours to the day, you can save time when it comes to creating APIs.
Step 1 — Defining the Interface of the API
Defining the API isn’t complicated, but it needs to be thought through before you start coding. Naming and data type models all need to be considered. This is something that cannot be rushed, because once you make the API available for consumption you can’t easily make changes to its interface without the risk of breaking the applications that consume it. For most cases, this will match the current input and output of the functionality in the terminal application:
Step 2 — Implement the API Using a Screen Recorder/RPA Tool
The quickest and easiest way to expose functionality in a terminal-based application as an API is by mimicking what the application user is doing today. The benefit of this approach is that application experts can validate and verify the steps you record. Make sure you ask the expert about any exceptions that might occur, because just recording the happy path will probably not cut it.
Because the definition of the API is based on the actual input and output of the functionality in the terminal application, implementing the API using the screen recorder is really straightforward:
Step 3 — Look for Ways to Optimize the API
With the API published, you now have time to research whether there might be more efficient ways to implement it. Response times are critical, so if it is possible to speed up the execution of the API, you should look into these. One possible option could be to investigate whether you can bypass the terminal screen and directly invoke the business logic of the application. Another could be to try to access data in the applications storage system (a database for example). In the example below it turns out that it is possible to directly call the business logic because the application exposes a callable program called ‘GetCustByNr’:
Step 4 — Update the Implementation of the API
Let’s assume that directly calling the business logic of the application proved to be faster than the screen recorder implementation. Before you switch to this faster implementation it is important to take a few things into account:
1. The interface of the business logic procedure is very different from the interface you defined in Step 1. You will need to do some field mappings and type conversions. CUSTNR, for example, is defined as a zoned decimal in this example. In the API defined at Step 1, ‘number’ is defined as a ‘string’ type (yes, I did that on purpose because I needed a type conversion example!)
2. Input validation/formatting. This is typically handled on the screen level, and it is possible that the business logic procedure has no checks/error handlers in place. This means you have to make sure that the input (and output) data is valid and any exceptions are handled.
3. This brings me to point 3: testing! Ideally, you run both implementations of the API side by side for a while. If the result of the business logic implementation version of the API differs from the result of the screen-based API then you obviously missed a scenario.
Step 5 — Monitor the Application Lifecycle
With building APIs on existing terminal applications comes great responsibility! Remember my comment in Step 1: you can’t change the interface of the API because it would break applications? Well, the same applies to the underlying application. If someone decides to update the underlying application, those changes might break the API.
Keep in mind that the person who is making the application changes might not even be aware APIs were built on top of the application. Fortunately, there are standard solutions out there that will help you manage and coordinate changes to the underlying terminal application and its dependent APIs so you can innovate, at your own pace, without disrupting the business.
Opinions expressed by DZone contributors are their own.