How to use the original incoming message to serve 2 different requests in WSO2 ESB

I am going to explain you a typical scenario where you have to manipulate the incoming message
into WSO2 ESB proxy service.

Proxy service is going to receive the following message as a soap request.

This message should be send to two endpoints. Those are
- Student Record department - The entire request message should be send to this endpoint.
- Finance Department - Only interested with contents inside the "Payment" element.

Initially the proxy service is expected to perform the following operation.

Extract the part and create a payload. Then send it to the finance endpoint.

Lately remove the part by applying the xslt operation to it and then you can send it to the Student Records department.




This proxy service performs following operations

1. Uses Enrich mediator to copy the complete envelope of incoming soap message.
2. Property mediator extracts the PAYMENT element and child elements.
3. Extracted Payment element can be used to create a new soap payload by using payload factory.
4. If this operation is successful we can use the enrich mediator to recreate the payload
5. On top of this enriched message XSLT mediator can be used to remove the Payment element.
6. This message now can be send to the endpoint.

The xslt script, that used to remove the Payment can be found here. I have uploaded it to the registry.

Therefore, the proxy can reference to it by using key.

How to enable nginx sticky module in Red-Hat version 6.5

Nginx seems to be the most effective software load balancer for the moment. It can be used to front several WSO2 products along with other load balancers.

When you are using load balancer with WSO2 products, the main concern is preserving the session affinity between several requests by a single user. In a clustered environment, sessions are not replicated throughout the cluster except some scenarios. Scenarios like SSO and OAuth information uses hazelcast based caching scenarios across the cluster. Therefore we don't need to have sticky sessions for them. But the admin service invocations depends on sticky sessions because we don't replicate sessions in a cluster. Therefore, it always recommended to use sticky sessions in wso2 products.

Nginx sticky session doesn't come along with default pack of nginx. Therefore, you have install it to the pack from building the source.



Step 1

Download nginx source from here.

Step 2

Download nginx sticky-module source from here.

Step 3

Stop the currently running nginx module and un-install it from the system.

service nginx stop

yum remove nginx

If you had install it from the source, you have to remove them manually. During the installation, if you had used the default installation places, you can use this command. 

sudo rm -rf /usr/local/nginx /usr/sbin/nginx /etc/nginx /usr/local/nginx/ /usr/local/nginx/

Step 4

Install the dependencies from yum install. If you are not allowed to use yum install, you can install them manually from source also.

yum install gcc gcc-c++ pcre pcre-devel openssl openssl-devel zlib zlib-devel

Step 5






Now we are going to build the nginx source with the sticky module. In order to do that, extract the nginx source and module into your preferred locations. Navigate to the nginx source's root directory and configure it.




./configure --user=nginx --group=nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --with-http_ssl_module --add-module=




If you had installed the zlib or pcre packages from the source, you have to add thier relevant path to the ./configure command. Ex. --with-pcre=/home/ec2-user/pcre-8.32  --with-zlib=/home/ec2-user/zlib-1.2.8





Step 6






Copy the nginx startup script from here to the /etc/init.d/nginx file.






change the permission level of that file  chmod a+x /etc/init.d/nginx





check the status of nginx config by running following command



chkconfig nginx on





Step 7




Now you can run the nginx with sticky session enabled.



service nginx start