Tibco Hawk Implemenration

White Paper on TIBCO Hawk Implementation
White Paper On TIBCO Hawk Implementation

Author: Creation Date: Version: Status: Wipro 08 17, 2009 0.1 Reviewed
Page
1 of 36
CHANGE RECORD
Date Aug 17,2009 Author Wipro Version 0.1 Change Reference Initial version
Page
2 of 36
CONTENTS
Change Record ..................................................................................................................2 1.Purpose..........................................................................................................5 2.Assumptions...................................................................................................6 3.Introduction....................................................................................................6 4.Product Versions.............................................................................................7 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......................................................................................14 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.3.2 Implementation Details.............................................................................................20 6.3.3 Load The Rulebase....................................................................................................21 6.3.4 Migration Across Environments.................................................................................21 6.3.5 Template Rulebase...................................................................................................22 Page
3 of 36
6.4 Rulebase: ADB Adapter ...............................................................................................22 6.4.1 Requirements...........................................................................................................22 6.4.2 Implementation Details.............................................................................................23 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.1 Requirements...........................................................................................................24 6.5.2 Implementation Details.............................................................................................24 6.5.3 Load The Rulebase....................................................................................................24 6.5.4 Migration Across Environments.................................................................................25 6.6 Rulebase: EMS Queues................................................................................................25 6.6.1 Requirements...........................................................................................................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.1 Requirements...........................................................................................................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.1 Requirements...........................................................................................................32 6.8.2 Implementation Details.............................................................................................32 6.8.3 Load The Rulebase....................................................................................................32 6.8.4 Migration Across Environments.................................................................................33 6.8.5 Template Rulebase...................................................................................................33 6.9 Rulebase: Hawk Agent ................................................................................................33 6.9.1 Configuration on Machine B......................................................................................34 6.9.2 Requirements...........................................................................................................35 Page
4 of 36
6.9.3 Implementation Details.............................................................................................35 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. PURPOSE
This document talks about the configuration and the implementation details for monitoring and management of following TIBCO components using TIBCO Hawk. Page
5 of 36
1. BusinessWorks Process Engines 2. File Adapter 3. ADB Adapter 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. Page
6 of 36
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 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
Page
7 of 36
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 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.
Page
8 of 36
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 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 -ems_transport tcp://<EMS server host>:port <user id> #!encrypted password d) Save the changes.
Page
9 of 36
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 <tibco_root>/tra/domain/<domain_name> /plugin is located in
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> Page
10 of 36
<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. 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. -ems_transport tcp://<EMS server host>:port <user id> #!encrypted password 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 d) Save the changes.
5.5 RESTART HAWK SERVICES

