Understanding the Message Mediation on WSO2 ESB

One of the key pieces of the WSO2 ESB/EI development is the Mediation Sequence. Almost everything we develop is done inside sequences. Simply put, we can define a sequence as a way to group a set of mediators that will be used to handle the messages that arrive in the sequence. If we think of a Proxy Service or API, we usually have 3 sequences:

• inSequence: Process the message received until it reaches the backend service.
• outSequence: Process the response payload from the backend service until it reaches the client.
• faultSequence: Used for Error Handling.

From that, we can understand that the sequences will contain the mediators that will be used to transform/process the message until its destination (the end of the sequence).

The mediators are well-defined components that perform a defined task. It is like the Unix Philosophy:

• “Make each program do one thing well”: In our scenario, the program will be a mediator.
• “Expect the output of every program to become the input to another”: The sequence will be the responsible for coordinating the programs and making the output of one mediator be the input of the next mediator.

In Linux, we can use the output of a program as an input for another using the “|” pipe. This way we can have combinations like below:

ls -ltr | grep *.txt

In the above example, we are listing all the items in the current directory and passing the output to the grep command where we are going to get only the lines that end with “.txt.”

In WSO2 ESB, the sequence could be compared to a big pipe, that makes it possible to use an output of a mediator as the input for the next mediator. Let us look at an example in the code below:

<sequence name="TransformMessage">
    <xslt key="My_xslt" />
    <send>
        <endpoint key="MyEndpoint" />
    </send>
</sequence>

In the example above, we have a sequence with two mediators:

• xslt
• send

The xslt mediator receives the incoming message and applies the transformation defined in the xslt file referenced by the mediator. The result of this mediator will be the transformed message, which means that at that point of the flow we have a new payload. And this new payload will be used as input for the next mediator in the sequence, in our example, the send mediator.

When we realize that, it becomes easier to understand what is going on when we see a sequence, and, hence, easier to develop on WSO2 ESB.

So, using the example above, let’s say that we use that sequence inside the inSequence of a proxy service, and this proxy receives the following request:

<bookRequest>
    <book>
        <id>123</id>
    </book>
    <user>
        <id>user1</id>
    </user>
    <start>2018-03-11<start>
    <end>2018-03-14<end>
</bookRequest>

This will be the payload used as the input of the first mediator in the sequence, in our case, the xslt mediator. After the xslt transformation, we will have a different payload, let’s say:

<bookRequest>
    <bookId>123</bookId>
    <userId>user1</userId>
    <start>2018-03-11<start>
    <end>2018-03-14<end>
</bookRequest>

As we can see, we have the request payload as input for the mediator (xslt) and the mediator produced a new payload. Then if we have another mediator in the flow, it will use the resulting payload from the previous mediator as input, instead of the original payload received in the request.

In this case, the payload that is going to be sent to the backend service, using send mediator, will be the last one generated by the xslt mediator.

That’s it for today.

I hope this post helps you understand the mediation flow on WSO2.

I hope you enjoyed!

See you in the next post.