Receiving alerts in OpenESB

 

Introduction:

An Alert is a machine-to-person communication that is triggered when a specified condition occurs in a Project component. The condition might represent a problem that must be corrected, or the condition might be informational. An alert may also contain user-requested content such as a reminder (important), a notification (urgent), and ultimately an alert (important and urgent).

An alert notification is triggered when a specified condition occurs in a component or a service unit. The condition might represent a problem that must be corrected, or the condition might be informational. Alert Notification severities could be one of the following:

  • Fatal
  • Critical
  • Major
  • Minor
  • Warning
  • Info

Alerting in Open ESB

The Alert Management is embedded in Glassfish ESB’s JBI Runtime. The alerts can be generated from various sources – BPEL, EJB, a POJO, etc. The project developer also can raise alerts at certain events when it occurs in the composite application / BPEL/Java code. These alerts can then be managed and monitored from a Alert Client.

UseCases

The below are the usecases where Alert Management is useful:

  1. Capture Alert Event Notifications from Composite Applications, Java EE components, the JBI runtime, JBI Component Containers, and JMS Servers
  2. Allow the Alert Client to enable/disable the persistence of events generated by the Composite application.
  3. Allow the client to define a policy that will remove alerts from the persistence to prevent persistence from degrading system performance. An Alert removal policy can define the alert max age, the alert level to discard and the total number of alerts allowed to be persisted.
  4. Allow the client to enable/disable the policy mentioned above
  5. Allow the client to register itself for events from one/or multiple domains with one or multiple servers
  6. Allow the subscribed client to de-register itself from receiving events
  7. Allow the client to subscribe to receive all the events reliably
  8. Filter the alerts based on Alert Code, Component Name, Project Name, Server Name, etc.

Developing a Alerts Receiver

Unfortunately GlassfishESB installer does not package the required tools/jars for receiving alert messages. The alert management was developed as part of esb-console project that you can find here: https://java.net/projects/esb-console.

For receiving events you need to deploy a eventmanagement-webapp.war. This web application registers the required Mbeans for receiving alerts and then it passes down the alerts received to the other applications. This is an optional war which makes receiving alerts easier. Custom alert receiving clients can be written who don’t want to use this above war.

To build the war file, we need to build the entire esb-console source. You can build it yourself using maven. Anyway I have attached the pre-built war file. Simply deploy this war in glassfish. Then write a client which subscribes to alerts and receives alerts.

Below jars are required for developing an alerts client:

extended.management.api.alerts-1.0-SNAPSHOT.jar

extended.management.api.core-1.0-SNAPSHOT.jar

jbi-admin-common-2.4.0-SNAPSHOT.jar

The above jars can be obtained by building esbconsole source. The attached AlertsReceiver.zip also has the jars in lib folder.

The following code snippet provides the steps to subscribe and receive alerts.

 alertManagementService = client.getService(org.glassfish.openesb.extended.management.api.alerts.AlertsManagementService.class);
alertNotificationService = alertManagementService.getAlertNotificationService();
subscriptionID = alertNotificationService.subscribe(filterMap, targets, this, "eventProcessCallBack",new Boolean(true), this, "exceptionProcessCallBack");

The above code subscribes for receiving alerts. Below is the explanation of each argument.

filterMap – A hashmap containing filter details. For example, to fetch alerts coming from sun-http-binding with SEVERE level.

targets – glassfish server targets from where we would like to receive alerts from. Can be set to null

this – The object where the call back method is available

“eventProcessCallBack” – Call back method where alerts should be delivered

new Boolean(true) – requireReliableDelivery . Specify true if reliable delivery is required

this – the object where the exception call back method is available

“exceptionProcessCallBack” – Call back method where exceptions should be delivered.

Once the client subscribes to alert, the alerts will be delivered to the client object’s registered method.

I have attached a sample main() program to receive alerts. Also a sample AlertCA to send alerts.

eventmanagement-webapp-war
AlertsReceiver
AlertsCA

This content is restricted to site members. If you are an existing user, please log in. New users may register below.

Existing Users Log In
   
New User Registration
*Required field