XSLT Data Transformation in Maximo

Are you in need of synchronizing to an external database with different column names and different data types? Do you have a requirement to integrate data from an external database that does not match your attributes?

XSLT may be just what you are looking for.

XSLT stands for extensible stylesheet language transformation, and it is backboned by XSL (Extensible Stylesheet Language). If you are new to this, you may say “what does that mean?” Think of XSL as a style sheet for XML, much like CSS is a style sheet for HTML. It is a set of order that allows you to form your XML. This can be something eye catching, such as displaying your XML with colors or fonts, or a full-fledged re-arranging of the way the XML data looked originally. Essentially, XSLT transforms XML from one document to another. It is created from different languages and will use them to retrieve the data you are requesting. Some parts of your document will rely on XPath to point to the data being retrieved. Some parts could use XQuery to query a database and bring back what you specifically need.

In this document, we’ll look at how XSLT is formed, how it retrieves data, how it re-formats data for transmission from one database to another, and how it is applied while the data is passing through a middleware system (e.g. WebSphere or Weblogic) into an external database from a Maximo database.

So, let’s get started. XML is the ultimate data transporting format. It is the backbone for the vast amount of data transmission that we do, and can be tweaked in many ways to pass data from one system to another. As mentioned above, knowing how to edit/write the additional languages (and apply them) will offer you boundless potential. In our scenario, we have an XML output from a Maximo database that has work order data.

This, unfortunately, is not going to work for our destination database, as it has different column names, attribute names, and data types that only allow so many characters to be in an attribute’s field. The destination database will render its XML output to look something like this:

At this point you may be thinking…”Whoa, how am I going to do anything with this?” WONUM is CUSTOMER. SITEID is LOCATION. PRODUCT is only the third section of my GLACCOUNT attribute, and why would you want two different descriptions with one of them obviously having been shortened? Enter XSLT.

With an XSLT document, we can re-construct the XML from what was originally produced by one database into a new “document” that relates the correct names and data that can be passed into the destination database. Let’s take a closer look at how this is done.

When setting up your document, of course you will need to make your opening declarations as done in the tag <xsl:stylesheet version=”1.0″ xmlns:xsl=http://www.w3.org/1999/XSL/Transform…………/>. The Transform section is indicating that this XSL sheet is actually an XSL(transformation). You can use transform instead of stylesheet at the beginning of the tag, but where the real work begins is at the <xsl:template match=”/”> tag. The element (match=”/”) is XPath and it points the XSLT file to the root of the results set that can be accessed.

You will also see that a match=”PublishMXWO_XSLT” as well as a few other match= elements are in place. Basically, the PublishMXWO_XSLT is our publish channel, which sends data out of a Maximo integration. We’ve got an XSLTSet (which is how Maximo can retrieve data in a dataset), and we’ve got WORKORDER, which is our actual object from the database. This lets the XSLT document know where we are retrieving our data from.

The next key element that is used is an XSL element that allows for the data to be “transformed” from one value to another. The XSLT element <xsl:value-of> is critical to extracting the value of a selected node from the source XML. Further down in your XSLT document, you will code for what you want to transform.

In this example of code, my matched value of SITEID is what we want to “transform” and, via the value-of element, we are telling the document to set it to LOCATION. Additionally, in XSLT, when using the select=”.” element, you will retrieve the current node. That node is LOCATION.

Further “drilling down” can be done via the <xsl: for-each/> element, however, we will only be transforming data in this document. More info on the for-each element can be studied here. There are many, many elements that can be used with XSL/XSLT that you may have a use for sometime down the line.

Now that you’ve seen how to transform an attribute, lets look at that tricky case of just needing the third section of the GL account; as that is all that is desired by the destination database.

Here, once our match has provided the dataset we want, we want to further “drill down” and pull back the number 2 section of the GL account as noticed in the select=”GLACCOUNT/GLCOMP[@glorder=’2′]”

In this code we simply want to transfer the third section of the GL Account. In Maximo, or more correctly the database, the GL Account sections are stored as section 1 (0 in the order), section 2 (1 in the order), and section 3 (2 in the order). We simply need to transfer the third (2) section in this integration. If we asked for the GLACCOUNT, the output would come back looking like this:

This is not the desired data, so the select=”GLACCOUNT/GLCOMP[@glorder=’2′]” statement will pull just the glorder 2.

We have one more tricky problem to deal with; our destination database has a description attribute that only allows 30 characters per field and a short description attribute that only allows 10 characters. We’ll set this on our match going into their database attributes.

Here we have the match element pulling description and our value-of element (going to our destination database) has attributes of DESCR and DESCRSHORT:

In our stylesheet, we are going to match the node, order, and length via the ., 1, and 30/10 substring values.

Once we have that done, we have our XSLT sheet set up and the complete document looks like this:

Now, we are done with our document and it needs to be added into your integration. Our Integration is outbound, so it is a Publish Channel, but an Enterprise Service can also be set up with an XSL transformation. In the XSL Map field, you will put the directory where your .xsl doc will exist (e.g. C:\TEMP\mycoolXSLTdoc.xsl).

A point of note for those who decide to use XSLT mapping in a multi-server (clustered) environment: if you have not built the XSL file into the EAR or cannot build the XSL into the EAR, you will need to put a copy of the XSL file into all of the servers that your integration can access in the directory path mentioned in the Publish Channel/External System.

Once the XSL Map is in place and the integration is turned on, Maximo will publish messages that get transformed into the external system format.

Go out there and give it a try, and the next time you’re in a meeting with one of your users and they say “how are we going to get the data from here to here”, you may just have the answer for them!

Feel free to leave any comments or questions below. For visual instruction of the previous steps, check out our video tutorial.