When you are using a certain version of Mule ESB you are going to run into an existing bug sooner or later. That isn’t really a problem, I would call it inevitable (at least based on my own experience). The big advantage of the open source idea is that you can dive into the source code and see where the problem is caused and fix it ( or at least work around it). I remember the time I was using Oracle Forms Developer to build applications. When you ran into a bug you had to wait until Oracle was ready to fix/patch it (or, of course, convince the client to not want that specific feature in their application).
Although its true you can find all known bugs for Mule in Jira, you still have to discover yourself your application is having a problem with that known issue. I recently implemented a new interface in our application and I started to make use of the CXF transport (until now it was mainly based on JMS and VM). The exception I got when processing a message was

java.io.IOException: Attempted read from closed stream.

The weird thing was, I didn’t get this exception when running my unit tests and it sometimes even worked in my deployed application.
As I said we got this exception when we added the CXF endpoint, although we did it as described in the manual. Well, to make a long story short, it appeared we were running into this issue. In our deployed version we make use of the Mule Notifications. We have extended the default Mule endpoints so they can indicate if a message they are processing should be logged. This logging is done by receiving the Notification and extracting the message from it. Then we log the payload of the MuleMessage as text in our database.
This works great as long the payload of the message isn’t an InputStream! in case of an InputStream the stream is read to make a String of it and since a InputStream can only be read once, the rest of the application cannot read it again (hence the ‘Attempted read from closed stream‘). This behaviour is described in Jira but you can image that it took some time before we realized we were running into this. Especially because the stack trace isn’t of much use in this case since it is pointing to some deep down CXF code that tries to read the input stream.
Next time someone has a similar issue and you are using Notification Handlers you might want to check these out and this way save yourself a lot of time looking for the cause of this issue.

Mule ESB is a versatile service bus that contains numerous usable components out-of-the-box. In this blog I’ll show you how to process an incoming XML document, break it up into multiple parts and insert them into the database without using any custom Java classes.

Continue reading…

As promised in our previous blog about Altova Mapforce we will show in this post how to combine the result of the generated code of Altova Mapforce with a Mule application. As we have shown before, the Java code that is generated by MapForce is divided in two parts:

• one is Altova generic, so will be reused for each mapping
• one is mapping specific so is the actual part that changes with the mapping (this package name is configurable)

Continue reading…

As I promised before here is an example of how to use Smooks in combination with Mule. In this example I transform a CSV file to a plain XML file. This XML file can then be transformed with an XSLT transformation to the desired XML format.
Continue reading…

For a new interface that we have to implement we have to transfrom a file with ‘character separated values’ to a XML message. One way to obtain this transformation is by using Smooks. Smooks is an extensible framework for building applications for processing XML and non XML
data (CSV, EDI, Java etc) using Java. Although Smooks can run standalone, we want to combine it with our integration platform that is based on Mule CE
Continue reading…

As I said before we were asked to check out the new Management Console of Mule. In this post I will show the steps I took to get the console up and running and the first results of the evaluation.

• The first thing I had to fix was the fact that the Management Console only works with the Enterprise Edition. Luckily there is a 30 days trial available of the Enterprise Edition here, so I started by downloading that one.
  Continue reading…

Currently we’re evaluating the Mule Management Console: a new product from MuleSoft that replaces Mule HQ.
We have had a look at Mule HQ before and decided that it was not offering the functionality we were looking for. Apparently we weren’t the only ones with this conclusion because MuleSoft decided to build a new Management Console from scratch. It is now available as an Early Access release and MuleSoft asked us to evaluate it.

As soon as we have set up a test environment (similar to our live situation) and done our first tests we will post the results here so stay tuned!

I needed Mule to determine the outbound endpoint based on the content of properties in my custom XML message. Although this might look as common functionality I couldn’t find a complete example for this on the net. This one was close, but didn’t match completely with my situation:
I receive an XML message that is conform my own custom format. Based on the content of several fields in this XML message I determine what the next endpoint must be to process the message. Then my message is forwarded to that endpoint.
Continue reading…

Although there are a lot of evaluators available in Mule CE it is very easy to add your own evaluator. In my case we have a self defined message format that holds some properties in the header of a message (similar to JMS Message, MuleMessage, etc.). To get access to these properties in the Mule config I created a custom evaluator that made this possible. Although there will be other solutions available for this situation, I found this a nice (pragmatic) way to solve it. It also provides a base to start from in case of possible changes in the future.
Continue reading…

In my current project we are going to need a BPEL engine besides our Mule CE implementation. Actually, we will use Mule for our stateless communication between systems and use BPEL for the stateful processes. One of the possible frameworks to use as a BPEL engine is Apache ODE. In this post I will show you how you can start a BPEL process in Apache ODE with Mule. As you will see, it is merely a combination of posts I made earlier, but I think it is nice to have the complete thing in one post.

Continue reading…