Using WinTask with Application Response and

Transcription

CA eHealth
®
Using WinTask with Application Response and
Service Availability
r6.1
This documentation and any related computer software help programs (hereinafter referred to as the
“Documentation”) is for the end user’s informational purposes only and is subject to change or withdrawal by CA at
any time.
This Documentation may not be copied, transferred, reproduced, disclosed, modified or duplicated, in whole or in part,
without the prior written consent of CA. This Documentation is confidential and proprietary information of CA and
protected by the copyright laws of the United States and international treaties.
Notwithstanding the foregoing, licensed users may print a reasonable number of copies of the Documentation for their
own internal use, and may make one copy of the related software as reasonably required for back-up and disaster
recovery purposes, provided that all CA copyright notices and legends are affixed to each reproduced copy. Only
authorized employees, consultants, or agents of the user who are bound by the provisions of the license for the
product are permitted to have access to such copies.
The right to print copies of the Documentation and to make a copy of the related software is limited to the period
during which the applicable license for the product remains in full force and effect. Should the license terminate for
any reason, it shall be the user’s responsibility to certify in writing to CA that all copies and partial copies of the
Documentation have been returned to CA or destroyed.
EXCEPT AS OTHERWISE STATED IN THE APPLICABLE LICENSE AGREEMENT, TO THE EXTENT PERMITTED BY
APPLICABLE LAW, CA PROVIDES THIS DOCUMENTATION “AS IS” WITHOUT WARRANTY OF ANY KIND, INCLUDING
WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE
OR NONINFRINGEMENT. IN NO EVENT WILL CA BE LIABLE TO THE END USER OR ANY THIRD PARTY FOR ANY LOSS
OR DAMAGE, DIRECT OR INDIRECT, FROM THE USE OF THIS DOCUMENTATION, INCLUDING WITHOUT LIMITATION,
LOST PROFITS, BUSINESS INTERRUPTION, GOODWILL, OR LOST DATA, EVEN IF CA IS EXPRESSLY ADVISED OF
SUCH LOSS OR DAMAGE.
The use of any product referenced in the Documentation is governed by the end user’s applicable license agreement.
The manufacturer of this Documentation is CA.
Provided with “Restricted Rights.” Use, duplication or disclosure by the United States Government is subject to the
restrictions set forth in FAR Sections 12.212, 52.227-14, and 52.227-19(c)(1) - (2) and DFARS Section
252.227-7014(b)(3), as applicable, or their successors.
All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.
Copyright © 2008 CA. All rights reserved.
Contents
Chapter 1: Introducing WinTask
WinTask Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
WinTask Used with Application Response . . . . . . . . . . . . . . . . .
WinTask Used with Service Availability. . . . . . . . . . . . . . . . . . .
WinTask Used with Application Response and Service Availability
Prerequisites for Using WinTask . . . . . . . . . . . . . . . . . . . . . . .
Supported Operating Systems . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
..
..
..
..
..5
..6
..7
..8
..9
. .9
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
12
15
17
17
18
Record a Business Transaction with WinTask . . . . . . . . . . . . . . . . .
Script Editing Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Add Pauses to Your Script . . . . . . . . . . . . . . . . . . . . . . . . . .
Insert Text and Images Checks for Synchronization . . . . . . . .
Timeout Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
#PauseTimeout Function – Add Timeout Values . . . . . . . . . . .
#ActionTimeout Function – Set Timeouts for a Specific Action .
Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
#IgnoreErrors Function – Set Global Error Handling . . . . . . . .
Cleanup After Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Error Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Create a Log File for Error Messages . . . . . . . . . . . . . . . . . .
Detailed Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compile and Run the Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deploy the WinTask Runtime Agent and Scripts to Client Systems . .
Configure AR to Monitor Transactions (Only for the AR Agent) . . . . .
Configure the AR Agent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enable the AR Agent to Run Continuously . . . . . . . . . . . . . . . . .
Create an Application (Custom Applications Only) . . . . . . . . . . .
Record Events for Custom Applications with the AR Agent . . . . . .
Modify Rules with BT Studio . . . . . . . . . . . . . . . . . . . . . . . . . .
Options for Scheduling the Scripts to Run . . . . . . . . . . . . . . . . . . .
Schedule Scripts to Run by Using the WinTask Scheduler . . . . . .
Configure Service Availability to Run Scripts . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
..
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
21
24
24
25
26
28
28
28
29
29
29
30
30
31
31
32
34
35
37
37
38
39
41
42
43
Contents
3
Chapter 2: Configuring Your Environment
Software Prerequisites. . . . . . . . . . . . . . . .
How to Get Started: Workflow . . . . . . . . . .
How to Set Up Your Systems . . . . . . . . . . .
eHealth System Configuration Prerequisites .
WinTask Components . . . . . . . . . . . . . . . .
Install WinTask . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Chapter 3: Recording and Monitoring Scripts
Enable the SystemEDGE Service to Interact with the Desktop . . . . . . . . . . . . . . . . . . . . . . . 44
Create a Virtual User Test to Schedule WinTask Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Monitor Log Files with SystemEDGE (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Chapter 4: Using eHealth for Monitoring and Reporting
View Service Availability Queries . . . . . . . . . . . . . . . . . .
How to Organize Response Elements for Reporting . . . . . .
eHealth Reports That You Can Run . . . . . . . . . . . . . . . . .
Data Collected by WinTask Scripts . . . . . . . . . . . . . . .
Trend Data Obtained by Drilling Down for More Detail .
Response and Availability Data in At-a-Glance Reports .
Performance Summaries in Health Reports . . . . . . . . .
How to Begin Using Live Health . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
49
50
50
50
52
53
54
55
Scripts That Identify and Terminate Processes for Error Cleanup . . . . . . . . . . . . . . . . . .
init_kill_process.src – Identify Running Processes Before the WinTask Script Executes .
kill_process.src – Terminate Processes Initiated by the Script . . . . . . . . . . . . . . . . . .
proc_error() function – Provide Error Output to an Error Log and Service Availability . .
Sample Script for Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
57
58
59
61
62
Appendix A: Sample WinTask Scripts and Tips
Index
4
Using WinTask with Application Response and Service Availability
Chapter 1: Introducing WinTask
This chapter contains the following topics:

WinTask Overview

WinTask Used with Application Response

WinTask Used with Service Availability

Prerequisites for Using WinTask

Supported Operating Systems
WinTask Overview
WinTask is a task-automation tool that can record and play back user actions for
any Windows-based application. It captures all the user activity associated with
a task, such as keyboard entry and mouse clicks, and can replay the activity to
reproduce the task automatically. WinTask scripts let you perform continuous,
automated tests that mimic interactive user sessions. Use WinTask to enhance
the power of eHealth Application Response and Service Availability reports with
continuous coverage for your critical business transactions.
WinTask significantly extends the power of Application Response and Service
Availability. Independently, these tools provide the following important features:

WinTask can record and play back scripts that mimic user transactions in a
structured, repetitive manner.

Service Availability provides availability and high-level, baseline response
time data for applications. In the case of a WinTask script, the SA response
time is a measurement of the overall script execution. This includes lookup
times, connect time, and pauses (synchronization). The WinTask response
times, therefore, serve as a baseline by which you can infer degrading or
improving response time.

Application Response provides response time data broken down into client,
network, and server time for applications and failed application transactions.
AR provides detailed status about the transactions running in a WinTask
script. You can control the type of transaction reporting by setting rules in
BT Studio.
Introducing WinTask
5
When used together, WinTask, Application Response, and Service Availability
can provide more robust coverage for your mission-critical applications. You can
use the applications in the following combinations:

WinTask with Application Response alone

WinTask with Service Availability alone

WinTask with both Application Response and Service Availability
This document is intended to help you install and configure WinTask, Application
Response, and Service Availability to run automated tests for monitoring
availability and response times. It explains how to configure the following
products to work together:

TaskWare® WinTask Release 2.6

eHealth® Service Availability Release 2.0 and later

eHealth Application Response Release 5.7 and later
Using WinTask with Application Response lets you do the following:

Compare client, network, and server time for the exact same user
transaction to detect changes in service.

Identify degradations in transaction performance without requiring actual
user activity.

Test specific use cases and transactions before you widely deploy tasks to
users.

Test all transactions, including the ones that users may not perform
frequently.
Compare Client, Network, and Server Time for the Exact Same User
Transaction
When you use WinTask to record and play back the same user transaction
repeatedly, you can monitor the client, network, and server time for each
transaction to watch for changes in service. Because you are repeating and
measuring the same transaction, the data you obtain should be identical for
each occurrence of the transaction.
When fluctuations occur, you can be sure that they are due to client,
network, or server time—not changes in user activity. For example, a user
might send one e-mail message of 1 MB and then another that includes a 5
MB attachment. You cannot gauge easily if a difference in response time is
due to the size of the different messages that the user is sending. When you
use WinTask to send the same message again and again, you know that any
fluctuations in response time are a result of changes in the client, network,
or server—not changes in the transaction being performed.
6
Identify Degradations in Transaction Performance without Requiring
Actual User Activity
With WinTask, you can run the same transactions all day, every day.
Coverage is no longer limited by the length of the work day. When you rely
on actual user actions to bring problems to your attention, your first
awareness that something is wrong may occur too late—after the problem
has started to affect users. When you record those user actions with a
WinTask script and then run them on a continuous basis, the AR agent can
monitor the transaction and alert you as soon as a problem begins, which
helps you to start fixing the problem as soon as possible.
Test Specific Use Cases and Transactions before Full Deployment
You can use WinTask to record a new user transaction and test it before
deploying it to multiple test systems. This feature can help you to test,
measure, and evaluate the transaction before you roll out a new application
or new Web site design on a wide basis.
For example, if you add a new capability for downloading files to your
Corporate Web site, you may want to test the new process before you make
it available to all of your customers. You can create a WinTask script that
accesses your Web site, opens the download page, downloads the files, and
then closes the Web browser. You can run this transaction again and again,
using the AR agent to monitor the response time, before you make this
feature available to customers.
Test All Transactions—Even Rare Use Cases
With Application Response, you can obtain data on transactions only when
users actually perform them. This feature means that you receive little or no
data for transactions that users perform infrequently. For example, if users
perform a transaction only once a month, you can obtain data for that
transaction only once a month. Such infrequent data may prevent you from
noticing problems with the transaction. When you use WinTask to create a
script that runs a rare use case, the AR agent can collect continuous data
about the transaction and provide you with vital information about how the
feature is performing.
Service Availability can run custom scripts and provide availability and response
data about those scripts but it does not record user transactions. Using WinTask
with Service Availability lets you create powerful scripts that mimic user actions.
You can play the scripts back with Virtual User tests, obtaining availability and
response information that WinTask cannot provide on its own.
Use WinTask with Service Availability to do the following:

Obtain continuous availability and response-time data for real user
transactions.

Manage the scheduling and deployment of user-transaction tests from a
centralized console.
Introducing WinTask
7
Obtain Continuous Availability and Response Data for Real User
Transactions
Service Availability provides response time and availability data for sample
transactions for a variety of network services. It does not provide data for
actual user tasks. When you use WinTask to create scripts that mimic user
transactions and then create Virtual User tests to run the scripts, Service
Availability can provide continuous response time and availability data for
those specific user transactions.
For example, when you are using Service Availability alone, you can create
a test that monitors the availability of a particular Web site and the amount
of time it takes for the site to load in your Web browser. When you use
Service Availability with WinTask, you can measure the availability of a
particular Web page, and can measure response time for user actions, such
as opening the Web page, selecting options from a menu on that page,
completing and submitting a form, and then closing the Web page. WinTask
supplements Service Availability so that you can obtain more meaningful
response-time data for the transactions that a user typically performs.
Monitor User Transactions from a Centralized Console
When you use Service Availability and WinTask, you can deploy scripts from
one central eHealth system. You can also schedule them to run on a variety
of client systems and collect data on them from that one central system.
WinTask Used with Application Response and Service
Availability
Using WinTask with both Application Response and Service Availability lets you
obtain a clearer picture of the response time and availability of your application
and user transactions from automated, continuous testing. You can obtain
availability data for your transactions (which you cannot obtain with Application
Response alone), and you can obtain a breakdown of client, network, and server
time for each transaction (which you cannot obtain with Service Availability
alone).
Using WinTask with Application Response and Service Availability lets you obtain
continuous, consistent data for all the user transactions and services that you
care about from the systems that you are monitoring, without waiting for actual
user activity.
On its own, the AR agent captures data only when a user is performing
transactions, and Service Availability provides only overall response time and
availability data. But you can use the applications together, recording the scripts
with WinTask, using Service Availability to create Virtual User tests that execute
the scripts on a continuous basis, and then monitoring the response time and
availability of the transactions with the Application Response and Service
Availability. This continuous data provides real-time monitoring for your
important services, and it makes your eHealth reports more useful for capacity
planning and longterm historical monitoring of the applications.
8
The following are required to use WinTask:

You must have an understanding of the SystemEDGE agent, Service
Availability, Application Response, AdvantEDGE View, Live Health, the
eHealth console, and the eHealth Web interface.

You must be using eHealth Release 6.0 or later and the SystemEDGE agent
Release 4.2 or later.
Note: For more information when using this document, see the eHealth
Response Administration Guide, the eHealth SystemEDGE User Guide, the
eHealth BT Studio Administration Guide, and the eHealth Help.
Supported Operating Systems
WinTask supports the following operating systems:

Microsoft Windows NT 4.0

Windows® 2000

Windows XP

Windows 2003
WinTask does not support Citrix environments.
Introducing WinTask
9
Chapter 2: Configuring Your
Environment

Software Prerequisites

How to Get Started: Workflow

How to Set Up Your Systems

eHealth System Configuration Prerequisites

WinTask Components

Install WinTask
Software Prerequisites
To use WinTask with Application Response and Service Availability, you must
have the following software components:

eHealth Release 6.0 or later, which includes the eHealth console, Web
interface, and Application Response

Published AR agents for your development and client systems

Business Transaction Studio (BT Studio), required if you are monitoring
custom applications with Application Response or modifying transaction
rules for your default applications

eHealth Service Availability 2.0

eHealth SystemEDGE 4.2 or later

WinTask 2.6 or later
Note: If you are using only Application Response with WinTask, you do not need
Service Availability or the SystemEDGE agent. If you are using only Service
Availability with WinTask, you do not need published AR agents or BT Studio.
Configuring Your Environment
11
You must also have the following systems:

A Windows development system, which is the dedicated system on which
you will create and test the WinTask scripts.

An eHealth system from which you will deploy and manage your AR agents,
SystemEDGE agents, and Service Availability modules. The eHealth system
stores the data about the scripts that you are running. You can use these
scripts to run and view reports on that data.

A Windows client system, on which you will run WinTask scripts and monitor
them with the AR agent and Service Availability. The client system is where
the AR agent, the SystemEDGE agent, and the Service Availability module
reside.
You can deploy all of these components (including the WinTask runtime
agent and the completed script) to your client system through the Agent
Deployment feature. Go to the Systems & Apps tab of the eHealth Web
interface, select AdvantEDGE View, click the Administration icon, then click
Agent Deployment.
More information:
Deploy the WinTask Runtime Agent and Scripts to Client Systems on page 32
You can use WinTask with Application Response, Service Availability, or both.
The steps in the following table summarize what you must do to begin
monitoring transactions with WinTask, Application Response, and Service
Availability.
12
Step
1.
Configure the development,
client, and eHealth systems.
For more information, see
on page 15 and eHealth
System Configuration
Prerequisites on page 17.
2.
eHealth 6.0
Client System:
Development System:
AR agent
SystemEDGE agent
WinTask runtime agent
AR agent
BT Studio
SystemEDGE agent
WinTask recording agent
Development System
Edit the WinTask script.
Script Editing Functions on
page 24.
4.
eHealth System:
Record a business transaction
with WinTask.
Record a Business
Transaction with WinTask on
page 21.
3.
Graphical Description
Development System
Deploy the WinTask scripts to
your client systems from the
Systems & Apps tab of the
eHealth Web interface.
Deploy the WinTask Runtime
Agent and Scripts to Client
Systems on page 32.
eHealth System
Client Systems
13
Step
5. Configure the AR agent to
monitor the script. (AR agent
only)
For more information,
see Configure AR to Monitor
Transactions (Only for the AR
Agent) on page 34.
eHealth System
6. Schedule the WinTask scripts
to run using one of the
following:

14
The WinTask Scheduler;
for more information,
refer to Schedule Scripts
to Run by Using the
WinTask Scheduler on
page 42.
Client System:
eHealth System:
WinTask Scheduler
Virtual User tests; for
more information, see
Configure Service
Availability to Run Scripts
on page 43.
Step
7.
Run At-a-Glance, Trend,
Top N, myHealth, Health, and
Service Level reports for the
tests.
How to Organize Response
Elements for Reporting on
page 50 and eHealth Reports
That You Can Run on
page 50.
8.
(Optional) Use Live Health to
associate Live Exceptions
profiles with the tests and
view data in the Live
Exceptions Browser and Live
Status.
eHealth System
Live Health System
A typical WinTask script may
take longer to run than a
default SA application. You
may want to adjust the
normal timeout values and
response time thresholds for
this timing difference. Copy
and rename standard Live
Exception profiles and modify
them to use settings that
reflect timing for your
WinTask scripts.
How to Begin Using Live
Health on page 55.
The following table lists the components that you must install on your
development and client systems. If you are using both Service Availability and
Application Response, you can install all components. If you are using only one
or the other, use the middle column of the table to determine which components
you need for the product that you are using.
15
Note: You can deploy the WinTask runtime agent and scripts, the AR agent,
Service Availability, and the SystemEDGE agent to your client system from the
Systems & Apps tab of the eHealth Web interface. For more information about
deploying WinTask, see Deploy the WinTask Runtime Agent and Scripts to Client
Systems on page 32.
Install this component:
If you are using
these products:
For more information, refer to
the following:
WinTask
WinTask
Install WinTask on page 18
AR agent
Application Response
eHealth Response Administration
Guide
BT Studio (development
system only)
eHealth BT Studio Administration
Guide
SystemEDGE agent
eHealth SystemEDGE User Guide
Service Availability in the eHealth
Help
Live Health (optional)
or Service Availability
Live Health in the eHealth Help
The application to monitor
WinTask, Application
Response, and/or
Installation instructions for the
application
The following graphic shows the three types of systems that you need and the
main components that you will use on each system.
16
You use the development system to record, edit, and test your scripts. When the
scripts are ready, you deploy them to the client systems, where you run them
and where the AR agent, SystemEDGE agent, and Service Availability are
running to monitor transactions. You use the eHealth system to configure your
AR agents and Service Availability modules and to store and report on the data
that they collect.
Before you use the eHealth system to manage your AR agents and Service
Availability modules, make sure that you are using an eHealth 6.0 or later
system on which you have access to the following:

Administration tab

Systems & Apps tab

Run Reports tab

An eHealth user account with permissions set to do the following:
–
Let the user manage AR agents and deploy agents.
–
Access System and Response Groups and Group Lists.
–
Run At-a-Glance and Trend reports.
–
Read, Write, Create, and Delete permissions.
You must have administrator privileges to access these tabs or to change these
user options. Ask your eHealth Web administrator to modify your user account
before you proceed.
Note: For more information about any of these settings, see the eHealth Help.
WinTask Components
WinTask provides two agents:

The recording agent

The runtime agent
The WinTask recording agent includes the following components:
Recorder
Lets you record a business transaction. It captures all keyboard entry and
mouse clicks to create a script that mimics actual user actions.
Script editor
Lets you modify a recorded script to adjust for network and server timing
plus user actions or system responses.
17
Install WinTask
Playback engine
Plays back the recorded script to mimic the actions of a user. WinTask
provides two playback engines: one that is part of the recorder, and a
separate, standalone runtime agent that can play back the script on a client
system.
Scheduler
Lets you play back the recorded transaction on a regular basis. You can use
either the WinTask Scheduler or eHealth Service Availability to schedule
your scripts.
The runtime agent includes only the playback engine.
You must install the recording agent on the development system and the
runtime agent on all client systems. Each WinTask license enables you to install
the WinTask recorder on one system and the runtime agent on an unlimited
number of systems.
The WinTask Scheduler is included only with the recorder. To run the WinTask
Scheduler on your client systems, you must purchase additional WinTask
licenses and install the recording agent on your client systems. If you plan to use
only the runtime agent, install the runtime agent.
You can use Service Availability (instead of the WinTask Scheduler) to schedule
your WinTask scripts to run.
More information:
Configure Service Availability to Run Scripts on page 43
Install WinTask
Installing WinTask consists of installing the WinTask recording agent and the
WinTask runtime agent.
To install the WinTask recording agent
1. Insert the CD that contains the WinTask software into the CD-ROM drive.
2. Copy the wintask26.exe file to the client desktop and then double-click it to
launch the installation.
The License Agreement appears.
3. Click Yes.
The Information dialog appears.
4. Click Next.
5. Enter your name and company name in the Name and Company fields and
then click Next.
The Destination Directory dialog appears.
18
Install WinTask
6. Click Browse, specify a directory name that includes no spaces in the Path
field (for example, C:\WinTask), and then click OK and Yes.
Note: Specify a pathname that does not include spaces. The Service
Availability Virtual User test may not run if there are spaces in the pathname
for the script or if the name of the WinTask executable contains spaces.
7. Click Next on the remaining screens to accept the defaults and then click
Finish on the final screen.
8. Verify that the installation was successful by making sure that the following
options appear under Start, Programs, WinTask:

Compiler

Open a Script

Scheduler

Spy

WinTask Help

WinTask

Run a Script

Scripts
To install the WinTask runtime agent
1. Insert the CD that contains the WinTask software into the CD-ROM drive.
2. Copy the install.bat and WTRuntime.msi files to the client desktop.
3. Open a command window and execute the following:
install.bat
This file runs the WTRuntime.msi file and installs the runtime agent in
C:\WintaskRuntime. To install the runtime agent in a different directory, edit
install.bat and specify a different value for the TARGETDIR variable.
4. Verify that the following options appear under Start, Programs, WinTask:

Run a script

Scripts
19
Chapter 3: Recording and Monitoring
Scripts
You must perform various tasks to use WinTask with Application Response and
Service Availability. Before proceeding, complete the setup tasks in How to Set
Up Your Systems on page 15.

Record a Business Transaction with WinTask

Script Editing Functions

Compile and Run the Script

Deploy the WinTask Runtime Agent and Scripts to Client Systems

Configure AR to Monitor Transactions (Only for the AR Agent)

Options for Scheduling the Scripts to Run
You can use WinTask to record the transactions that you want to monitor. When
you record a transaction, WinTask creates a source (.src) file that you can edit
and later compile into a robot (.rob) file. (The robot file is the runtime version of
the WinTask script that mimics user actions for the application that you want to
monitor.) You must record the script on a development system that includes the
full version of WinTask.
Note: When you are recording scripts with WinTask, use keyboard shortcuts
instead of the mouse to provide input whenever possible. WinTask captures the
precise X and Y coordinates of the mouse. Any change to a window size or its
location on the screen could affect WinTask’s ability to click (with a mouse
pointer) on the correct location, especially when running the script on systems
other than the one used to record the script.
To record a transaction with WinTask
1.
Start WinTask by selecting Start, Programs, WinTask, WinTask.
2.
Click the Record button
to start recording.
Recording and Monitoring Scripts
21
The Starting recording mode dialog appears.
3. Do one of the following:

To record a transaction in an application:
a.
Select An application and click OK.
b.
Specify the full pathname to the application you want to record in
the Program field in the Launching a Program dialog, or click Browse
to search for the application.
c.
Click OK.
The application starts.

To record Web-based transactions:
a.
Select Internet Explorer and click OK.
b.
Specify the URL for the Web site that you want to test in the Web
Address field of the Launching Internet Explorer dialog.
c.
Click OK.
The specified Web page appears.
If you are recording a script that runs Internet Explorer, you may receive
the following error message: “TaskEdit has generated errors and will be
closed by Windows. You need to restart the program. An error log is
being generated.” If you receive this error, run the following in a
command window:
regsvr32 shdocvw.dll
This command re-registers the DLL that manages Internet Explorer for
WinTask.
The WinTask window minimizes itself and becomes a task bar icon
. The
record icon also appears in the taskbar to indicate that WinTask is in record
mode.
4. Perform each step in the exact order in which you want to record it.
For example, you can click a button on the Web page, fill out a form, save
the form, and then close Internet Explorer. WinTask records your actions.
22
5. Stop recording by pressing the blinking WinTask icon in the taskbar on the
bottom-right of your screen.
The restored WinTask window appears on the screen, and the completed
WinTask script appears in the WinTask window. The following graphic shows
a sample script.
6. Select File, Save as, specify a file name, and specify the WinTask\Scripts
directory.
7. Click Save.
The script is saved.
8. Edit the script.
23
After you create a script, you must edit it to add the following types of control
and tuning statements. These statements help to ensure proper behavior and
timing so that the WinTask script can run robustly and continuously on a variety
of client systems:

Synchronization

Timeout values

Error handling
When you are editing scripts, be careful to remove any extra spaces between
variables and values. For example, do not include spaces before or after the
equal sign (=) character when specifying values for variables. If you include
spaces, the WinTask script will report errors and may not run properly.
Note: To see a complete list of all the statements you can insert in a WinTask
script, click the Languages button on the WinTask menu bar.
Synchronization
When users are working with an application, they wait for responses from the
system before continuing with their actions. For example, a user waits for an
application to launch before attempting to use the application and waits for a
particular form to appear before attempting to specify information into that
form. WinTask reproduces that behavior by letting you insert synchronization
statements before actions that are directed to specific windows, and waits for
those windows to appear at run time before sending keystrokes or mouse input.
If the window does not appear within a specific amount of time (30 seconds by
default), WinTask displays an error message.
Some scripts require pauses during the execution of the script for timing
purposes. For example, if a user completes an online form and clicks Submit, the
system may respond with a confirmation screen on which the user must click OK.
You must edit the script to ensure that it waits for the confirmation screen to
appear before executing the action to click OK. To determine whether your script
requires pauses, you must play it and determine whether it works without
pauses or where pauses are required.
Note: You must test the location and amount of time required for each pause by
running the script and verifying that the pauses that you have specified are
sufficient.
24
Add Pauses to Your Script
WinTask enables you to specific a variety of pauses. The following table shows
the options that you can select from the WinTask menu bar and the types of
pauses that they insert.
Button
Pause Until
A mouse click
A keyboard entry
A particular date or time
The appearance of a specific window
The appearance of a menu
The appearance of an image
For more information, see Insert Text and Images
Checks for Synchronization on page 26.
The appearance of a text string
For more information, see Insert Text and Images
Checks for Synchronization on page 26.
To add a pause to your script
1. Place your cursor, Within the WinTask script (.src file), at the point at which
you want to add a pause.
2. Click the menu selection that matches the type of pause that you want to
add.
For example, click WaitWind to specify a pause for the appearance of a
particular window and to specify the window.
3. Complete the dialog that appears and then click Paste into the script.
To add a pause for a specific amount of time
1. Place your cursor in the script at the point where you want to pause for a
specific amount of time.

Specify the following, where n represents the number of seconds to
wait:
Pause n
25
For example, specify Pause 10 to insert a pause for 10 seconds.

Select Insert, Synchronization, On Time delay, specify the amount of
time in the Time delay field, select the units (Seconds, Minutes, or
Hours), and then click Paste into the script.
WinTask adds a pause and waits for the amount of time that you specified
before executing the next part of the script.
Insert Text and Images Checks for Synchronization
In some cases, it is necessary to edit a script to wait for a specific image or text
to appear before continuing. If so, you must add image or text synchronization
to your script. Comparisons of graphical images and text can provide flow control
within your script and maintain synchronization.
Note: When possible, use text check rather than an image check. Graphics card
differences can introduce variation and inconsistency in image checks.
To insert a text check
1. Position the cursor, within the WinTask script (.src file), at the point at which
you want to pause to compare a text string.
2. Open the Web page or application to the text to capture for comparison, and
do one of the following:

Click the Wait Text button
.

Select Insert, Synchronization, On Text.
The Text Synchronization window appears.

Specify the text to compare in the Text field.

Click Capture, under Select the text to look for, and then select the text
to capture by clicking, holding down the mouse button, dragging to
select the text to capture, and then releasing the mouse button.
The Preview dialog box appears.
4. Deselect Only in this area (not in the whole window) and then click Paste into
the script.
26
The WinTask script reappears with new code that is similar to the following:
Pause until
Text("Company Profile")
InWindow("IEXPLORE.EXE|Internet
Explorer_Server|Customer | Company Profile Microsoft Internet Explorer|1",2)
PauseFalse - if comparison fails
MsgBox("'Wait for' at line " + #ErrorLine$ + "
has failed !",16,"Runtime error")
End
EndPause
Note: You can add synchronization to the script with any of the other Wait
options. For more information, refer to the online help from WinTask.
To insert an image check
1. Position the cursor, within the WinTask script (.src file), at the point at which
you want the script to pause for the graphic.
2. Open the Web page or the place within the application that displays the
image to capture and do one of the following:

Click the Wait Image button
.

Select Insert, Synchronization, On Image.
The Image Synchronization dialog appears.
3. Click Capture, located to the right of Use mouse to capture image.
4. Select the image to capture by doing one of the following:

Click the image to select everything on the screen.

Click, hold down the mouse button, and drag to select the area to
capture. Then release the mouse button.
The Preview dialog appears.
5. Verify that the image you want to select appears and then close the Preview
dialog.
The Image Synchronization dialog reappears.
6. Specify a file name for the graphic in the filename (.BMP) field.
7. Select Somewhere under ‘The synchronization is done only if the captured
area is’ in the window and then click Paste into the script.
27
The WinTask script reappears with new code that is similar to the following:
PAUSE until
Bitmap("c:\scriptsDir\bitmap.bmp")
InWindow("IEXPLORE.EXE|Internet
Explorer_Server|Customer | Company Profile Microsoft Internet Explorer|1",2)
PauseFalse
MsgBox("’Wait for’ at line " + #ErrorLine$ + "
has failed !",0 ,"Runtime error")
End
EndPause
This code indicates the image to use for comparison and the window in which the
comparison will take place. (The number after the comma is the instance of the
Internet Explorer window.) If the image does not appear, the comparison fails,
a message box appears to indicate that the correct image did not appear, and
the script stops running.
Timeout Values
When you are adding pauses, you must add timeout values to ensure that the
pauses time out if the condition that you specified does not occur within a
defined amount of time. For example, if you added a pause for a particular
window and the window does not appear, you must time out the pause so that
the script can exit.
#PauseTimeout Function – Add Timeout Values
You can use the #PauseTimeout function to stop the script if a process within
the script does not return a response within a certain amount of time. If you do
not add timeouts for the pauses, the script may be unable to execute beyond a
certain point. If that occurs, the script remains open, preventing the system
from returning to the state it must be in to run the script effectively at the next
scheduled interval.
Add the #PauseTimeout function to your script to pause for a certain amount of
time. For example, you can specify the following to time out actions that do not
return after 45 seconds:
#PauseTimeout=45
#ActionTimeout Function – Set Timeouts for a Specific Action
Use the #ActionTimeout function to specify a timeout for a specific action.
Note: If you set #IgnoreErrors to 1, the #ActionTimeout function can cause the
script to record a specific error and continue running.
28
For example, specify the following to indicate that if WinTask does not locate the
target of an action within 10 seconds, it will display an error:
#ActionTimeout=10
Error Handling
You can edit the WinTask script to set global error handling, log errors to a file,
and stop the script after errors.
Note: To display specific arguments and options for any WinTask statement,
click Languages on the WinTask tool bar. Then click the Wizard button and click
any WinTask statement.
#IgnoreErrors Function – Set Global Error Handling
WinTask provides the global variable #IgnoreErrors to set error handling. If
#IgnoreErrors is set to 0 (zero) and an error occurs, the script stops running,
generates an error pop-up window, and does not close any open applications. If
#IgnoreErrors is set to 1, the script continues running and you can test the
return code of the function that generated the error.
Note: For information about return codes, see the online Help that is available
from WinTask.
When you set the #IgnoreErrors function to 1, Service Availability can log the
application as being unavailable when an error occurs. Service Availability can
also record the error code in the Exit Code column of the Service Availability
query.
To continue the script when an error occurs, specify the following:
#IgnoreErrors=1
To stop the script when an error occurs, specify the following:
#IgnoreErrors=0
Cleanup After Errors
A good practice is to include instructions in the WinTask script to execute cleanup
tasks after errors occur so that the system returns to the state it was in before
the script began running. Without appropriate cleanup procedures, WinTask may
not be able to run the script the next time it is scheduled to do so.
Note: In particular, refer to the KillApp scripting statements in WinTask help.
These statements can go a long way to making Windows cleanup simple and
straightforward, typically requiring just a few lines of code.
29
You can call additional, subordinate scripts from a parent script and record the
processes that are running before a script executes. This approach makes it
easier to identify the processes that the script creates and to terminate them.
For examples, see Appendix A: Sample WinTask Scripts and Tips.
Error Codes
The following table lists user-specified error codes. If you are using Service
Availability, these codes display in Last Results and Last Error Codes query of
the Service Availability query.
Error Code
Description
0
Success; no errors.
1
Failed test; service unavailable.
600000–699999
Test script failed. This error type is not
used to calculate service availability.
Note: For a complete list of standard error codes generated by WinTask, see the
WinTask online Help. To see an example of how to add error handling to a
WinTask script, see Appendix Appendix A:
Create a Log File for Error Messages
When you instruct the script to log error messages to a file, you can review the
messages later to determine when and why the error occurred.
To create a log file
1. From the WinTask menu bar, select Configure, Run.
The Configure Run dialog box appears.
2. Select Log.
a.
Specify a log file name in the Name field. (The default name is the name
of the script with a .log extension.)
The log file is saved in the Logs subdirectory under the main WinTask
directory.
b.
Select Full to log all executed statements and all errors into this log file.
c.
Select Overwrite file to recreate the log file each time the script runs.
If you do not select this option, the new information is appended to the
end of the log file each time that the script runs.
30
Detailed Logging
A recommended practice when writing WinTask scripts is to use detailed logging
when debugging basic problems.
You can capture useful information in a WinTask log file, which helps determine
the conditions leading to a script failure. One reliable technique for capturing
errors is to test the return code of action statements like UseWindow and
SendKeys.
For other types of statements, such as Pause Until, it is important to capture
timeout failure conditions by using PauseFalse.
For intermittent problems, such as script failures caused by timeouts or
unexpected application pop-ups, turn on extended logging (which does not
overwrite the log file) by changing the Logfile options from
Logfile(script_name.log,1,1) to Logfile(script_name.log,1,0). For example:
Logfile(“script_name.log“,1,1)
Specifies detailed logging and overwrites the existing log.
Logfile(“script_name.log”,1,0)
Specifies detailed logging but appends to existing log.
Logfile(“script_name.log“,0,1)
Specifies logging only of Comment() commands and overwrites the existing
log.
This technique is useful if you have to generate a log file that captures script
behavior for repeated executions of the script to understand errors/failures that
occur only infrequently.
Note: Be careful when appending to an existing log file. The log can grow
without limit if you leave the option enabled.
After you create a script and before you deploy it, test it on your development
system to ensure that it is working properly. After your script development and
testing is complete, remove your old or unused scripts or logs as a standard
housekeeping practice.
To compile and then run the script
1. Open the .src file for your script in WinTask if it is not already open.
2. Click Play to compile the script.
The Compilation dialog appears.
31
3. Click Run if errors do not appear.
If errors appear, click View, and on the corresponding page, click the black
boxes next to the error message to bring the cursor to the code in question.
After you fix the errors, click Play.
Note: For more information, see the online Help available from WinTask.
Deploy the WinTask Runtime Agent and Scripts to Client
Systems
After editing and testing a WinTask script on your development system, deploy
both the WinTask runtime agent and the scripts to your client systems by using
AdvantEDGE View. WinTask is deployed to a directory called wintask in the root
directory of the boot drive on the target system.
Note: When you deploy a WinTask runtime agent to your client system,
AdvantEDGE View places the executable in the target directory that you specify
in the install.bat file. After the deployment, you must run the installer from that
directory on each client system. For instructions, see Install WinTask on
page 18.
To deploy the WinTask runtime agent and scripts
1. Make a copy of the WinTask directory on your development system,
including all subdirectories, and copy it to your eHealth system in the
following directory:
ehealth\web\aview\deploy\ntx86\wintask
ehealth
Defines the home directory for your eHealth installation.
2. Change directory to the following On the eHealth system:
ehealth\web\aview\deploy\ntx86\wintask
3. Use a text editor to create a file named release (with no extension) in this
directory.
32
Specify the version of WinTask in this file as follows:
WinTask 2.6
Note: Save this file as an unformatted ASCII text file with no extension in
the file name. Do not save it in Word or RTF format.
4. Use the text editor, in the same directory, to create another file named
installhints (also with no extension), and in that file specify the directories
you want to include in the deployment.
Explicitly name every subdirectory in your WinTask directory as follows:
dirs=wintask,wintask\subdir1,wintask\subdir1\subdira,wintask\subdir2
Note: To deploy the scripts without deploying the entire WinTask
application, copy the scripts that you want to deploy into the deployment
directory and specify only dirs=wintask\scripts (assuming that you have
saved the scripts you want to deploy in the wintask\scripts directory) in the
installhints file.
5. Save the installhints file (with no extension).
6. Open the products file, located in the ehealth\web\aview\deploy directory,
and add the following line:
wintask;WinTask Record and Playback;
Note: You must include the final semicolon shown in the example above.
7. Save the products file (with no extension).
8. Deploy the WinTask executable and any scripts that you have saved in the
WinTask\Scripts directory to the client systems as follows:
a.
Log into the Web interface of the eHealth system and select the Systems
& Apps page.
b.
Click AdvantageEDGE View.
c.
Click the Administration icon and then the Agent Deployment icon.
The Agent Deployment form appears.
d.
Complete the form by selecting the components that you want to deploy.
1.
Click Begin Search.
2.
Deselect the systems to which you do not want to deploy the
executable and scripts.
3.
Click Deploy to Selected Hosts.
Note: For more information, see the eHealth Help.
33
If you are using only Service Availability with WinTask, continue to Configure
Service Availability to Run Scripts on page 43.
Application Response provides a set of predefined, default applications and
server definitions that allow you to begin monitoring application response time
almost immediately for the following applications:

Mail

Lotus Notes®

Oracle® applications

Microsoft® Outlook®

PeopleSoft®

SAP® R/3®

Telnet

Web (including Web transactions performed through Microsoft Internet
Explorer and Netscape Navigator)
Use AR to monitor the activity of transactions generated by a script. Before AR
can monitor any application, the application must be enabled. A default
application is disabled by default. You must enable the application before you
can monitor it.
In the case of a custom application, you must create it before you can monitor
it. See Create an Application (Custom Applications Only) on page 37.
Note: If you are using Service Availability with the AR agent to run WinTask
scripts, you must edit the AR agent registry to run the ARwatch.exe process
continuously. For more information, see Enable the AR Agent to Run
Continuously on page 37.
To configure AR to monitor a default application
1. Select the System & Apps page from the eHealth Web interface.
2. Select Applications, under Application Response, in the left pane.
The Applications List page appears.
3. Select the default application to monitor.
4. Click the Enable Selected Application icon
.
5. Configure AR agents, as described in Configure the AR Agent on page 35.
6. Schedule the script to run by using one of the following:
34

Service Availability, as described in Configure Service Availability to Run
Scripts on page 43

WinTask Scheduler, as described in Schedule Scripts to Run by Using the
WinTask Scheduler on page 42
To monitor a custom application
1. Configure the agents.
2. Use the eHealth Web interface to create an application, as described in
Create an Application (Custom Applications Only) on page 37.
3. Record the script to create a rule set for the application, as described in
Record Events for Custom Applications with the AR Agent on page 38.
A rule set tells AR what transactions to monitor and how to recognize them.
4. Edit the rules with BT Studio, as described in section on page 39.
For Java or TN3270 applications, you must edit the WinTask script so that
the AR agent can identify areas for measuring response, as described in Step
4 of the procedure Modify Rules with BT Studio on page 39.
Note: For more information, see the eHealth Help for BT Studio.
5. Schedule the script to run with one of the following:

Service Availability, as described in Configure Service Availability to Run
Scripts on page 43.

WinTask Scheduler, as described in Schedule Scripts to Run by Using the
WinTask Scheduler on page 42.
Configure the AR Agent
After you deploy the AR agents, you must configure them for your eHealth
system.
To configure the AR agents
1. Open a Web browser, and make sure that it is set to update with every visit
to a page by doing the following:
a.
Select Tools, Internet Options.
The Internet Options dialog appears.
b.
Select the General tab and then click Settings under Temporary Internet
Files.
The Settings dialog appears.
c.
Select Every visit to the page and then click OK.
d.
Click OK.
The Internet Options dialog closes.
2. Log in to the eHealth Web interface for the eHealth system that is managing
the AR agents.
3. Select the System & Apps page.
4. Select Agents, under Application Response, in the left pane.
The Agent List page appears.
5. Review the list of agents.
35
Make sure that the systems to which you deployed the agents appear in the
list. If they do not appear, the agents are not yet installed on the systems.
6. select the checkbox next to the name in the list if ON does not appear in the
State column for an agent and then click the Start Selected Agents button
above the list.
After the screen refreshes, the Status column should display a green
triangle.
7. Turn transaction logging on.
a.
Select the agent names in the agent list.
b.
Click the Start Transaction Logging for Selected Agents button above the
list.
The screen refreshes and displays a checkmark for each agent in the
Transaction Logging column.
Note: You must license an agent before you can view an application’s
transactions with the Agent Transaction Viewer (ATV). If the Licensed
column does not display a checkmark for an agent, the AR agent is not
licensed. You must use the eHealth console to specify an AR Agent license.

If you are running a script for an application that Application Response
can monitor by default, enable the application as follows:
a.
Click Applications, under Application Response.
The Application List appears.
b.
Select the application that you want to monitor.
c.
Click the Enable Selected Application icon
d.
Click OK in the message box that appears.
e.
Click Refresh.
from the tool bar.
The Disabled field displays the new application status.

If you are running a script for a custom application, create and then
import the custom rules. For more information, see section on page 37,
section on page 38, and section on page 39.
9. View the agent transaction log:
a.
Select each agent name in the agent list and then click the View
Transaction Logs of Selected Agents button above the list.
b.
Click OK to launch the ATV.
The Agent Transaction Viewer window appears.
c.
Select an agent name from the Agent list and then click the Get
Transaction Data from Agent button at the top of the screen.
The screen refreshes and displays the list of transactions that have been
performed by the client.
d.
36
Repeat Step c to view the agent transaction log of each agent.
If the user is not currently using the application, transactions do not
appear.
Enable the AR Agent to Run Continuously
You must perform this procedure if you are using Service Availability to run the
scripts that the AR agent is monitoring.
If you are using Service Availability to run the scripts that the AR agent is
monitoring, you must enable the ARwatch.exe process to run continuously on
the system to collect events. ARwatch.exe starts whenever a user logs onto the
system, but it does not start when Service Availability runs a script remotely
because Service Availability does not log in as a specific user.
You can instruct ARwatch.exe to run continuously by modifying the AR agent
through the eHealth Web interface. To do so, make sure that your eHealth user
account has permission to manage AR agents. (Your user account must have the
User can manage AR agents option set to Yes.)
To enable the AR agent to run continuously
3. Select the agent name(s) in the Name column.
The Agent Properties page appears.
4. Click the Configure Agent icon
in the toolbar.
The Agent Properties – Configuration page appears.
5. Select StartWatch from the Name list under Existing Custom Settings.
6. Specify 1 in the Value field.
7. Specify exhaustive in the EventLogSetting field
Every transaction in the event log will be recorded.
8. Click Apply in the Existing Custom Settings area and then click OK.
Create an Application (Custom Applications Only)
If you are running a script for a custom application (for which the AR agent does
not provide a default application definition), you must create the application to
create a default rules file that you can later modify with BT Studio.
37
Note: You do not need to perform the steps in this section if you are monitoring
transactions for a default application. For a list of default applications, see
Configure AR to Monitor Transactions (Only for the AR Agent) on page 34. If you
are monitoring one of the default applications, proceed to the instructions for
scheduling the scripts to run. If you are using WinTask to schedule the scripts,
see Schedule Scripts to Run by Using the WinTask Scheduler on page 42. If you
are using Service Availability to run the scripts, see Configure Service Availability
to Run Scripts on page 43.
To create an application
2. Click Applications, under Application Response, in the left pane.
The Application List page appears.
3. Click the Add Application icon
.
4. Specify the application name in the Name field in the Application Properties
window.
5. Select the type of application from the Application Type list and click Next.
The Application Properties page appears.
6. Specify the executable name of the application—omitting any file
extension—in the Application Executable field under Parameter
Substitutions.
7. Click Insert and then click Apply or OK.
Record Events for Custom Applications with the AR Agent
The AR agent does not monitor a custom application (such as that automated by
a WinTask script) by default. You must write custom rules for monitoring a
custom application using BT Studio. Before writing custom rules, you must
record the events of the custom application. After you write the custom rules,
use BT Studio to upload those rules to eHealth, which then distributes them
automatically to all of the agents.
Note: If you are monitoring transactions for a default application, you do not
have to perform the following steps. For a list of default applications, see
Configure AR to Monitor Transactions (Only for the AR Agent) on page 34.
To record events and generate an event log file
1. Exit all open applications on the development system.
The AR agent records everything that is happening on the system. Closing
other applications helps ensure that the event log file does not contain
extraneous information.
2. Log into the eHealth Web interface from your development system and then
select the System & Apps page.
38
4. Click the agent that will run the script in the Name column.
5. Click the Record button
.
6. On the development system, run the .rob file for the script that you want to
record by double-clicking it, and then run it at least one more time to create
the Events.btl file, which BT Studio uses.
7. Click the Stop Recording button
.
8. Log out of the eHealth Web interface.
9. Navigate to the drive:\ehealth\agent\response\Events.btl file and verify that
the date and time match the time that you ran the script.
10. Use BT Studio to modify the default rule set.
Modify Rules with BT Studio
After you create an event log file, use BT studio to create or modify rules that
you can upload to the eHealth system for the application. When you do so and
WinTask runs the scripts, the AR agent begins to collect data for the
transactions.
Note: For more information about using BT Studio, see the eHealth Help.
To modify rules
1. Start BT Studio by selecting Start, Programs, BT Studio.
2. Select File, Open, select the Events.btl file that you just created, and click
Open.
The file appears in the events pane of BT Studio.
3. Download rules from the eHealth system as follows:
a.
Select Tools, Download Rules.
The eHealth System Connection Parameters dialog appears.
b.
Specify the eHealth server name in the eHealth System Hostname field
and the user name and password in the eHealth Administrator and
Password fields.
c.
Click Connect.
The Select an Application to Download from the eHealth System dialog
appears.
d.
Select the application that you created in Create an Application (Custom
Applications Only) on page 37 and then click OK.
e.
Click OK.
The rule is displayed.
39
4. (Optional) Perform the following steps if you are monitoring a Java or
TN3270 application:
a.
Open the .src file in WinTask and add lines at the point in the script
where you want to measure response time to specify a message frame
or message box for which the AR agent can search.
For example, add lines similar to the following and substitute the correct
URL for your specific Web page:
MsgFrameTitle("Transaction1 Start", "www.customer.com", 1)
Pause 3 secs
RemoveFrame(1)
b.
Add lines similar to the following at the point in the WinTask script (.src
file) where you want to stop measuring response:
MsgFrameTitle("Transaction2 End", "www.customer.com", 1)
RemoveFrame(1)
c.
Add the following line to the required section of the resource definition
in the BT Studio rule set:
resource Process {ExecutableName=”TASKEXEC”}
This line ensures that the AR agent can recognize the create and destroy
events of the MsgFrameTitle syntax that you added.
d.
Edit the transaction definition of the rule set as follows:
u
Specify a unique name in the transaction field and the same name
in the module field.
u
Locate the event ““ Windows Destroy {Title=““} field and specify the
window title that you used in the first MsgFrameTitle syntax in the
WinTask script between both sets of quotation marks.
For example, specify event “PageLoadStart“ Windows Destroy
{Title=“PageLoadStart“}.
u
Locate the event ““ Windows SetTitle {Title=““} field and specify the
window title that you used in the second MsgFrameTitle syntax in the
WinTask script between both sets of quotation marks.
For example, specify event “PageLoadEnd“ Windows SetTitle
{Title=“PageLoadEnd“}.
For example, you could specify lines similar to the following:
transaction "CheckCustmrURL"
module "CheckCustmrURL"
{
event "PageLoadStart" Windows Destroy
{Title="PageLoadStart"}
event "PageLoadEnd"
Windows SetTitle
{Title="PageLoadEnd"}
}
5. Test the rule, after modifying it, against the Events.btl file to verify that it is
correct.
40
When you are running this file, the client, network, and server times appear
in the results pane.
To play the Events.btl file:
a.
Click the right-arrow button.
b.
Click OK when the simulation is complete.
If the simulation is not successful, do the following:

Verify that the BT Studio syntax is correct.

Verify that the titles of the MsgFrameTitle windows match the names
that you used in the event and Title BT Studio syntax.

Verify that the modified syntax for the resources exists in the Events.btl
file.
6. Upload the rules to the eHealth server as follows if the simulation is
successful:
a.
Select Tools, Upload Rules.
The eHealth System Connection Parameters dialog appears.
b.
Specify the eHealth server name in the eHealth System Hostname field
and the user name and password in the eHealth Administrator and
Password fields.
c.
Click Connect.
BT Studio uploads the configuration and displays a status message.
d.
Click OK.
7. Select File, Exit to exit BT Studio.
8. Deploy the updated WinTask script to your client system, as described in
Deploy the WinTask Runtime Agent and Scripts to Client Systems on
page 32.
9. Schedule the script to run locally with the WinTask Scheduler or with Service
Availability.
10. Use eHealth to run reports on the data that you are collecting.
More information:
How to Organize Response Elements for Reporting on page 50
eHealth Reports That You Can Run on page 50
You can schedule the scripts to run with either of the following:

WinTask Scheduler

41
Schedule Scripts to Run by Using the WinTask Scheduler
After you create, edit, and deploy your WinTask scripts, you can schedule them
to run from the local client system if you have installed the full WinTask
recording agent (not the runtime agent alone) on your client system.
Note: If you want to manage the scheduling of your scripts from a central
console, you must use Service Availability instead of the WinTask Scheduler to
schedule them. For more information, see Configure Service Availability to Run
Scripts on page 43.
To schedule scripts to run by using the WinTask scheduler
1. Start the scheduler on the client system where you want to run the test by
selecting Start, Programs, WinTask, Scheduler.
The WinTask Scheduler dialog appears.
2. Verify that the scheduler service (WTScheduler) has started.
A green traffic light
running.
next to Service Status indicates that the service is
If a red traffic light appears, start the service as follows:
a.
Click Services Control Panel,
b.
Right-click WTScheduler and click Start.
The Task Properties dialog, shown in the following graphic, appears.
3. Click New Task.
4. Specify a name for the task in the Task name field.
5. Select Browse next to the Command line field, navigate to the WinTask script
to run, and click Open.
42
6. Click the Schedule tab and select the frequency with which you want to run
the test in the Frequency area.
You can specify any of the following:

Once

Repeat every x d x h x mn x s

Repeat every x month(s)

At every reboot
7. Locate the Time and Date fields under Starting and specify a time and date
to start running the script.
8. (Optional) Specify times that you do not want the script to run under
Exclusions.
9. Click OK to schedule the script to run.
Configure Service Availability to Run Scripts
Service Availability can run WinTask scripts from a centralized management
console. It can also provide response and availability measurements about the
transactions that the script is executing.
Service Availability is a multi-threaded application. When you are running
multiple scripts on one system, you must configure the maximum number of
threads to 1 so that the module runs each script in turn rather than attempting
to run them in parallel. A WinTask script takes over the workstation screen.
Running multiple scripts concurrently on the same system creates a conflict.
The SA installation Install Shield prompts for the number of threads to use. The
default is 10. Similarly, the SA installation Install Shield default is not to allow
custom tests.
Before you schedule the tests, make sure that the Service Availability modules
on your client systems are configured to run custom tests and to execute only
one thread at a time. Also, verify that your SystemEDGE service is configured to
interact with the desktop, as described in Enable the SystemEDGE Service to
Interact with the Desktop on page 44.
To configure Service Availability
1. Use a text editor, on the client systems on which you want to run the scripts,
to open the svcrsp.cf file (located in the drive:\sysedge\plugins\svcrsp
directory).
2. Configure the maximum number of threads to 1, if you are running multiple
scripts on one system, so that the module runs each script in turn and does
not try to run more than one script at a time.
43
Add the following lines in the global block, near the beginning of the file.
Make sure that the lines are not formatted as comments.
allow_scripts
maxthreads=1
3. Save and close the svcrsp.cf file.
4. Restart the SystemEDGE agent by opening the SystemEDGE control panel
and clicking Stop and then Start.
Enable the SystemEDGE Service to Interact with the Desktop
Before you can run a Service Availability Virtual User test, you must modify the
SystemEDGE properties to enable it to interact with the desktop.
To enable the SystemEDGE Service to interact with the desktop
1. Open the Services Control Panel.
2. Right-click SystemEDGE Service and select Properties.
3. Select the Log On tab.
4. Select ‘Allow service to interact with desktop’ under Local System Account.
5. Click Restart
6. Click OK.
Create a Virtual User Test to Schedule WinTask Scripts
You can create Virtual User tests for all of your development and client systems
from your eHealth system. Create the tests by using options under the Systems
& Apps page of the eHealth Web interface. For more information, see Create a
Virtual User Test to Schedule WinTask Scripts on page 44.
Before you create Virtual User tests, make sure that the systems from which you
want to create the tests exist in the eHealth poller configuration. If they do not
appear in the System list on the Systems & Apps page or in the Available
Elements list on the Run Reports page, they do not exist in the poller
configuration. In this case, run the discover process and then save them in the
poller configuration.
Note: For more information about running the discover process for response
elements, see the eHealth Response Administration Guide.
To create a Virtual User test with AdvantEDGE View
2. Select Tests under Service Availability in the left pane.
The Test Management page appears.
3. Click Add.
The Create a new Test page appears.
44
4. Select Virtual User from the list Test Type.
5. Specify the path to taskexec.exe (drive:\exec.exe) in the Test Name field
and name of the WinTask robotic file (drive:\scriptname.rob) as follows:
C:\taskexec.exe C:\pingtest.rob
6. Specify a Test Interval value (in seconds) and a Test Timeout value (in
seconds).
Specify the interval between tests in the Test Interval field. The interval that
you select must be greater than the amount of time that the script requires
to execute.
Note: If you are running multiple tests on the same system, select intervals
and timeout values that enable each test to complete before the next test is
scheduled to begin running.
7. (Optional) Specify a hostname and port in the Target field.
Note: If you specify a hostname and port, Service Availability looks up the
specified system and attempts to connect to the specified port. If the
connections are successful, it attempts to execute the script (which works
on the specified port on the specified system). If you do not specify a
hostname and port, Service Availability does not provide the DNS name
resolution or connect times.
8. (Optional) Specify a Run as User and specify (and verify) a password.
9. Click Save.
The test profile is saved.
10. Click Commit Changes in the left panel.
The changes to the SA agent(s) are committed.
11. Click Tests & Profiles.
45
12. Associate a test profile with an SA agent so you can monitor the test.
a.
Click Test Profiles in the left panel under Service Availability.
b.
Provide, minimally, the name of the agent and click Save.
Note: If you have not discovered your systems yet, agents will not appear in the
Test Profiles.
Advanced options for creating a Virtual User test are as follows:

Specify 1 in the Samples Per Interval field.

In the Statistics Window field, specify the time (in seconds) over which
Service Availability calculates the response time statistics for this test. Set
this value to be greater than the interval and a multiple of the interval. For
example, if you are running the scripts at 30-second intervals, you can set
this value to 120 seconds.

You can modify test settings by clicking Modify in the Index column for the
test that you want to modify. After completing the Modify form, click
Commit.
After the scripts run a few times, run Service Availability and monitor the
response times, availability, and configuration details for the scripts that you are
running.
Monitor Log Files with SystemEDGE (Optional)
You can use the SystemEDGE agent to monitor the log files that your WinTask
application is creating. For example, if the logs are recording error conditions,
you may want to monitor them for a specific error message. The SystemEDGE
agent can then send a trap to the eHealth system whenever that message
appears in a log file.
To monitor log files
1. View the Log Monitor table as follows:
a.
Select AdvantageEDGE View from the Systems & Apps page of the
eHealth Web interface and then select the target system from the
System or Group list.
b.
Select Logfile Monitoring from the Configuration list.
c.
Click the Configuration icon
.
2. Create an entry to monitor log files by clicking Add Log Monitor Entry from
the Log Monitor table and then complete the form as follows:
46
a.
Specify a unused row number in the Index field.
b.
Specify a description of the entry you are creating in the Description
field.
c.
Specify the full pathname to the ASCII log file to monitor in the Logfile
field.
For example, specify Customer.log.
d.
Specify the regular expression on which to match in the Regular
Expression field.
For example, specify Failure – Text Not Found.
e.
(Optional) Locate the Action field and specify the full pathname to an
action script or program that you want SystemEDGE to execute when it
finds a matching log entry.
For example, you can specify a script that can e-mail you when the agent
matches the specified regular expression.
f.
(Optional) Select any behaviors that you want the SystemEDGE agent
to follow in the Flags field.
3. Click Create.
A new entry is created.
The SystemEDGE agent monitors the log that you specified for the regular
expression that you specified.
47
Chapter 4: Using eHealth for Monitoring
and Reporting
eHealth lets you produce real-time and historical reports for the data that you
collect with Application Response and Service Availability. Before you can
produce reports, your eHealth system must be configured as described in
eHealth System Configuration Prerequisites on page 17.

View Service Availability Queries

How to Organize Response Elements for Reporting

eHealth Reports That You Can Run

How to Begin Using Live Health
View Service Availability Queries
When an AR agent collects data on response elements, it creates response paths
and adds them to the poller configuration. You can view the paths in the Poller
Configuration dialog. You can also obtain real-time data on your Service
Availability tests by running Service Availability queries from the System & Apps
tab of the eHealth Web interface.
To view a Service Availability query
1.
Select the System & Apps tab from the eHealth Web interface.
2.
Click AdvantageEDGE View in the left pane.
The Queries list identifies the spectrum of queries available.
3.
Click the Help button for details.
Using eHealth for Monitoring and Reporting
49
Before you run reports on response elements, you may also want to organize
your response elements for reporting as follows:

Create response groups and group lists.

Set response limits.

Create any service profiles that you want to use.
Note: For more information, see the eHealth Response Administration Guide
and the eHealth Administration Guide.
You can run eHealth reports from the Run Reports page of the eHealth Web
interface. You can run any of the following reports to display data about your
response paths:

At-a-Glance

Top N

Trend

Health:

–
–
Service Response
Service Level:
–
AR-Service Delivery
–
AR-Service Performance
–
AR-Service Summary
–
Executive
–
Business Unit
–
Service Customer
Note: For detailed information about these reports and how to run them, see
the eHealth Help available from Run Reports page of the eHealth Web interface.
Data Collected by WinTask Scripts
When you run reports on data that the AR agent and Service Availability have
collected for WinTask scripts, you obtain more robust data than you would obtain
from monitoring actual user transactions.
The following graphic shows two sample At-a-Glance reports.
50
AR Agent Monitoring User Transactions
AR Agent Monitoring WinTask Transactions
The AR agent alone captures
data only when a user is
performing transactions, leaving
gaps in the data when a user is
not actively using the application.
With WinTask, the
transactions run continuously, as
shown in the charts on the right.
If gaps appear in the data, they may
indicate that a problem with the
network, client, or server is
preventing the transaction from
running. You can use the
continuous data that is
produced by the WinTask
script to observe peaks and dips in
the data that occur even during
times when a user was not actively
performing a transaction.
The report on the left shows actual user data that the AR agent collected for
users who were logging into the Remedy application.
The report on the right shows data that the AR agent collected for a WinTask
script that was running the login transaction continuously.
51
The actual user data includes gaps at times when users were not logging in to
Remedy. The data that was generated from a WinTask provides an ongoing view
of how the transaction performs throughout the day—even when users are not
performing the transaction.
Trend Data Obtained by Drilling Down for More Detail
To obtain more information about one of these charts, click on it to view a Trend
report. For example, if you click on the Average Response chart in the
At-a-Glance report for Application Response (see the previous graphic), you
obtain a trend report that displays average client, network, and server time for
the report period, as shown in the following graphic.
52
Response and Availability Data in At-a-Glance Reports
When you run an At-a-Glance report for a Service Availability response path,
eHealth provides data on both response and availability, as shown in the
following graphic.
The gap in the Service
Availability chart indicates
that the service was
unavailable between 4:30
and 5:00 A.M.This
downtime accounts for the
failed attempts and lack of
response data during that
time.
53
Performance Summaries in Health Reports
You can run a Health report to evaluate the performance of a group of elements
based on response time, failed attempts, and service availability. eHealth
provides Health reports for Application Response and for Service Availability. On
both, you can use the Response Path Summary Reports to determine which
paths in a selected group have the worst performance.
Note: For more information about running Health reports, see the eHealth Help
available from the Run Reports tab of the eHealth Web interface.
The following graphic shows a sample Health report for Service Availability. The
Poorest Performing Paths chart shows that all of the monitored paths exceed the
response limit by a significant amount. Both the Poorest Performing Paths chart
and the Response Breakdown chart indicate that the transaction time accounted
for the significant delay in response.
54
If you are using Live Health, you can create groups of response paths for
WinTask scripts and then associate them with profiles to monitor them for
service thresholds.
Before you begin using Live Health to monitor your WinTask scripts, complete
the following tasks:
1. Use the eHealth console to discover the client systems for which you want
to obtain real-time data and receive alarms.
Note: The AR agent response path elements are created automatically as
transactions occur.
2. Configure the client systems where you are running your WinTask scripts to
send traps to your eHealth system.
3. Create groups that include the response paths for your WinTask scripts.
4. Confirm that you have permission to use Live Health.
Contact your eHealth Web administrator if you do not.
5. Install the Live Health client software (if it is not already installed) on a
system from which you want to view the data.
You can do so from your eHealth system or any other system.
6. Start the Live Exceptions Browser.
7. Create associations between your WinTask groups and the default profiles
for monitoring response paths.
For example, you can associate the following profiles with your response
groups:

Response - Delay

Response SLA

Response Test - Failure
These profiles include rules that monitor variables such as Average
Response Time, Average DNS Lookup Time, Average TCP Connect Time,
Average Transaction Time, Minimum and Maximum Response, and Failed
Attempts. If eHealth observes that the variables have exceeded the defined
thresholds, Live Health raises an alarm, as shown in the following graphic.
55
8. (Optional) Modify the Live Exceptions alarm rules to make the alarms more
meaningful for your environment.
9. (Optional) Create Notifier rules to send notifications in the form of traps,
e-mail, and commands when specific events occur.
10. Use the Live Status display to view alarms (as shown in the following
graphic) and drill down to more information about the alarms.
Note: For more information about completing these tasks, see the eHealth Help
for Live Health.
56
Appendix A: Sample WinTask Scripts
and Tips
This appendix provides sample WinTask scripts and contains the following
topics:

Scripts That Identify and Terminate Processes for Error Cleanup

Sample Script for Error Handling
Scripts That Identify and Terminate Processes for Error
Cleanup
This section includes the following:

Two scripts (init_kill_process.src and kill_process.src) that identify and then
terminate running processes

A parent script that calls the other two scripts.
Save all three scripts in the same directory (for example, C:\WinTask\Scripts).
Sample WinTask Scripts and Tips
57
init_kill_process.src – Identify Running Processes Before the WinTask Script
Executes
The init_kill_process.src script identifies the processes that are running before
the WinTask script begins to execute. Call this script at the beginning of a parent
script that requires error handling.
Dim name_proc$(100)
Dim pid(100)
Dim times(100)
Dim memory(100)
'-----------------------------------------------------------------Sub recup_processes_list()
local nb, i
if exist(File_process_init$) then
kill(File_process_init$)
endif
nb=GetProcessList(name_proc$(),pid(),times(),memory(), 1 )
write(File_process_init$,str$(nb),crlf)
i=0
repeat
write(File_process_init$, name_proc$(i)+"@@@@@@@@@@"+str$(pid(i)),crlf)
i=i+1
until i=nb
EndSub
'--------------------------------------------------------------------'Write in the file specified in file_process_init$ the list of processes at the time this
script is running.
File_process_init$="c:\proces_init.txt"
recup_processes_list()
58
kill_process.src – Terminate Processes Initiated by the Script
The kill_process.src script terminates the processes that have appeared since the
WinTask script began executing. The parent script calls kill_process.src only
when it detects a failure on a particular action. It calls the script from a generic
error handler, proc_error(). For more information about proc_error(), see
proc_error() function – Provide Error Output to an Error Log and Service
Availability on page 61.
Dim name_proc$(1000)
Dim pid(1000)
Dim times(1000)
Dim memory(1000)
Dim name_proc_ini$(1000)
Dim pid_ini(1000)
'-----------------------------------------------------------------Function recup_file_processes_list()
local nb, i, buffer$, pos, lg
if exist(File_process_init$) then
read(File_process_init$,buffer$,crlf)
nb=val(buffer$)
i=0
repeat
read(File_process_init$,buffer$,crlf)
pos=instr(buffer$, "@@@@@@@@@@")
lg=len(buffer$)
name_proc_ini$(i)=left$(buffer$,pos-1)
pid_ini(i)=val(right$(buffer$,lg-pos-9))
'msgbox("Process : "+name_proc_ini$(i)+"\n\Pid : "+str$(pid_ini(i)))
i=i+1
until i=nb
else
nb=0
endif
recup_file_processes_list=nb
endfunction
'-----------------------------------------------------------------sub kill_new_process()
local ini_process, act_process, process_find
act_process=0
repeat
59
ini_process=0
process_find=0
repeat
if name_proc$(act_process)=name_proc_ini$(ini_process) and
pid(act_process)=pid_ini(ini_process) then
process_find=1
else
ini_process=ini_process+1
endif
until process_find=1 or ini_process=nb_process_ini
if process_find=0 then
if name_proc$(act_process)<>"TaskExec.exe" and
name_proc$(act_process)<>"TaskLock.exe" and name_proc$(act_process)<>"TaskSync.exe" then
killprocess(pid(act_process),1)
"+str$(pid(act_process)))
'msgbox("kill process : "+name_proc$(act_process)+"\n\Pid :
endif
endif
act_process=act_process+1
until act_process=nb_process_act
endSub
'-----------------------------------------------------------------'FILENAME where the list of processes has been stored.
File_process_init$="c:\proces_init.txt"
'-----------------------------------------------------------------nb_process_ini=recup_file_processes_list()
if nb_process_ini > 1 then
'msgbox("Process ini : "+str$(nb_process_ini))
nb_process_act=GetProcessList(name_proc$(),pid(),times(),memory(), 1 )
'msgbox("Process act : "+str$(nb_process_act))
kill_new_process()
endif
60
proc_error() function – Provide Error Output to an Error Log and Service Availability
You can use the proc_error() function as follows to send output to an error log
and to provide correct handling of error codes for Service Availability:
Sub proc_error()
Comment(#ErrorFunction$ + " Error on Line " + #LastErrorLine$)
MsgFrame(#ErrorFunction$ + " Error on Line " + #LastErrorLine$,1)
Pause 1 Secs
RemoveFrame(1)
Run("kill_process")
End(2)
EndSub
This example does the following:

The Comment line sends error output to an error log.

MsgFrame/RemoveFrame provides a pop-up window (for usability
purposes).

End(2) returns a non-zero error code that Service Availability detects as a
failed test, which enables proper handling of the Availability statistics.
61
This script provides an example of how to add error handling to your scripts. It
calls the init_kill_process.src and kill_process.src scripts.
#ActionTimeout=10
#PauseTimeout=10
The parent script calls
the kill_process script.
#ScriptAfterTimeout$="kill_process"
LogFile("c:\WinTask\Logs\history.log",1,1)
'---------------------------------------------------------------------' Global Error Management
'---------------------------------------------------------------------OnAction Error
The proc_error function can
send output to an error log or to
Service Availability.
DoSub proc_error
EndAction
'---------------------------------------------------------------------' Main Program
'---------------------------------------------------------------------'Before performing the tasks inside the script,
'run the script that stores the list of processes
'that are already running.
Run("init_kill_process")
The parent script calls the
init_kill_process script.
UseWindow("EXPLORER.EXE|Shell_TrayWnd",1)
Click(Button,"Start")
ChooseMenu(Context,"&Programs|Microsoft Office|Microsoft Office Outlook 2003")
'Ret=ExistW("OUTLOOK.EXE|#32770|Microsoft Office Outlook",1)
'If Ret = 0 Then
'
Comment("Outlook failed to start correctly last time")
'
UseWindow("OUTLOOK.EXE|#32770|Microsoft Office Outlook",1)
'
Click(Button,"&No")
'EndIf
UseWindow("OUTLOOK.EXE|REComboBox20W|Choose Profile|1",1)
SendKeys("Calendar-be1 Profile<Enter>")
If ExistW("OUTLOOK.EXE|#32770|Connecting To Microsoft Exchange Server",1) Then
Comment("Microsoft Exchange Server Not Available")
Server",1)
UseWindow("OUTLOOK.EXE|#32770|Connecting To Microsoft Exchange
Click(Button,"Cancel")
End(2)
62
EndIf
UseWindow("OUTLOOK.EXE|Edit|Microsoft Office Outlook - Enter Password|2",1, NoActivate)
SendKeys("<Shift <Tab>>")
SendKeys("basam<Tab>")
SendKeys("basam1204<Enter>")
Pause until
WinStatus(Active)
InWindow("OUTLOOK.EXE|rctrl_renwnd32|Inbox - Microsoft Outlook",1)
PauseFalse
proc_error()
EndPause
If the window takes longer than the
specified time to load, the script
calls proc_error().
Pause 5
UseWindow("OUTLOOK.EXE|SUPERGRID|Table View",1)
SendKeys("<Alt <F4>>")
End
63
Index
Symbols
#ActionTimeout variable • 28
creating
application • 37
Virtual User test • 44
#IgnoreErrors variable • 29
custom applications, monitoring • 35
#PauseTimeout variable • 28
A
adding
error handling • 29
pauses • 25
creating an application • 37
creating response paths • 49
default applications • 34
modifying rules with BT Studio • 39
monitoring
custom applications • 35
default applications • 34
Java and TN3270 applications • 40
recording events • 38
applications, default • 34
D
default applications
Application Response • 34
monitoring • 34
deploying WinTask and scripts • 32
E
editing the WinTask script
adding pauses • 25
overview • 24
synchronization • 24
eHealth reports
Health • 54
overview • 50
AR agent, starting • 35
eHealth system • 17
configuring • 17
description • 12
B
eHealth Web interface, permissions • 17
BT Studio • 39
C
error codes • 30
error handling
adding to WinTask script • 29
identifying processes • 58
Service Availability example • 61
terminating processes initiated by the script •
59
cleanup
identifying processes • 58
terminating processes initiated by the script •
59
error messages, logging • 30
client system • 12
event log file • 39
components
WinTask • 5
WinTask, AR agent, and Service Availability
environment • 16
Events.btl file • 39
configuring
environment • 11
Service Availability • 43
getting started • 12
G
Index
65
I
enabling custom scripts to run • 43
modifying SNMP properties • 44
scheduling scripts to execute • 43
setting maxthreads=1 • 43
image synchronization • 26
installing WinTask • 17
setting up systems • 15
J
SNMP service, interacting with desktop • 44
Java applications, monitoring • 40
software required • 11
starting AR agent • 35
L
SystemEDGE agent, monitoring log files • 46
Live Health
response profiles • 55
using to monitor WinTask scripts • 55
logging error messages • 30
T
text synchronization • 26
TN3270 applications, monitoring • 40
M
modifying
AR agent rules • 39
SNMP properties • 44
monitoring
Java applications • 40
TN3270 applications • 40
P
pausing • 25
R
recording a transaction with WinTask • 21
recording events with AR agent • 38
required software • 11
response paths
running the script • 31
S
V
Virtual User test
creating • 44
W
WinTask
adding error handling • 29
adding pauses to script • 25
comparing images • 26
comparing text • 26
components • 5
deploying • 32
editing the script • 24
error codes • 30
installing • 17
logging error messages • 30
overview • 5
recording a business transaction • 21
running the script • 31
Scheduler • 42
workflow • 12
scheduling scripts to execute
Service Availability • 43
WinTask Scheduler • 42
configuring • 43
creating Virtual User test • 44
66