XML/ XSD/ XSLT | redstream

Although I am not always happy with the online documentation of the Mule ESB I found this article quite good. I have set up our configuration of Mule ESB implementation on several projects this way and it has proved to be working nicely. Although last time I got into the following issue. To use a datasource in my Mule3 project I had configured it like this in my Mule config file:

<jdbc:oracle-data-source 
          name="jdbcDataSource" 
          user="${db.username}" 
          password="${db.password}" 
          host="${db.host}" 
          port="${db.port}" 
          sid="{db.sid}" />

However, when I deployed the application on my Mule instance I got the following XML parse exception:

org.xml.sax.SAXParseException: cvc-datatype-valid.1.2.1: ‘${db.port}’ is not a valid value for ‘integer’.

This is caused by the fact that the XML is validated against its XSD before the parameters are resolved. Although I found threads in several forums that described a solution for this issue I chose the following (pragmatic) solution. I decided to configure the datasource like this:

<jdbc:oracle-data-source 
         name="jdbcDataSource" 
         user="${db.username}" 
         password="${db.password}" 
         url="jdbc:oracle:thin:@//${db.host}:${db.port}/${db.sid}" />

This way the XML validates fine against its XSD and during runtime the parameters are resolved.

We use a fair lot of XSLT transformations in our projects. Since making XSLT stylesheets is a tedious and error-prone job, we use Altova MapForce to do the job. MapForce is very versatile, but can not always cope with the requirements our customers come up with. This time, the customer asked us to implement some sort of maintainable translation mechanism. This mechanism should be able to translate incoming values using a user maintainable collection of values. This way, the transformation process does not need to be changed if a translation is added or updated.

Adding a (hardcoded) parameterized XSLT template is not an option, because this is not maintainable without changing the stylesheet. The answer? XSLT Java extensions!

In this blog I’ll show you a simple example on how to use Java extensions in a XSLT 2.0 stylesheet.

(more…)

Some time ago I was asked to review existing web services for a customer. The main thing I noticed was that they were using Microsoft’s diffgram elements and attributes in their input and output messages. I was not familiar with this format but found out that it has been created by Microsoft to make synchronizing datasets in .Net easier. In this case the web services were implemented with Spring-WS, so there was no real reason to use this format on the server side. Besides, it only makes the web service less useful on the client side since it leads to complications if you want to use a XML-Object mapper like JAXB (see this for example). One of the issues with Diffgram is that, besides the XML containing the Diffgram element, also the XSD is included. This XSD describes the content of the Diffram Dataset, however, the XSD and the resulting Dataset do not match because extra attributes are added (this is described in more detail here). (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…)

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

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:

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

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

(more…)

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.

(more…)

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. (more…)

XML is quite common nowadays, especially in the application integration business that I am involved in. However, I still see companies making big mistakes when they decide to start using XML (for example as the exchange format with their business partners). This series of posts is about mistakes (or at least clumsiness) in using XML that I noticed during several projects.

No use of versions in namespaces (more…)

Not making (useful) use of namespaces
(more…)

Meest gelezen