Tibco Hawk Implemenration

White Paper on TIBCO Hawk Implementation
White Paper
On
TIBCO Hawk Implementation
Author: Wipro
Creation Date: 08 17, 2009
Version: 0.1
Status: Reviewed
Page 1 of 34
CHANGE RECORD
Date Author Version Change Reference
Aug 17,2009 Wipro 0.1 Initial version
CONTENTS
Change Record............................................................................................................................................................2
1. Purpose....................................................................................................................................................... 6
Page 2 of 34
2. Assumptions................................................................................................................................................ 6
3. Introduction................................................................................................................................................ 6
4. Product Versions.......................................................................................................................................... 8
5. Hawk Configuration..................................................................................................................................... 8
5.1 Configure Domain Hawk Agent......................................................................................................................9
5.2 Rename Default Hawk Agent.........................................................................................................................9
5.3 Monitor And Manage EMS Server From Hawk.............................................................................................10
5.4 Monitoring Event Service from Hawk...........................................................................................................11
5.5 Restart Hawk Services..................................................................................................................................11
5.6 Configure Hawk Display For EMS transport (On Windows).........................................................................12
6. Rulebases.................................................................................................................................................. 13
6.1 Pre-requisites................................................................................................................................................13
6.1.1 Folder Structure........................................................................................................................................13
6.1.2 Command Procedures...............................................................................................................................13
6.1.3 Variables Configuration File......................................................................................................................13
6.2 Rulebase: BusinessWorks Process Engine.....................................................................................................15
6.2.1 Requirements............................................................................................................................................15
6.2.2 Implementation Details............................................................................................................................15
6.2.3 Load The Rulebase....................................................................................................................................19
6.2.4 Migration Across Environments...............................................................................................................19
6.2.5 Template Rulebase....................................................................................................................................19
6.3 Rulebase: File Adapter..................................................................................................................................20
6.3.1 Requirements............................................................................................................................................20
6.4 Rulebase: ADB Adapter.................................................................................................................................22
6.4.1 Requirements............................................................................................................................................22

Page 3 of 34
6.5 Rulebase: EMS Server...................................................................................................................................24
6.5.1 Requirements............................................................................................................................................24
6.6 Rulebase: EMS Queues.................................................................................................................................25
6.6.1 Requirements............................................................................................................................................25
6.7 Rulebase: EMS Durable Topics......................................................................................................................28
6.7.1 Requirements............................................................................................................................................28
6.8 Rulebase: Client Connections to the EMS server..........................................................................................32
6.8.1 Requirements............................................................................................................................................32
6.9 Rulebase: Hawk Agent..................................................................................................................................33
6.9.1 Configuration on Machine B.....................................................................................................................33
6.9.2 Requirements............................................................................................................................................34

Page 4 of 34
6.10 General Guidelines........................................................................................................................................36
1. PURPOSE
This document talks about the configuration and the implementation details for monitoring and management
of following TIBCO components using TIBCO Hawk.
1. BusinessWorks Process Engines
2. File Adapter
3. ADB Adapter
Page 5 of 34
4. EMS server
5. EMS queues
6. EMS durable topics
7. Client connections to the EMS server
8. Hawk Agent
As the monitoring and management requirements vary from project to project, the requirements listed in this
document may not hold good for every project. However, this document can be used as a reference for
getting started on TIBCO Hawk implementation.
2. ASSUMPTIONS
The following assumptions were made in the writing of this document:
Reader must be very knowledgeable with TIBCO Hawk to understand the rulebase layouts.
Reader is knowledgeable with other TIBCO products
3. INTRODUCTION
TIBCO Hawk is a tool for monitoring and managing distributed applications and operating systems. Unlike other
monitoring solutions, TIBCO Hawk software uses TIBCO Messaging software for communication and inherits
many of its benefits. These benefits include a flexible architecture, enterprise-wide scalability, and location-
transparent product components that are simple to configure. In this particular implementation, the TIBCO
Enterprise Messaging Service (EMS) will be used for messaging.
TIBCO Hawk is an event-based system built around the concept of a distributed, autonomous smart agent that
operates on each managed machine. The software is designed specifically for monitoring distributed systems,
so there is no centralized console or frequent polling across the network. With this structure, TIBCO Hawk is
able to scale and has the flexibility to allow individual managed entities to be added or modified without the
need to re-configure or re-start any other parts of the system.
The work required to monitor applications is performed by TIBCO Hawk agents.
TIBCO Hawk Agent runs on each node in the TIBCO domain and monitors local conditions. Each agent uses
collections of locally loaded rules organized into rulebases to apply monitoring logic. A rulebase tells an agent
how to monitor particular application or system resources and what actions to take when specific conditions
are detected.
The TIBCO Hawk Display application subscribes to alert messages generated by TIBCO Hawk rulebases and
presents them in an organized view. Alerts are color-coded to indicate the severity of a reported problem.
Clicking on a node displays the error message along with a recent history of problems on the node. TIBCO
Hawk Display does not store centralized monitoring intelligence; it simply offers a view of events from the
Page 6 of 34
monitored systems. Adding more instances of the Display application requires no additional network overhead
or configuration.
The TIBCO Administrator also subscribes to the alert messages, and will display the alerts under the individual
machines in the TIBCO domain.
FIGURE 1 HAWK ARCHITECTURE DIAGRAM
4. PRODUCT VERSIONS
Given below are the TIBCO products and their versions used in this particular implementation. The TIBCO suite
is installed on HP-UX B.11.23 ia64 operating system.
TIBCO BusinessWorks 5.4.2
TIBCO EMS Server 4.4.3
TIBCO File Adapter 5.5.0
TIBCO ADB Adapter 5.4.0
TIBCO Runtime Agent 5.5.3
Page 7 of 34
TIBCO Hawk 4.7.0
5. HAWK CONFIGURATION
This section talks about the configuration steps.
In general, there will be 2 Hawk agent services, one comes with TIBCO Admin domain and another one comes
with standalone Hawk installation. In this particular implementation, domain Hawk agent is used for all
monitoring purposes.
TIBCO Hawk Agent is an autonomous process that monitors applications and systems activity. Each
administration server has a corresponding TIBCO Hawk Agent. The Hawk Agent monitors activity by processing
rulebases, which hold the logic that determines how monitoring and management will take place.
A Hawk Agent runs on the machine that hosts the administration server and on each machine that is part of
the administration domain.
In this implementation, EMS server is used as the messaging transport for communication across Hawk Agent,
Hawk Display and Hawk Event services. The advantage in using EMS transport is that Hawk Display from any
subnet can be used to monitor the agents, alerts and rulebases as long as Hawk Display is connected to the
right EMS server.
EMS servers can be configured to route messages between networks where rvrd is not setup to do so. In order
to do this both networks must have an EMS server running. Messages from one network are routed to the
other via the EMS server instead of the rvrd
The only disadvantage is that EMS server will be single point of failure unlike Rendezvous daemon.
5.1 CONFIGURE DOMAIN HAWK AGENT

