The Call mediator is The Call mediator is used to send messages out of the ESB to an an endpoint. The
When you invoke a service, the Call mediator invokes the service in an asynchronous (acts in a non-blocking ) manner. Thenmode, and the underlying worker thread returns without waiting for the response. Mediation will be paused from that point. When the response is received, the mediation flow resumes
Since Call mediator behaves in a synchronous manner, mediation pauses after the service invocation, and resumes from the next mediator in the sequence.The Call mediator is similar to the Callout mediator, which performs a blocking external service invocation during mediation. Unlike the Callout mediator, 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 much greater performance. Therefore, in most cases you should use the Call mediator instead of the Callout mediator. However, the Callout mediator is recommended in situations where you need to execute the mediation flow in a single thread.The Send Mediator is another similar mediator. A send operation can be blocking or non-blocking depending on the actual transport implementation used. The default NIO-based http/s implementation does not block on a send.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).
| Info |
|---|
The Call mediator is a content-unaware mediator. |
...
| Table of Contents | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
Set up
Enabling mutual SSL in the blocking mode
When using the Call mediator in the blocking mode (blocking=true), enable the mediator to handle mutual SSL by adding the following JVM settings to the <ESB_HOME>/bin/wso2server.sh file:
| Code Block |
|---|
-Djavax.net.ssl.keyStore="$CARBON_HOME/repository/resources/security/wso2carbon.jks" \
-Djavax.net.ssl.keyStorePassword="wso2carbon" \
-Djavax.net.ssl.keyPassword="wso2carbon" \ |
Syntax
| Code Block | ||||
|---|---|---|---|---|
| ||||
<call/> |
If the message is to be sent to one or more endpoints, use the following syntax:
...
Select one of the following options to define the endpoint to which the message should be delivered.
| Parameter Name | Description | ||
|---|---|---|---|
| None | Select this option if you do not want to provide an endpoint. The Call mediator will send the message using its wsa:to address. | ||
| Define Inline | If this is selected, the endpoint to which the message should be sent can be included within the Call mediator configuration. Click Add to add the required endpoint. See Adding an Endpoint for further details. | ||
| Pick From Registry | If this is selected, the message can be sent to a pre-defined endpoint which is currently saved as a resource in the registry. Click either Configuration Registry or Governance Registry as relevant to select the required endpoint from the resource tree. | ||
| XPath | If this is selected, the endpoint to which the message should be sent will be derived via an XPath expression. You are required to enter the relevant XPath expression in the text field that appears when this option is selected.
|
|
...
Example
Example 1 - Service orchestration
...
| Code Block | ||
|---|---|---|
| ||
<target>
<inSequence>
<log/>
<call>
<endpoint>
<http method="get" uri-template="http://192.168.1.10:8088/mockaxis2service"/>
</endpoint>
</call>
<enrich>
<source type="body" clone="true"/>
<target type="property" action="child" property="body_of_first_call"/>
</enrich>
<filter source="get-property('axis2', 'HTTP_SC')" regex="200">
<then>
<log level="custom">
<property name="switchlog" value="Case: first call successful"/>
</log>
<call>
<endpoint>
<http method="get" uri-template="http://localhost:8080/MockService1"/>
</endpoint>
</call>
<filter source="get-property('axis2', 'HTTP_SC')" regex="200">
<then>
<log level="custom">
<property name="switchlog" value="Case: second call successful"/>
</log>
<enrich>
<source type="property" clone="true" property="body_of_first_call"/>
<target type="body"/>
</enrich>
<respond/>
</then>
<else>
<log level="custom">
<property name="switchlog" value="Case: second call unsuccessful"/>
</log>
<property name="HTTP_SC" value="500" scope="axis2"/>
<payloadFactory media-type="json">
<format>{ "status": "ERROR!"}</format>
<args/>
</payloadFactory>
<respond/>
</else>
</filter>
</then>
<else>
<log level="custom">
<property name="switchlog" value="Case: first call unsuccessful"/>
</log>
<respond/>
</else>
</filter>
</inSequence>
</target> |
...
Example 2 - Continuing mediation without waiting for responses
...