Response Transformation Policy Properties

Edit online
The table lists the properties that you can specify for the Response Transformation policy:
Property Description
Condition Conditions are used to specify when the policy has to be executed. You can add multiple conditions with logical operators.
Available values are:
  • AND. webMethods API Gateway transforms the responses that comply with all the configured conditions
  • OR. This is selected by default. webMethods API Gateway transforms the responses that comply with any one configured condition.
Click Add Condition and provide the following information and click add.
  • Variable. Specifies the variable type with a syntax.
  • Operator. Specifies the operator to use to relate variable and the value. You can select one of the following:
    • Equals
    • Equals ignore case
    • Not equals
    • Not equals ignore case
    • Contains
    • Exists
    • Range
    • Greater Than
    • Less Than
  • Value. Specifies a plain value or value with a syntax.

For details about the variables available in webMethods API Gateway, see Variables Available in API Gateway.

Transformation Configuration. Specifies various transformations to be configured.
HeaderTransformation Specifies the header, query or path transformation to be configured for the responses received from the native API.

You can add or modify header, query or path transformation parameters by providing the following information:

  • Variable. Specifies the variable type with a syntax.
  • Value. Specifies a plain value or value with a syntax.

You can add multiple variables and corresponding values by clicking add.

You can remove any header, query, or path transformation parameters by typing the plain value or value with a syntax.

Note: It is recommended not to modify the headers ${response.headers.Content-Length} and ${response.headers.Content-Encoding} as webMethods API Gateway adds the right values for these headers before sending the response back to client.

For details about the variables available in webMethods API Gateway, see Variables Available in API Gateway.

Note: Payload transformation does not happen automatically for content-type transformation. When you change the content type, ensure to do payload transformation. For example, if you change the content-type header from application/xml to application/json, you must also change the respective payload from application/xml to application/json.
Status transformation Specifies the status transformation to be configured for the responses received from the native API.

Provide the following information:

  • Code. Specifies the status code that is sent in the response to the client.

    For example if you want to transform status code as 201, provide 201 in the Code field.

  • Message. Specifies the Status message that is sent in the response to the client.

    As both these properties support variable framework, you can make use of the available variables to transform the response code and message.

    For example You have submitted successfully can be used to transform the original OK status message.

    For details about the variables available in webMethods API Gateway, see Variables Available in API Gateway.

Payload Transformation Specifies the payload transformation to be configured for the responses received from the native API.
Provide the following information:
  • Payload Type. Specifies the content-type of payload, to which you want to transform. The Payload field renders the respective payload editor based on the selected content-type.
  • Payload. Specifies the transformation that needs to be applied for the response.

    As this property supports variable framework, you can make use of the available variables to transform the response messages.

    For example, consider the client accepting two integer values value1 and value2, and you want to pass these two values from webMethods API Gateway to the client, you can configure the payload field as follows: 
    { 
"value1" : 12,
"value2" : 34
}
    You can also configure the payload field using one or more variables by using variable framework. Let us see another syntax. For example, for the same API seen in the previous example, if your native sends both the values through headers val1 and val2, and you want to add it to payload for the client to recognize the input, you can do so by configuring the payload field as follows: 
    { 
"value1" :${response.headers.val1}, 
"value2" :${response.headers.val2}
}

    For details about the variables available in webMethods API Gateway, see Variables Available in API Gateway.

    Note: If your payload content-type is different from the incoming payload's content-type, you need to transform the content-type of the header using Header Transformation.
  • Click + Add xslt document to add an xslt document and provide the following information:
    • XSLT file. Specifies the XSLT file used to transform the response messages as required.

      Click Browse to browse and select a file.

    • Feature Name. Specifies the name of the XSLT feature.
    • Feature value. Specifies the value of the XSLT feature.

      You can add more XSLT features and xslt documents by clicking add.

    Note: API Gateway supports XSLT 1.0 and XSLT 2.0.
  • Click + Add xslt transformation alias and provide the following information:
    • XSLT Transformation alias. Specifies the XSLT transformation alias

    When you receive the response in JSON, you can use a XSLT file similar to the below sample: 

    <?xml version="1.0" ?>
<xsl:stylesheet version="1.1" 
   xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

   <xsl:output method="xml"/>

   <xsl:template match="/" >
   <xsl:element name="fakeroot">
   <xsl:element name="fakenode">
        <!-- Apply your transformation rules based on the response received from the native API-->  
	</xsl:element>
	</xsl:element>
   </xsl:template>
</xsl:stylesheet>

    When you receive the response in XML, you can use a XSLT file similar to the below sample: 

    <?xml version="1.0" ?>
<xsl:stylesheet version="1.1" 
   xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">

   <xsl:output method="xml"/>

   <xsl:template match="/" >
   <xsl:element name="soapenv:Envelope">
   <xsl:element name="soapenv:Body">
        <!-- Apply your transformation rules based on the response received from the native API-->  
	</xsl:element>
	</xsl:element>
   </xsl:template>
</xsl:stylesheet>
Advanced Transformation Specifies the advanced transformation to be configured for the responses received from the native API..
Provide the following information:
  • webMethods IS Service. Specify the webMethods IS service to be invoked to process the response messages.

    You can add multiple services by clicking add.

    For details about usage of Invoke webMethods IS policy in versions 10.2 and higher, see Invoke webMethods IS Policy.

    Note: The webMethods IS service must be running on the same Integration Server as webMethods API Gateway.
  • Run as User. Specifies the authentication mode to invoke the IS service. If this field is left blank the incoming credentials of the user, identified by webMethods API Gateway, are used to authenticate and invoke the IS service. You can also specify a particular user, you want API Gateway to use to run the IS service.
  • Comply to IS Spec. Mark this as true if you want the input and the output parameters to comply to the IS Spec present in pub.apigateway.invokeISService.specifications folder in wmAPIGateway package.
  • webMethods IS Service alias. Specifies the webMethods IS service alias to be invoked to pre-process the request messages.
Transformation Metadata. Specifies the metadata for transformation of the responses received from the native API. For example, the namespaces configured in this section can be used when you provide the syntax for XPath ${response.payload.xpath} For example: ${response.payload.xpath[//ns:emp/ns:empName]}
Namespace Specifies the namespace information to be configured for transformation.
Provide the following information:
  • Namespace Prefix. The namespace prefix of the payload expression to be validated.

    For example, specify the namespace prefix as SOAP_ENV.

  • Namespace URI. The namespace URI of the payload expression to be validated.

    For example, specify the namespace URI as http://schemas.xmlsoap.org/soap/envelope/. This declaration defines SOAP_ENV as an alias for the namespace: http://schemas.xmlsoap.org/soap/envelope/.

    Note: You can add multiple namespace prefix and URI by clicking add.