In this step, Domain Hawk agent is configured to use EMS server as its transport and also to communicate with
Hawk event service.
a) Open the <tibco_root>/tra/domain/<domain_name>/hawkagent.cfg file in a text editor
b) Under ems_transport property, specify the EMS server connection details as, shown below.
-ems_transport tcp://<EMS server host>:port <user id> #!encrypted password
c) In order to communicate with Hawk event service, add the ami_rvd_session that matches with that of
Hawk event services ami_rvd_session. (Steps to configure the Hawk event service with the same
parameters is mentioned in a later section)
For example, -ami_rvd_session 8500 127.0.0.1 tcp:8500
Page 8 of 34
d) Save the changes.
Note: The encrypted password can be generated by running the Hawk utility program tibhawkpassword
located in your hawk/bin directory:
tibhawkpassword -encrypt password
where password is the current password
5.2 RENAME DEFAULT HAWK AGENT

In this step, Hawk agent that comes with standalone installation is renamed so that the two Hawk agents (one
that comes with standalone Hawk installation and another one that comes with TIBCO Admin domain) can be
distinguished in the Hawk Display.
a) Open the <tibco_root>/hawk/bin/hawkagent.cfg file in a text editor
b) Change the agent name as mentioned below.
-agent_name <machine-name>_default
c) Under the ems_transport, specify the EMS server connection details
5.3 MONITOR AND MANAGE EMS SERVER FROM HAWK

To use TIBCO Hawk to manage the TIBCO Enterprise Message Service server, load the HawkController or
HawkListenerclasses provided into the TIBCO Hawk agent. Once the classes are loaded, methods for
managing the EMS server are available in the TIBCO Hawk display. In this implementation, the
HawkController classes have been loaded.
Installing the classes is different for UNIX and Windows platforms. Given below are the steps for installing the
classes in UNIX. Please refer to Hawk documentation for the procedure on Windows.
a) Locate the tibjmsadmin.hma file in the TIBCO EMS installation directory under the
<tibco_root>/ems/samples/admin/hawk subdirectory and copy it to TIBCO TRA Hawk plugins
directory.
Usually, TIBCO TRA Hawk plugins directory is located in <tibco_root>/tra/domain/<domain_name>

/plugin
Page 9 of 34
b) Locate tibjmsadmin.jar in the ems/clients/java subdirectory, and copy it into the TIBCO TRA Hawk
plugins directory.
c) Open the <tibco_root>/tra/domain/<domain_name>/hawkagent.cfg file in a text editor and specify

the -hma_plugin_dir option to include the directory where your TIBCO Hawk plugins are located.
-hma_plugin_dir "<tibco_root>/tra/domain/ <domain_name>/plugin"
Save changes to hawkagent.cfg
d) Navigate to plugins directory and open the tibjmsadmin.hma file in a text editor
e) Specify the TIBCO Hawk microagent class you wish to use in the <classname> element. In this
implementation, com.tibco.tibjms.admin.hawk.HawkController has been used.
f) Specify the username and password and server URL to use to connect to the TIBCO EMS server in the
appropriate <arg> elements For example:
<arguments>
<arg>-user</arg>
<arg>admin</arg>
<arg>-password</arg>
<arg>MyPassword</arg>
<arg>-server</arg>
<arg>tcp://<EMSServerHost>:<port></arg>
<arg>-timeout</arg>
<arg>5</arg>
</arguments>
You should use specify the predefined admin user or a user that is a member of the $admin group.
Save changes to tibjmsadmin.hma.
Note: To use an encrypted password, specify encryptedPassword instead of -password. As the value
for -encryptedPassword, supply the output you obtain by running the Hawk utility program
tibhawkpassword located in your hawk/bin directory:
tibhawkpassword -encrypt password
where password is the current password
5.4 MONITORING EVENT SERVICE FROM HAWK

