Error Processing with Sentry
Sentry administrators may wish to customize the error messages returned from Sentry to the client application. With Sentry the customization of the error responses can range from simply changing the HTTP status code to full customization of the HTTP response headers and response message body.
With Forum Sentry there are two distinct scenarios for processing error conditions. The first is customization of Sentry generated errors. The second is customization of remote server generated errors. The information below details the different scenarios.
Customizing Sentry Generated Errors
If the processing failure occurs in Sentry for any reason, Sentry will generate an error response based on the applicable Error Template. The Error Templates in Sentry can be set per listener policy, per virtual directory, and in some cases at the task list level. The error templates will build the appropriate error format for the type of traffic being processed. For instance, if working with a SOAP 1.1 service, a SOAP 1.1 fault will be generated. The content of the error template can be customized, and there are system variables that can be used within these error templates
Error Template System Variables:
%attr.<attribute name>% The value of the session attribute. In the example %attr.sessionnum%, the attribute name is sessionnum. The attribute name can be a defined attribute on a Map Attribute to XML task, a Map Attribute from XML task or it can be a user attribute.
%date% The date (year, month and day) displayed when the Task generated the error.
%datetime% The date (year, month and day) and time (hour, minute and second) displayed when the Task generated the error.
%errorcode% The error code returned by the server or a system error matched to an HTTP error code.
%errormsg% The detailed error message displayed when the error is triggered.
%policy% The policy name that generated the error.
%sysname% The name of the system. This name is added in the Network screen or through the network config name command from the CLI. Note: If a System Name (found on the Network screen) has not been added, then the default template will display the %sysname% tag as blank.
%task% The name of the Task that generated the error.
%tasklist% The name of the Task List that generated the error.
%time% The time (hour, minute and second) displayed when the Task generated the error.
%transaction% The document ID of the request.
%username% The user name for the user that generated the error.
For more information on Error Templates please review the attached Network Policies Guide.
If modifying the message body and the status code on the error template is not enough, a Task List Group can be run on the Sentry generated error (body and headers) to further customize the error response.
The Task List Group can contain multiple task lists ( to be conditional ) that uniquely identify the Sentry generated errors (Identify Document task) and then modify the headers or status code (Map Attributes and Headers task), and/or replace the entire document with a custom response (Replace Document task).
Customizing Remote Server Generated Errors
When the processing error occurs on the remote server, the error response is returned to Sentry rather than generated by Sentry. These responses can be returned back to the client as is, or modified by Sentry. With this scenario the Sentry Error Templates are not used. Instead, use Task Lists that process the response messages.
In order for Sentry to process response messages, ensure that the Response Processing is enabled on the applicable Network Remote Policy.
The Task List Group can contain multiple task lists ( to be conditional ) that uniquely identify the remote server errors (Identify Document task) by HTTP status code, response header value, or XML content using XPath; then modify the headers or status code (Map Attributes and Headers task), modify the body (Map to XML), and/or replace the entire document (Replace Document task) with a custom response doc.
0 Comments