Contents

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.

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.
Icon
  • Alternatively, you may create a subscriber to topic FES_AUDIT_EVENT_TOPIC present in the Enterprise Server to listen to audit events from all connected Peer Servers.
  • Audit Events from the Enterprise Server need to be subscribed to by using the method described above.

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:

System EventDescription
HAStatusEventThis Event is launched within the Enterprise Server when there is a change of state of an HA Server such as from the ACTIVE to the STANDALONE state.
HARepositorySyncEventThis Event is launched within Enterprise Server when HA Servers synchronize their databases with each other.
UserEventThis Event is launched within the ESB network by business components whose monitoring configuration has been enabled.
ApplicationEventThis Event is launched by the Enterprise Server when an application is launched, killed, created, saved, or deleted. Application launch and kill events are also handled by the Peer Servers.
RouteEventThe Enterprise Server launches this Event when a debugger is set or removed from a running Event Process.
BacklogMonitorEvent

This Event is launched by the Peer Servers when the configured backlog level is reached as defined by the backlog policies active on that Peer Server.

LowMemoryEventThis Event is launched by all Fiorano Servers when they detect that memory usage of a Server has crossed the specified threshold.
SBWEventThis Event is launched by the Peer Servers when a message reaches a port on which document tracking is enabled. On receiving these Events from the Peer Servers, the Enterprise Server stores them into a preconfigured document tracking database.
SecurityEvent

The Enterprise Server launches this Event when a User action results in security violations (as determined by the ACL of that particular User in the Enterprise Server such as launching or killing an Event Process or a Service Instance.

ServiceEventThis Event is launched by the Peer Server when a Service Instance is launched or killed.
ServiceRepositoryUpdationEvent

The Enterprise Server launches this event when some modification is made to the Service Repository of the Enterprise Server such as registering a new service, addition of a resource to an existing service and so on.

SPEventThe Enterprise Server raises this Event at the time of startup and shutdown.
TPSEvent

This Event is launched by both the Enterprise Server and Peer Servers when connecting to/disconnecting from the Enterprise Server. Note: On receiving this Event from a Peer Server, the Enterprise Server synchronizes the states of all Event Processes with the Peer Server.

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.

Icon

Please refer to the section named Sample Subscriber Applications for JAVA Samples to create a Topic Event Subscriber and a RTL Event Subscriber.

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)
Icon

The value of DATA_TYPE will be different for different types of audit events as shown below:

  • Application Life-Cycle Audit Event (DATA_TYPE = 105)
  • Application Repository Audit Event (DATA_TYPE = 103)
  • Component Life-Cycle Audit Event (DATA_TYPE = 106)
  • Service Repository Audit Event (DATA_TYPE = 104)
  • Principal Store Sync Audit Event (DATA_TYPE = 108)
  • Authentication Audit Event (DATA_TYPE = 1)
  • Authorization Audit Event (DATA_TYPE = 2)
  • Security Audit Event (DATA_TYPE = 3)

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:

System EventDescription
EnableSystemEventTrackingThis parameter determines whether System Events will be inserted into the Events databasefor future reference. By default, this property is enabled.
ListenForUserEvents

This parameter determines whether the Enterprise Server will create a subscriber to listen for User Events or not. If RTL clients are to receive User Events, this parameter should be enabled. By default, this property is enabled.

RTLToReceiveUserEvents

This parameter determines whether or not User Events captured by the Enterprise Server (given the ListenForUserEvents flag is Enabled) will be forwarded to RTL clients. By default, this property is in disabled state.

RTLToReceiveSecurityEventsThis parameter determines whether Security Events raised within the Enterprise Server will be forwarded to RTL clients. By default this property is disabled.

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

System EventDescription
EnableDocTrackingThis parameter determines whether the SBW Events received by the Enterprise Server will be inserted into the SBW database for future reference.
RTLToReceiveSBWEvents

This parameter determines whether the SBW Events captured by the Enterprise Server will be forwarded to RTL clients. This is an expert property specified under the profile node listed above.

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.

Event TypeEvents RaisedDescription
ApplicationAPPLICATION_LAUNCH_STARTED

Starting launch of an application

APPLICATION_LAUNCHED

Successful launch of an application
APPLICATION_KILLED

Successful stop of an application

APPLICATION_SYNCHRONIZEDSynchronize call sent to an application
ServiceSERVICE_HANDLE_BOUNDService handle created / Service started

SERVICE_HANDLE_UNBOUND

Service handle destroyed / Service stopped
SERVICE_FAILED_TO_LAUNCHService failed to start
FPS

FPSTIFOSI_SERVER_UNAVAILABLE_EVENT

Peer Server disconnected
TIFOSI_SERVER_RECONNECT_EVENTPeer Server reconnected
TIFOSI_SERVER_LAUNCHEDPeer Server started
TIFOSI_SERVER_SHUTDOWNPeer Server shutdown
FES

FESSERVICE_PROVIDER_STARTED

Enterprise Server Started
SecurityCREATE_ACL_REQUESTPermission to create an ACL
SET_ACL_REQUESTPermission to change / add new values to an existing ACL
TPS_LOGIN_REQUESTPermission seeked by Peer for logging in to the Enterprise Server
APPLICATION_PREPARE_LAUNCH_REQUESTPermission to Check Resources and Connectivity of an application

APPLICATION_LAUNCH_REQUEST

Permission to launch an application
SP_LOGIN_REQUESTPermission for Client for logging in to the Enterprise Server
APPLICATION_KILL_REQUESTPermission to Stop Event Process
Adaptavist ThemeBuilder EngineAtlassian Confluence