Configuring TIBCO Hawk to keep running the TIBCO Enterprise Administrator

Usually in this blog we talk a lot about development techniques, trips or tricks, but we don’t pay so much attention to the administration tasks. In this topic we are going to change that because we are going to explain how to use the main TIBCO tool for monitoring and administrative tasks, TIBCO Hawk.

As we said earlier, TIBCO Hawk is the main tool by TIBCO to reach the following goals:

  • Monitoring your platform performance
  • Extract statistics about your performance
  • Executing administrative tasks based on the data of their micro-agents.

In this topic we are not going to discuss conceptual aspects about the TIBCO Hawk architecture. We are only going to say that it is a distributed architecture based on agents and a network (preferred Rendezvous network but EMS also supported). All different agents (one agent for  TIBCO software: There is an agent for TIBCO AMX BusinessWorks, another for TIBCO BusinessEvents and so on) use this network to comunicate with each other and to send the data available for all including the Hawk console.

These agents are retrieving all the statistics that allowed to monitor the performance. It also supports the execution of actions inside the monitored object based on JMX messages and requests.

In this topic are only going to explain how to use the TIBCO Hawk to implement a rule to restart TIBCO Enterprise Administrator and we are going to use the current version of the product: TIBCO Hawk 5.1.1. (Note: If you are using or your experience resides in the 4.9 version, you are going to notice a set of important changes in this new version but nothing about the essence of the ideas showed here)

We are going to start with the assumption that we have a sucessfully TIBCO Hawk installation inside our TIBCO BusinessWorks enviroments so in this topic we are not covering that part.

To do any kind of action or control inside our TIBCO Hawk enviroment we need to implement a Hawk Rule to tell Hawk how this actions should be performed. Hawks Rules are grouped by Rulebase when all the rules shared a common context.

Subjects to cover when you are creating rules

You will have to use the TIBCO Hawk Display component in order to get implemented and deployed the Hawk Rules inside your Hawk domain, and you will have to cover these subjects:

1.- Define the number of rules we are going to implement

You will have to design the rules that which will be included your Hawk rulebase to get the work done. In this case we are going to define two rules: One to check if the TEA is running and another to act in case that the TEA is not running.

2.- Choose the main microagent about we are going to act.

In our case we are use the Process Microagent because we are going to interrogate about the OS processes that are currently running inside our host. To do that we are going to use the following operation that belong to that microagent: getProcess


Additional to that, we are going to use a periodical condition (retrieve the process running each 60 seconds or so) to implement this check.

3.- Check for the right condition

In our case we are going to check that one of the processes listed by the command above is the one that belonged to our TIBCO Enterprise Administration instance running. In our case the process name will be: tea.exe. If there is the process running we are going to raise a flag (implemented by a PostCondition). This flag will be checked by the other rule to action if the TEA is not running.

4.- Execute the action when your condition happens

The last thing is to act when your condition is triggered or detected due to this pooling process developed in the steps above. In this case, the action is too easy, we only have to launch again the startup script of the TIBCO Enterprise Administratior.

Implementation details

After explaining all the aspects important to create a Hawk rule we are going to go trough the implementation process. And to do that, the first step is to create a new Rulebase for the host we are going to manage, in our case is the only host we have in our Hawk domina (in a production evironment it will be usual to have several machines with several TIBCO components so you will have different rules and rulebases deployed to each one).

We select the machine and in the context menu we select: Get configuration –> Rulebases and we’ll be facing a new form to create our new rulebase as you can see here:


After that, we have to create and to configure the rules and the first thing we have to do is to specify the datasource (a.k.a the microagent and the operation we are going to use)

in our case, as we said earlier: one will  use the Process microagent and getProcess operation each 60 seconds. We are going to look for the tea.exe process because we are going to use the rule to restar the TEA when it is not up.


And we only have to configure the condition we have to test and as the action for the first rule will be to raise a PostCondition as you can see here:


The other rule will be so much easy to configure because we only need a periodical loop to check the condition and if there is no condition to execute the procedure to start the TIBCO Enterprise Administrator. We are going to use the Self Microagent and the getUptime operation as the Data Source for this second rule, and we are going to check is the post-condition have been activated by the previous rule and to execute the action to restart the TEA as you can see here:


The last thing we have to do is to deploy the rule inside the machine but that is too easy. You only have to select the rulebase and press the button labeled “Apply changes” and we are done!


End of explanation time, so now we are going to test it! So we have our TEA up, but we are having to take our TEA down to check the correct work of the rule. While we have the TEA is up, as we configure the rule to leave notification messages, in the Hawk console we are going to see periodical messages telling us that the TEA is running as you can see here:


And is one you kill the tea.exe process you will see all the new behaviour we have configured using the rule (the maximun time between the kill and the restart is 75 seconds – because we configure one loop each 60 secs, and the other 15 secs – but you can configure when the times based on your SLA)


We leave for you the HRB (the text format of an exported Hawk Rulebase) so you can easily imported into your Hawk console using the wizard provided in the Hawk Display component: Download!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s