CA ehealth. Using WinTask with Application Response and Service Availability. r6.1

Transcription

1 CA ehealth Using WinTask with Application Response and Service Availability r6.1

2 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 , , and (c)(1) - (2) and DFARS Section (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.

3 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 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 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 Contents 3

4 Enable the SystemEDGE Service to Interact with the Desktop Create a Virtual User Test to Schedule WinTask Scripts Monitor Log Files with SystemEDGE (Optional) 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 Appendix A: Sample WinTask Scripts and Tips 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 Index 4 Using WinTask with Application Response and Service Availability

5 Chapter 1: Introducing WinTask This chapter contains the following topics: 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 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

6 WinTask Used with Application Response 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 WinTask Used with Application Response 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 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 Using WinTask with Application Response and Service Availability

7 WinTask Used with Service Availability 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. WinTask Used with Service Availability 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

8 WinTask Used with Application Response and Service Availability 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 Using WinTask with Application Response and Service Availability

9 Prerequisites for Using WinTask Prerequisites for Using WinTask 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

10

11 Chapter 2: Configuring Your Environment This chapter contains the following topics: 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

12 How to Get Started: Workflow 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 How to Get Started: Workflow 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 Using WinTask with Application Response and Service Availability

13 How to Get Started: Workflow Step Graphical Description 1. Configure the development, client, and ehealth systems. ehealth System: ehealth 6.0 For more information, see How to Set Up Your Systems on page 15 and ehealth System Configuration Prerequisites on page 17. Client System: AR agent SystemEDGE agent Service Availability WinTask runtime agent Development System: AR agent BT Studio SystemEDGE agent Service Availability WinTask recording agent 2. Record a business transaction with WinTask. For more information, see Record a Business Transaction with WinTask on page 21. Development System 3. Edit the WinTask script. For more information, see Script Editing Functions on page 24. Development System 4. Deploy the WinTask scripts to your client systems from the Systems & Apps tab of the ehealth Web interface. For more information, see Deploy the WinTask Runtime Agent and Scripts to Client Systems on page 32. ehealth System Client Systems Configuring Your Environment 13

14 How to Get Started: Workflow Step Graphical Description 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: The WinTask Scheduler; for more information, refer to Schedule Scripts to Run by Using the WinTask Scheduler on page 42. Service Availability Virtual User tests; for more information, see Configure Service Availability to Run Scripts on page 43. Client System: WinTask Scheduler ehealth System: Service Availability 14 Using WinTask with Application Response and Service Availability

15 How to Set Up Your Systems Step 7. Run At-a-Glance, Trend, Top N, myhealth, Health, and Service Level reports for the tests. For more information, see How to Organize Response Elements for Reporting on page 50 and ehealth Reports That You Can Run on page (Optional) Use Live Health to associate Live Exceptions profiles with the tests and view data in the Live Exceptions Browser and Live Status. Graphical Description 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. For more information, see How to Begin Using Live Health on page 55. How to Set Up Your Systems 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. Configuring Your Environment 15

16 How to Set Up Your Systems 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) Application Response ehealth BT Studio Administration Guide SystemEDGE agent Service Availability ehealth SystemEDGE User Guide Service Availability Service Availability Service Availability in the ehealth Help Live Health (optional) The application to monitor Application Response or Service Availability WinTask, Application Response, and/or Service Availability Live Health in the ehealth Help 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 Using WinTask with Application Response and Service Availability

17 ehealth System Configuration Prerequisites 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. ehealth System Configuration Prerequisites 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. Configuring Your Environment 17

18 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 Using WinTask with Application Response and Service Availability

19 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 Configuring Your Environment 19

20

21 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. This chapter contains the following topics: 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 Record a Business Transaction with WinTask 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

22 Record a Business Transaction with WinTask 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 Using WinTask with Application Response and Service Availability

23 Record a Business Transaction with WinTask 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. Recording and Monitoring Scripts 23

24 Script Editing Functions Script Editing Functions 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 Using WinTask with Application Response and Service Availability

25 Script Editing Functions 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. 2. Do one of the following: Specify the following, where n represents the number of seconds to wait: Pause n Recording and Monitoring Scripts 25

