For the XSLT mapping, the Response Type indicates the output of the transformations, which can be as follows:
If the Response Type is specified as
Payload, the output document of the transformation contains just the payload and is used as the request payload for the next stage in the request pipeline processing.
If the Response Type is specified as
Full, you can access additional fields from the transaction object. The main field is the request context field which contains the HTTP headers information, URI, user name, and other authentication fields.
The following functionality is implemented using the Full Response Type of mapping transformation capability:
With the mapping transformation with Response Type as
Full, you can set the error code when the validation of the contents fails. The output of the transformation is a document which contains the updated transaction object with the error code.
For example, in case of extra validation of requests like semantic validation using XPath, it sets the error code if it fails. With the Full mapping type, the error code is updated in the transaction object. The request message processing follows the error handler path in the request processing pipeline, and is sent back to the original requestor with the error message. See
Implement Request Validation.
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.
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.
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. The additional elements,
errorBody and
errorDetails elements allows you to 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 have to be executed.
Use the responseType as Full to
access the request context field. The request context field contains the transport level information and is available for any transformations. The request context field is used for the following purposes:
For example, GetLocation is a service which finds the location for a single service. This service can be exposed as a service to find location for a group of services. This means that the gateway has to map one request to multiple requests per service. For this case, the payload in the operation request contains a sequence of multiple requests which has to be spilt and sent individually to each service endpoint.