The TIBCO Hawk Event Service is a process that records TIBCO Hawk alerts and changes in agent status. When
communication with an agent is lost, the Event Service can invoke a user-provided script. Alerts and
notifications can be recorded to log files or a database.
Typically, the TIBCO Hawk Event Service is installed on a minimal number of computers in the network.
Page 10 of 34
In this step, Hawk event service is configured to use EMS server as its transport and also to communicate with
Hawk agent service.
a) Open the <tibco_root>/hawk/bin/hawkevent.cfg file in a text editor
b) Under the ems_transport, specify the EMS server connection details.
c) Also specify the TIBCO Rendezvous session used by the TIBCO Hawk event service for AMI
communications.
For example,
-ami_rvd_session 8500 127.0.0.1 tcp:8500
5.5 RESTART HAWK SERVICES

Save all the above changes and restart the following services so that the changes will be effective.
a) Hawk agent service that comes with standalone installation
b) Domain Hawk agent service
c) Hawk event service
5.6 CONFIGURE HAWK DISPLAY FOR EMS TRANSPORT (ON WINDOWS)

In this particular implementation, Hawk Display running on Windows is configured to use EMS transport.
Open the Hawk Configuration window from menu and configure the following.
a) Ensure that Hawk Domain name matches with that of domain name mentioned in the Domain Hawk
agents hawkagent.cfg
Page 11 of 34
b) In the Transport tab, select the Primary Transport as EMS and provide the EMS server connection
details. This should be the same EMS server that was configured in Step 5.1
c) Click Ok
d) Click No on the dialogs that ask for restarting the Hawk related services.
Now open the Hawk Display from menu to verify that all the changes are done successfully.
6. RULEBASES
6.1 PRE-REQUISITES
The many new Hawk rulebases, command procedures, etc. need to be separate from the core TIBCO and Hawk
products. This will allow TIBCO Hawk to be upgraded independently from the custom components and vice-
versa. Given below are the pre-requisites for the rulebases.
6.1.1 FOLDER STRUCTURE

Create the following folder structure under TIBCO domain root (i.e. <tibco_root>/tra/domain/
<domain_name>)
----Accelerator
-flags (Location of .enabled and .running files)
-scripts (Location of custom command procedures)
6.1.2 COMMAND PROCEDURES

Page 12 of 34
The BW and ADB Adapter rulebases use Command Procedures to perform some actions. To track the status of
BW process engine or ADB adapter .enabled and .running files will be created and deleted in the flags folder,
using these Command Procedures.
UNIX shell script files namely CreateEmptyFile.sh and RemoveFile.sh will be used for creating and deleting the
appropriate files. If running on Windows the equivalent batch scripts need to be prepared. At any point of
time, Hawk rulebase will identify the status of BW process engine or ADB adapter based on the availability of
one or both of these files and takes the necessary action.
CreateEmptyFile.sh RemoveFile.sh
Copy the CreateEmptyFile.sh and RemoveFile.sh scripts to tibco_root>/tra / domain/ <domain_name>

/Accelerator/scripts folder.
After copying the files, change the permissions of CreateEmptyFile.sh and RemoveFile.sh to 777 so that these
can be invoked from the rulebases.
6.1.3 VARIABLES CONFIGURATION FILE

TIBCO Hawk has the capability to use external variables within the Hawk rulebases. There are some fields that
will be used in all rulebases. Some of the fields will be common, others will not. These include certain directory
locations, log file locations, and several e-mail related values.
The <tibco_root>/tra/domain/<domain_name>/Accelerator/scripts/HawkAC_variables.dat will hold all of the

variables. All of the values will be configured for each machine/environment in this file. Every agent can read
only one configuration file.
Standard Variables to include:
MAIL_SERVER: This is the mail server used for sending emails.

MAIL_FROM: The email address defined in this variable will be used as from address on any email
sent from Hawk
MAIL_CC: Any email recipient defined in this variable will be CCed on any Hawk alert sent.
MAIL_SUBJECT: The prefix used in the subject of email is defined in this variable.
MAIL_TO: Any email recipient defined in this variable will be emailed on any email sent from Hawk.
DOMAIN_NAME: This should be set to the name of the TIBCO Administration domain
CONFIG_ROOT: This is the location of all of the scripts and config files for Hawk. The variables file
should already be set to the correct value.
FLAG_ROOT: This is the location of the Hawk enable flags. The variables file should already be set to
the correct value.
TRA_ROOT: This is the root location of the TIBCO domain. The variables file should already be set to
the correct value.
Page 13 of 34
Note: Apart from above variables, rulebase specific variables also can be added. Please keep in mind that
if any changes are done in the HawkAC_variables.dat, Domain Hawk agent service need to be restarted to
make the changes effective. The recommendation would be to add the variables for all rulebases at once,
to avoid restarting the Hawk agent service for several times.
The HawkAC_variable.dat file need to be placed in the <tibco_root>/ tra/domain/ <domain_name>/

