Invoke IS Service Step (Outbound, REST Virtual Service)
An IS (Integration Server) service is a user-defined Integration Server flow service that you can invoke in the Out Sequence step to pre-process the response message from the native service before it is returned to the consuming application. You can create multiple Invoke IS Service steps.
An IS service must be running on the same Integration Server as CloudStreams. It can call out a C++ or Java or .NET function. It can also call other IS services to manipulate the message.
You can use predefined or custom context variables in an IS service. For more information, see the section Using Context Variables in the document Administering webMethods CloudStreams.
To add the Invoke IS Service step (outbound):
1. Click the virtual service name in the CloudStreams Governance view.
2. Expand the Out Sequence step in the editor.
3. Right-click Out Sequence and click Invoke IS Service.
The Invoke IS Service step is added under the Out Sequence step. You cannot change the order of the steps.
4. Click Invoke IS Service and complete the following fields in the Properties view.
Name
You can optionally change the step name from Invoke IS Service to any other name. There are no naming convention restrictions.
Service
The IS Service to pre-process the response message before it is returned to the consuming application. Click Browse to select a file from your file system.
When you define the IS service, the Pipeline In section of the service should have the following input variables:
proxy.name: This is the name of the virtual service.
SOAPEnvelope: This is of the Java type org.apache.axiom.soap.SOAPEnvelope
MessageContext:
CloudStreams will automatically place a MessageContext variable into the pipeline before executing the IS service call.
MessageContext is of the Java type
org.apache.axis2.context.MessageContext.
Integration Server users can use the Axis2 MessageContext object to manipulate the incoming SOAP request. The Integration Server provides built-in services (the pub.soap.* services) to work with the MessageContext object to get/set/modify the SOAP body, header, properties, etc. Integration Server users should use these services to extract the information they need from the MessageContext to build the necessary business logic.
Users do not need to understand Axis2 or Axiom (the XML object model based on StAX) to work with the SOAP request, because if they are familiar with the Integration Server pub.soap.* services, they can accomplish most of the tasks. For more information about these related Integration Server services, see the webMethods Integration Server Built-In Services Reference.
Related Topics