One IBM i Route Into the API Economy
September 27, 2017 Alex Woodie
The so-called API Economy is emerging as a legitimate engine for driving the growth of commerce around the world. But with mostly monolithic apps written years ago, the IBM i installed base isn’t well positioned to be a major player. However, there are alternative pathways into the API Economy for IBM i shops, if they know where to look.
The API Economy refers to the idea that, by exposing bits and pieces of our internal systems out to the world through well-defined application programming interfaces (APIs) – which usually manifest REST-based Web services, although SOAP and XML files will work too– we can create new services and business models that didn’t exist before. As more and more businesses expose their APIs, the network effect kicks in and we see a flowering of commerce across the Internet manifesting with the capability for users to assemble new apps and services using a veritable smorgasbord of available APIs.
While Web-based software as a service (SaaS) apps such as Salesforce and Netsuite are the driving forces of the API economy, there’s nothing preventing companies with on-premise systems from partaking of the increased revenues it can bring. Ideally, a company embarking into the API Economy had the forethought to develop its applications using modern concepts, including compartmentalizing business logic into individual micro-services that can be called upon as needed and have few outside dependencies.
That, unfortunately, doesn’t describe the typical IBM i shop. Anecdotal evidence says most IBM i shops run a packaged or homegrown application, often developed in RPG, that originally was developed more than a decade ago — and sometimes much longer ago than that. These applications are typically monolithic in their composition, which raises the difficulty level considerably for anybody hoping to break them into constituent components that can be readily packaged as an API or a microservice.
But before you give up on the API Economy, realize that there are other avenues into the system. Remember this: While these monolithic RPG and COBOL applications were developed long before the Web browser became the standard graphical user interface (GUI), that didn’t stop IBM i shops from developing Web and mobile GUIs for these apps. It just required another approach.
It’s an approach that’s advocated by Rocket Software with its Rocket API product. The Rocket API has multiple methods for exposing IBM i business logic as REST, SOAP, or XML APIs. Getting into the target system, however, is the challenge. If the IBM i app was developed with Java, it can tap into the JT400 driver, or if the database is well organized, it can leverage existing stored procedures.
But if these pathways don’t work, there’s one other method to get in: 5250 emulation. By essentially watching a user navigate a program through a 5250 terminal, Rocket API can “learn” how the program works, and then bundle that learning into a REST, SOAP, or XML-based API. This lets third parties access that system through the 5250 interface, even though the third parties only see the modern API types.
This approach has worked well for Kirona, a UK company that offers workforce optimization solutions for organizations whose workers spend most of their days in the field. The company oversees the daily scheduling of about 60,000 workers on behalf of its clients in the healthcare, property management, logistics, telecommunications, utilities, and construction industries.
The challenge for Kirona stemmed from the fact that it schedules workers and handles all the paperwork and communications on behalf of so many clients. Many of its clients have newer ERP systems, such as Oracle E-Business Suite or SAP Business Suite, that sport modern API interfaces that speak REST. Hooking into these systems was easy for Kirona. For other types of businesses, it may arrange to use XML as the integration medium, or even a flat file drop, which requires a bit more work.
However, Kirona sometimes encountered client systems that couldn’t be accessed in these manners, according to Kirona CTO Neil Harvey.
“Occasionally a challenge comes along where there is no API or a vendor wants to charge a prohibitively high price to buy that API, or it’s a bespoke legacy system that’s been hanging around the customer for 20 years and they have no idea how it works or how to integrate with it,” Harvey tells IT Jungle. “That’s when we need the Rocket API. It’s the only way we can access the systems.”
Kirona is currently working with a National Health Service (NHS) office in Scotland to find a way into a legacy application originally developed by another NHS office. Kirona will be managing the daily scheduling of 1,000 nurses in the region, but getting access to the system was a real problem.
“There’s quite a few NHS Trusts who are using the system, but there’s no API to it. There’s no access into a database. There’s no stored procedure,” Harvey explains. “The only way to get data in and out is through the user interface, which is a ColdFusion Web-based application.”
Before the company started using the Rocket API product, it was up a loch without a paddle. “The only way we could possibly have done it is effectively create some kind of a flat file extract that we can pull out on a weekly basis and load into a database somewhere and then try and somehow handball the data back in once the jobs were complete,” Harvey says. “It really wasn’t a viable solution for us without Rocket API.”
Once the NHS implementation is online, Harvey expects it Kirona to be generating 100,000 transactions per day against the NHS application for about 20,000 jobs. Thanks to Rocket API, the integration will be handled programmatically.
“We don’t deploy Rocket API in every single implementation,” Harvey says. “It’s a tool we have in our kitbag. In an ideal world, we have a nice clean API that we can talk to. It doesn’t make any economic sense to do this kind of solution on a system where you have other ways of getting into it. But if you’re handballing data, it’s a waste of time.”
None of Kirona’s clients currently are using IBM i-based systems, according to Harvey, who says it’s mostly Windows, Unix, and Linux. But there’s nothing stopping the company from working with IBM i shops if it needs to.
According to Rocket’s Magid, most Rocket API customers are using it with IBM i applications. “We made a strategic decision a few years back to focus on this whole idea of the API Economy, and helping our customers, whether they’re IBM i or Unix/Linux or Windows or IBM z customers, to expose the existing capability that they have in these applications that they’ve built over decades and to make them available over APIs, and to make that very, very easy, and to do it in a way that doesn’t force them to change the existing code base,” he says.
“It’s been around for a while, but we weren’t really focusing on it that much,” Magid continues. “It has become one of the hottest things we have across the entire Rocket portfolio right now.”
