In this example we will be using this (simple) XML document as source input. The document contains a collection of Customers.

After breaking the XML up into multiple Customer entities, we will insert them into the following database structure:

To split the XML document into multiple Customer entities, we'll use an outbound splitting router like this one:

The xpath evaluator mentioned in the expression-splitter-router excepts both Dom and String objects. This means we can just use plain XML files (no need to create a w3c.dom.Document first. It'll be parsed on-the-fly.

Once the message has been split, we want each Customer to be inserted into a database. The trick here is to use the JDBC transport. We'll need to configure a connector in which
"named queries" can be configured. A "named query" is a PODS (~Plain Old Dml Statement) identified by a key.

In this example, a Map payload is expected from which the values are derived. When using XML, an XPATH expression evaluator seems more appropriate (see final solution).

PS: It might be nice to know that unnamed queries are also supported.

I've introduced the basics, now let's have a look at the complete Mule configuration:

Et voila ... using the above configuration, you will be able to process incoming XML and insert the contents in a database.

Some final notes:

• Use a property-placeholder to configure the database credentials.
• When incoming XML contains namespaces, they could globally be configured using a namespace-manager
• Notice that the jdbc:outbound-endpoint refers to the named query by key
• The named query will be "injected" with a single Customer entity, accessible by the XPATH expression evaluator

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

We first jarred the Altova generic code and added it to our Maven repository (Artifactory) so we can include this in our Mule project as dependency. We removed the generated mapping-specific Java code and used the included Ant build script to create the jar file. Here is a screenshot of how it looks in Artifactory:

Now if we want to use Mapforce generated code, we add the following dependency to the pom:

The next step is to add the generated mapping-specific code to the project. We do this by copying the generated mapping specific code to our Mule project (in MapForce you can configure the package name to be used for the generated code so that makes it easier fitting in
with the rest of the code). Here is a screenshot of the code to copy in this case:

Then we created a Transformer class in the Mule project that calls the generated mapping code and returns the result.
Here is an example of a Transformer which uses the generated code:

That's it! Define the transformer as a 'custom-transformer' in your Mule config and your done. You can now create and maintain all your mappings visually with MapForce.
We are now looking into the capabilities that SPL (Spy Programming Language) offer, because it looks like we can generate the Mule Transformer straight from MapForce, that would even boost the producivity more!

No use of versions in namespaces

In the previous post I already explained the usefulness of using namespaces in your XML schemas. The next improvement would be to make a version number be part of the namespace. Imagine if you don't do that and you have to modify your schema. And with modifying I mean a serious change like adding a mandatory element to your schema. If you make this change then all systems and clients using your schema for their interaction will fail to do so as long as they haven't changed their side of the interface. So actually you are forcing others to make modifications to their system. If I were a client of such a supplier I would definitely be unhappy with this kind of actions.
A nice way to avoid this situation is when you add a version number in the namespace of your schema. In that case you can create a new schema with a new namespace.
For example, the old situation:

xmlns:tns="http://www.redstream.nl/message

becomes

xmlns:tns="http://www.redstream.nl/message/v01_0

Now you can let the users of your schema decide when they are going to use the newer version. Of course you can provide a roadmap about when which version will become deprecated or even unusable.
This post concludes the series about using XML in real life projects. There are a lot more issues to discuss but I thought these were the most relevant to share. The final thing I want to mention is that you should use XML as meaning to get at your goal, it should not be the goal itself.

Not making (useful) use of namespaces

As blogged before I had situations where I received XML files to describe the interface file without a schema (XSD). In this situation I did receive a schema, actually several schemas. Unfortunately, they forgot (?) to make use of XML namespaces. In each different XSD they added a description of the same xml type 'OrderType'. You can imagine the rework you have if you have to change this 'OrderType'; they have to modify all XSD's and we had to regenerate all our JAXB objects. It would be much better if they supplied a separate XSD for the order element, gave it a namespace and import that in the other schemas. Another big advantage of using namespace is the possibility to distinct different versions of the same schema. I will clarify this issue in the next post.

Only change the syntax of the CSV file (no normalization)

With this I mean that there has been existing interfaces based on character separated values like:

car-height|car-width|driver-name|driver-gender

And when they start to use XML they change it to:

More readable would be something like:

The fields concerning one entity are now grouped together, like you would do when normalize a relational database. This not only increases human readability but it also increases the chance to get to a reusable schema. With this latest example you can imagine that you can use the 'car' element also in another scheme.
So the tip of the day is: perform normalization in your XSD where possible.

Not using a schema (XSD) or DTD

In this situation I contacted a business partner to ask them how the XML file/message should look like if I want to communicate with them. The reply to the question was just an example XML file with the text: 'it must look like this'. In this case there is no way to check if the XML is valid according to their specs and it is unknown if it can be processed by the other party.
Although they might check the xml very well when they process it, it would be much better if I could do some checking at our side. It would reduce the network traffic and increase the performance a lot. Also using Object-XML mapping tools like JAXB become difficult (or even impossible) which may working with the XML files harder in a Java environment.
The final issue I want to mention is that you can't use XML mapping tools like Altova Mapforce. These tools really make your life easier if you have to transform one XML to another XML format. But they are based on XSD's so without these you can't create your XSLT for mapping purposes.
There might be a lot more disadvantages but I think the point is clear: when using XML files make sure you have an XSD for them.

And example message looks like this:

To get access to the 'Property' elements in the message-header via an 'evaluator expression' I created the following Java class based on the info given here:

I think the code is fairly straightforward. In the method 'evaluate' I receive the payload of the MuleMessage and I check to see if the payload is a JAXBObject of the type Message. If it is a String I assume I receive the XML message as payload and transform the String to the expected JAXB object myself (see this post for more details about this subject).
When I have access to the JAXBObject I simply question the properties of the message for the property name that is supplied with the expression. If a value is found this is returned by the expression.
To make use of this evaluator I 'bootstrapped' it with the Mule application. This can simply be done by adding the file 'registry-bootstrap.properties' to your classpath in the folder 'META-INF/services/org/mule/config' (as explained here). In this file I put:

And that's it. To make use of this evaluator I have in my Mule config:

This will take the property 'ADDR_LIST' out of my Message and use it as outbound Endpoint, but I will explain that in another post.

It just receives an XML message as String and translates it by using a XSLT Transformer. The Xslt file that is used looks like this (please note that this example is just that, an example , don't expect anything useful in this xslt file):

The test class to test the config file looks like:

When you run this test class with this xml as input:

you will receive an error message:

Error at xsl:value-of on line 39 of :
XPST0080: XPath syntax error at char 25 on line 39 in {xs:nonNegativeInteger(50)}:
The type xs:nonNegativeInteger is not recognized by a Basic XSLT Processor.

So the problem is clear, I think. To solve this you just need to add the following to the root element of your xslt file:

Now when you run the test class you will get the expected result:

As you can see I only have XML files in this project. I have grouped the following files together in directories in the resources folder:

• xml

Contains xml file that respects the xsd that is generated. This file is used to validate it against the generated xsd to make sure it is valid. In this example 'customer-msg.xml' it will look like:

PLAIN TEXT
XML:
1. <?xml version="1.0" encoding="UTF-8"?>
2.  
3. <ns0:customer xmlns:ns0="htpp://www.redstream.nl/customer">
4.     <ns0:firstName>Pascal</ns0:firstName>
5.     <ns0:lastName>Alma</ns0:lastName>
6.     <ns0:address>
7.         <ns0:street>sesamestreet</ns0:street>
8.         <ns0:nr>13</ns0:nr>
9.         <ns0:postalCode>
10.             <ns0:firstPart>1234</ns0:firstPart>
11.             <ns0:secondPart>AB</ns0:secondPart>
12.         </ns0:postalCode>
13.     </ns0:address>
14. </ns0:customer>
• xsd

Contains the xsd's, both the 'concept' one as well as the generated 'final' one.

• concept

As said earlier this one contains the 'concept' xsd. In this example 'customer_concept.xsd' it looks like:

PLAIN TEXT
XML:
1. <?xml version="1.0" encoding="UTF-8"?>
2. <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
3.     <xs:complexType name="Address">
4.         <xs:sequence>
5.             <xs:element name="street" type="xs:string"/>
6.             <xs:element name="nr" type="xs:integer"/>
7.             <xs:element name="postalCode" type="myPostalCode"/>
8.         </xs:sequence>
9.     </xs:complexType>
10.     <xs:complexType name="Customer">
11.         <xs:sequence>
12.             <xs:element name="firstName" type="xs:string" minOccurs="0"/>
13.             <xs:element name="lastName" type="xs:string"/>
14.             <xs:element name="address" type="Address"/>
15.         </xs:sequence>
16.     </xs:complexType>
17. </xs:schema>
• final

Here is the output put. In this example 'customer.xsd' it looks like:

PLAIN TEXT
XML:
1. <?xml version="1.0" encoding="UTF-8"?>
2. <xs:schema xmlns:tns="htpp://www.redstream.nl/customer"
3.            xmlns:xs="http://www.w3.org/2001/XMLSchema"
4.            targetNamespace="htpp://www.redstream.nl/customer"
5.            elementFormDefault="qualified">
6.    <xs:element name="customer" type="tns:CustomerType"/>
7.     <xs:complexType name="AddressType">
8.         <xs:sequence>
9.             <xs:element name="street" type="xs:string"/>
10.             <xs:element name="nr" type="xs:integer"/>
11.             <xs:element name="postalCode" type="tns:myPostalCodeType"/>
12.         </xs:sequence>
13.     </xs:complexType>
14.     <xs:complexType name="CustomerType">
15.         <xs:sequence>
16.             <xs:element name="firstName" type="xs:string" minOccurs="0"/>
17.             <xs:element name="lastName" type="xs:string"/>
18.             <xs:element name="address" type="tns:AddressType"/>
19.         </xs:sequence>
20.     </xs:complexType>
21.    <xs:complexType name="myPostalCodeType">
22.       <xs:sequence>
23.          <xs:element name="firstPart">
24.             <xs:simpleType>
25.                <xs:restriction base="xs:string">
26.                   <xs:length value="4"/>
27.                </xs:restriction>
28.             </xs:simpleType>
29.          </xs:element>
30.          <xs:element name="secondPart">
31.             <xs:simpleType>
32.                <xs:restriction base="xs:string">
33.                   <xs:length value="2"/>
34.                </xs:restriction>
35.             </xs:simpleType>
36.          </xs:element>
37.       </xs:sequence>
38.    </xs:complexType>
39. </xs:schema>

• xslt

And finally the one that does all the work. In this example 'transform_customer.xslt' it looks like:

PLAIN TEXT
XML:
1. <?xml version="1.0" encoding="UTF-8"?>
2. <xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xs="http://www.w3.org/2001/XMLSchema">
3.     <xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>
4.     <!-- first copy the root and apply templates-->
5.     <xsl:template match="/">
6.         <xsl:copy>
7.             <!-- copy the attributes (if any) of the root element -->
8.             <xsl:copy-of select="@*"/>
9.             <xsl:apply-templates/>
10.         </xsl:copy>
11.     </xsl:template>
12.     <!-- match any other element and copy it with the attributes -->
13.     <xsl:template match="*">
14.         <xsl:copy>
15.             <xsl:copy-of select="@*"/>
16.             <xsl:apply-templates/>
17.         </xsl:copy>
18.     </xsl:template>
19.     <!-- Add the necessary namespaces to the root of the schema -->
20.     <xsl:template match="xs:schema">
21.         <!-- Recreate the xs:schema element-->
22.         <xsl:element name="xs:schema">
23.             <!-- Copy the existing attributes in the original xs:schema element to this one -->
24.             <xsl:copy-of select="@*"/>
25.             <!-- add Namespace -->
26.             <xsl:attribute name="targetNamespace">htpp://www.redstream.nl/customer</xsl:attribute>
27.             <xsl:attribute name="elementFormDefault">qualified</xsl:attribute>
28.             <xsl:namespace name="tns">htpp://www.redstream.nl/customer</xsl:namespace>
29.  
30.             <!-- add toplevel element -->
31.             <xsl:element name="xs:element">
32.                 <xsl:attribute name="name">customer</xsl:attribute>
33.                 <xsl:attribute name="type">tns:CustomerType</xsl:attribute>
34.             </xsl:element>
35.             <!-- continue with matching al child elements of the xs:schema element-->
36.             <xsl:apply-templates/>
37.             <!-- call a custom template to add an extra complexType to the schema that couldn't be generated by the modelling tool-->
38.             <xsl:call-template name="addPostalCodeType"/>
39.         </xsl:element>
40.     </xsl:template>
41.     <!-- suffix all complexType names with 'Type' -->
42.     <xsl:template match="xs:complexType">
43.         <xsl:choose>
44.             <!-- Check if the type already has the suffix 'Type' -->
45.             <xsl:when test="substring(@name, (string-length(@name)-3)) = 'Type'">
46.                 <!-- if so, just copy the existing attributes -->
47.                 <xsl:copy>
48.                     <xsl:copy-of select="@*"/>
49.                     <xsl:apply-templates/>
50.                 </xsl:copy>
51.             </xsl:when>
52.             <xsl:otherwise>
53.                 <!-- if not, copy all attribute and overwrite the attribute 'name' so the suffix 'Type' is added-->
54.                 <xsl:copy>
55.                     <xsl:copy-of select="@*"/>
56.                     <xsl:attribute name="name"><xsl:value-of select="@name"/>Type</xsl:attribute>
57.                     <xsl:apply-templates/>
58.                 </xsl:copy>
59.             </xsl:otherwise>
60.         </xsl:choose>
61.     </xsl:template>
62.     <!-- Prefix all types with 'tns:'. All default xs: types are untouched.    -->
63.     <xsl:template match="xs:element">
64.         <!-- Create a variable with the name of the type of the element in it. It appears this 'type' attribute
65.             can be of different types so take this into account -->
66.         <xsl:variable name="elementType">
67.             <xsl:choose>
68.                 <xsl:when test="@type instance of xs:string or @type instance of xs:untypedAtomic">
69.                     <xsl:choose>
70.                         <xsl:when test="contains(@type,':')">
71.                             <xsl:value-of select="substring-after(@type,':')"/>
72.                         </xsl:when>
73.                         <xsl:otherwise>
74.                             <xsl:value-of select="@type"/>
75.                         </xsl:otherwise>
76.                     </xsl:choose>
77.                 </xsl:when>
78.                 <xsl:otherwise>
79.                     <xsl:value-of select="@type"/>
80.                 </xsl:otherwise>
81.             </xsl:choose>-->
82.         </xsl:variable>
83.         <!-- Create a variable with the namespace prefix of the attribute if any. -->
84.         <xsl:variable name="elementTypePrefix">
85.             <xsl:choose>
86.                 <xsl:when test="@type instance of xs:QName">
87.                     <xsl:value-of select="prefix-from-QName(@type)"/>
88.                 </xsl:when>
89.                 <xsl:otherwise>
90.                     <xsl:value-of select="substring-before(@type,':')"/>
91.                 </xsl:otherwise>
92.  
93.             </xsl:choose>
94.         </xsl:variable>
95.         <!-- Now the variables are filled we can use it to determine if we need to add a prefix -->
96.         <xsl:choose>
97.  
98.             <!-- if type starts with xs: the prefix must not be changed -->
99.             <xsl:when test="$elementTypePrefix = 'xs'">
100.                 <xsl:copy>
101.                     <xsl:copy-of select="@*"/>
102.                     <xsl:apply-templates/>
103.                 </xsl:copy>
104.             </xsl:when>
105.             <xsl:otherwise>
106.                 <xsl:copy>
107.                     <xsl:copy-of select="@*"/>
108.                     <!-- A few steps back we renamed complextypes so they ended with 'Type'. Now we have to suffix the places
109.               where the types are reffered also with 'Type' -->
110.                     <xsl:if test="substring($elementType, (string-length($elementType)-3)) != 'Type'">
111.                         <xsl:attribute name="type">tns:<xsl:value-of select="@type"/>Type</xsl:attribute>
112.                     </xsl:if>
113.                     <xsl:if test="substring($elementType, (string-length($elementType)-3)) = 'Type'">
114.                         <xsl:attribute name="type">tns:<xsl:value-of select="@type"/></xsl:attribute>
115.                     </xsl:if>
116.                     <xsl:apply-templates/>
117.                 </xsl:copy>
118.             </xsl:otherwise>
119.         </xsl:choose>
120.     </xsl:template>
121.     <!-- The next template generates the complexType 'myPostalCodeType' when the template is called -->
122.     <xsl:template name="addPostalCodeType">
123.         <xsl:element name="xs:complexType">
124.             <xsl:attribute name="name">myPostalCodeType</xsl:attribute>
125.             <xsl:element name="xs:sequence">
126.                 <xsl:element name="xs:element">
127.                     <xsl:attribute name="name">firstPart</xsl:attribute>
128.                     <xsl:element name="xs:simpleType">
129.                         <xsl:element name="xs:restriction">
130.                             <xsl:attribute name="base">xs:string</xsl:attribute>
131.                             <xsl:element name="xs:length">
132.                                 <xsl:attribute name="value">4</xsl:attribute>
133.                             </xsl:element>
134.                         </xsl:element>
135.                     </xsl:element>
136.                 </xsl:element>
137.                 <xsl:element name="xs:element">
138.                     <xsl:attribute name="name">secondPart</xsl:attribute>
139.                     <xsl:element name="xs:simpleType">
140.                         <xsl:element name="xs:restriction">
141.                             <xsl:attribute name="base">xs:string</xsl:attribute>
142.                             <xsl:element name="xs:length">
143.                                 <xsl:attribute name="value">2</xsl:attribute>
144.                             </xsl:element>
145.                         </xsl:element>
146.                     </xsl:element>
147.                 </xsl:element>
148.             </xsl:element>
149.         </xsl:element>
150.     </xsl:template>
151. </xsl:stylesheet>

And of course the pom file. This one looks like this:

This completes the example of how you can perform xslt transformations within the Maven build cycle.

• no use of namespaces (both import and prefixes)
• names of custom defined types didn't end with the suffix 'Type'
• some complex types were missing

And several more things but the idea stays the same.
Here is an example XSD that could be generated by the tool:

Here is how I would like the XSD to be look like:

To get to this last XSD I used the following XSLT (see inline documentation for explanation):

Although this example might be very specific and there are better ways to obtain similar results, to me this might be a handy reminder how to solve an issue with XSLT and perhaps it might even help you in some way. In another post I will show how I do this translation in Maven and also validate the outcome.