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.

Crowning of WSO2 ESB as "Usain Bolt" in the ESB space !!!

With the latest round of performance testing results published for WSO2 ESB 4.8.1, it is unveiled that the fastest ESB in the ESB space is WSO2 ESB. You can find the complete article here.

The tests has been conducted against number of leading open source ESB's and it is proven that WSO2 ESB surpasses rest in almost all the scenarios and crowned as the No 1.

Observations

The table and the graph below shows the summarized results.

Conclusion

WSO2 ESB 4.8.1 has continued to outperform all other compared ESBs in almost all scenarios !!!

References

[1] http://wso2.com/library/articles/2014/02/esb-performance-round-7.5/

WSO2 ESB - Get-rid of Scientific Representation of Large Numbers When Message Transformed Through a XSLT Mediator

In this blog post I'm going to explain how to get-rid of the scientific representation ( ex: 2.2908408306E44 ) and get the non-scientific representation of the number when large numbers are mediated through the XSLT mediator. 

Problem

Following diagram explains the problem that I'm going to explain. Note that the large number that is sent across the mediator is derived from defined xpath and do some mediation logic to that particular number. (in this example multiplied by 55 ) The non-scientific number that we sent across the mediator has been converted in to a scientific number.

 When is this problematic ?

Assume that the number that is sent across the mediator is a customer ID. And the mediated customer ID will be sent through some other mediation logic or will be sent to a login portal. But that end will be expecting a non-scientific representation of the customer ID and this will result in a failure in that end.

Why is the large number represented in a scientific format ?

If you have used WSO2 ESB versions earlier to ESB 4.5.0, you might have noticed that this conversion does not happen. Reason behind this representation is from ESB 4.5.0 on-wards the XSLT engine that does the XSLT mediation has been replaced from xalan 2.7.0 to saxon. So saxon converts large numbers in to scientific representation.

How to reproduce the above scenario ?

I will explain how you can reproduce the above scenario using a sample proxy configuration with a sample XSLT style-sheet.

1. Start WSO2 ESB (tested in ESB 4.7.0) and create a proxy service using the following synapse configuration.

2. Go to Browse under Registry in the left pane and navigate to /_system/config/users/ and Click on Add Resource to add the given XSLT style-sheet (Add it as transform.xslt) and Save.

3. Go to back to Services list under Manage in the left pane and click on Try this service under testXSLT. (Our transoformation proxy service is testXSLT)

4. Use the following sample request to test out the behavior. And then click on Send.

<body>
   <customerDetail>
      <name>Tanya Madurapperuma</name>
      <id>416516514654651634984</id>
   </customerDetail>
</body>

5. Go and observe the logs that get printed on the ESB console. (Please note that in the given sample proxy configuration I have paid attention only to the message that is sent through the XSLT mediator and the message that is returned from the mediator but not about what is sent out from the out-sequence as this is just for reproducing the issue. )

In the sample proxy configuration I have set to log the message before it is sent through the mediator and the message after it is mediated by XSLT mediator.

Following are the logs that got printed in my console. Note I have marked the important parts of the log in red.

[2013-12-04 06:24:00,252]  INFO - LogMediator To: /services/testXSLT.testXSLTHttpSoap12Endpoint, WSAction: urn:mediate, SOAPAction: urn:mediate, MessageID: urn:uuid:61a7932a-1852-421b-b6f2-fbea95117e95, Direction: request, Envelope: <?xml version='1.0' encoding='utf-8'?><soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Body><customerDetail><name>Tanya Madurapperuma</name><id>416516514654651634984</id></customerDetail></soapenv:Body></soapenv:Envelope>

[2013-12-04 06:24:00,383]  INFO - LogMediator To: /services/testXSLT.testXSLTHttpSoap12Endpoint, WSAction: urn:mediate, SOAPAction: urn:mediate, MessageID: urn:uuid:61a7932a-1852-421b-b6f2-fbea95117e95, Direction: request, Envelope: <?xml version='1.0' encoding='utf-8'?><soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Body><id xmlns:cus="http://test.com" CUSTOMER_ID="2.2908408306005837E22"/></soapenv:Body></soapenv:Envelope>

Observe that id which was originally in non-scientific format is converted in to the scientific format once it is sent through the XSLT mediator.

How to get-rid of the scientific representation ?

Now let's look at how we can avoid our number getting converted to a scientific representation. There are two approaches that we can take in order to get this done.

Approach No 1
Change your XSLT style-sheet to get the number formatted back to non-scientific representation as in the following manner.

format-number($customerId * 55, "#")

You can edit your style-sheet as follows. Go to Browse under Registry and navigate to  /_system/config/users/transform.xslt and click on Edit as text and modify your XSLT style-sheet.

So at the end of the day your complete style-sheet will look as below.

Approach No 2
Replace the XSLT engine saxon with xalan.

Although this is not a recommended approach, you can get back the non-scientific representation by replacing the XSLT engine in WSO2 ESB with xalan.

For that download a WSO2 ESB version prior to 4.5.0. Then follow the below steps.

1. Go to ESB_HOME_4.7.0/lib/endorsed/ and back up saxon9he.jar and delete it.
2. Go to ESB_HOME_Prior_to_4.5.0/lib/endorsed/ and copy xalan-2.7.0.wso2v1.jar and paste in ESB_HOME_4.7.0/lib/endorsed/

And then try the transformation proxy with the same sample request.

So you logs will look like as follows once you have taken any of the above suggested approaches.

[2013-12-04 11:15:37,167]  INFO - LogMediator To: /services/testXSLT.testXSLTHttpSoap12Endpoint, WSAction: urn:mediate, SOAPAction: urn:mediate, MessageID: urn:uuid:5a9fbd26-b905-4e4e-894d-325e5881c50d, Direction: request, Envelope: <?xml version='1.0' encoding='utf-8'?><soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Body><customerDetail><name>Megan Aguilar</name><id>416516514654651634984</id></customerDetail></soapenv:Body></soapenv:Envelope>

[2013-12-04 11:15:37,171]  INFO - LogMediator To: /services/testXSLT.testXSLTHttpSoap12Endpoint, WSAction: urn:mediate, SOAPAction: urn:mediate, MessageID: urn:uuid:5a9fbd26-b905-4e4e-894d-325e5881c50d, Direction: request, Envelope: <?xml version='1.0' encoding='utf-8'?><soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Body><id xmlns:cus="http://test.com" CUSTOMER_ID="22908408306005836824576"/></soapenv:Body></soapenv:Envelope>

Observe that the number is back in non-scientific format !!!