Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Build Message Before Sending - When set to No, this setting improves performance by not building the full message XML in memory before sending it. If your configuration includes logic that is performed after the Send has initiated, set this option to Yes.

 

...

Examples

Example

...

1 - Send

...

mediator used in

...

the In sequence and Out sequence

In this example, the first send operation is included in the In mediator. Both the request and response will go through the main sequence, but only request messages will go through the In mediator. Similarly, only response messages will go through the Out mediator. The request will be forwarded to the endpoint with the given address. The response will go through the second send operation, which in this example just sends it back to the client because there is no Out endpoint specified.

Code Block
XML
XML
<definitions xmlns="http://ws.apache.org/ns/synapse">
    <in>
        <send>
            <endpoint>
                <address uri="http://localhost:9000/services/SimpleStockQuoteService"/>
            </endpoint>
        </send>
        <drop/>
    </in>
    <out>
        <send/>
    </out>
</definitions>

 

Example 2 - Specifying a response handling sequence (service chaining) 
Anchor
serviceChain
serviceChain

Code Block
language

In this configuration, the first send operation is used inside the In mediator. Both the request and response will go through the main sequence, but only request messages will go through the In mediator, and only response messages will go through the Out mediator. The request will be forwarded to the endpoint with the given address. The response will go through the second send operation, which in this example just sends it back to the requester because there is no Out endpoint specified.

html/xml
<send receive="personInfoSeq">
    <endpoint key="PersonInfoEpr"/>
</send>

In this example, requests are sent to the PersonInfoEpr endpoint, and responses from the service at that endpoint are handled by a sequence named personInfoSeq. This approach is particularly useful for service chaining. For example, if you want to take the responses from the PersonInfoEpr service and send them to the CreditEpr service for additional processing before sending the final response back to the client. In this case, you can configure the personInfoSeq sequence to send the response to the CreditEpr service and also specify another receive sequence named creditSeq that sends the response from the CreditEpr service back to the client. Following is the configuration of these sequences.

Code Block
languagehtml/xml
<sequence name="personInfoSeq">
    <xslt key="xslt">
        <property name="amount" expression="get-property('ORG_AMOUNT')"/>
    </xslt>
    <send receive="creditSeq">
        <endpoint key="CreditEpr"/>
    </send>
</sequence>

<sequence name="creditSeq">
    <log level="full"/>
    <send/>
</sequence>

Anchor
blocking
blocking

Example 3 - Configuring a blocking/non-blocking send operationoperation 

In this example, the Send mediator in a proxy service using the VFS transport is transferring a file to a VFS endpoint. VFS is a non-blocking transport by default, which means a new thread is spawned for each outgoing message. The Property mediator added before the Send mediator removes the ClientAPINonBlocking property from the message to perform the mediation in a single thread. This is required when the file being transferred is large and you want to avoid out-of-memory failures.

...