fb
WSO2 Enterprise Integrator 6 min

Main sequence adaptation for WSO2 ESB Analytics

Domenique Mulder
Domenique Mulder
Head Of Connext
DSS Design In Sequence
Scroll

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.

Echo Message - ESB Analytics.png

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.

Mail sequence ESB Anayltics.png

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:

WSO2 ESB Anayltics thrift port settings Carbon Log.png

  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

      Define new event stream.png

    4. In the next screen “PERSIST” the data:Define new event stream WSO2 ESB 'persist'.png
    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.Create a new event receiver.png

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?

Edit Event Sink.png

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>

 

DSS- Design In Sequence.png

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:

Note your ESBs carbon console to log our message.png

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”:

Data Explorer MAINSEQCALLS WSO2 ESB.png

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. 

Full API lifecycle Management Selection Guide

WHITEPAPER

smartmockups l0qqucke