Implementing Request Validation
Validation of requests is supported for the following stages:
- Request Parsing
The request message can be validated at the request parsing stage. The following elements exist in the schema for the output message to be used by the Parse XSLT:
<errorCode> <errorMessage>
If errorCode is set, the request is handled by the error processing path of the processing pipeline. An error XSLT, as defined, for the operation generates an error response message by executing the FaultReportXSLT that is defined for the operation. The request is rejected with the error message sent back as the response to the request.
- Mapping and Transformation Stage
Extended request or response validation can be implemented at any of the four mapping steps. If the message does not pass the validation rules, an error message is constructed and returned in the message.
- Include the following name spaces in the XSLT
xmlns:map="http://www.tibco.com/asg/mapping" xmlns:err="http://www.tibco.com/schemas/asg/error"
- With these namespaces, use the following elements in the output message of the mapper:
<map:mapping-result> <map:error>
- Within "http://www.tibco.com/schemas/asg/error" namespace, use the following error elements to set error code and message details:
<errorCode> <errorMessage> <errorBody> <errorDetails> <nestedError> </errorDetails>
With the mapping registered as Full mode, if an error element within the registered namespaces is found in the output message, the error attributes for the request object are set with the corresponding values in the elements from the /schemas/asg/error schema from the output message.
This instructs the Core Engine to follow the error handling path of the processing pipeline. An error XSLT, as defined, for the operation generates an error message. The request is rejected and the error message is sent back as the request response.
In the Parsing step, you can only set the errorCode and errorMessage.
In any of the four mapping steps, you can return four error elements: errorCode, errorMessage, and additional elements as errorBody and errorDetails. In case, if errorCode and errorMessage are only set, then the request processing is handled in same way as in the parse step. Using the additional elements, errorBody and errorDetails elements you can construct the actual error response message for the request, which can override the creation of error message by the FaultReportXSLT. This helps to speed up processing as no second XSLT action has to be executed.