CloudStreams 10.5 | webMethods CloudStreams | webMethods CloudStreams Development | CloudStreams Governance Project | Connector Virtual Services (REST)
 
Connector Virtual Services (REST)
 
New Connector Virtual Service Wizard (REST)
General Properties View (REST Connector Virtual Service)
Advanced Properties View (REST Connector Virtual Service)
Entry Step (REST Connector Virtual Service)
Routing Rule Step (REST Connector Virtual Service)
Invoke IS Service Step (Inbound, REST Connector Virtual Service)
Invoke IS Service Step (Outbound, REST Connector Virtual Service)
Error Messaging Step (REST Connector Virtual Service)
Use this editor to create custom REST-based connector virtual services. Connector virtual services handle requests in the outbound processing scenario. When an on-premise application sends a service request to a SaaS application, a connector virtual service handles the provider's responses and logs the requests/responses.
A connector virtual service runs on CloudStreams and acts as the consumer-facing proxy for a native service running in a SaaS application. A connector virtual service provides a layer of abstraction between the service consumer and the service provider, and promotes loose coupling by providing independence (of location, protocol and format) between the consuming application and the provider service.
CloudStreams provides a default connector virtual service for each metadata handler: the service WmCloudStreams.RestVS (for the REST handler) and the service WmCloudStreams.SoapVS (for the SOAP handler). The default services are located in the sample CloudStreams Governance project in the WmCloudStreams package. You cannot modify these default services.
Each default connector virtual service has a default policy (named Logging Policy), which logs all requests/responses to a database. You cannot modify the default policy. Alternatively, you can create additional connector virtual services with custom policies. If you create a connector virtual service with a custom policy, you can only include the actions in the Monitoring or Additional action categories; you cannot include the WS-SecurityPolicy 1.2 actions. For example, you might want to create a custom policy that monitors run-time performance, customizes how the service invocations are logged, validates response messages against an XML schema, or optimizes server traffic.