You are on page 1of 26

5.

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 latersection) 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 1 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> Page 1010 of

36

<arg>-timeout</arg>

Page 1111 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 1212 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 Step5.1

c)

Click Ok Page 1313 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 P RE - 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 1414 of

36

6.1.3

V ARIABLES 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 added. Please keep in mind that if any changes are done in HawkAC_variables.dat, Domain Hawk agent service need to be restarted to make changes effective. The recommendation would be to add the variables for rulebases at once, to avoid restarting the Hawk agent service for several times.

be the the all

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 1515 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 : BUSINESSW ORKS PROCESS ENGINE


This section will discuss on the Hawk Rulebase TIBCO BusinessWorks Process engines. to monitor and manage the

The naming convention followed for this kind of rulebase is BWEngineDeployment- Component.hrb . Here Deployment is the Enterprise Archive name and Component is the process archive name in the BW project.

6.2.1

R EQUIREMENTS

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-CISCommonProces

Given below is the sequence diagram which describes the high level implementation of this rulebase.

Page 1616 of

36

FIGURE 2 BW PROCESS ENGINE RULEBASE FLOW

Page 1717 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 1818 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 CISCommonCISCommonProcesses.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 1919 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

M IGRATION 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 2020 of

36

BWEngine-Deployme ntName-ComponentIn

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 DeploymentName and ComponentInstanceName with actual values of

6.3 RULEBASE : FILE A DAPTER


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 FileAdapterDeployment- Component.hrb . Here Deployment is the Enterprise Archive name and Component is the File Adapter archive name in the BW project.

6.3.1

R EQUIREMENTS

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

IMPLEMENTATION DETAILS

Given below are the implementation details for a Payment File Adapter. The rulebase name is "FileAdapter-Finance-FinancePaymentFileAdapter.hrb"

Page 2020 of

36

FileAdapter-FinanceFinancePaymentFileA

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

M IGRATION 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. Page 2121 of

36

6.3.5

TEMPLATE RULEBASE

Given below is the template rulebase that has been implemented with the requirements mentioned in section 6.3.1

FileAdapter-Deploym entName-Component

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 DeploymentName and ComponentInstanceName with actual values of

6.4 RULEBASE : ADB A DAPTER


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

R EQUIREMENTS
Page 2222 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

IMPLEMENTATION DETAILS

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

LOAD THE RULEBASE

Loading rules are same as that of BW Process Engine defined in section6.2.3

6.4.4

M IGRATION ACROSS ENVIRONMENTS

Migration rules are same as that of BW Process Engine defined in section6.2.4

6.4.5

TEMPLATE RULEBASE

Given below is the template rulebase that has been implemented with the requirements mentioned in section 6.4.1

ADBAdapter-Deploy mentName-Componen

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 2323 of

36

ADBAdapterDesc needs to be replaced with appropriate description of the ADB adapter. Finally, the rulebase file name need to be changed DeploymentName and ComponentInstanceName with actual values of

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

R EQUIREMENTS

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

IMPLEMENTATION DETAILS

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 2424 of

36

6.5.4

M IGRATION 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.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

R EQUIREMENTS

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

IMPLEMENTATION DETAILS

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 2525 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

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 2626 of

36

6.6.4

M IGRATION 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.6.5

TEMPLATE RULEBASE

Given below is the template rulebase that has been implemented with the requirements mentioned in section 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 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 2727 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 DeploymentName with actual value of

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

R EQUIREMENTS

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

IMPLEMENTATION DETAILS

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 2828 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 2929 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

M IGRATION ACROSS ENVIRONMENTS

Page 3030 of

36

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.7.5

TEMPLATE RULEBASE

Given below is the template rulebase that has been implemented with the requirements mentioned in section 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 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 3131 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

R EQUIREMENTS

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

IMPLEMENTATION DETAILS

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 3232 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

M IGRATION 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. Since the allowable machine names vary from one environment to another, rulebase need to be modified before deploying on each environment.

Page 3333 of

36