In a previous post, I mentioned that you could extend the function library in Altova MapForce and add your own functions. In this post I’ll show you (briefly) how to do this using the Java methods from the previous post.
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.
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…)
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)
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…)