How to implement a custom message processor for wso2 ESB

Storing and forwarding those messages by using WSO2 ESB is a widely adopted approach. We call this Message Store and Message Forward (MSMF) pattern.

ESB has two components to achieve this target. Those are

Message Store

Used to store the incoming messages in to the ESB to JMS message Queue.

Message Processor

This keeps polling the JMS queue in predefined interval and sends the message to the target endpoint.


But by default there are two types of message processors are supported out of the box.
 
  Scheduled Message Forwarding Processor

       This message processor process's the message from queue and forward it to a target endpoint.            The implementation of this can be found in following location.

  Sampling Processor

       This message processor process's the message from queue and forward it to a target sequence.            The implementation of this can be found in following location.

You can define the maximum retry count in the message processor. Once the retry count exceeded the limit, message processor can be configured to either one of the thing.

1. Message processor can deactivate itself.
2. Or it can drop that specific message from the message queue and continue processing the rest of
    the messages in the queue.

I have requirement of message processor which is sort of extension of the second configuration defined above

Use case

I have a setup 2 activemq message queues. Those are stock_message_queue and 

failed_stock_message_queue.

Here after failing to send the message to the back end after the number of retry counts, rather than dropping the message, I have to move that message to failed_stock_message_queue. The initially obtained messages are placed in the stock_message_queue.

Therefore, as a solution we can implement a custom message processor. Custom message processor can be implemented by using MessageProcessor interface. Since the message processor goes through several life cycle stages, we have to consider a great deal of care in developing our implementation during high loads.

I will be extending the existing ScheduledMessageForwardingProcessor class. In the "checkAndDeactivateProcessor" method, I will be adding an additional check to invoke a sequence, once the maximum attempt count breached. Invoked sequence will be moving the message from the stock_message_queue to failed_stock_message_queue. 

This is the changed code snippets from original implementation of ScheduledMessageForwardingProcessor class and synapse configuration.

The complete synapse code, custom code and capp project can be found from here. The queue messages can be checked from accessing the web console of active-mq.


Built the custom store and place the jar in to /repository/components/lib

Restart the ESB server

Upload the capp from ESB management console.

How to overcome the update error in Ubuntu 13.10 version

Since the Ubuntu 13.10 version seems to be an old version, when ever I try to perform update, I have been keep getting following error.

"Err http://archive.ubuntu.com saucy/main amd64 packages 
 404 Not Found [ IP :91.189.91.23 80]"

This issue happens due to end of providing support for this version of ubuntu ( in my case its saucy ). Once the support is over it will moved to another server.

Therefore in order to fix this issue, you can either update the OS version to the latest one or you can update the package repository archives of archive.ubuntu.com  and  security.ubuntu.com package repository domain names with  old-releases.ubuntu.com. You can achieve this by using following command.

sudo sed -i -e 's/archive.ubuntu.com\|security.ubuntu.com/old-releases.ubuntu.com/g' /etc/apt/sources.list

Next in order to make sure, no places are missed again we can manually update the source.list.d file using simple grep commands.

grep -E 'archive.ubuntu.com|security.ubuntu.com' /etc/apt/sources.list.d/*

Next run the simple sudo apt-get update command. 

Next while performing the update, you might face the signature validation failed error message.

"A error occurred during the signature verification"

In such scenarios, we can follow the old famous way of solving this issue.

sudo apt-get clean
cd /var/lib/apt
sudo mv lists lists.old
sudo mkdir -p lists/partial
sudo apt-get clean
sudo apt-get update

How to configure nginx to handle same Rest URL for GET, POST, PUT in the same URI

Here the use case is there is a rest endpoint, and the incoming requests for the endpoint may have any type of HTTP methods.

Now the requirement is to configure the nginx to handle such scenarios.

Incoming url :- https://10.29.17.29:9443//api-gw/hello2/1.0/oooooogggggggggg


This url might be a GET or POST.

We can define the following nginx configuration for this purpose


upstream internallbgwhttps {
        server wso2.apimgw-cluster.com:8243;
}

server {

       listen 10.29.17.29:9443;
       server_name 10.29.17.29;

       ssl on;
       ssl_certificate     /usr/local/keys/self-ssl.crt;
       ssl_certificate_key /usr/local/keys/self-ssl.key;



 location ~^/api-gw/(.*)$ {

           access_log  /usr/local/whp/nginx/conf.d/logs/external-api-all-gw-access.log  main;

                   if ($request_method = GET){
                       rewrite  ^/api-gw/(.*)$  /gw-get/$1$is_args$args last;
           }

                   proxy_set_header X-Forwarded-Host $host;
           proxy_set_header X-Forwarded-Server $host;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header Host $http_host;

           proxy_pass https://internallbgwhttps/$1;
           proxy_redirect  https://internallbgwhttps/(.*) https://10.29.17.29:9443/$1;
       }


           location ~^/gw-get/(.*)$ {

           access_log  /usr/local/whp/nginx/conf.d/logs/external-api-get-gw-access.log  main;


                   proxy_set_header X-Forwarded-Host $host;
           proxy_set_header X-Forwarded-Server $host;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header Host $http_host;

                   proxy_pass https://internallbgwhttps/$1$is_args$args;
           proxy_redirect  https://internallbgwhttps/(.*) https://10.29.17.29:9443/$1;
       }

}