APIs are helping companies grow revenue, reduce costs and streamline business processes. It’s been exciting to see how many IBM i users have begun implementing an API strategy to connect their IBM i applications with their customers, business partners and with the latest technology. One of the key lessons we have learned is that you can dramatically increase the value of an API and simplify the API maintenance by API enabling a business process rather than just the update to the database.
Don’t get me wrong, there is significant value to creating an API interface to database updates. By API enabling database access (rather than directly accessing the database via SQL), you can add sophisticated authorization and authentication functions like JSON Web Tokens (JWTs) and OAuth, you can sanitize the incoming data to ensure it is valid, you can trap errors and log them, and you can manage all the database connections in one place.
However, one of the key benefits of API enablement is you can build orchestration and business process functions directly into the API. For example, instead of creating an API that directly adds an order record to an open order file via SQL, you can create a “New Order” API. In the New Order API, you might add functions like checking the customer’s credit, checking available inventory, and verifying the customer’s address. You might want to add authorization and authentication functions like JWTs and OAuth. All of these functions can be added to the API code. Loose coupling between the application calling the API and the application being called means you can make changes on either side of the API without breaking the communication. You can add functions (eg. send out a confirmation email or text), change functions and even change the database schema without breaking the API connection.
We have several customers who are using these orchestration functions to call public APIs as part of their API business process. We are working with an insurance company that needs the latitude and longitude of a property to provide an accurate quote. Sometimes that latitude and longitude comes with the API request and sometimes they only get an address. Their API code looks at the incoming data. If it includes the latitude and longitude it calls the RPG quoting program. If it does not include the latitude and longitude, it automatically calls out to the Google Maps API with the address to retrieve the lat/long before calling the quote program. We have other customers who include software development kits from Amazon or Shopify for calling their APIs which perform the authentication and data serialization functions for them automatically. In both these situations, the customer is able to update their RPG code without breaking the API connection.
Using JavaScript for the API code makes adding functions to your APIs simple. You can simply download existing modules for things like OAuth, JWT processing, label printing, dashboard creation, and so many other functions. There are over 1.7 million open source JavaScript modules to choose from. Using JavaScript for APIs is right in line with IBM’s strategy for “blended” application development in which you always choose the right language for the job. JavaScript is purpose built for web services. By connecting it to your core RPG applications, you get the best of all worlds – highly functional, secure APIs that support the latest technology.
If you want to learn more about creating business process APIs with JavaScript and RPG, just reach out to us at www.eradani.com or via email at info@eradani.com. We have worked with a wide variety of IBM i users across all industries to help them implement their IBM i API strategy.