Save all the above changes and restart the following services so that the changes will be effective. Page
11 of 36
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
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 Page
12 of 36
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 prerequisites for the rulebases.
6.1.1
FOLDER STRUCTURE
under TIBCO domain root (i.e.
Create the following folder structure <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
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. Page
13 of 36
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.
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
Page
14 of 36
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: BUSINESSWORKS 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-DeploymentComponent.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
15 of 36
FIGURE 2 BW PROCESS ENGINE RULEBASE FLOW
Page
16 of 36
The rules include:
Check for the .running file: This rule will test to see the CISCommonCISCommonProcesses.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 CISCommonCISCommonProcesses.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
17 of 36
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. 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. 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. 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. 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 Page
18 of 36
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 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
Page
19 of 36
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 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-DeploymentComponent.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.
6.3.2
Given below are the implementation details for a Payment File Adapter. The rulebase name is "FileAdapter-Finance-FinancePaymentFileAdapter.hrb"
Page
20 of 36
FileAdapter-FinanceFinancePaymentFileAdapter.hrb
The rule will:
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.
6.3.3
LOAD THE RULEBASE
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.4
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. Page
21 of 36
6.3.5
TEMPLATE RULEBASE
FileAdapter-Deploym entName-ComponentInstanceName.hrb
Following changes have to be done, prior to using this rulebase for a File Adapter. DeploymentName need to be replaced with the EAR name defined in the BW Project ComponentInstanceName need to be replaced with File Adapter Archive name defined under the EAR. AuthorName need to be replaced with the author of the rulebase HostName(IPAddress) need to be replaced with a corresponding value DateTime need to be replaced with the current date time 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. Finally, the rulebase file name need to be changed with actual values of DeploymentName and ComponentInstanceName
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-DeploymentComponent.hrb. Here Deployment is the Enterprise Archive name and Component is the ADB Adapter archive name in the BW project.
6.4.1
REQUIREMENTS
Page
22 of 36
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.
6.4.2
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-WaterQualityLIMS.hrb"
ADBAdapter-WaterQ uality-LIMS.hrb
6.4.3 6.4.4 6.4.5
LOAD THE RULEBASE MIGRATION ACROSS ENVIRONMENTS TEMPLATE RULEBASE
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
ADBAdapter-Deploy mentName-ComponentInstanceName.hrb
Following changes have to be done, prior to using this rulebase for an ADB adapter. DeploymentName need to be replaced with the EAR name defined in the BW Project ComponentInstanceName need to be replaced with ADB Adapter Archive name defined under the EAR. AuthorName need to be replaced with the author of the rulebase HostName(IPAddress) need to be replaced with a corresponding value DateTime need to be replaced with the current date time Page
23 of 36
ADBAdapterDesc needs to be replaced with appropriate description of the ADB adapter. Finally, the rulebase file name need to be changed with actual values of DeploymentName and ComponentInstanceName
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.
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.
6.5.2
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.
6.5.3
LOAD THE RULEBASE
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.
Page
24 of 36
6.5.4
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
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.
6.6.2
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:
Page
25 of 36
Check for the .enabled file: This rule will test to see the ContactContactProcess.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 ContactContactProcess.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.
6.6.3
LOAD THE RULEBASE

26 of 36
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. Page
6.6.4
6.6.5
TEMPLATE RULEBASE
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 ComponentInstanceName need to be replaced with Process Archive name defined under the EAR. AuthorName need to be replaced with the author of the rulebase HostName(IPAddress) need to be replaced with a corresponding value DateTime need to be replaced with the current date time 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. 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 file, it is recommended to add a prefix to this property name. 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 file, it is recommended to add a prefix to this property name.
Page
27 of 36
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.
6.7.2
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
28 of 36
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
29 of 36
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. 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.
6.7.3
LOAD THE RULEBASE
This rulebase can be sent to the machine at any point of time. It will check the current state of the topic, and accordingly an alert and email will be sent.
6.7.4
Page
30 of 36
6.7.5
TEMPLATE RULEBASE
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 ComponentInstanceName need to be replaced with Process Archive name defined under the EAR. AuthorName need to be replaced with the author of the rulebase HostName(IPAddress) need to be replaced with a corresponding value DateTime need to be replaced with the current date time 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 file, it is recommended to add a prefix to this property name. 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 file, it is recommended to add a prefix to this property name. 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. Page
31 of 36
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
This section will discuss on the Hawk Rulebase to monitor the unauthorized client connections established to TIBCO EMS server. The naming convention UnauthorizedConnections.hrb. followed for this rulebase is EMSServer-
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.
6.8.2
Given below are the implementation details for monitoring the unauthorized client connections to EMS server. The rulebase name is "EMSServerUnauthorizedConnections.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.
6.8.3
LOAD THE RULEBASE

Page
32 of 36
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.
6.8.4
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. Since the allowable machine names vary from one environment to another, rulebase need to be modified before deploying on each environment.
6.8.5
TEMPLATE RULEBASE
EMSServer-Unauthor izedConnections.hrb
Following changes have to be done, prior to using this rulebase for monitoring unauthorized connections to EMS server. AuthorName need to be replaced with the author of the rulebase HostName(IPAddress) need to be replaced with a corresponding value DateTime need to be replaced with the current date time 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). Page
33 of 36
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. -ems_transport tcp://<EMS server host>:port <user id> #!encrypted password 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.
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. -ems_transport tcp://<EMS server host>:port <user id> #!encrypted password 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. Page
34 of 36
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.
6.9.3
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. 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.
6.9.4
LOAD THE RULEBASE
This rulebase can be sent to the machine at any point of time. It will check the status of Hawk agent, and accordingly an alert and email will be sent.
6.9.5
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.6
TEMPLATE RULEBASE
MonitorHawkAgent.h rb
Following changes have to be done, prior to using this rulebase for monitoring the Hawk agent service. Page
35 of 36
AuthorName need to be replaced with the author of the rulebase HostName(IPAddress) need to be replaced with a corresponding value DateTime need to be replaced with the current date time 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
36 of 36

