Aggregate multiple responses using WSO2 ESB

This blog post explains how we can aggregate multiple responses from different endpoints.
In my previous post, I explained how we can call multiple endpoints in parallel using WSO2 ESB. So in this post we are aggregating the responses we got from those service calls.

Synapse Configuration


Explanation

In this example, we have aggregated the two responses coming from our two service calls and have wrap them using My_Response tag. So your final message after the aggregation will look like below.

Note the following.

• When aggregating we have used the same id (which is "BOOKING_RESPONSE") that we set when we are calling the two services
• Inside "onComplete" element you can write the logic you want to perform after the aggregation. It can contain sequences or another call to an endpoint.
• In this example we have aggregated the bodies of the two responses without any condition
• "Aggregated_Responses" property defined before the aggregate mediator is used to accumulate the aggregated messages inside a single property. Note we have given the name of the property in the "enclosingElementProperty" tag

Apart from aggregating the responses of the service calls sent from clone mediator, we can use the aggregate mediator to aggregate responses of the service calls from iterate mediator as well.

Call multiple endpoints in parallel using WSO2 ESB

In this blog post I'm going to explain how to call multiple endpoints in parallel using the Clone Mediator.

Synapse Configuration


Explanation

In the above example configuration, we are calling the two endpoints defined in the two call templates in parallel. Similarly by adding multiple "target" elements to the same configuration you can call multiple endpoints in parallel. When using the above configuration same message is cloned and two identical copies of the message is send to the two endpoints.

Note the following.

• "sequential" attribute is set to false. Hence the two calls are happening in parallel
• A value is set to "id" so that later we can use this id to aggregate the responses from two services
• By default "continueParent" is set to false
• Instead of the call template you can also use a sequence inside the "target"

In a future post I will explain how we can aggregate the response from the two services when the clone mediator is used to call endpoints.

Adding a new xml element to the payload - WSO2 ESB

In this blog post I'm going to explain how we can insert a single new xml element in to the payload in WSO2 ESB.

Why not payloadFactory Mediator ?
If you are familiar with WSO2 ESB you may know that if we want to change the entire payload into a different payload or build a new payload by extracting properties using the existing payload, we can use payloadFactory mediator. But for this requirement that I'm going to describe, payload factory mediator will not be the ideal mediator due to different reasons. One major reason is, if the current payload is bit lengthy one, you will have to build the other parts of the payload even though you don't need to change them at all.

If not payloadFactory then what?
It will be very convenient to get this requirement done using Enrich Mediator. Enrich Mediator will take your desired OMElement (xml element) using the configuration that you state in the source section and then will insert it to the target location you state.

Usecase
I will explain the configuration using a sample usecase. Say I receive some request into ESB and depending on some properties in the payload I want to set some element in the payload. For an example assume I need to insert a new element into the payload if the received payload is not a valid payload.

Configuration
In the above example I have set the incoming request to ESB in to a property (INCOMING_REQUEST) during a previous mediation. And hence using the first enrich mediator I am replacing the body of the current payload using that property.
So the second mediator is the one actually does the job.
It will take the OMElement given under source which is
and will insert as a child element of /BookingRequest/Booking xpath location in the INCOMING_REQUEST xml.

Incoming Request


After enrich mediator
In this example I have modified the payload by adding only one xml element. Even if you need to add more elements also you can follow the same approach.

Acknowledgement

Many thanks to Rajith from WSO2 for the tip.