Page Comparison

The The Call mediator is 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 acts in a synchronous mannernon-blocking mode, 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.

Table of Contents

maxLevel	3
minLevel	3
style	border:1
location	top
type	flat
separator	pipe

There are two modes of operation in a Call Mediator:

...

better performance. You can obtain the service endpoint for the Call mediator as follows:

Pick from message-level information
Sending a message to a predefined Pick from a pre-defined endpoint

If we you do not provide specify an endpoint, it will try the Call mediator tries to send the message using the wsaWSA:toTO address of the message. If we do provide you specify an endpoint, it will send the Call mediator sends the message according to the information in the based on the specified endpoint.

The endpoint type can be either a Leaf endpoint Endpoint (i.e. Address, /WSDL, /Default or Http/HTTP) or a Group endpoint Endpoint (Failover, Loadbalance or Recipient List).i.e. Failover/Load balance/Recipient list).

Info
The Call mediator is a content-unaware mediator.

...

Table of Contents

maxLevel	3
minLevel	3
location	top
style	border:1
type	flat
separator	pipe

...

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

	XML
	XML

<call/>

If the message is to be sent to one or more endpoints, use the following syntax:

...

The endpoint token refers to an anonymous endpoint definition.

...

UI Configuration

When adding mediators to a sequence, you can add the Call mediator by choosing Core -> Call.

Image Removed

Specify the endpoint by selecting one of the following values:

Define Inline - 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 Adding an Endpoint.
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.

Example

Service orchestration

Image Added
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.
Tip
You can click NameSpaces to add namespaces if you are providing an expression. Then the Namespace Editor panel would appear where you can provide any number of namespace prefixes and URLs used in the XPath expression.

...

Example

Example 1 - Service orchestration

In this example, the Call mediator invokes a backend service. An Enrich mediator stores 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. This response is sent to the client by 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.

Code Block

language	xml

<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

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.

Non-blocking synchronous service invocation

See this example, the message will be cloned by the Clone Mediator and sent via the Call mediator. The Drop mediator drops the response so that no further mediation is carried out for the cloned message. However, since the continueParent attribute of the Clone mediator is set to true, the original message is mediated in parallel. Therefore, the Log Mediator at the end of the configuration will log the After call mediator log message without waiting for the Call mediator response.

Code Block

language	xml

...
<log level="full"/>
<clone continueParent="true">
<target>
<sequence>
<call>
<endpoint>
<address uri="http://localhost:8080/echoString"/>
</endpoint>
</call>
<drop/>
</sequence>
</target>
</clone>
<log level="custom">
<property name="MESSAGE" value="After call mediator"/>
</log>
...

Samples

For another example, see Sample 500: Call Mediator for Non-Blocking Synchronous Service Invocation.

Versions Compared

Old Version 13

New Version Current

Key

Set up

Enabling mutual SSL in the blocking mode

Syntax

UI Configuration

Example

Service orchestration

Example

Example 1 - Service orchestration

Example 2 - Continuing mediation without waiting for responses

Non-blocking synchronous service invocation

Samples