Tibco Hawk Implemenration

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Tibco Hawk Implemenration

Încărcat de

Drepturi de autor:

Formate disponibile

White Paper on TIBCO Hawk Implementation

White Paper On TIBCO Hawk Implementation

White Paper on TIBCO Hawk Implementation

White Paper on TIBCO Hawk Implementation

White Paper on TIBCO Hawk Implementation

White Paper on TIBCO Hawk Implementation

White Paper on TIBCO Hawk Implementation

White Paper on TIBCO Hawk Implementation

FIGURE 1 HAWK ARCHITECTURE DIAGRAM

White Paper on TIBCO Hawk Implementation

White Paper on TIBCO Hawk Implementation

5.1 CONFIGURE DOMAIN HAWK AGENT

5.2 RENAME DEFAULT HAWK AGENT

White Paper on TIBCO Hawk Implementation

MONITOR AND MANAGE EMS SERVER FROM HAWK

White Paper on TIBCO Hawk Implementation

5.4 MONITORING EVENT SERVICE

5.5 RESTART HAWK SERVICES

White Paper on TIBCO Hawk Implementation

5.6 CONFIGURE HAWK DISPLAY FOR EMS

White Paper on TIBCO Hawk Implementation

Create the following folder structure <tibco_root>/tra/domain/ <domain_name>) ----Accelerator

White Paper on TIBCO Hawk Implementation

VARIABLES CONFIGURATION FILE

White Paper on TIBCO Hawk Implementation

6.2 RULEBASE: BUSINESSWORKS PROCESS ENGINE

White Paper on TIBCO Hawk Implementation

FIGURE 2 BW PROCESS ENGINE RULEBASE FLOW

White Paper on TIBCO Hawk Implementation

The rules include:

White Paper on TIBCO Hawk Implementation

White Paper on TIBCO Hawk Implementation

LOAD THE RULEBASE

MIGRATION ACROSS ENVIRONMENTS

White Paper on TIBCO Hawk Implementation

6.3 RULEBASE: FILE ADAPTER

White Paper on TIBCO Hawk Implementation

The rule will:

LOAD THE RULEBASE

MIGRATION ACROSS ENVIRONMENTS

White Paper on TIBCO Hawk Implementation

6.4 RULEBASE: ADB ADAPTER

White Paper on TIBCO Hawk Implementation

6.4.3 6.4.4 6.4.5

LOAD THE RULEBASE MIGRATION ACROSS ENVIRONMENTS TEMPLATE RULEBASE

White Paper on TIBCO Hawk Implementation

6.5 RULEBASE: EMS SERVER

LOAD THE RULEBASE

White Paper on TIBCO Hawk Implementation

MIGRATION ACROSS ENVIRONMENTS

6.6 RULEBASE: EMS QUEUES

The rule will:

White Paper on TIBCO Hawk Implementation

LOAD THE RULEBASE

White Paper on TIBCO Hawk Implementation

MIGRATION ACROSS ENVIRONMENTS

White Paper on TIBCO Hawk Implementation

6.7 RULEBASE: EMS DURABLE TOPICS

The rule will:

White Paper on TIBCO Hawk Implementation

White Paper on TIBCO Hawk Implementation

LOAD THE RULEBASE

MIGRATION ACROSS ENVIRONMENTS

White Paper on TIBCO Hawk Implementation