vendredi 14 mai 2010

New Petals Webconsole feature

Well, I waited quite some time before post a new article because, I wanted to present the new feature that I added in the Petals Webconsole. This new feature is the technical monitoring which was expected for quite some time, in the new webconsole version.


This new version of monitoring functionnality is more robust, flexible and
intuitive than the old version. This new version allows you to declare several filters, each of these can monitor exchanges with the following parameters :

  • Interface name
  • Service name
  • Endpoint name
  • Operation name
But all these parameters are optional, you can declare a filter with null/null/null/null parameters. This previous filter, then monitor each exchange passing through Petals ESB.

But you can declare a filter only on an endpoint name, this will effect to monitor all exchanges on the specified endpoint name.


For this demonstration, I take in account the following components are already installed and started on the ESB :

  • petals-se-rmi, in order to send a message.
  • petals-sample-clock, in order to provide a « clock service ».


The first step of this demonstration is to create a new filter, which will monitor all exchanges performed on the « clock service » and the operation name « time ». On the following screen-shot you can observe, the four parameters (service, interface, operation, endpoint) are checked that mean, just exchanges performed on the following parameters will be monitored :

  • Interface name : {}Clock
  • Service name : {}ClockService
  • Endpoint name : 47141270665691
  • Operation name : {}time
The parameter « store » will be used to persist monitored exchange informations.

After created the filter you can see it on the filter list of current server :

You can enable it, by clicking on « Enable » on the monitoring column. After that the filter is active and

Begins to monitor focused exchanges.



For this demonstration, you can go into the « Test » tab in order to send a message to the ClockService.

For the « Test » form, you need to select :


  • the clock endpoint : 47141270665691
  • The interface name : {}Clock
  • The service name : {}ClockService
  • The operation name : {}time


You need to take in account, these previous parameters must match the same filter parameters.

To finish select the « InOut », the accepted mep on the « time » operation, and check « send a DONE »

message. You normally don't need to change the « timeout », and the content is automatically generated.

After you need to click on « SUBMIT » in order to send the message to the « ClockService ». The service

normally send you this following response :

When the response is received, thank to the monitor filter actived on the endpoint/interface/service/operation

the previous exchange should have been monitored. In order to display this monitored exchange, you need to

go on the « Filter Monitoring » tab :

So you can observe into the previous screen shot, that the exchange was correctly monitored. If by

bad luck the exchange was not displayed, you can « SUBMIT » a good starting/ending date, in order

to refresh the view and display the good slice of monitored exchanges. When you have found the

good exchange, you can click on « More details » .


The following view will be displayed :


This huge view allows to display all exchange informations, the big advantage is that the user don't need to

click somewhere to see data. This previous is very perfect J I love this term because, attachments, properties

content of each message are detailed, but also the representative image of the exchange pattern here « InOut »,

the consumer component, the provider component and all messages were sent during the exchange.

the duration, exchange properties, related informations (endpoint, service, interface, operation) are also displayed

and especially the status of the exchange ! Here « done » that tell you if the exchange was correctly finished.



To conclude, we developped this monitoring filter mechanism because, the declarative aspect of this feature

makes very light and flexible to use. I just need to monitor one endpoint/interface/service/operation, I have

just to declare a monitoring filter with the previous parameters, and after that is activated all exchanges

matching the filter parameters will be persisted. The best benefit is not all messages will be persisted but,

just those I want, the minimum needed …


After reading this and after having tested, you could give me back your opinion, your exceptions if you found them

and any comments on my new feature will be welcome.