26 Script Editing Functions 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. 3. Do one of the following: 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 Using WinTask with Application Response and Service Availability

27 Script Editing Functions 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. Recording and Monitoring Scripts 27

28 Script Editing Functions 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") EndPause End 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 Using WinTask with Application Response and Service Availability

29 Script Editing Functions 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. Recording and Monitoring Scripts 29

30 Script Editing Functions 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 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 Using WinTask with Application Response and Service Availability

31 Compile and Run the Script 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. Compile and Run the Script 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. Recording and Monitoring Scripts 31

32 Deploy the WinTask Runtime Agent and Scripts to Client Systems 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 Using WinTask with Application Response and Service Availability

33 Deploy the WinTask Runtime Agent and Scripts to Client Systems 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. Recording and Monitoring Scripts 33

34 Configure AR to Monitor Transactions (Only for the AR Agent) Configure AR to Monitor Transactions (Only for the AR Agent) 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 Schedule the script to run by using 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 Using WinTask with Application Response and Service Availability

35 Configure AR to Monitor Transactions (Only for the AR Agent) 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 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. Recording and Monitoring Scripts 35

36 Configure AR to Monitor Transactions (Only for the AR Agent) 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. 8. Do one of the following: 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 from the tool bar. d. Click OK in the message box that appears. e. Click Refresh. 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 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. Repeat Step c to view the agent transaction log of each agent. 36 Using WinTask with Application Response and Service Availability

37 Configure AR to Monitor Transactions (Only for the AR 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 1. Select the System & Apps page from the ehealth Web interface. 2. Select Agents, under Application Response, in the left pane. The Agent List page appears. 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. Recording and Monitoring Scripts 37

38 Configure AR to Monitor Transactions (Only for the AR Agent) 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 1. Select the System & Apps page from the ehealth Web interface. 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. 3. Select Agents, under Application Response, in the left pane. 38 Using WinTask with Application Response and Service Availability

39 Configure AR to Monitor Transactions (Only for the AR Agent) The Agent List page appears. 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. Recording and Monitoring Scripts 39

40 Configure AR to Monitor Transactions (Only for the AR Agent) 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", " 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", " 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 u u Specify a unique name in the transaction field and the same name in the module field. 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 }. 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 Using WinTask with Application Response and Service Availability

41 Options for Scheduling the Scripts to Run 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 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 Options for Scheduling the Scripts to Run You can schedule the scripts to run with either of the following: WinTask Scheduler Service Availability Recording and Monitoring Scripts 41

42 Options for Scheduling the Scripts to Run 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 next to Service Status indicates that the service is running. 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 Using WinTask with Application Response and Service Availability

43 Options for Scheduling the Scripts to Run 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. Recording and Monitoring Scripts 43

44 Options for Scheduling the Scripts to Run 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 1. Select the System & Apps page from the ehealth Web interface. 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 Using WinTask with Application Response and Service Availability

45 Options for Scheduling the Scripts to Run 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. Recording and Monitoring Scripts 45

46 Options for Scheduling the Scripts to Run 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: 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. 46 Using WinTask with Application Response and Service Availability

47 Options for Scheduling the Scripts to Run 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 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. Recording and Monitoring Scripts 47

48

49 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. This chapter contains the following topics: 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

50 How to Organize Response Elements for Reporting How to Organize Response Elements for Reporting 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. ehealth Reports That You Can Run 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: Application Response 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 Using WinTask with Application Response and Service Availability

51 ehealth Reports That You Can Run 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. Using ehealth for Monitoring and Reporting 51

52 ehealth Reports That You Can Run 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 Using WinTask with Application Response and Service Availability

53 ehealth Reports That You Can Run 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. Using ehealth for Monitoring and Reporting 53

54 ehealth Reports That You Can Run 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 Using WinTask with Application Response and Service Availability

55 How to Begin Using Live Health How to Begin Using Live Health 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. Using ehealth for Monitoring and Reporting 55

56 How to Begin Using Live Health 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, , 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 Using WinTask with Application Response and Service Availability