Fiorano ESB Server hosts various JMS topics for the ESB Peer Servers to publish information related to application, component and internal state changes. These events are used to keep the ESB Server and the Peer Server synchronized with each other. Events generated within the Enterprise Server are not published to any JMS topic but these can be subscribed to using various other transport protocols. All these events are referred to as control messages within the Fiorano Network.

Custom monitoring applications can be written to subscribe to these control messages so as to monitor the Fiorano Network. In addition, the Fiorano Network can be monitored using the Web Dashboard. This document gives insight of all the necessary details to build one such custom monitoring application in addition to describing the in-built monitoring and reporting capabilities.

Event Types and Subscription

This section describes various kinds of events that are raised in the Fiorano Network. These events are used to perform various tasks such as updating necessary data structures, synchronizing application states, notifying connected clients and so on.

Audit Events

All audit events generated by the Peer Servers are published onto the Enterprise Server topic 'FES_AUDIT_EVENT_TOPIC'. These audit events provide a means of accountability for changes done in the system and also help in detecting security violation which may occur.

ApplicationAuditEvent

• ApplicationLifeCycleAuditEvent: This event is raised when there is a change in the Event Process life cycle such as from a stopped to a launched state or vice-versa.
• ApplicationRepositoryAuditEvent: This event is raised when there is a modification in the Event Process Repository such as when changes are made to an Event Process, Deletion of an Event Process, Addition of an Event Process to a repository and so on. This audit event is raised only within the Enterprise Server as the Peer Server does not have an Event Process repository of its own.

ServiceAuditEvent

• ComponentLifeCycleAuditEvent: This event is raised when there is a change in the Component life cycle such as from a stopped to a running state or vice-versa.
• ServiceRepositoryAuditEvent: This event is raised when there is a modification in the component repository of either the Enterprise Server or the Peer Server.

PrincipalStoreSyncAuditEvent

This event is raised when the Peer Server synchronizes its principal store with that of the Enterprise Server.

AuthenticationAuditEvent

This event is raised when the User tries to log on to or create a connection with the Server.

AuthorizationAuditEvent

This event is raised when a user tries to perform an operation that is protected by permissions granted to the user such as looking up a connection factory, creating a JMS connection, launching an event process, changing audit policies, and deleting audit events.

SecurityAuditEvent

This event is raised when there is a modification in the security database of the Server such as when there is a new User creation, a User deletion, a group creation, an addition of a member to a group, the granting of specific permissions to a user and so on.

Refer to eMapper section for detailed description of Audit Events and Audit Functionality as a whole.

Subscribing to Audit Events

To subscribe to audit events generated by any Server, add an Audit Event Listener by performing the following actions:

1. Launch the preferred profile in eStudio.
2. From he Profile node, navigate to to Fiorano > etc > AuditManager.
3. Right-click the AuditManager node and select Add > Add AuditEventListener.
4. Provide a fully qualified class name for the audit listener class of this listener and add this class to the Server classpath.

System Events

System Events have an important part to play within the Fiorano System since they determine how the system behaves in a particular situation. All Events are defined in the fiorano.tifosi.dmi.events package present at the location $FIORANO_HOME/esb/shared/lib/esb-shared-tif-dmi.jar. This section provides a brief explanation of System Events and also describes various ways to subscribe to Events.

Event Description

A brief description of various System Events is as below:

Refer to Events Tracking section for detailed description of Audit Events and Audit Functionality as a whole.

Subscribing to System Events

System Events generated within the Peer Servers are published onto various monitoring topics. Users can create subscribers to these topics to listen to the Events generated by the Peer Servers. (See next section for the list of events published onto such topics.)

Note that such a subscriber would not receive events generated within the Enterprise Server, as these Events are not published onto any topic. For listening to Events generated within both the Enterprise Server and the Peer Server using a single application, Users can register an Event listener within the Enterprise Server using the Run Time Library (RTL) APIs. These RTL APIs provide support for subscribing to Events from the Enterprise Server and the Peer Servers such as:

• HAStatusEvent
• HARepositorySyncEvent
• UserEvent
• ApplicationEvent
• RouteEvent
• SBWEvent
• SecurityEvent
• ServiceEvent
• ServiceRepositoryUpdationEvent
• SPEvent
• TPSEvent

An RTL Event Subscriber can listen to all System Events except Backlog and Low Memory Events. To subscribe to these two Events from the Peer Server, create a subscriber for the topic FES_BACKLOG_MONITORING_TOPIC and for the topic FES_SYSTEM_EVENTS_TOPIC along with appropriate message selectors as shown in the next section.

To subscribe to Low Memory Events from within the Enterprise Server, Users need to register a JMX notification listener with the JMX Object identified using the following name:

Fiorano.jmx.notifications:ServiceType=EventManager,Name=ResourceEventManager.

