Inside the WSO2 EI/ESB product’s message context, everything is handled as XML which has an impact on the way JSON is processed. Luckily there are a few easy ways to use the JSON support within the bus. In this blog, I will cover how the product handles JSON objects.
Example setup
For this example I created a basic API definition on the EI product which is able to receive POST requests on http://localhost:8280/transform/example1 and I will use postman to send either JSON or XML messages to this endpoint.
Example API <resource methods="POST" uri-template="/example1"> <inSequence> <log level="full"/> <respond/> </inSequence> <outSequence/> <faultSequence/> </resource> </api> |
Example 1 input message { "testData": { "testValue1": "value", "testValue2": "value" } } |
When sent into the bus it will look like below. As you can see here inside we have an element which wasn’t defined in our original message body called “jsonObject”. The bus uses this to specify that the next XML element is a JSON Object when converted to the JSON format. The exception to this rule is when there are only elements with values in them instead of elements that contain elements. In that case it will create a nameless object containing the value.
Example 1 message inside the bus <testData> <testValue1>value</testValue1> <testValue2>value</testValue2> </testData> </jsonObject> |
Now let’s look at what gets returned by the API
It will respond back our original message in JSON as expected and the original format is still intact.
Example 1 result message "testData": { "testValue1": "value", "testValue2": "value" } } |
But what if I want to convert the incoming XML message to an outbound JSON message?
Example 2 input message <testData> <testValue1>value</testValue1> <testValue2>value</testValue2> </testData> |
This will of course look exactly the same inside the bus as we established it handles all the messages as XML. But as we want to get the return message in the JSON format we will have to add a line to the API insequence before the <respond/> mediator.
<property name="messageType" scope="axis2" type="STRING" value="application/json" /> |
This line details one of the generic properties that are available inside the WSO2 EI/ESB product, it causes the message type to be set to application/json which results in the bus returning a JSON message as the response. More information about generic properties can be found inside the WSO2 documentation.
Example 2 output message { "testData": { "testValue1": "value", "testValue2": "value" } } |
Now we’ve seen that if we change the message type, the bus can handle changing XML to JSON just fine. So, what does the <jsonObject> tag do in the first example? This has to do with the way JSON is handled by the product. If an incoming message contains the JSON content type http header the product converts the surrounding object to an XML representation of that object. i.e. <jsonObject> and then reconverts it during the outflow. This is also why it doesn’t work to just send the message in xml form with just the <jsonObject > element surrounding our content. The bus interprets it as XML because the content type initially given to the bus is XML so the <jsonObject> element remains an element and does not dictate the message turning into a JSON message.
Example 3 input message <testData> <testValue1>value</testValue1> <testValue2>value</testValue2> </testData> </jsonObject> |
This message is just interpreted as XML.
So, what happens if we use the above message but also use the property mediator to set the messageType? The bus will note that the <jsonObject> element is supposed to only be there in the XML notation and removes it during the JSON conversion.
Example 3 output message |
This covers the basic handling of JSON Objects on the WSO2 EI and ESB products. In part 2 of this blog I will talk about the way JSON arrays are handled and how you can use an XSLT transformation to easily create these if necessary. For more information on JSON support of the WSO2 EI/ESB product check out the WSO2 documentation or leave a comment below. I will be happy to help you.
Yenlo is the leading, global, multi-technology integration specialist in the field of API-management, Integration technology and Identity Management. Known for our strong focus on best-of-breed hybrid and cloud-based iPaaS technologies. Yenlo is the product leader and multi-award winner in WSO2, Boomi, MuleSoft and Microsoft Azure technologies and offers best-of-breed solutions from multiple leading integration vendors.
With over 240+ experts in the API, integration, and Identity Access Management domain and over $35 million in annual revenue, Yenlo is one of the largest and best API-first and Cloud-first integration specialists worldwide.