The Processing Steps of Virtual Services
When you create a virtual service, you can configure the following processing steps:
The service's
"In Sequence" step, which you configure to manipulate the request messages. This step can include the following sub-steps:
The
"Entry Step" (provided by default), which specifies the protocol (HTTP or HTTPS) of the requests that the virtual service will accept. For REST-based virtual services, you also specify the REST resource that the service will access and the HTTP methods (GET, POST, PUT and DELETE) that the virtual service should be allowed to perform on the REST resource.
The
"Transform" step (optional), which performs an XSLT message transformation on the request message before the virtual service submits it to the native service.
The
"Invoke IS Service" step (optional), which preprocesses the request message before the virtual service submits it to the native service.
The
"Routing Rule" step (provided by default), which specifies how the virtual service will route the requests to the native service endpoint(s). For HTTP or HTTPS requests, you have four routing choices:
"Straight Through" routing (to route requests directly to the native service endpoint).
"Context-Based" routing (to route specific types of messages to specific endpoints according to context-based routing rules).
"Content-Based" routing (to route specific types of messages to specific endpoints based on specific values that appear in the request message).
"Load Balancing" routing (to distribute requests among multiple endpoints).
The service's
"Out Sequence" step, which you configure to manipulate the response messages. This step can include the following sub-steps:
The
"Transform" step (optional), which specifies how the response message from the native service provider is to be transformed before the virtual service returns it to the consuming application.
The
"Invoke IS Service" step (optional), which preprocesses the response message before the virtual service returns it to the consuming application.
The service's
"Error Sequence" step (provided by default).
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, such as policy violation errors, connection timeouts, etc. You can choose whether or not to send the native service provider's service fault content, or just send the message. In addition, you can invoke IS services to pre-process or post-process the error messages.