The Call mediator is used to send messages out of the ESB to an endpoint.
When you invoke a service, the Call mediator acts in a non-blocking mode and the underlying worker thread returns without waiting for the response.
Since Call mediator behaves in a synchronous manner, mediation pauses after the service invocation, and resumes from the next mediator in the sequence when the response is received. Call mediator allows you to create your configuration independent from the underlying architecture.
Also, Call mediator leverages the non-blocking transports for better performance. You can obtain the service endpoint for the Call mediator as follows:
- Pick from message-level information
- Pick from a pre-defined endpoint
If you do not specify an endpoint, the Call mediator tries to send the message using the
WSA:TO address of the message. If you specify an endpoint, the Call mediator sends the message based on the specified endpoint.
The endpoint type can be Leaf Endpoint (i.e. Address/WSDL/Default/HTTP) or Group Endpoint (i.e. Failover/Load balance/Recipient list).
If the message is to be sent to one or more endpoints, use the following syntax:
endpointreftoken refers to the following:
endpointtoken refers to an anonymous endpoint definition.
When adding mediators to a sequence, you can add the Call mediator by choosing Core -> Call.
Specify the endpoint by selecting one of the following values:
- Adding an Endpoint. - Allows you to define and add the endpoint in one step. Click Add, choose an endpoint type from the list, and then define it as described in
- Pick From Registry - Pick a path either from the Configuration Registry or Governance Registry. See Working with the Registry for more information about choosing a path from the registry.
- XPath - Specify an XPath expression. You can click Namespace to map namespaces to the prefixes you use in your expression.
In the above configuration, the Call mediator is used to invoke a backend service. An Enrich mediator is used to store the response received for that service invocation.
The Filter Mediator added after the Call mediator carries out a filter to determine whether the first call has been successful. If it is successful, second backend service is invoked. The payload of the request to the second backend is the response of the first service invocation.
After a successful second backend service invocation, response of the first service is retrieved by the Enrich mediator from the property where it was formerly stored and sent to the client as the response using the respond mediator.
If it is not successful, a custom JSON error message is sent with HTTP 500. If the first call itself is not successful, the output is just sent back with the relevant error code.
For another example, see Sample 500: Call Mediator for Non-Blocking Service Invocation.