Call Mediator

The Call mediator is used to send messages out of the ESB to an endpoint. The Call mediator invokes the service in a synchronous manner, 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 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 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.

There are two modes of operation in a Call Mediator:

• Sending a message using message-level information
• Sending a message to a predefined endpoint

If we do not provide an endpoint, it will try to send the message using the wsa:to address of the message. If we do provide an endpoint, it will send the message according to the information in the endpoint. The endpoint type can be either a Leaf endpoint (i.e. Address, WSDL, Default or Http) or a Group endpoint (Failover, Loadbalance or Recipient List).

Syntax

<call/>

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

<call>
   (endpointref | endpoint)+
</call>

• The endpointref token refers to the following:

<endpoint key="name"/>

• 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.

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
 

<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>

In the above configuration, the Call mediator is used to call a backend. An Enrich mediator is used to store the response received from the backend. The Filter Mediator added after the Call mediator carries out a filter to determine whether the first call has been successful. If it was successful, second backend is called. The payload of the request to the second backend is the response to the first request (which is retrieved by the Enrich mediator from the property where it was formerly stored). In this example, the second call is made to an HTTP endpoint, but you ca modify the configuration to send it to a JMS queue if required.

If the second call is successful, the output of the first call is sent with HTTP 200. 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 Sample 500: Call Mediator for Non-Blocking Synchronous Service Invocation.