Accelerator/scripts directory
HawkAC_variable.da
t
The TRA hawkagent.cfg configuration file must be modified to include the variables file. The variables line
must be uncommented, and the name and location of the variables file appended to the parameter.
-variables <tibco_root>/tra/domain/<domain_name>/Accelerator/scripts/HawkAC_variable.dat
Save the changes.
Restart Domain Hawk agent service.
6.2 RULEBASE : BUSINESS WORKS PROCESS ENGINE

This section will discuss on the Hawk Rulebase to monitor and manage the TIBCO BusinessWorks Process
engines.
The naming convention followed for this kind of rulebase is BWEngine-Deployment-Component.hrb. Here
Deployment is the Enterprise Archive name and Component is the process archive name in the BW project.
6.2.1 REQUIREMENTS
If the engine is started or stopped from the TIBCO Administrator, then Hawk rulebase should not start
the engine. If the engine is stopped abruptly due to some reason, then the rulebase should attempt to
start the engine for once.
At each step, appropriate alerts and/or emails should be sent from the rulebase.
6.2.2 IMPLEMENTATION DETAILS

Given below are the implementation details for CISCommon BW process engine. The rulebase name is
"BWEngine-CISCommon-CISCommonProcesses.hrb"
BWEngine-CISComm
on-CISCommonProcesses.hrb
Given below is the sequence diagram which describes the high level implementation of this rulebase.
Page 14 of 34
FIGURE 2 BW PROCESS ENGINE RULEBASE FLOW
The rules include:

Page 15 of 34
Check for the .running file: This rule will test to see the CISCommon-CISCommonProcesses.running
file exists in flags directory. If the file exists, then the no_error post condition is set. If the file does
not exist, then the error post condition is set. The rule will check for the .running file every 2
seconds. This post condition is used later in the rulebase to help Hawk determine if the BW Process
Engine has successfully started previously.
Check for the .enabled file: This rule will test to see the CISCommon-CISCommonProcesses.enabled
file exists in flags directory. If the file exists, then the enabled post condition is set. If the file does
not exist, then the disabled post condition is set. The rule will check for the .enabled file every 5
seconds. This post condition is used later in the rulebase to decide whether the rulebase need to take
some action or not
This rule checks to see if the BW Process Engine is running, also using the TRA.getComponentStatus
Hawk microagent. This test is performed every six seconds. This rule has several steps depending on if
the service is running. The rule will:
Page 16 of 34
o Check to see if the BW Process Engine has a state of INITIALIZING. If it does, the BW Process
Engine is being started via the TIBCO Administrator. The rule will run the
CreateEmptyFile.sh script with appropriate parameters such that CISCommon-
CISCommonProcesses.enabled file is created and there by enabled post condition is set.
o Check to see if the BW Process Engine has a state of RUNNING. If it does, the BW Process
Engine has successfully started. The rule will send an informational notification and email
that it is running, and run the CreateEmptyFile.sh script with appropriate parameters such
that CISCommon-CISCommonProcesses.running file is created and there by no_error
post condition is set.
o Check to see if the BW Process Engine has a state of STOPPING and enabled post condition
exists. This signifies that BW Process Engine is being stopped via TIBCO Administrator. The
rule will run the RemoveFile.sh script with appropriate parameters to remove the
CISCommon-CISCommonProcesses.enabled file to ensure that disabled post condition is
set. This will prevent Hawk from attempting to restart the BW Process Engine.
o Check to see if the BW Process Engine has a state of STOPPED. This signifies that BW Process
Engine is no longer running. It could be stopped via TIBCO Administrator or due to some
error. The rule will run the RemoveFile.sh script with appropriate parameters to remove
the CISCommon-CISCommonProcesses.running file to ensure that error post condition is
set.
o Check to see if the BW Process Engine has a state of STOPPED and enabled post condition
is set. This signifies that BW Process Engine got terminated abruptly due to some error. The
rule will send a low alert stating the BW Process Engine is not running, and will attempt to
start the engine. The rule will also run RemoveFile.sh script with appropriate parameters to
remove the CISCommon-CISCommonProcesses.running file to ensure that error post
condition is set. After 90 seconds, if the BW process is not started, a high alert will be sent
stating that the BW Process Engine is still down. The BW Process Engine will be disabled to
Page 17 of 34
prevent the rule from attempting to start it again. The rule will also run the RemoveFile.sh
script with appropriate parameters to remove the CISCommon-
CISCommonProcesses.enabled file to ensure that disabled post condition is set,
preventing Hawk from attempting to restart the BW Process Engine.
o Check to see if the BW Process Engine has a state of STOPPED and disabled post condition
is set. The rule will send a low alert that the Hawk rulebase will not attempt to start the BW
Process Engine.
6.2.3 LOAD THE RULEBASE

Before sending the rulebase (from the rulebase editor) to the selected machine, please keep in mind the
following items.
This rulebase need to be applied only after verifying that a BW Process Engine has been started
successfully once in TIBCO Administrator.
Apply the rulebase only when the BW process engine is down. After applying the rulebase start the
BW Process Engine from TIBCO Administrator.
Before redeploying a new Enterprise Archive for a BW process engine that is being monitored by this
rulebase, please STOP the BW Process engine manually in TIBCO Administrator and ensure that it is
not running. If the BW process engine is not stopped before redeployment, the engine will get killed
and the rulebase will try to start the engine again.
6.2.4 MIGRATION ACROSS ENVIRONMENTS

