Recently, I ran into an open-source test framework called Citrus. Citrus supports you in testing message interfaces in enterprise applications. Manual testing effort as well as coding mocks and simulators are not necessary. Instead Citrus enables integration testing in an automated way with out-of-the-box simulation of various message transports. We’ll use it to test our Mule based ESB.

Mule, of course, offers great possibility to unit test your application. And we also have a test setup which ‘talks’ to other applications. What we didn’t have was a testing environment which we could use to test the ESB as a blackbox without being dependent on other (external) applications. And this is exactly where Citrus comes in. Citrus makes it possible to test the complete lifecycle of a message flow without being dependent of other systems, actually with Citrus you proxy these dependencies.
In this post I will provide details and tips on how to setup and use Citrus. Although the documentation that is available is easy to read, it is not complete. It took me quite some effort to get it all running but like I said before the benefits of this framework are huge.
(more…)

Recently I got into a situation where I had to put ‘metadata’ values (which were part of the Mule Message) into the XML result of an XSLT transformer. Let me explain the situation with an example. Imagine you have an ‘order’ xml that needs to be translated into an ‘invoice’ xml. Here is a simple ‘order.xsd’:

Here is the ‘invoice.xsd’:

The mapping for the transformation looks like this in MapForce:
(more…)

In a previous post I described how you can configure an ActiveMQ connection-factory as datasource in Tomcat. Although this works great in a deployed Mule application you can’t use this technique in your unit tests! So in this post I describe how we set up our test environment. (more…)

This post describes how we managed to use standalone ActiveMQ (v5.2.0) as JNDI datasource in our Mule ESB application deployed in Apache Tomcat(v6.0). If you are still with me after reading this first line then I may assume you know your way in this part of the Java open-source world :-)
Here is the situation:
We have deployed a number (about 10) of Mule applications as WAR’s in our Tomcat installation. Each WAR is using the same standalone ActiveMQ instance as JMS provider. We implemented this by defining an ActiveMQ connector in each WAR (actually in a separate JAR that is included in each WAR). (more…)

A month ago I stumbled upon the open source project ‘Saddle‘. According to themselves:

“Saddle is an extension of the Mule enterprise service bus (ESB). It allows the graphical configuration, administration and monitoring of the mule system. Furthermore, it eases the message handling and extends the connectivity of the Mule ESB. “

In my opinion the most important feature it offers is the graphical designer for the Mule configuration files. This is what I am missing the most right now. And I must say, since I have been using Mule for some years now I now know my way around in the XML configurations, but I remember the first months it took me quite some effort to get these configurations right. And of course a diagram is much easier to read instead of crawling through XML files. (more…)

At a project for one of our customers we migrated from Mule CE to Mule EE edition (version 2.2.7). The customer had various good reasons to do this and it offered us new functionalities in Mule ESB to use. One of those ‘new’ things is RetryPolicy for some of the Mule Connectors. I quoted ‘new’ because there is also an open source variant that you can use in the community edition but since the customer paid for it I wanted to use this version that comes with Mule EE out-of-the-box. (more…)

One of the main functions of a Mule ESB application (besides transporting messages) is transforming messages to another format. Nowadays a lot of messages are XML based so a lot of transformations are done by using XSLT, or in Mule terminology, an XSLT Transformer. In our current project this is no different.

As I posted before we happily using Altova Mapforce for this. But this also means that a lot of changes and issues during the development are being solved by modifying the XSLT. In our Mule ESB setup we have deployed our Mule applications as a WAR in Tomcat. So this means to take our modified XSLT into account we have to redeploy the WAR or at least, stop and start the WAR in Tomcat. And as we found out, if the Mule application is inside a JAR inside the WAR we had to stop and start the complete Tomcat instance for our changes to be picked up.

To solve this issue we have created our own instance of the Xslt Transformer in Mule. Our implementation checks for the timestamp of the XSLT file and reloads it if there is found a newer XSLT file. This way we don’t have to restart our Tomcat if a newer version is in place. In a production environment you might want to discard this functionality to avoid unexpected behaviour of the running applications but I leave that up to you. In this post I will show you how our implementation of the XSLT Transformer works. (more…)

This post continues the use case I explained here. The part left to explain was the ‘custom-correlation-aggregator-router‘.
Let us start with the source code of this routing component. (more…)

While implementing an integration platform with Mule at a client we run into a lot of different use cases. The use case in this example was the following:
Messages from 2 different source systems had to be combined and offered as one message to another application. The messages were generated shortly after each other with a regular scheme, like once a week.
Both messages were xml messages according to a certain schema and they had to be combined to one xml message. One of the XML message was supplied by JMS and had to be combined with the other message that was offered as a file. Two messages should be combined if they have the same code-period combination.
(more…)

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:

1
2
3
4
5
6
7
8

...
<outbound>
  <filtering -router>
    <vm:outbound -endpoint ref="out-queue" />
     <xm:jaxen -filter pattern="//firstname" expectedValue="Pascal"/>
  </filtering>
</outbound>
...

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):

1
2
3
4
5
6
7
8

...
<outbound>
  <filtering -router>
    <vm:outbound -endpoint ref="out-queue" />
    <xm:jaxen -filter pattern="local-name(//Relations)" expectedValue="Relations"/>
  </filtering>
</outbound>
...

(more…)

Meest gelezen