Skip to Content

Peeking under the hood of CPI’s XSLT processor

When it comes to transforming XML, I’m a huge fan of XSLT. There is a fairly steep learning curve to climb, but once you’ve done so, the power and expressiveness of the language is unmatched. Luckily, Cloud Integration supports XSLT mappings in your integration flows.

In this blog I will take a peek under the hood of the XSLT processor running in CPI, to see what we can learn about it.

Peeking under the hood

So CPI supports XSLT, which is great, because XSLT – like bow ties – is cool. But which processor is performing the XML transformations behind the scenes? To answer this, we can utilise XSLT’s system-property function to learn more about the underlying processor. The function takes a property name as its only input, and returns the value of that property. The following properties must be supported, as per the W3C specification:

  • xsl:version (the supported XSLT version)
  • xsl:vendor (the processor’s implementer)
  • xsl:vendor-url (the URL of the implementer’s web site)
  • xsl:product-name (the processor’s product name)
  • xsl:product-version (the version string of the product)
  • xsl:is-schema-aware (whether the processor is schema-aware)
  • xsl:supports-serialization (whether the processor supports the serialization feature)
  • xsl:supports-backwards-compatibility (whether the processor supports earlier versions of XSLT and XPath)

Right, let’s put all of these in an XSLT 2.0 stylesheet and run it through CPI’s processor. First, the stylesheet:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="2.0" xmlns:xsl="">

  <xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>

  <xsl:variable name="properties" select="(

  <xsl:template match="/">
      <xsl:for-each select="$properties">
        <xsl:variable name="prop" select="."/>
        <xsl:element name="{substring-after($prop, ':')}">
          <xsl:value-of select="system-property($prop)"/>


Executing this stylesheet in CPI, I get the following output:


This tells us that the XSLT 2.0 processor in CPI is Saxon-HE, the open-source version of the Saxon processor, specifically version at the time of writing.

What does schema-aware mean anyway?

You might have noticed from the system-property output, that the open-source version of Saxon is not schema-aware. But what does that mean, exactly? Two things:

  1. It cannot validate the stylesheet’s input and output using XML Schema
  2. It cannot use data types defined in XML Schema

The first point doesn’t really matter in CPI, since we’re able to validate before and after the XSLT mapping using the XML Validator step anyway. The consequence of the second point is that you cannot create e.g. function parameters and variables with types, that are defined in XML Schema. You can of course still use the built-in types (xs:string, xs:integer et al).

Java extensions in Saxon-HE

The Saxon XSLT processor supports two mechanisms for executing Java code from inside a stylesheet: Reflexive extension functions and integrated extension functions. Unfortunately, neither is available to us in CPI. In the following I will briefly explain why that is the case. With XSLT 2.0, Java extensions are not as important as in XSLT 1.0, though. With user-defined functions and a much larger number of built-in functions available in XSLT 2.0, many problems can be solved directly in XSLT without resorting to external code.

Reflexive extension functions

This is the easier but more limited mechanism of the two. In the following example, the static pow method of class java.lang.Math is called with the parameters 2 and 8:

<xsl:value-of select="math:pow(2,8)" xmlns:math="java:java.lang.Math"/>

However, reflexive extension functions are not supported in Saxon-HE, the specific version of Saxon running in CPI.

Integrated extension functions

Integrated extension functions are more powerful, but require a bit more work. They are Java classes that you write, which means they can contain more complicated logic than is possible with reflexive extension functions. They also let you manage the conversion between XPath and Java types. However, there is a problem: Integrated extension functions must either be registered programmatically with the processor or added to a Saxon configuration file, and neither is possible in CPI.

You must be Logged on to comment or reply to a post.
  • Hi Morten,

    Useful blog and currently working to get external parameters in xslt mapping with below code but its not working so any suggestions?

    <xsl:param name=”external_location” select=”getProperties(Job_Location)” />




  • Hello Morten,

    Its possible to set and get exchange properties inside XSLT  .

    How to get:

    How to set:

    <?xml version="1.0" encoding="UTF-8"?>
    <xsl:stylesheet version="1.0" xmlns:xsl=""
        xmlns:hci="" exclude-result-prefixes="hci">
    	<xsl:param name="exchange"/>
    	<xsl:param name="Param1"/>
    	<xsl:param name="Param3"/>
    	<xsl:output method="xml" encoding="UTF-8" indent="no" />
    	<xsl:template match="/">
    		<xsl:value-of select="hci:setProperty($exchange, 'Param2', $Param1)"/>
    		<xsl:value-of select="hci:setProperty($exchange, 'Param3', '222222')"/>
    		<xsl:value-of select="hci:setHeader($exchange, 'Param1', '1234567890')"/>


    Sriprasad Shivaram Bhat

  • Hi Morton, wanted to know if CPI supports XSLT 2.0 and didn’ t find the info in the official CPI help,  found then your blog 🙂 . In the tenant i use (2.43.11) it is exactly as in your example. thanks for sharing, best regards, Sophie.