Since this rulebase depends on the variables defined in HawkAC_variables.dat, please ensure that
the values for these variables are correctly defined as per the respective environment configuration.
Same rulebase can be moved from one environment to another environment without any changes.
6.2.5 TEMPLATE RULEBASE

Given below is the template rulebase that has been implemented with the requirements mentioned in section
6.2.1
BWEngine-Deployme
ntName-ComponentInstanceName.hrb
Following changes have to be done, prior to using this rulebase for a BW Process Engine.
DeploymentName need to be replaced with the EAR name defined in the BW Project
ComponentInstanceName need to be replaced with Process Archive name defined under the EAR.
AuthorName need to be replaced with the author of the rulebase
Page 18 of 34
HostName(IPAddress) need to be replaced with a corresponding value
DateTime need to be replaced with the current date time
BWEngineDesc needs to be replaced with appropriate description of the BW Process Engine.
Finally, the rulebase file name need to be changed with actual values of DeploymentName and
ComponentInstanceName
6.3 RULEBASE : FILE ADAPTER

This section will discuss on the Hawk Rulebase to monitor and manage the TIBCO File Adapter.
The naming convention followed for this kind of rulebase is FileAdapter-Deployment-Component.hrb. Here
Deployment is the Enterprise Archive name and Component is the File Adapter archive name in the BW project.
6.3.1 REQUIREMENTS
If the File Adapter is started or stopped from the TIBCO Administrator, then the Hawk rulebase should
send alerts and email notifications. If the File adapter is stopped abruptly due to some reason, then
also the rulebase should send alerts and emails.

Given below are the implementation details for a Payment File Adapter. The rulebase name is "FileAdapter-
Finance-FinancePaymentFileAdapter.hrb"
FileAdapter-Finance-
FinancePaymentFileAdapter.hrb
The rule will:
Page 19 of 34
Check for the existence of the Payment File Adapter microagent. If the number of microagents
becomes zero, sends a high alert along with an email mentioning that Payment File Adapter is down.
If the number of the microagents becomes one, a notification and email will be sent saying that
Payment File Adapter is up and running. The rule will check the microagent count for every 5 seconds.

This rulebase can be sent to the machine at any point of time. Based on the current state of the File Adapter,
an alert and email will be sent.


6.3.1
Page 20 of 34
FileAdapter-Deploym
entName-ComponentInstanceName.hrb
Following changes have to be done, prior to using this rulebase for a File Adapter.
ComponentInstanceName need to be replaced with File Adapter Archive name defined under the
EAR.
FileAdpaterMicroagentName property needs to be defined with appropriate value in the

HawkAC_variables.dat file. In general as there will be more than one file adapter in the properties
file, it is recommended to add a prefix to this property name.
FileAdapterDesc needs to be replaced with appropriate description of the file adapter.
6.4 RULEBASE : ADB ADAPTER

This section will discuss on the Hawk Rulebase to monitor and manage the TIBCO ADB Adapter.
The naming convention followed for this kind of rulebase is ADBAdapter-Deployment-Component.hrb. Here
Deployment is the Enterprise Archive name and Component is the ADB Adapter archive name in the BW
project.
6.4.1 REQUIREMENTS
If the ADB Adapter is started or stopped from the TIBCO Administrator, then Hawk rulebase should
not start the adapter. If the ADB Adapter is stopped abruptly due to some reason, then the rulebase
should attempt to start the adapter for once.
At each step, appropriate alerts and/or emails should be sent from the rulebase.

The implementation details for a LIMS ADB Adapter are similar to that of BW Process Engine defined in section
6.2.2. The rulebase name is "ADBAdapter-WaterQuality-LIMS.hrb"
Page 21 of 34
ADBAdapter-WaterQ
uality-LIMS.hrb

Loading rules are same as that of BW Process Engine defined in section 6.2.3

Migration rules are same as that of BW Process Engine defined in section 6.2.4

6.4.1
ADBAdapter-Deploy
mentName-ComponentInstanceName.hrb
Following changes have to be done, prior to using this rulebase for an ADB adapter.
ComponentInstanceName need to be replaced with ADB Adapter Archive name defined under the
EAR.
ADBAdapterDesc needs to be replaced with appropriate description of the ADB adapter.
6.5 RULEBASE : EMS SERVER

This section will discuss on the Hawk Rulebase to monitor and manage the TIBCO EMS server.
The naming convention followed for this rulebase is EMSServer-Status.hrb.

Page 22 of 34
6.5.1 REQUIREMENTS
If the EMS server is not running, rulebase should send an alert and email and try starting the EMS
server. If the EMS server could not be started successfully then an appropriate alert and email should
be sent.
If the EMS server is up and running, a notification and email should be sent.

Given below are the implementation details for an EMS server. The rulebase name is "EMSServer-Status.hrb"
EMSServer-Status.hr
b
For every 10 seconds, the rule will check whether the EMS server is running or not.
If the EMS server is not running, a low alert and email will be sent and rulebase will attempt to start the EMS
server. If the EMS server is brought back successfully then notification and email will be sent. If the EMS server
could not be brought back, an alert and email will be sent.

This rulebase can be sent to the machine at any point of time. Based on the current state of the EMS server,
alert and email will be sent. In case the EMS server is not running, rulebase will attempt to start it.

6.6 RULEBASE : EMS QUEUES

