Error Messaging Step (SOAP Virtual Service)
CloudStreams returns a default fault response to the consuming application, which you can customize with context variables. This fault response is used for faults returned by the native service provider as well as faults returned by internal CloudStreams exceptions (policy violation errors, cloud connection errors and cloud connector service errors). In addition, you can:
Choose whether or not to send the native service provider's service fault content, or just send the response message.
Invoke IS services to pre-process or post-process the error messages.
You use this step to configure error messaging for a single virtual service. If you want to configure global error messaging for all virtual services, set the Service Fault Configuration options, which are located in the Integration Server Administrator (go to Solutions > CloudStreams > Administration > Service Fault Configuration).
To configure the Error Messaging step:
1. Click the virtual service name in the CloudStreams Governance view.
2. Expand the Error Sequence step in the editor.
3. Click Error Messaging and complete the following fields in the Properties view.
Error Message
Select one or both of the following options:
Custom Failure Response Message: Returns the following fault response to the consuming application:
CloudStreams encountered an error:$ERROR_MESSAGE while executing operation:$OPERATION service:$SERVICE at time:$TIME on date:$DATE. The client ip was:$CLIENT_IP. The current user:$USER. The consumer application:$CONSUMER_APPLICATION".
Note:
When $CLIENT_IP is used, CloudStreams will replace $CLIENT_IP with the IP address of the client. For privacy concerns or to be in compliance with General Data Protection Regulation (GDPR), delete the "The client ip was:$CLIENT_IP." string.
This fault response is returned in both of the following cases:
When a fault is returned by the native service provider.
In this case, the
$ERROR_MESSAGE variable in the fault response will contain the message produced by the provider's exception that caused the error. This is equivalent to the
getMessage call on the Java Exception. This maps to the
faultString element for SOAP 1.1 or the
Reason element for SOAP 1.2 catch.
CloudStreams discards the native service provider's fault and does not return this content to the web service caller since it could be considered a security issue, especially if the native provider is returning a stack trace with its response.
When a fault is returned by internal
CloudStreams exceptions (policy violation errors, cloud connection errors and cloud connector service errors).
In this case, the $ERROR_MESSAGE variable will contain errors generated by CloudStreams.
The default fault response contains predefined fault handler variables ($ERROR_MESSAGE, $OPERATION, etc.), which are described in the document Administering webMethods CloudStreams.
You can customize the default fault response using the following substitution variables, where CloudStreams replaces the variable reference with the real content at run time:
The predefined
CloudStreams context variables listed in the section
The Predefined Context Variables in the document
Administering webMethods CloudStreams.
Custom context variables that you declare using the
CloudStreams API (see the section
The API for Context Variables in the document
Administering webMethods CloudStreams).
Native Provider Fault: When you select this option,
CloudStreams sends the native service provider's service fault content, if one is available.
CloudStreams will send whatever content it received from the native service provider.
If you select this option, the Custom Failure Response Message is ignored when a fault is returned by the native service provider. (Faults returned by internal CloudStreams exceptions will still be handled by the Custom Failure Response Message option.)
Processing Method
Optionally select either of the following:
Pre-Processing: Select this option if you want to invoke an IS service to manipulate the response message before the Error Sequence step is invoked. The IS service will have access to the response message context (the axis2
MessageContext instance) before it is updated with the custom error message. For example, you might want to send emails or perform custom alerts based on the response payload. For more information about IS services, see
Invoke IS Service Step (Inbound, SOAP Virtual
Service).
Post-Processing: Select this option if you want to invoke an IS service to manipulate the service fault after the Error Sequence step is invoked. The IS service will have access to the entire service fault and the custom error message. You can make further changes to the fault message structure, if needed.
Related Topics