Monitoring UI

I have described using Java Callout - class for monitoring messages, adding callout class in the mediator enables to monitor messages. You can specify in my UI which fields to monitor and those fields are stored in the database. Advantage of using this approach is that you can log message fields dynamically, if you just know the XML-element you can define content of that element to be logged. Later on you can query instances with the fields you have defined.

I will add composite sensors to this monitoring UI/application so that if you do not want to use Java callout - class, or you don't have mediator, you can specify that composite sensor values will be stored in this custom monitoring app.

I will notify when I have finished these modifications and I will post a link to the source and binaries when I have finished the app.

IJavaCallout implementation class

Oracle Soa Suite 11g has possibility to specify Java callout class in mediators. By implementing IJavaCallout - interface you can intercept the messages before and after the processing in the mediator. The interface is oracle.tip.mediator.common.api.IJavaCallout this interface and other classes needed can be found from following jars: Mediator.jar, Oracle.soa.mediator.jar, Soa-infra-mgmt.jar, Fabric-client.jar and Fabric-runtime.jar.

The implementation class (or the jar containing the class) should be copied to /soa/modules/oracle.soa.ext_11.1.1. Then you should run ant against this directory, the ant can be found at: /module/org.apache.ant_1.7.1/bin.
After these steps the server should be booted.

After copying the implementation classes and restarting the server, you can call your own implementation class in the mediator. You just simple type the full classname to the field in the mediator.

I have used this feature with my previous employer. I used this feature to log messages or part of messages. I created JMS-queue to which this IJavaCallout implementation class queued the message as a string. On the other end was MessageDriven bean which listened this queue and used another EJB to query if composite with this name and version was defined. If it was, the EJB examined if there were elements specified which would be logged. If these fields were defined the EJB parsed the message and wrote element names and element values to database. Then I constructed a JSF-application which showed these fields and allowed the users to query composite instance information.

This was useful when the audit trail was se to minimum at the Soa Suite 11g, but for example the business needed to verify that some order has been processed. Then the Soa Suite administrator would specify that for example OrderId-element should be logged. The business user could use this custom JSF-application to search composite instances with certain OrderId.

I will have agreed with my former employer that I can release this whole application as a open source, so I will update this blog when I have published the code in some Open Source version control system. Meanwhile if someone is interested about this custom monitoring application you contact me and ask for the source.