Create the Virtual Services
A virtual service runs on a CloudStreams server and acts as the consumer-facing proxy for a native service that runs in a SaaS application or in an on-premise application. Service requests sent from a service consumer go to a virtual service hosted on the CloudStreams server for processing rather than directly to the service provider. You should create a virtual service for each SaaS service you want to expose to consumers.
There are two types of virtual services: virtual services and connector virtual services.
In the inbound processing scenario, when a SaaS application sends a service request, a virtual service performs security checks and other user-defined processing before sending the request to the on-premise application.
In the outbound processing scenario, when an on-premise application sends a service request, a special kind of virtual service is used, called a connector virtual service. A
connector virtual service handles the SaaS provider's responses and logs the request/responses and their payloads.
CloudStreams provides a default connector virtual service for each metadata handler (one for the SOAP handler and one for the REST handler). You cannot modify these default services, which are located in the WmCloudStreams package. Alternatively, you can create additional connector virtual services with custom policies.
You create both types of virtual services using the CloudStreams Development plug-in provided in Designer, and then you deploy them to a CloudStreams server.
Both types of virtual services can have policies, which provide governance capabilities for the services; policies are discussed later in this overview.