Skip to content

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=…………/>. 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.

Share This

Related Posts

Preventing fields from Editing Once Record is in Workflow
Preventing fields from Editing Once Record is in Workflow I like this problem because it involves a few...
How to Enable Print Functionality in IBM Maximo
How to enable the print button in Maximo.   By default, Maximo only allows the MAXADMIN group to have...
WBENC Anoounement thumbnail

4 Responses


  1. Hi Alex,

    Thanks for this great article.

    Below, I am trying to convert STATUSDATE from format YYYY-MM-DDTHH:MM:SS.FFFFF to YYYY-MM-DD HH:MI:SS,
    but its not working as expected. Could you assist please?


  2. How do you process data into Multiple Maximo objects using XSL mapping? Can you share XSL file that insert data into multiple objects?

  3. Hi ,

    Its a wonderful article , Please emphasize on the location of XSLT or where we should place the XSLT So that Maximo server could read it but restart is not required when we update it?
    This is super important to know because this avoids expensive downtime when change required.

    waiting for the reply


    • The value in the XSL Map field is a path to the file. This can either be an absolute path with a full drive letter to a valid file on the server, e.g. C:\Temp\myfile.xsl, or a relative path to a file built within the MAXIMO.EAR archive. In a development situation, it’s oftentimes easier to use the absolute path option. Simply change the file on the server and stop/start the Maximo application server to see your changes. There is no need to rebuild the MAXIMO.EAR archive in that case. In Production however, it’s often better to build the XSL file into the MAXIMO.EAR archive.

Add a Comment