Modern enterprise architectures shift from all-encompassing ERPs to a network of smaller components that address specific business capabilities and communicate via common integration channels such as APIs. In some cases migrating to new system or best of breed may work. For most companies, however, the complete replacement is a risky and expensive proposition. Most successful modernization initiatives use a hybrid approach. Core line of business ERP systems are revitalized while some non-differentiating components that run industry standard processes may be replaced with purpose built applications or services.

The ERP components typically communicate with each other via shared database, resulting in a complex web of bi-directional real time integrations. When migrating a part of such system, these implicit inter-process communications must now be brought to light. The success of the project often depends on the speed of implementing these use cases. Comprehensive integration platforms such as Mulesoft Anypoint help delivering integrations at scale.

In this post I will show how to implement a real time external API call from IBM i (AS400) application using Mulesoft Anypoint, AS/400 connector, and Web Transaction Framework.

Let’s start with the business requirements. For this example we will build a currency conversion function that other IBM i programs can call in real time, pass in a pair of currencies, and get back the exchange rate.

Now let’s think about implementation. There are many ways to do it on IBM i. Based on my experience, dealing with JSON, XML, HTTPS, proxies in RPG is possible but has learning, development and support overhead. The approach we took here is to delegate all this work to Mule. WebTF and AS400 connector take care of communications between IBM i program and Mule via lightweight messaging (Data Queues). This leaves the interface program to just call WebTF, pass in the request and get back the response. Nothing to parse, no data queue operations to worry about. 

Full source code for the program can be found here.

Here’s a Web Transaction Framework definition for this interface:

WebTF has a pair of data queues defined for each interface. When called, it generates a unique transaction ID, places request to data queue, then waits for the response message. It can be configured to time out and retry for specific number of times. WebTF keeps track of each transaction status and start / finish date times and can be integrated with external monitoring tools such as Splunk.

Now let’s take a look at Mule code. We use AS400 connector to continuously listen for IBM i requests. When new request arrives, we pass the data to Currency Exchange API, format the response and send the message back to IBM i response data queue.

Finally, let’s start the flow and test it from the IBM i side:

As mentioned before, WebTF keeps track of transaction status, start and end time, providing operational metrics such as average / peak transaction counts per interface and processing times. It is also very useful for setting up integration monitoring and alerting processes, where IT support can be notified when transaction fails, or when the total processing time degrades, pointing to the potential issue that IT support can proactively check before stuff begins to blow up.

To recap, we created one very simple RPG program and one simple Mule flow. WebTF and AS400 connector hide low level communications between RPG and Mule. IBM i developers don’t deal with JSON, XML and HTTP, Mule developers focus on data transformations and process orchestration.  The code for this template is available on github and can be used as a starting point to implement similar interfaces at scale. 

https://github.com/infoviewsystems/IBM-i-Mule-API-Consumer