Creating Web Services APIs Can Be Easy On IBM i
September 16, 2020 Andrew Ireland
Many IBM i customers are taking a hard look at how they can bring their heritage applications, along with all the significant business value they contain, into a modern world. There are a number of different approaches to do that, and in reality, these methods work together and complement each other. There is no one single route, but rather a combination of approaches that leads to the best results at the lowest cost and the least grief.
The average IBM i customer has something in the order of five million lines of code that embody their mission critical applications. Companies want to leverage that code to create flexible application programming interfaces or APIs and Web services – the building blocks of modern software.
But quite often, within that heritage code, there is complex business logic that would require gargantuan effort to rewrite in a modern language. When I entered the workforce decades ago, knowing full well there is very little perfect code out there, my first boss told me that programmers did two things: they debug and they bug . . . . But if we look at the code contained in our IBM i applications, we’ve likely been debugging it for 20 years or even 30 years by now. We therefore know this is rock solid code, an invaluable asset and a likely competitive advantage. It makes business sense to take that rich code and make it easy for programmers and even power users to wrap it and turn it into a service.
This, in short, is why we created ARCAD API, a solution which takes heritage applications using the 5250 green screen protocol and allows portions of that code to be accessed, wrapped up, and turned into a Web service that can be called like any other API by programming languages old and new.
ARCAD API works by allowing programmers and users to iterate through the application screens, keying in values in fields and wrapping that up into a complete transaction. This is far easier and cheaper than rewriting code. By generating a Web service automatically, programmers no longer have to figure out which rules and logic are somewhere buried in the code. Most applications are not just running SQL requests against a database. There is typically a lot of validation that happens. And in reality, at most IBM i shops, most programmers have not separated the business logic from the actual program logic and quite often the database rules are buried inside the RPG code instead of being encapsulated stored procedures and triggers down in the database. In a perfect world, a lot of that logic would be located inside the database, thus simplifying the application code, but that’s not the reality on the ground. And, significantly, in many cases, some functionality that programmers or power users need can be strung together from multiple 5250 screens, maybe three or four in a lot of cases.
Moreover, a chunk of that five million lines of heritage application code at the typical IBM i shop has no business value to convert to Web services or rewrite in another language. There are, for instance, batch reports and batch processes buried in the applications that do not need such a conversion.
But using ARCAD API, it might take a couple of minutes to create a Web service as opposed to writing a new web service from scratch, which might in some cases take 20 days of effort. And to what end? Just to move something to Node.js or Java or PHP? To get the same result as you would get if you just accessed several fields in a 5250 application? It makes much more sense in a lot of cases to unlock the value in those proven heritage applications, which have been customized over the years to meet specific business requirements. Unfortunately, using other methods such as 5250 emulation or screen scraping, this may not result in the sexiest looking applications. The beauty of ARCAD API is that it allows you to take that code and rapidly expose in the form of as a service to be consumed by any number of more modern “front-end” technologies.
With ARCAD API users are completely shielded from application internals. They literally iterate through a series of screens and drag and drop elements to rapidly build APIs. This way, no one has to write any code in any language. ARCAD API discovers the parameters and builds metadata around them in order to construct Web services, which is easier than using macros. That is why we expect that business analysts, who are not expected to have programming skills, will be able to create Web services autonomously. All they need to know, from a data entry perspective, is what information is contained within in the system, how the application works and what information they need to drive a new application. With this knowledge alone, they can then generate API services using the tool ready to be consumed by anyone in the organization. We are of course not advising that you let all end users loose on creating APIs, but we do safeguard the process further with our testing tools – particularly ARCAD Verifier and ARCAD i Unit – in order to automate the testing of these APIs created from the 5250 data stream to validate that it they produce the expected result set.
ARCAD API is particularly useful for IBM i shops in another regard. For IBM i customers who either no longer have access to their source code (or never did because they are using vintage third party applications), the only way to modernize code is by rewriting it. So now, this easy alternative of simply walking through the 5250 screens to create APIs from elements of the application is an attractive way to modernize at least some of the functionality of those applications. This may only be needed to extend somewhere in the order of 10 percent of those 5 million lines of code, but by leveraging that 10 percent it is far easier for customers to create extensions to applications or whole new applications.
As an example, let’s say I need to do a transaction and then return a value, for instance. The underlying applications might do fifty validations and write to ten files, and thanks to ARCAD API the programmer or user does not need to know what those fifty validations are or what ten files are written to. They just need to know how to enter data in those elements of two, three, or four 5250 screens that comprise a particular subset of transactions that are being encapsulated in the API.
The other way that ARCAD API is useful is to bridge the gap between RPG programmers that are familiar with the IBM i architecture and the heritage applications that run the company and those programmers using new languages such as Java and PHP who might be working on new applications that need access to data stored in the IBM i platform. ARCAD API can capture elements of a transaction and within two to three minutes there is a Web service API that Java or PHP developers can now use to consume or generate information in the system. This takes away the obstacle of understanding an unfamiliar technology. Those IBM i shops that are already using RPG Free Form can already onboard Java or PHP programmers to work with modern RPG code. But for those companies whose applications are still on column-based RPG – and that is the majority of the IBM i base – this can be a real challenge for the young developers who don’t think in columns.
We see ARCAD API very much as one tool among many to help customers modernize applications. There will be certain parts of the applications that companies will want to rewrite. There will be other parts for which a tactical solution such as ARCAD API is a better fit, in order to very rapidly start to deliver Web services APIs to front-end developers, for example. And finally, there will be other parts that warrant a deeper modernization, starting with ARCAD Observer for application discovery, transformation to RPG Free Form using ARCAD Transformer RPG and potentially a conversion to SQL using ARCAD Transformer DB.
If you want to try ARCAD API, we are giving customers access to a 60-day, fully functional, free trial version of the software, which you can download at this link.
This content is sponsored by ARCAD Software.
Andrew Ireland is Global Alliances Manager and DevSecOps Business Manager at ARCAD Software.
RELATED STORIES
ARCAD Generates APIs From 5250 Screens
ARCAD Unveils GUI Modernization Tool
