Structural validation of the query

Because writing ViewConfigs and TableViewConfigs is a tedious and error-prone task, the following endpoints allow using the validationEnabled parameter.

• {{domain}}/rest/2.0/outputModule/export/{{xml | json | csv}}

• {{domain}}/rest/2.0/outputModule/export/{{xml | json | csv | excel}}-file

• {{domain}}/rest/2.0/outputModule/export/{{xml | json | csv | excel}}-job

This parameter, when set to true, enables validation of the input ViewConfig/TableViewConfig. By default, the parameter value is set to false.

The example below shows a small typo in the filter. userID is used instead of userId. When you make a POST request to {{domain}}/rest/2.0/outputModule/export/json?validationEnabled=true, the following body results.

JSON

{
  "ViewConfig": {
    "displayLength": 5,
    "Resources": {
      "Community": {
        "Id": { "name": "communityId" },
        "Name": { "name": "community" },
        "Responsibility": {
          "Id":{ "name": "responsibilityId"},
          "User": {
            "Id": { "name": "userId" },
            "FirstName": { "name": "userName" }
          }
        },
        "Filter": {"Field": {"name":"userID", "Operator":"NOT_NULL"}}
      }
    }
  }
}

YAML

The response will be similar to the example below.

{
    "viewConflict": [
        {
            "type": "View Configuration Conflict",
            "message": "Field 'userID' is unknown.",
            "id": "7c723d33-dc8d-484b-90df-91e3364d771a"
        }
    ]
}