Refer to $FIORANO_HOME/fmq/samples/JMX/JMXNotifications.java for a sample code to register the JMX Notification listener.

Event Topics

System Events from Peer Servers are published onto various monitoring topics present within the Enterprise Server. Each type of Event has a JMS message header property named 'DATA_TYPE' or 'EVENT_TYPE' set to a unique value to distinguish between various Events. This section provides a list of the Event Topics along with the list of Events that are published by the Peer Servers. Please note the different values given for DATA_TYPE/EVENT_TYPE properties of these Events. These values may be used to create message selectors; subscribe to preferred set of Events from an Event Topic.

FES_SYSTEM_EVENT_TOPIC

• Application Event (DATA_TYPE = 302)
• Service Event (DATA_TYPE = 303)
• TPS Event (DATA_TYPE = 305)
• Low Memory Event (DATA_TYPE = 404)

FES_SBW_EVENTS_TOPIC

• SBW Event (DATA_TYPE = 307)

FES_USER_EVENTS_TOPIC

• User Event (DATA_TYPE = 217)

FES_BACKLOG_MONITORING_TOPIC

• Backlog Monitor Event (DATA_TYPE = 403)

FES_AUDIT_EVENT_TOPIC

• Audit Event (EVENT_TYPE = 600)

Sample Subscriber Applications

Please refer to the samples named TopicEventSubscriber.java and RTLEventSubscriber.java located under $FIORANO_HOME/esb/samples/SamplePrograms/EventSubscriber which illustrate the use of APIs to subscribe to various Events. Custom applications can be built around these samples to perform various actions on receiving the Event.

Built-in Event Tracking / Reporting

Using the Fiorano dashboard or the Event Manager tool, you can see various types of System Events raised within the Fiorano Network. As these events are stored into a configurable SQL database, it enables to search for historical events using these tools.

The Event Viewer can be used to view the System Events listed below:

• Application Events
• Service Events
• Security Events
• TPS Events
• SP / Enterprise Server Events
• SBW Events

In addition, FioranoMQ provides built-in support for registering SMTP alerts for various types of System Events. For Backlog and Memory Events, you have a choice to sign up for JMS alerts. Alert registration can be done via dashboard. Refer to sections Server Status and Document Tracking for instructions regarding this.

Alerts can be registered for the System Events listed below:

• Application Events
• Service Events
• Security Events
• TPS Events
• SP / Enterprise Server Events
• Backlog Notification Events
• Low Memory Events

Event Parameters

Various Enterprise Server Level parameters determine whether the Enterprise Server will listen to a particular type of Event and whether these events will be forwarded to RTL clients. These parameters can be configured via Profile Manager in eStudio.

The configurable parameters present at FES > Fiorano > Esb > Events > FESEventsManager are described below:

The configurable parameters present at FES > Fiorano > Esb > Sbw > SBWManager are described below:

Other Monitoring activities

Measuring Response Time

Each SBW Event captures information of the time the message was tracked. This information can be used to measure the response time of a service by enabling document tracking at both input and output ports of the service. This feature can also be used to measure the time taken for the message to flow from one service to another. In the screenshot below, document tracking has been enabled on the input port of chat1 service and output port of chat2 service. It is possible to view that it took 69 milliseconds for the message to flow from chat1 service to the chat2 service.

Measuring Throughput

Fiorano pre-built components provide functions to enable monitoring via their Custom Property Sheet (CPS) panel. When monitoring is enabled, these components publish information about the messages processed within configured interval in the form of User Events. These events provide information about the number of messages processed within this time. The dashboard can be used to view data both in tabular as well as graphical forms (see screenshot below). Please, refer to Events section for more details.

Service Status Monitoring

Service Events raised by the Peer Server contain information about the current status of the service such as whether the service is running or not. Using the dashboard, you can register to receive SMTP alerts when a particular service within an Event Process is launched or killed. These alerts can be useful in detecting abnormal service termination due to unexpected errors such as a JVM crash or an unintentional shutdown. Please refer to Server Status section for more details.

Messaging Threshold

Using the dashboard, you can create backlog policies and define SMTP/JMS alerts to be sent when a service has more than the specified number of messages in its pending messages queue. You may also create more than one policy for a single service to receive alerts at multiple levels of a pending message queue. For example, registering to receive SMTP alerts or registering to receive JMS alerts when the size of the pending message queue reaches 5, 10 or 15 either in an upward or a downward direction. Please refer to Monitoring section for more details on Backlog Monitoring feature.

Server Memory Threshold

Using the dashboard, you can create memory usage policies to receive SMTP/JMS alerts when a Server memory reaches the specified threshold. These alerts can be used as a preventive measure to avoid any future issues caused by Out Of Memory problems. Please refer to Document Tracking in for more details.

List of Events

While registering to receive SMTP alerts or registering to receive JMS alerts, Dashboard configures the framework to send email alerts for various events. Below is the list of Events under various Event Types.