For companies running their ERPs and line of business applications on IBM i or mainframe, the ability to rapidly connect applications to an ever-increasing number of cloud and third-party services is critical for business success.
IBM i (AS400, iSeries) is a modern, powerful, and secure platform optimized for running complex and diverse workloads. The recent versions of the system have several integration options available out of the box, including integrated webservices, the Apache HTTP server, and XML services, as well as a host of available Node.js, PHP, and Java-based options.
We all know that having choices always beats the alternative, right? In this article, I present one more option and show how to run Mule on IBM i.
Taking it straight from the donkey’s mouth:
“Mule, the runtime engine of MuleSoft Anypoint Platform, is a lightweight Java-based enterprise service bus (ESB) and integration platform that allows developers to connect applications together quickly and easily, enabling them to exchange data.”
MuleSoft offers its platform in community (open source), enterprise (commercially licensed), and cloud (fully managed) editions. Even the free Community Edition comes with a large number of out-of-the-box connectors, making it a great low-code integration platform that excels at integrating with various systems and transforming the messages from one format to another. Depending on who’s counting, Mule is considered as (one of) the most popular ESBs.
Why would you want to run Mule on IBM i as opposed to a separate server or a cluster? Long term, the single responsibility and separation of duties is one of the key factors for success. Delegating XML/JSON parsing and composing TLS/SSL and data transformations to Mule (or similar low-code integration platforms) while keeping the business rules close to the back-end ERP systems seems to shorten time-to-market and optimize the operational overhead.
Remember, IBM i shines when running a diverse mix of data, UI, back-end, and integration workloads on the same server. That being said, your actual mileage may vary. The choice of IBM i versus other deployment options depends on many factors such as the place and prominence of IBM i in the company’s infrastructure landscape, the average/peak loads on the system, integration use cases, skill availability, etc.
Now, for the fun part! Below are the steps I went through to run Mule on IBM i. My system is at version 7.3 with Java 8 and the latest PTFs, and I am using Mule Community Edition for the purpose of this exercise. The Mule Enterprise Edition should work just as well.
The very first step is to ensure that the latest PTFs are applied to IBM i server. Then, confirm or define the localhost IP route:
CFGTCP -> Option 1. Work with TCP/IP interfaces.
There must be an interface with Internet address 127.0.0.1, Subnet mask 255.0.0.0, and alias name
= LOCALHOST. Create one if not already defined.
I downloaded Mule CE runtime to my local system.
Next, I created a new folder on IBM i
/home/dkuznets/muleCE and FTP’ed the Mule Runtime ZIP file to IBM i IFS folder
ftp <IBM i> <user> <password> bin cd /home/dkuznets/muleCE put <mule zip>
Once the transfer was completed, I opened the PASE terminal by typing
CALL QP2TERM on the IBM i command line. Most of the IBM i steps are performed in that terminal environment.
I unzipped the files with the Java archiver:
cd /home/dkuznets/muleCE jar xf <mule zip>
Next, I tried to run the server in console mode:
cd /home/dkuznets/muleCE/mule-standalone-3.8.1/bin ./mule start
But I got an error right away:
> ./mule start MULE_HOME is set to /home/dkuznets/mulece/mule-standalone-3.8.1 Your machine's hardware type (uname -m) was not recognized by the Service Wrapper as a supported platform. Please report this message along with your machine's processor/architecture.
Clearly, the startup script doesn’t recognize the server type. I called
uname from the command line and got OS400. No problem — knowing that PASE is essentially AIX, I edited the startup script
/home/dkuznets/mulece/mule-standalone-3.8.1/bin/mule to add the section below so that OS would essentially report its AIX:
DIST_OS=`uname -s | tr [:upper:] [:lower:] | tr -d [:blank:]` case "$DIST_OS" in <various os uname mappings> # Dima - added IBM i mapping below 'os400') DIST_OS="aix" ;; # Dima - end of IBM i mappings section 'aix') DIST_OS="aix" ;;
I saved the changes and tried to start Mule again. This time, it got through the machine version check, but got a new error:
> ./mule start MULE_HOME is set to /home/dkuznets/mulece/mule-standalone-3.8.1 Unable to locate any of the following binaries: /home/dkuznets/mulece/mule-standalone-3.8.1/lib/boot/exec/wrapper-aix-ppc-32 /home/dkuznets/mulece/mule-standalone-3.8.1/lib/boot/exec/wrapper-aix-ppc-64 /home/dkuznets/mulece/mule-standalone-3.8.1/lib/boot/exec/wrapper $
After a bit of googling, I found that Mule uses Java Server Wrapper to run as a Windows service or Unix daemon. I downloaded the 32 and 64 bit versions and FTP’ed to the
I started the Mule server again, and it worked!
> ./mule start MULE_HOME is set to /home/dkuznets/mulece/mule-standalone-3.8.1 Starting Mule... $
Mule logs are located in the
<mule home>/logs directory and show that the server and deployed apps are up and running:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Mule is up and kicking (every 5000ms) + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Now that Mule is up and running, we need a way to monitor and control the servers. For the Enterprise Edition, I can use the Mule Management Console or cloud-based Runtime Manager to control the server, applications, flows, and messages. For the Community Edition, the Mule server can be configured with JMX hooks that can be controlled with JMX tools such as JConsole or Java Mission Control. Below are the steps to configure JMX agent for Community Edition:
Stop Mule server by keying in
Create a new Mule application JMXAgent in your Studio and add the code below:
<?xml version="1.0" encoding="UTF-8"?> <mule xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:management="http://www.mulesoft.org/schema/mule/management" xmlns:spring="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation= "http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd http://www.mulesoft.org/schema/mule/management http://www.mulesoft.org/schema/mule/management/current/mule-management.xsd"> <management:jmx-server> <management:connector-server url="service:jmx:rmi:///jndi/rmi://127.0.0.1:9000/jmxrmi"/></management:jmx-server></mule>
Restart the server. In your dev environment, type
jmc to open the Java Management Console. Go to File > Connect... then select New Connection and provide an IBM i host and port name (in the above example, the host is the IBM i host as seen from my dev laptop, with port 9000).
Now that the Mule server is running on IBM i (iSeries/AS400), you can provide or consume APIs directly from IBM i applications.
To recap, in less than an hour, we can get a comprehensive integration platform up and running directly on IBM i so that it can play the role of an edge integration server that simplifies connecting IBM i applications to enterprise integration platforms or of an integration hub in the IBM i-centric IT environments.
In my previous articles, we already walked through how to build Mule flows that natively communicate with IBM i programs, databases, and data queues. Next on my todo list are the use cases of streaming the IBM i log data to monitoring and alerting services such as Splunk or ELK, and integrating IBM i applications with event streams such as Apache Kafka. Stay tuned!