Part 1 of this series layed the foundation for some Groovy concepts and what makes the language suitable for data mapping tasks. With that in mind, lets dive into some of the advanced mapping features and some real world samples.
Introducing GroovyMap
There are 3 data transformation scenarios which we commonly encounter:
- xml to xml – Reads an inbound xml and maps it to a different XML structure.
- xml to map – Reads an inbound xml and maps it to a java.util.Map. Maps and Lists are very common data structures in Mule applications, being used for both JSON data formats and when using the Database transport.
- map to xml – Reads an adapter response in the form of a java.util.Map, iterates over the enumeration of keys and maps that to a response xml.
We notice these transformations often involve a lot of plumbing code:
- Accept an array of mapping inputs and an array of ‘helper’ objects (e.g. lookup tables, DB connections)
- Initialise a Groovy builder object to help construct the mapping output. Perform the data mapping using the result Builder object.
- ‘Serialise’ the result in a certain way (string, DOM tree, POJOs etc)
To rapidly churn out mapping code, it makes sense to move this boilerplate code into a common script which developers would import. This script provides a foundation involving the “Builders” which are used across all our mapping code and the serialisation approach.
Here’s what a light weight might look like:
You can see the full constructor for the GroovyMap is quite involved. To make life easier for developers, we provide static factory methods to create pre-built GroovyMaps for common scenarios (e.g. transforming to XML DOM). The final method is a convenience method for the simplest, most common mapping scenario: a single input object to a single output with no helpers.
Now let’s take a look at some examples of the common data mapping scenarios:
XML to XML
Java Lists / Maps to XML
This is a common requirement when working with Mule’s JDBC transport (for example).
XML to Java Lists / Maps
In this case the GroovyMap helper class is not needed, because Groovy List/Map data structures are easy enough to create without a builder
Other helper classes
You’ll notice in the above code that we use our own versions of the standard ‘DOMBuilder’ and ‘DOMCategory’ classes. We made some small patches to the GDK classes to make our mapping code behave the way we wanted:
- The patched DOMBuilder class constructs a full org.w3.dom Document object with the top-most element created by the builder inserted as the document element.
- The patched DOMCategory class tries to convert each expression value to a string if it has a sensible string representation (i.e. it is not a list of elements). This is to replicate the handy behaviour of XPath and means we don’t have to add
.text()or.toString()to the end of every mapping statement.
Working with Groovy in Eclipse/Mule Studio
Since Mule Studio is based on the Eclipse platform, you can install a Eclipse plugin to get excellent editor and debugging support for writing Groovy mappings without leaving your IDE.
To add Groovy support to your eclipse based IDE, install the GRECLIPSE plugin:
- Help → Install New Software → In the “Work With” text field add
- name - Groovy-Eclipse update site
- url - http://dist.springsource.org/release/GRECLIPSE/e4.2/
- Add the Groovy editor support and Groovy 1.8.6 runtimes.
- Restart when requested.
Once this is installed, right click on the Project → Configure → Convert to Groovy Project. This should add the Groovy DSL Support Libraries to the classpath. It also adds Groovy Libraries to the classpath. However, if you’ve already added that in your pom, get rid of it using the “Configure Build Path…” link in eclipse.