API Gateway: XSLT Transformation

Enterprises who are providing SOAP-based web services or REST APIs returning XML payloads to the consuming applications often need the ability to transform XML payload from source to target format. A common use case is a SOAP to REST transformation.

Even though the existing web service in the backend returns a full-fledged SOAP envelope with XML payload in the SOAP body, we might want to just return the XML payload. The XML payload might further be expanded or reduced. For example, if client A makes the request return the XML payload as it is and if client B makes the request return a section of original XML payload.  Such use cases are better in API Gateways with rich support for XSLT transformation.

The XML payload might be expanded further or reduced. For example, if client “A” makes the request returns the XML payload as it is and if client “B” makes the request return a section of original XML payload. Such use cases are better in API Gateways with rich support for XSLT transformation.

 This article walks you through the high-level steps required to apply the XSLT transformation in Axway’s API Gateway. 

High-Level Steps:

1.  Import XSLT style sheet into Gateway
2. Implement a policy to apply transformation
3. Create a relative path
4. Test policy
5. Trace the execution using the Traffic Monitor

Step 1: Import XSLT style sheet into Gateway

1. Import the style sheet into Gateway using Policy Studio. Right-click on the “Stylesheets” menu and click on “Add stylesheet.” 

2. The sample XSLT code is shown below (transform.xslt).

<xsl:stylesheet version="1.0"

 xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

 <xsl:output omit-xml-declaration="yes" indent="yes"/>

 <xsl:strip-space elements="*"/>


 <xsl:template match="node()|@*">

  <xsl:copy>

   <xsl:apply-templates select="node()|@*"/>

  </xsl:copy>

 </xsl:template>


 <xsl:template match="address">

  <xsl:copy>

   <xsl:value-of select=

   "concat(streetNo, ' ', street, ',',

           suburb,',', state,', Australia')

   "/>

  </xsl:copy>

 </xsl:template>

 <xsl:template match="address/node()"/>

</xsl:stylesheet>

Step 2: Implement a policy to apply transformation 

1. Set the source XML request using the “Set Message” filter.  A sample XML request is provided as well for testing.

 <rentalProperties>

    <property contact ="1">

        <type>House </type>

        <price>420</price>

        <address>

            <streetNo>1</streetNo>

            <street>Wavell Street</street>

            <suburb>Box Hill</suburb>

            <state>VIC</state>

            <zipcode>3128</zipcode>

        </address>

        <numberOfBedrooms>3</numberOfBedrooms>

        <numberOfBathrooms>1</numberOfBathrooms>

        <garage>1</garage>

    </property>

</rentalProperties>

2. Configure the “XSLT Transformation” filter to use the XSLT Stylesheet imported as part of Step 1. This will filter will apply the XSLT Stylesheet on the source XML request. 

3. Return the transformed XML response using the “Reflect Message” filter.

Step 3: Create Relative Path

1. Expose the policy created from Step 3 as an HTTP service using Policy Studio.

2. The HTTP service endpoint, from the below diagram, would be http://[IPAddress]:[Port]/applyxslt

Step 4: Test Policy

1. Test the service URL “http://[IPAddress]:[Port]/applyxslt” from the browser.
2. The XML response returned by the policy is shown below.

<rentalProperties>

<property contact="1">

  <type>House</type>

  <price>420</price>

  <address>1 Wavell Street,Box Hill,VIC, Australia</address>

  <numberOfBedrooms>3</numberOfBedrooms>

  <numberOfBathrooms>1</numberOfBathrooms>

  <garage>1</garage>

</property>

</rentalProperties>

Step 5: Trace the execution using Traffic Monitor

1. Access the API Gateway Manager and view the transaction tested as part of Step 5. The policy execution flow will look similar to the one shown below.