Understanding the Message Mediation on WSO2 ESB

Apr 3, 2018 · 3 minute read · Comments
WSO2 ESB EI

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

inSequence: Process the message received until the backend service;
outSequence: Process the response payload from the backend service until 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 performs a defined task. It is like the Unix Philosopy 1:

“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 to coordinate the programs and make the ouput of a 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 of the current directory and passing the output to the grep command where we are going to get only the lines that ends with “.txt”.

In WSO2 ESB, the sequence could be compared as big pipe, that makes possible to use an output of a mediator as input for the next mediator. Let us see 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 apply the transformation defined in the xslt file referenced by the mediator. The result of this mediator will be the tranformed message, it 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 could 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 on understading the mediation flow on WSO2.

I hope you enjoyed!

See you in the next post.

Xico Junior

Understanding the Message Mediation on WSO2 ESB