Main sequence adaptation for WSO2 ESB Analytics

The WSO2 ESB has two sequences that are already defined / available when you install the product, the FAULT and MAIN sequence.

The main sequence

The main sequence is used for any calls to the ESB where there is no defined service to match the call. With a defined service we mean for instance a axis2 service like localhost:8280/services/echo. This is a web service bundled with WSO2 ESB that does nothing more than simply echoing for instance a string you send it to.

Calling this service with the right soap message (taken from the wsdl that accompanies the echo service) it will simply respond with an echo of the message.

Let’s say that we make a mistake and we do not call the existing echo service but add an extra ‘o’ to the URL making it: localhost:8280/services/echoo. Unless we defined a service with such a name the ESB cannot find what you want to call and will route the call to something that is called the main sequence.

This main sequence will do nothing other than give a 202-accepted, log the incoming message to the console (unless it is one of the samples) as you can see in the actual text of the main sequence. The first 18 lines of comments are omitted from this screenshot.

So your call will end up nowhere since there is actually no place it could go.

One of the best practices of using the ESB is to change the main sequence a little bit so it will actually record all calls that end up in the main sequence.

In this blog  we record some simple data about the call and publish this call as an event to WSO2 ESB Analytics. In WSO2 ESB Analytics we can persist the data for review or further processing.

You can elaborate on this example for your own environment adding more information or perhaps putting the message on a message queue.

In this simple case we send an event to the ESB Analytics containing:

1. Service called
2. Date / time of the call
3. Message format

Although they are available they are not defined yet in the way that would make sense.

Setting up WSO2 ESB Analytics to receive events:

For this blog we assume you have WSO2 ESB Analytics running on the default port offset. Please note the thrift port settings in the Carbon Log when starting the instance:

1. Go to the carbon console of WSO2 ESB Analytics (https://192.168.33.10:9444/carbon);
2. Add an event stream with this data:
   1. Event stream name: mainseqcalls
   2. Event stream version: 1.0.0
   3. Set Payload Data Attributes:
      

      Attribute Name	Attribute Type
      callto	String
      date	String
      messageformat	string

      

   4. In the next screen “PERSIST” the data:
   5. Save the Event Stream.
3.  Add an event receiver for your new stream:
   1. Event Receiver name: mainseqreceiver
   2. Input event adapter type: wso2event
   3. Event stream: mainseqcalls:1.0.0 (the one you just created)
   4. Message Format: wso2event.

Now you have the required event receiver and the event stream defined. Once the ESB starts publishing events to this receiver an events table will be created and the events will be stored.

Setting up WSO2 ESB and modify the main sequence 

First WSO2 ESB needs to know where to send the published data to. Go to the “Configure” tab and select “Event Sinks” to add an event sink with this data:

• Name: mainSeqCallsSink
• Username: admin
• Password: admin
  • Or the username / password you set in Analytics
• Receiver URL: tcp://<analytics-ip-adress>:7612
• Authenticator URL: ssl:// <analytics-ip-adress>:7712
  • Remember the thrift ports?

We now need to change the main sequence to send the events to ESB Analytics.

The first part is logging to the console the fact that there is no proxy with the name we just called. The value is taken from the ‘To’ property.

<log level="custom">
<property xmlns_ns="http://org.apache.synapse/xsd" name="There is no proxy called:" expression="get-property('To')"></property>
   <property xmlns_ns="http://org.apache.synapse/xsd" name="Please check the URL - " value="This call is logged in the database"></property>
</log>

The final part is calling the PublishEvent mediator. We define the streamName, streamVersion, and eventSink and define which attributes to send as payload data:

<publishEvent>
            <streamName>mainseqcalls</streamName>
            <streamVersion>1.0.0</streamVersion>
            <eventSink>mainSeqCallsSink</eventSink>
            <attributes>
                <meta/>
                <correlation/>
                <payload>
                    <attribute defaultValue=""
                        expression="get-property('To')" name="callto"
                        type="STRING" xmlns_ns="http://org.apache.synapse/xsd"/>
                    <attribute defaultValue=""
                        expression="get-property('SYSTEM_DATE')"
                        name="date" type="STRING"
xmlns:ns="http://org.apache.synapse/xsd"/>
                    <attribute defaultValue=""
                        expression="get-property('MESSAGE_FORMAT')"
                        name="messageformat" type="STRING" xmlns_ns="http://org.apache.synapse/xsd"/>
                </payload>
                <arbitrary/>
            </attributes>
        </publishEvent>

The main sequence is now changed and when we start up the ESB again will load the main sequence. It is also possible to do that while the ESB is running. Changes will be detected and hot deployed.

We start a browser and try to access:http://localhost:8280/services/echodienietbestaat

Note your ESB’s carbon console to log our message:

In the background your ESB will publish this events’ attributes to ESB Analytics through the event sink you created. On the Analytics server side, it receives the event using the event receiver we created and send the attributes to the event table. We can review this data using the DATA EXPLORER and search data in the table “MAINSEQCALLS”:

Thanks to Rob Blaauboer for his contribution to this blog.

Also read our other WSO2 tutorials and blogs, written by our WSO2 Gurus. In case you need WSO2 support, contact the Yenlo WSO2 Guru team to get WSO2 Development Support or WSO2 Operational Support. Of course we do deliver excellent WSO2 training services as well, based on reallife WSO2 tutorials.