Some of our Mule ESB applications make use of content-based routing when processing a message. To implement this in Mule we use a filtering-router with a jaxen-filter. The most simple example looks like this:

You can also use a XPath function in your jaxen-filter like this (if you want to check a certain element is in an XML message regardless the value of the element):

Continue reading...

Last week I had to implement an interface for a customer in which an XML file had to be loaded into the database. But ... the database table needed to be truncated first. At first, I thought that a chaining router would suffice. I soon found out that the behaviour of this router was not desirable at all.

Continue reading...

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...

After attending to Jason van Zyl's session about Maven3 we decided to start using Maven 3 instead of the 2.2 we were using. Since it is fully backward compatible we made it run without making a change to our pom's. However, what this version does add is generate warnings for all kinds of 'misconfigurations' in the poms. This does not lead to problems in this version but it might do so in future version, so it is better to solve this issues.
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...

Currently I'm finalizing a reporting solution based on JasperReports. The solution includes a JasperServer instance running on Linux. After deploying some initial reports to JasperServer using iReports I noticed that the TrueType fonts used when designing the reports (on Windows) did not render correctly. In fact, they did not render at all ... JasperReports decided to use a default font instead.

From the JasperServer log it appeared that the font used in the report could not be found: "JRFontNotFoundException: Font 'Courier New' is not available to the JVM"

Continue reading...

Although we see many advantages in using (free) open source tools or frameworks we keep our eyes open to check whether the chosen open source solution is best for our customer.

We recently had a situation where we preferred a commercial solution over an open source one.
For a specific interface, we had to map a CSV file to an XML file and this transformation should be processed by the Mule ESB. At first we looked at Smooks to tackle this issue, as I described here. It resulted in a workable solution, but as you can read in post, the transformation had to take place in two steps: first from CSV to simple XML format and secondly, a transformation from the simple XML to a more advanced XML schema. For this second transformation we made use of an XSL stylesheet. We created the XSL file used for the transformation by making use of Altova MapForce.
However, MapForce can do a lot more then this simple XML to XML mapping.
Continue reading...

From time to time I am evaluating a tool or framework for which I need a web service. Although there are examples of running serviuces available on the web, I don´t always have access to the web and sometimes you need some more control over the service so you can edit/influence the corresponding WSDL. For these cases I created the following class which is all you need to get a web service running on your local machine (assuming you have JDK1.6 installed).
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...