DataPower API
Gateway

Validate - DataPower API Gateway

Use the Validate policy to validate the payload in an assembly flow against a schema.

Gateway support

Note: This page describes the Validate policy implementation in the DataPower® API Gateway. If you are using the DataPower Gateway (v5 compatible), see Validate - DataPower Gateway (v5 compatible).

For information on the different types of gateway, see API Connect gateway types.

Table 1. Table showing which gateways support this policy, and the corresponding policy version
Gateway Policy version
DataPower API Gateway 2.0.0

2.1.0 (DataPower API Gateway Version 10.0.0.1 or later)

2.2.0 DataPower API Gateway Version 10.0.1.1 or later)

2.3.0 DataPower API Gateway Version 10.0.1.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.

About

Position this policy where required in the assembly flow as follows:
  • 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.
Note: With the DataPower API Gateway, the input to the Validate policy must be parsed data. One way to produce parsed data is to use a Parse policy before a Validate policy in your assembly flow, which provides explicit control of the parse action.

Properties

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.

Table 2. Validate policy properties
Property label Required Description Data type
Title Yes The title of the policy.

The default value is validate.

string
Description No A description of the policy. string
Input No Specifies the name of a variable in the API context. The content of the body field of the variable, which is represented by variable_name.body, is the input data to validate. By default, the variable name is message. string
Output No Specifies the name of a variable in the API context.
  • If the validation passes, the body field of the output variable, which is represented by variable_name.body, stores the output of the assembly validate action.
  • If the schema to validate is a JSON schema, the validation also adds any default values that are missing from the payload.
  • If the validation fails, no output is stored.
  • If an output variable is not specified, the results of the assembly validate action are not saved.
string
Validate against Yes Specifies the schema to be used for validating the payload.
Select one of the following values:
  • definition: Select this value if you want to use a previously defined schema to validate the payload that is returned from other invoke actions or tasks in the assembly flow.

    From the Definition Object list, select the required schema. For information on defining a schema for an API definition, see Editing an API definition.

  • URL: the schema is identified by a URL location.
    • In the JSON Schema URL field, enter the URL of the JSON schema to be used for validating a JSON payload.
    • From the XML Validation Mode list, select how XML validation is to be performed:
      • None: no XML payload validation is required.
      • xsd: an XML schema will be used to validate an XML payload. In the XML Schema URL field, enter the URL of the XML schema.
      • wsdl: a WSDL schema will be used to validate a SOAP payload. In the WSDL URL field, enter the URL of the WSDL schema.
      • soap-body: validate the body of a SOAP message against the XML schema only.
      Note: The following limitations apply to schemas used for JSON validation, which include JSON schemas and OpenAPI documents that are used as schemas for validation. Exceeding these limits can impact compilation performance and is not supported.
      • Maximum of 6,500 lines. Each key and each item in an array count as a line.
      • Maximum recursion depth of 250.
      • Maximum of 3,000 items in enum lists.
  • WSDL: (available with a SOAP service based API only) use the XML schema in the WSDL file associated with the API operation or the API path.
  • body-param: validate the request input against the schema definition that is specified in the TYPE field for the request parameter for this operation. For information about how to create a request parameter, see Configuring an operation.
  • response-param: validate the response to be returned to the client application, against the schema definition that is specified in the SCHEMA field for the response parameter for this operation. For information about how to create a response parameter, see Configuring an operation.
  • GraphQL: (available for a GraphQL proxy API only) validate the payload against the GraphQL schema that has been imported into the GraphQL proxy API. In addition, either the GraphQL query or response, depending on the input, is analyzed against the GraphQL schema to calculate the cost, and the result is placed in the API context.

    For more information on GraphQL proxy APIs, see Creating a GraphQL proxy API and GraphQL context variables.

string