Validate - DataPower API Gateway
Use the Validate policy to validate the payload in an assembly flow against a schema.
For information on the different types of gateway, see API Connect gateway types.
|DataPower API Gateway||2.0.0
2.1.0 (DataPower API Gateway Version 10.0.1.0 or later)
2.2.0 (DataPower API Gateway Version 10.0.2.0 or later)
2.3.0 (DataPower API Gateway Version 10.0.2.0 or later)
2.4.0 (DataPower API Gateway Version 10.0.4.0 or later)
2.5.0 (DataPower API Gateway Version 10.5.0.0 or later)
2.6.0 (DataPower API Gateway Version 10.5.0.2 or later
2.7.0 (DataPower API Gateway Version 10.5.0.3 or later
This topic describes how to configure the policy in the assembly user interface; for details on how to configure the policy in your OpenAPI source, see validate - DataPower API Gateway.
- To validate the original input, position a Validate policy at the start of your flow.
- To validate an intermediate response that is returned from other invoke actions or tasks, position a Validate policy after those actions or tasks.
- To validate the response that is returned to the client application, position a Validate policy after the task that collates the response.
The following table lists the policy properties, indicates whether a property is required, specifies the valid and default values for input, and specifies the data type of the values.
|Property label||Required||Description||Data type|
|Title||Yes||The title of the policy.
The default value is
|Description||No||A description of the policy.||string|
|Input||No||Specifies the name of a variable in the API context. The content of the
|Output||No||Specifies the name of a variable in the API context.
|Validate against||Yes||Specifies the schema to be used for validating the payload.
Select one of the following values:
|XSLT version||No||The XSLT processor version. The default value is XSLT10.||string|
|Strict||No||Whether to enable strict XSLT error checking. Non-strict operations attempt to recover from certain errors, such as use of undeclared variables, calling undeclared templates, and so forth. By default, strict XSLT error checking is enabled.||boolean|
|Profile rule||No||Whether to enable stylesheet profiling. This option should not be used in production environments. By default, stylesheet profiling is disabled.||boolean|
|Debug rule||No||Whether to run the stylesheet, XQuery script, and JSONiq script in debug mode. When a stylesheet, XQuery script, or JSONiq script is run in debug mode, it generates a custom web page instead of displaying its normal output. The web page details exactly what occurred during execution, including the values of variables and where particular pieces of the output came from. This option should not be used in production environments. By default, debug mode is disabled.||boolean|
|Streaming rule||No||Whether the stylesheet must be run in streaming mode. Transformation of the document begins before the input is fully parsed. Not all stylesheets can be streamed. If the stylesheet cannot be streamed, an error is generated and the input is not processed. By default, streaming mode is disabled.||boolean|
|Attempt streaming rule||No||Whether to attempt to run the stylesheet in streaming mode. Transformation of the document begins before the input is fully parsed. Not all stylesheets can be streamed. If the stylesheet cannot be streamed, a warning is generated during compilation and the stylesheet is read in the entire input as normal at execution time. By default, attempting to run the stylesheet in streaming mode is disabled.||boolean|
|Minimum output escaping rule||No||Whether to escape output produced from the stylesheet during processing. Minimal escaping is particularly useful when handling non-English character sets. By default, minimum escaping is disabled.||boolean|
|Maximum stack size||No||The maximum number of bytes that the stack is allowed to use while executing a stylesheet or other compiled content. This setting is used to block infinite recursion. The minimum value is 10 kilobytes, or 10,240 bytes. The maximum value is 100 megabytes, or 104,857,600 bytes. The default value is 1 megabyte, or 1,048,576 bytes.||integer|
|WS-I Basic Profile validation||No||The validation behavior to apply to WSDL files that are checked for conformance to section 5
of WS-I Basic Profile (version 1.0, April 2004). The default setting is Warn.
|Validate message body||No||The validation behavior for the
|Validate message headers||No||
The validation behavior for the
|Validate message fault details||No||Specifies the validation behavior for the fault detail. The default setting is
|Require wrappers on fault details specified by type||No||Whether to require compatibility with RPC-style wrappers. By default, RPC-style wrappers are not required.||boolean|
|Specifically allow xsi:type='SOAP-ENC:Array' rule||No||Whether to allow the schema to accept most uses of elements with
|Validate SOAP 1.1 encoding rule||No||Whether to perform extra schema validation following the encoding rules in SOAP 1.1 Section 5. When enabled, members of SOAP arrays are validated, attributes such as @id and @href are allowed even if they are not allowed by the schema, and @href values are checked to ensure that they have a corresponding @id element. By default, the extra validation is not performed.||boolean|
|Wildcards ignore xsi:type rule||No||Whether
|Strict SOAP envelope version||No||Whether to strictly follow the SOAP binding in the WSDL. When enabled, only messages bound to SOAP 1.2 appear in SOAP 1.2 envelopes and only messages bound to SOAP 1.1 appear in SOAP 1.1 envelopes. By default, strict SOAP binding is disabled.||boolean|
|Debug XACML policy||No||Whether to compile XACML policies with debug information. Note that the XACML debugging messages are also controlled by the log event in the XACML category. Use the debug log level to view the full XACML debugging messages. By default, XACML policies are not compiled with debug information.||boolean|
|Accept MTOM/XOP optimized messages||No||Specifies whether the schema or WSDL document accepts messages where base64-encoded binary
content was optimized according to the MTOM/XOP specifications. XOP binary-optimization replaces
base64-encoded binary data with an