This section will discuss on the Hawk Rulebase to monitor and manage the TIBCO EMS queues.
The naming convention followed for this rulebase is EMSQueueTopic-Deployment.hrb. Here Deployment is
the Enterprise Archive name.
6.6.1 REQUIREMENTS
Page 23 of 34
For a queue, if the pending message count exceeds the limit (even though the corresponding BW
Process Engine is up and running) an alert and email should be sent. Here the limit is defined based
on the message load and the monitoring interval.
At any point of time, if the pending message count exceeded the limit an alert and email should be
sent. This check need to be repeated for every subsequent one hour and up to 12 hrs.

Given below are the implementation details for an EMS queue in Contact project. The rulebase name is
"EMSQueueTopic-Contact.hrb"
EMSQueueTopic-Con
tact.hrb
The rule will:
Check for the .enabled file: This rule will test to see the Contact-ContactProcess.enabled file exists
in flags directory. If the file exists, then the enabled post condition is set. If the file does not exist,
then the not_enabled post condition is set. The rule will check for the .enabled file every 5 seconds.
This post condition is used later in the rulebase to decide whether the rulebase need to take some
action or not.
Page 24 of 34
Check for the .running file: This rule will test to see the Contact-ContactProcess.running file exists in
flags directory. If the file exists, then running post condition is set. If the file does not exist, then
the not_running post condition is set. The rule will check for the .running file every 4 seconds. This
post condition is used later in the rulebase.
Get the pending message count: This rule gets the queue properties for every 60 seconds. It verifies
whether the pending message count is greater than 1 and BW Process Engine is running (both
enabled and running post conditions exist). If this condition is satisfied then an alert and email will be
sent stating that there are n pending messages in the queue. Once the condition is satisfied then for
every subsequent one hour (and up to 12 hrs) this check will be performed and if the condition exists
at that instance of time an alert and email will be sent.

This rulebase can be sent to the machine at any point of time. It will check the current state of the queue, and
accordingly an alert and email will be sent.

Since this rulebase depends on the variables defined in HawkAC_variables.dat, please ensure that the
values for these variables are correctly defined as per the respective environment configuration.

6.6.1
EMSQueueTopic-Depl
oymentName(Q).hrb
Following changes have to be done, prior to using this rulebase for monitoring an EMS queue.
DeploymentName need to be replaced with the EAR name defined in the corresponding BW Project
QueueName property needs to be defined with appropriate value of queue name in the
HawkAC_variables.dat file. In general as there will be more than one queue in the properties file, it
is recommended to add a prefix to this property name.
Page 25 of 34
ProcessName property needs to be defined with appropriate value of BW process name in the
HawkAC_variables.dat file. In general as there will be more than one process name in the properties
ProjectName property needs to be defined with appropriate value of BW project name in the
HawkAC_variables.dat file. In general as there will be more than one project name in the properties
MaxPendingMessages is the maximum number of messages in the queue and if the messages exceed
this limit an alert and email will be sent. This needs to be replaced with appropriate number based on
the requirement.
Finally, the rulebase file name need to be changed with actual value of DeploymentName
6.7 RULEBASE : EMS DURABLE TOPICS

This section will discuss on the Hawk Rulebase to monitor and manage the TIBCO EMS durable topics.
The naming convention followed for this rulebase is EMSQueueTopic-Deployment.hrb. Here Deployment is
the Enterprise Archive name.
6.7.1 REQUIREMENTS
For a durable topic, if the pending message count exceeds the limit (even though the corresponding
BW Process Engine is up and running) an alert and email should be sent. Here the limit is defined
based on the message load and the monitoring interval.
At any point of time, if the pending message count exceeded the limit an alert and email should be
sent. This check need to be repeated for every subsequent one hour and up to 12 hrs.
Also if the durable count for this topic does not match with the expected durable count, an alert and
email should be sent. This check need to be repeated for every subsequent one hour and up to 12 hrs.

Given below are the implementation details for an EMS durable topic in WAA project. The rulebase name is
"EMSQueueTopic-WAA.hrb"
EMSQueueTopic-WA
A.hrb
The rule will:
Page 26 of 34
Check for the .enabled file: This rule will test to see the WAA-WAA.enabled file exists in flags
directory. If the file exists, then the enabled post condition is set. If the file does not exist, then the
not_enabled post condition is set. The rule will check for the .enabled file every 5 seconds. This post
condition is used later in the rulebase to decide whether the rulebase need to take some action or
not.
Check for the .running file: This rule will test to see the WAA-WAA.running file exists in flags
directory. If the file exists, then running post condition is set. If the file does not exist, then the
not_running post condition is set. The rule will check for the .running file every 4 seconds. This post
condition is used later in the rulebase.
This rule checks for the pending message count and the durable count for this topic. This test is
performed every 30 seconds. The rule will:
Page 27 of 34
o Get the durable count: This test verifies whether the durable count is equal to 2 or not. If the
durable count is not equal to 2, an alert and email will be sent. Once the condition is satisfied
then for every subsequent one hour (and up to 12 hrs) this check will be performed and if
the condition exists at that instance of time an alert and email will be sent.
o Get the pending message count: This test verifies whether the pending message count is
greater than 5 and the BW Process Engine is running (both enabled and running post
conditions exist). If this condition is satisfied then an alert and email will be sent stating that
there are n pending messages in the queue. Once the condition is satisfied then for every
subsequent one hour (and up to 12 hrs) this check will be performed and if the condition
exists at that instance of time an alert and email will be sent.

