Saturday, November 14, 2009

Installing MULE ESB on Centos

I have one configuration that downloads SAP data using a Mule-1.4.4. Why not mule 2? The SAP Transport for Mule 2 didn't exist yet during the time I built the system. It was implemented on a Windows Sandbox system, that unfortunately has few shortcomings such as not being backed by tech support staffs, virus-prone, must be started up after power outages, and shared system load with SAP ERP Sandbox & one Ubuntu OS loaded in VMWare (whew, that's a lot..).
So I think it would be better to migrate the Mule-system into a Centos-powered virtual machine located in the Data Center (where power outages are rare and of course we have no worm/virus problem).
Extracted mule-1.4.4.tar.gz into /opt/mule-1.4.4. Put the IBM JDK 1.5's bin directory onto user's PATH by editing user's .bashrc file. Extracted sapjco 2.1.8 into /opt/sapjco2.
Tried run Mule for the first time, but it wants to download mail-1.4.jar. I copied the missing file from the previous system to lib\user. I also copied activation-1.1.jar to lib\user. Mule runs but complains about it being unable to write pid files and log folders. Chown-ed the entire mule tree to the mule user I created for the purpose of running the system.
Now, for the SAP integration part.. extracted in the home folder of mule user. Copied mule-transport-sap.jar and mule-transport-sap-examples.jar from the target folders resulting from the previous built (on a WinXP system, I think) onto lib\user.
I tried to run the config file from the mule-sap-transport system. Unfortunately it choked because of missing commons-dbcp and ojdbc.jar (I used oracle jdbc endpoint). I copied the missing jars from the previous system onto lib\opt (don't know whether will make any difference if I used lib\user). Symlinked sapjco.jar into lib\user.
At long last, Mule runs now. But when I triggerred the sap download (RFC call), exceptions spewn in the console (or mule.log, depends on I used mule start -config ... or just mule -config ...). It couldn't find the native library, but somehow it was able to load in the same folder. Must be the wrapper mechanism (mule used wrapper from tanukisoftware) that causes this strangeness. Poking my .bashrc again, and finds out that the LD_LIBRARY_PATH is not being exported.. silly me. Adds LD_LIBRARY_PATH to the export clause, exit the console, re-login, and now it works..

No comments: