How to Run Mule on IBM i
For companies running their ERPs and Line of business applications on IBM i or mainframe, ability to rapidly connect the applications to 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 Web Services, Apache HTTP server, XMLSERVICES, as well as a host of available Node.js, PHP, and Java based options. And we all know that having a choice always 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 it’s platform in Community (open source), Enterprise (commercially licensed), and Cloud (fully managed) editions. Even the free Community Edition comes with 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 ESB.
Why would you want to run Mule on IBM i as opposed to a separate server or a cluster? Long term, the single responsibility / separation of duties is one of the key success factors. 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’s said your actual mileage may vary. The choice of IBM i vs other deployment options depends on many factors such as the place and prominence of IBM i in company’s infrastructure landscape, the average / peak loads on the system, integration use cases, skill availability etc.
Now to the fun part! Below are the steps I went through in order to run Mule on IBM i. My system is at version 7.3 with Java 8 and 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 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 from https://developer.mulesoft.com/download-mule-esb-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 /home/dkuznets/muleCE:
ftp <IBM i> <user> <password> bin cd /home/dkuznets/muleCE put <mule zip>
Once the transfer completed, I opened PASE terminal by typing CALL QP2TERM on IBM i command line. Most of the IBM i steps are performed in that terminal environment.
I unzipped the files with 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
and 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 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 it’s 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" ;;
Saved the changes and tried to start Mule again. This time it got through the machine version check, but got the 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 Windows service or Unix daemon. Downloaded the 32 and 64 bit versions from https://wrapper.tanukisoftware.com/doc/english/download.jsp#stable and FTP’ed to /home/dkuznets/mulece/mule-standalone-3.8.1/lib/boot/exec/ folder.
Started 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 <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 the Mule is up and running, we need a way to monitor / control the servers. For Enterprise Edition, I can use Mule Management Console or cloud-based Runtime Manager to control the server, applications, flows and messages. For Community Edition, 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
./mule stop. Create 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 – it will open Java Management Console. Go to File -> Connect… select New Connection then 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, playing a role of edge integration server that simplifies connecting IBM i applications to enterprise integration platform, or even used as an integration hub in the IBM i centric IT environments.
In the 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!