This rulebase can be sent to the machine at any point of time. It will check the current state of the topic, and

Since this rulebase depends on the variables defined in HawkAC_variables.dat, please ensure that the
values for these variables are correctly defined as per the respective environment configuration.
Page 28 of 34

6.7.1
EMSQueueTopic-Depl
oymentName(T).hrb
Following changes have to be done, prior to using this rulebase for monitoring an EMS durable topic.
DeploymentName need to be replaced with the EAR name defined in the corresponding BW Project
TopicName property needs to be defined with appropriate value of topic name in the
HawkAC_variables.dat file. In general as there will be more than one queue in the properties file, it
is recommended to add a prefix to this property name.
ProcessName property needs to be defined with appropriate value of BW process name in the
HawkAC_variables.dat file. In general as there will be more than one process name in the properties
ProjectName property needs to be defined with appropriate value of BW project name in the
HawkAC_variables.dat file. In general as there will be more than one project name in the properties
DurSubCount is the durable subscriber count for this topic. If the durable count doesnt match with
this number then an alert and email will be sent. This needs to be replaced with appropriate number
based on the requirement.
MaxPendingMessages is the maximum number of messages in the queue and if the messages exceed
this limit an alert and email will be sent. This needs to be replaced with appropriate number based on
the requirement.
Finally, the rulebase file name need to be changed with actual DeploymentName
6.8 RULEBASE : CLIENT CONNECTIONS TO THE EMS SERVER

Page 29 of 34
This section will discuss on the Hawk Rulebase to monitor the unauthorized client connections established to
TIBCO EMS server.
The naming convention followed for this rulebase is EMSServer-UnauthorizedConnections.hrb.
6.8.1 REQUIREMENTS
This rulebase should monitor the connections established to the EMS server and if a connection has
been established from a unknown machine (that is not part of the allowable machines), an alert and
email should be sent.
The list of allowable machines should be prepared in advance as this list should be included in the
rulebase.
Note: This rulebase will not prevent the connection from an unauthorized machine to the EMS server,
but will generate alert and email when such connection is established.

Given below are the implementation details for monitoring the unauthorized client connections to EMS server.
The rulebase name is "EMSServer-UnauthorizedConnections.hrb"
EMSServer-Unauthor
izedConnections.hrb
The rule will get the list of EMS server connections for every 60 seconds and verifies the host name of the
machines that are connected. If there is at least one machine that is not in the list of allowable machines, then
an alert and email will be sent.

This rulebase can be sent to the machine at any point of time. It will check the existing EMS server
connections, and accordingly an alert and email will be sent.

Since the allowable machine names vary from one environment to another, rulebase need to be
modified before deploying on each environment.

6.8.1
Page 30 of 34
EMSServer-Unauthor
izedConnections.hrb
Following changes have to be done, prior to using this rulebase for monitoring unauthorized connections to
EMS server.
machine1 to machine9 need to be replaced with actual machine names. Based on the requirement,
the number of machines has to be changed in the rulebase.
6.9 RULEBASE : HAWK AGENT

If the Hawk agent service goes down, none of the rulebases will be active and the monitoring functionality will
cease. So it is essential to know the status of the Hawk agent service. This section will discuss on the Hawk
Rulebase to monitor the TIBCO Hawk agent service.
The naming convention followed for this rulebase is MonitorHawkAgent.hrb.
Hawk agent running on machine A (having hawk domain as domainA) will be monitored from a rulebase that
is deployed on machine B (with hawk domain as domainB).
6.9.1 CONFIGURATION ON MACHINE B

1. In order to communicate with the Hawk agent running on machine A, there is some configuration required
to the hawkevent.cfg on machine B (hawkevent.cfg on machine B needs to be configured with the EMS
of machine A.)
a) On machine B, open the <tibco_root>/hawk/bin/hawkevent.cfg file in a text editor
b) Under the ems_transport, specify the EMS server connection details.
Here the EMS server details are same as that of mentioned in section 5.4.
c) Save the changes.
d) Restart the Hawk Event service on machine B.
Page 31 of 34
2. Configure the hawkagent.cfg (of the domain Hawk agent) on machine B to point to EMS server running
on machine B.
a) Open the <tibco_root>/tra/domain/<domain_name>/hawkagent.cfg file in a text editor
b) Under ems_transport property, specify the EMS server connection details as, shown below.
Here machine Bs EMS server details need to be provided.
c) Save the changes
d) Restart the Hawk Agent service on machine B.
3. On a Windows machine, open the Hawk Configuration display from menu and configure the following to
connect to the Hawk agent running on machine B.
a) Ensure that Hawk Domain name matches with that of domain name mentioned in the Domain Hawk
agents hawkagent.cfg of machine B.
b) In the Transport tab, select the Primary Transport as EMS and provide the machine Bs EMS server
connection details.
c) Click Ok
d) Click No on the dialogs that ask for restarting the Hawk related services.
Now open the Hawk Display from the menu and you should see the machine Bs domain Hawk agent.
6.9.2 REQUIREMENTS
If the Hawk agent running on machine A is expired or up and running, then the rulebase running on
machine B should send an alert/notification and email.

