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 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 the 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 the 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 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 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 the 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:
[code]ftp <IBM i> <user> <password> bin cd /home/dkuznets/muleCE put <mule zip>[/code]
Once the transfer was completed, I opened the 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:
[code]cd /home/dkuznets/muleCE jar xf <mule zip>[/code]
Next, I tried to run the server in console mode
[code]cd /home/dkuznets/muleCE/mule-standalone-3.8.1/bin ./mule[/code]
and got an error right away:
[code] > ./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. [/code]
Clearly, the startup script doesn’t recognize the server type. I called the name 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 it’s AIX:
[code]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" ;; [/code]
Saved the changes and tried to start Mule again. This time it got through the machine version check, but got the new error:
[code]> ./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 $ [/code]
After a bit of googling, I found that Mule uses Java Server Wrapper to run as a 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 the Mule server again, and it worked!
[code]> ./mule start MULE_HOME is set to /home/dkuznets/mulece/mule-standalone-3.8.1 Starting Mule... $ [/code]
Mule logs are located in <mule home>/logs directory and show that the server and deployed apps are up and running:
[code]++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Mule is up and kicking (every 5000ms) + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ [/code]
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, 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 [code]./mule stop[/code]. Create a new Mule application JMXAgent in your Studio and add the code below:
[code] <?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> [/code]
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 the role of an edge integration server that simplifies connecting IBM i applications to the 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!
Recent Comments