Flylib.com

Books Software

 
 
 

Appendix B: Using Rational Robot in the Tivoli Management Agent Environment

 < Day Day Up > 


Appendix B: Using Rational Robot in the Tivoli Management Agent Environment

This appendix describes how to use Rational's Robot with a component of Tivoli Monitoring for Transaction Performance (TMTP), in order to measure typical end- user response times.

Rational Robot

Rational Robot is a functional testing tool that can capture and replay user interactions with the Windows GUI. In this respect, it is equivalent to Mercury's WinRunner, and we are using it to replace the function that was lost when we were forced to remove WinRunner from TAPM.

Robot can also be used to record and play back user interaction with a Java application, and with a Java applet that runs in a Web browser.

Documentation is included as PDF files in the note that accompanies this package.



 < Day Day Up > 
 < Day Day Up > 


Tivoli Monitoring for Transaction Performance (TMTP)

TMTP includes a component called Enterprise Transaction Performance (ETP). The core of ETP is an Application Response Measurement (ARM) agent, which recognizes "start" and "stop" calls made by an application (or script), and uses them to report response time and other data in real-time and historical graphs.

Since ETP is fully integrated with the Tivoli product set, thresholds can be set on response time, and TEC events can be created when the response time is too long. ETP saves its data in a database, from which it can be displayed with TDS, or sent to the Tivoli Data Warehouse and harvested using TSLA.

This way, standard capabilities of the TMTP/ETP product are used to measure response time, which can also be viewed in real-time graphs such as the one shown in Figure B-1 on page 441.

click to expand
Figure B-1: ETP Average Response Time

In order for TMTP/ETP to record this data, the ARM API calls must be made from Rational Robot scripts.



 < Day Day Up > 
 < Day Day Up > 


The ARM API

The ARM API is an Open Group standard for a set of API calls that allow you to measure the performance of any application. The most common use of the API is to measure response time, but it can also be used to record application availability and account for application usage. The ARM API is documented at http://www.opengroup.org/management/arm.htm . The ARM Version 2 implementation is a set of C API calls, as shown in Figure B-2 on page 442.

click to expand
Figure B-2: ARM API Calls

There are six ARM API calls:

arm_init

This is used to define an application to the response time agent.

arm_getid

This is used to define a transaction to the response time agent. A transaction is always a child of an application.

arm_start

This call is used to start the response time clock for the transaction.

arm_update

This call is optional. It can be used to send a heartbeat to the response time agent, while the transaction is running. You might want to code this call in a long-running transaction, to receive confirmations that it is still running.

arm_stop

This call is used to stop the response time clock when a transaction completes.

arm_end

This call ends collection on the application. It is effectively the opposite of the arm_getid and arm_init calls.

The benefit of using ARM is that you can place the calls that start and stop the response time clock in exactly the parts of the script that you want to measure. This is done by defining individual applications and transactions within the script, and placing the ARM API calls at transaction start and transaction end.



 < Day Day Up >