Given below are the implementation details for monitoring the Hawk agent. The rulebase name is
MonitorHawkAgent.hrb
MonitorHawkAgent.h
rb
The rule will be triggered whenever the communication with the Hawk agent running on machine A goes down
or is established. In either case an alert/notification and email will be sent.
Page 32 of 34
The lost communication with the Hawk agent running on machine A could be due to any of the reasons like
machine A itself is down, network issues, EMS server is down or agent itself is down. So once the alert/email
has been generated, analysis needs to be done to find the root cause.

This rulebase can be sent to the machine at any point of time. It will check the status of Hawk agent, and

Since the machine name and Hawk domain name changes from one environment to another, rulebase
need to be modified before deploying on each environment.

6.9.1
MonitorHawkAgent.h
rb
Following changes have to be done, prior to using this rulebase for monitoring the Hawk agent service.
HawkDomainName need to be replaced with the domain name of monitored Hawk agent.
AgentBeginsWith need to be replaced with the beginning part of the monitored Hawk agent.
tibcosupport@abc.org and postmaster3.abc.org need to be replaced with the right email address and
SMTP server.
6.10 GENERAL GUIDELINES

1. Since the rulebases will not be undeployed automatically while undeploynig a TIBCO component, the
rulebases that are no longer required have to be undeployed manually.
2. If there is any issue with the rulebase, please check the availability of .enabled and .running files (where
applicable) and accordingly create or delete these files manually to fix the problem temporarily. Rulebase
need to be modified for permanent fix.
Page 33 of 34
Page 34 of 34

Tibco Hawk Implemenration

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tibco Hawk Implemenration

Uploaded by

Copyright:

Available Formats

White Paper on TIBCO Hawk Implementation

TIBCO Hawk Implementation

Aug 17,2009 Wipro 0.1 Initial version

5.1 Configure Domain Hawk Agent......................................................................................................................9

5.2 Rename Default Hawk Agent.........................................................................................................................9

5.3 Monitor And Manage EMS Server From Hawk.............................................................................................10

5.4 Monitoring Event Service from Hawk...........................................................................................................11

5.5 Restart Hawk Services..................................................................................................................................11

5.6 Configure Hawk Display For EMS transport (On Windows).........................................................................12

6.1.1 Folder Structure........................................................................................................................................13

6.1.2 Command Procedures...............................................................................................................................13

6.1.3 Variables Configuration File......................................................................................................................13

6.2 Rulebase: BusinessWorks Process Engine.....................................................................................................15

6.2.2 Implementation Details............................................................................................................................15

6.2.3 Load The Rulebase....................................................................................................................................19

6.2.4 Migration Across Environments...............................................................................................................19

6.2.5 Template Rulebase....................................................................................................................................19

6.3 Rulebase: File Adapter..................................................................................................................................20

6.3.2 Implementation Details............................................................................................................................20

6.3.3 Load The Rulebase....................................................................................................................................21

6.3.4 Migration Across Environments...............................................................................................................21

6.3.5 Template Rulebase....................................................................................................................................21

6.4 Rulebase: ADB Adapter.................................................................................................................................22

6.4.2 Implementation Details............................................................................................................................22

6.4.3 Load The Rulebase....................................................................................................................................23

6.4.4 Migration Across Environments...............................................................................................................23

6.4.5 Template Rulebase....................................................................................................................................23

6.5 Rulebase: EMS Server...................................................................................................................................24

6.5.2 Implementation Details............................................................................................................................24

6.5.3 Load The Rulebase....................................................................................................................................24

6.5.4 Migration Across Environments...............................................................................................................24

6.6 Rulebase: EMS Queues.................................................................................................................................25

6.6.2 Implementation Details............................................................................................................................25

6.6.3 Load The Rulebase....................................................................................................................................26

6.6.4 Migration Across Environments...............................................................................................................27

6.6.5 Template Rulebase....................................................................................................................................27

6.7 Rulebase: EMS Durable Topics......................................................................................................................28

6.7.2 Implementation Details............................................................................................................................28

6.7.3 Load The Rulebase....................................................................................................................................30

6.7.4 Migration Across Environments...............................................................................................................30

6.7.5 Template Rulebase....................................................................................................................................31

6.8 Rulebase: Client Connections to the EMS server..........................................................................................32

6.8.2 Implementation Details............................................................................................................................32

6.8.3 Load The Rulebase....................................................................................................................................32

6.8.4 Migration Across Environments...............................................................................................................32

6.8.5 Template Rulebase....................................................................................................................................33

6.9 Rulebase: Hawk Agent..................................................................................................................................33

6.9.1 Configuration on Machine B.....................................................................................................................33

6.9.3 Implementation Details............................................................................................................................34

6.9.4 Load The Rulebase....................................................................................................................................35

6.9.5 Migration Across Environments...............................................................................................................35

6.9.6 Template Rulebase....................................................................................................................................35

6.10 General Guidelines........................................................................................................................................36

1. BusinessWorks Process Engines

6. EMS durable topics

7. Client connections to the EMS server

Reader is knowledgeable with other TIBCO products

The work required to monitor applications is performed by TIBCO Hawk agents.

FIGURE 1 HAWK ARCHITECTURE DIAGRAM

TIBCO BusinessWorks 5.4.2

TIBCO EMS Server 4.4.3

TIBCO File Adapter 5.5.0

TIBCO ADB Adapter 5.4.0