Use the Service Invoke mediation primitive to call a service from inside a mediation flow. If the service returns a fault, you can retry the same service or call another service.
The Service Invoke mediation primitive lets you call a service from inside a mediation flow, rather than waiting until the end of the mediation flow and using the callout mechanism. The input message is used to call the service and, if the call is successful, the response is used to create the output message. If the call is unsuccessful you can retry the same service, or call another service.
You can have multiple Service Invoke mediation primitives inside one mediation flow. Therefore, you can have a series of service calls. You can use the Service Invoke mediation primitive in a request or response mediation flow.
Generally, the initial service that the Service Invoke mediation primitive calls is defined by the reference operation, which is a combination of the Reference Name property and the Operation Name property. For a Service Invoke mediation primitive in a subflow, the reference is defined on the subflow and resolved to a reference in the parent flow when an instance of the subflow is created.
The Service Invoke mediation primitive has one input terminal (in) and multiple output terminals. There is a fail terminal (fail) for unmodeled faults, and one output terminal for each modeled fault. Modeled faults are those that are explicitly listed in a WSDL file, any other fault is an unmodeled fault. In addition, there is an output terminal (out) that maps to the WSDL response message and a timeout terminal (timeout), which is used for some types of asynchronous calls.
Terminal type | Terminal name | Dynamic terminal? See: Note 1. |
Message type | Terminal description |
---|---|---|---|---|
Input | in | No | WSDL message type, for the request message of the operation. | Receives the input message. The message (SMO) received at the input terminal is used to call the service. See: Note 2. |
Output | out | Yes. WebSphere® Integration Developer defines one for the response message on the interface. | WSDL message type, for the response message of the operation. | Propagates the updated message. The result of the service call is used to make a new message (SMO) that is sent to this terminal. Used when the service call is successful. See: Note 3. |
Output | Defaults to modeled fault name. | Yes. WebSphere Integration Developer defines one for each modeled fault on the interface. | WSDL message type, for the fault message of the operation. | Propagates the fault response message. No information is put in the failInfo element. Used when the relevant modeled fault is returned from the service call. |
Output | timeout | No | WSDL message type, for the request message of the operation. (Same as input terminal.) | Propagates the original message together with the timeout exception information. The timeout exception information is stored in the failInfo element. Used when an asynchronous service call fails because of a timeout. The timeout terminal is not used for calls that are asynchronous with callback, only for calls that are asynchronous with a deferred response. See: Note 3. |
Fail | fail | No | WSDL message type, for the request message of the operation. (Same as input terminal.) | Propagates the original message together with any exception information. The exception information is stored in the failInfo element. Used when an unmodeled fault is returned from the service call. |
|
How the mediation flow component is called | Preferred interaction style of the target | One-way or request-response | Require mediation flow to wait for service response when the flow component is invoked asynchronously with callback | Invocation style |
---|---|---|---|---|
invoke (synchronous) | ANY | One-way | true or false | Async |
Request-response | true or false | Sync | ||
SYNC | Either | true or false | Sync | |
ASYNC | Either | true or false | Async | |
invokeAsync (asynchronous with deferred response) | ANY | One-way | true or false | Async |
Request-response | true or false | Sync | ||
SYNC | Either | true or false | Sync | |
ASYNC | Either | true or false | Async | |
invokeAsyncWithCallback (asynchronous with callback) | ANY | One-way | true or false | Async |
Request-response | true | Async | ||
Request-response | false | AsyncWithCallback | ||
SYNC | Either | true or false | Sync | |
ASYNC | One-way | true or false | Async | |
Request-response | true | Async | ||
false | AsyncWithCallback |
For example, suppose that the first endpoint is ServiceA, and the alternate endpoints are ServiceB and ServiceC. If the retry count is 5, the sequence of service calls is as follows: ServiceA, ServiceB, ServiceC, ServiceA, ServiceB, ServiceC.
Property | Valid Values | Default |
---|---|---|
Reference Name | String | |
Operation Name | String | |
Use Dynamic Endpoint if set in the message header | Boolean: true or false | true |
Async Timeout | Integer | 5 |
Invocation Style | String: Default, Sync or Async | Default |
Require mediation flow to wait for service response when the flow component is invoked asynchronously with callback | Boolean: true or false | false |
Retry On | String: Never or Any fault or Unmodeled fault or Modeled fault | Never |
Retry Count | Integer | 0 |
Retry Delay | Integer | 0 |
Try Alternate Endpoints | Boolean: true or false | true |
Consider the following when using the Service Invoke mediation primitive: