Error Messaging Step (REST Connector Virtual Service)

The default connector virtual services are configured to return the native service provider's service fault, if one is available. CloudStreams will send whatever content it received from the native service provider. You can optionally invoke IS services to pre-process or post-process the error messages.

To configure the Error Messaging step:

1. Click the connector 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.

Name

You can optionally change the step name to any other name. There are no naming conventions.

Type

(Read-only field.) Error Messaging.

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. 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 (Outbound, REST Connector Virtual Service).

Post-Processing: Select this option if you want to invoke one or more IS services 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.