Nav

Request-Reply Scope

The Request-Reply scope enables you to embed a "pocket" of asynchronous processing within a Mule flow. This functionality enables you to receive a response from an asynchronous flow without hardcoding the destination of the response. For example, you can use request-reply to convert a one-way VM or JMS flow to a request-response flow without having to change it’s configuration.  In other words, the request-reply converts part of a synchronous process into an asynchronous one. . 

Prerequisites

This document assumes that you understand the difference between synchronous and asynchronous flows. Furthermore, review Scopes in general.

Basic Anatomy

Request-reply consists of two parts:

  • The request portion wraps the connector or outbound connector which submits an asynchronous request to another flow or an external resource

  • The response portion wraps the connector or inbound connector which receives an asynchronous response from another flow or an external resource

image

Request-reply obviates the need to explicitly reference the outbound- and inbound-connectors to each other. When Mule asynchronously sends a request via the VM outbound-connector in the Request-Reply scope, it implicitly sets the message’s outbound property – MULE_REPLYTO – to the URL of its corresponding inbound connector. In other words, in the example above, you do not need to include a reference in the VM in the Reply portion to reference the VM in the Request portion which submitted the request. 

VM or JMS connectors that are set up to be transactional can’t be used inside a request-reply scope. Both VM and JMS connectors allow you to perform transactions of several different types, but none of these are compatible with how the request-reply scope works. This is because the request that is to be sent out by the request-response isn’t sent until the transaction is committed – but the transaction in turn is not committed until the entire flow has been executed (including the execution of the request-response scope). This leads to a situation where both processes are blocking each other: the flow isn’t fully executed because it’s still waiting for the response on the request-reply scope, but this response never arrives since the request hasn’t been sent yet (as mentioned before, this message is sent only once the transaction is committed).

Configuring Request-Reply

  1. Add a Request-Reply scope to your flow, then configure the attributes according to the table below.

    image

    Field Description

    Display Name

    Defines unique value for the element in the application.

    Value: String
    Required: Yes

    Prefix of the Object Store

    Defines the object store name prefix in which Mule should store request-reply messages.

    Value: String
    Required: No

    Timeout (ms)

    Defines the time the asynchronous process remains alive before timing out. This defines how long the inbound-connector waits for a response.

    Value: Integer
    Required: No

  2. Add an outbound-connector to the Request portion of the scope, then add an inbound-connector to the Response portion of the scope. Configure each connector to submit requests and receive responses, respectively. The scope ensures that the activity that occurs within it proceeds asynchronously, relative to the rest of the flow.

    image

  1. Add a request-reply element to your flow, then configure the attributes according to the table below.

    
           
                   
                
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    
    <?xml version="1.0" encoding="UTF-8"?>
     
    <mule xmlns:http="http://www.mulesoft.org/schema/mule/http" xmlns:vm="http://www.mulesoft.org/schema/mule/vm" xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
        xmlns:spring="http://www.springframework.org/schema/beans"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd
    http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
    http://www.mulesoft.org/schema/mule/vm http://www.mulesoft.org/schema/mule/vm/current/mule-vm.xsd
    http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd">
     
        <http:listener-config name="HTTP_Listener_Configuration" host="localhost" port="8081" doc:name="HTTP Listener Configuration"/>
     
        <flow name="request-replyFlow1" doc:name="request-replyFlow1">
            <http:listener config-ref="HTTP_Listener_Configuration" path="/" doc:name="HTTP"/>
            <request-reply doc:name="Request-Reply">
                <vm:outbound-endpoint exchange-pattern="one-way" path="request" doc:name="VM"/>
                <vm:inbound-endpoint exchange-pattern="one-way" path="reply" doc:name="VM"/>
            </request-reply>
        </flow>
    </mule>
    Element Description

    request-reply

    Defines unique value for the element in the application.

    Attribute: doc:name
    Value: String
    Required: Yes

    request-reply

    Defines the object store name prefix in which Mule should store request-reply messages.

    Attribute: storePrefix
    Value: String
    Required: No

    request-reply

    Defines the number of milliseconds the asynchronous process remains alive before timing out. This defines how long the inbound-connector waits for a response. By default, the timeout=-1 and it waits indefinitely.

    Attribute: timeout
    Value: Integer
    Required: No

  2. As a child element of the request-reply element, add an outbound connector or connector to define how Mule submits a request to an external source.

  3. As a child element of the request-reply element, add an inbound connector or connector to define how Mule receives a response to an external source. The scope ensures that the activity that occurs within it proceeds asynchronously, relative to the rest of the flow.

See Also