Understanding JD Edwards Virtual Autopilot Components

This chapter discusses:

• Virtual Autopilot components.

• Virtual Autopilot Script Editor.

• Virtual Script Player.

• VSMEditor.

• JD Edwards Virtual Runner.

Virtual Autopilot Components

To create virtual scripts, Oracle's JD Edwards EnterpriseOne Virtual Autopilot uses external JD Edwards Autopilot components that capture, record, and store data generated by a JD Edwards Autopilot playback session.

You use these JD Edwards Autopilot components with the internal components of JD Edwards Virtual Autopilot to complete the JD Edwards Virtual Autopilot scripting process. The JD Edwards Virtual Autopilot components are:

• Virtual Autopilot Script Editor

• Virtual Script Player

• VSMEditor

• JD Edwards Virtual Runner

To create a JD Edwards Virtual Autopilot script, you use the internal components of JD Edwards Virtual Autopilot to complete these tasks:

• Import an event stream into the Virtual Autopilot Script Editor

• Modify the event stream by adding rules that govern the passing of parameters

• Use the Virtual Autopilot Script Editor to automatically add rules to handle thread identification and hRequest handles

• Generate a JD Edwards Virtual Autopilot script

• Run a JD Edwards Virtual Autopilot script on the Virtual Script Player

• Use the VSMEditor to concatenate a series of individual JD Edwards Virtual Autopilot scripts into one master script

• Use JD Edwards Virtual Runner to manage script playback, either from a single workstation or from multiple workstations

  You also can manage script playback using LoadRunner from Mercury Interactive.

Virtual Autopilot Script Editor

This section discusses:

• Virtual Autopilot Script Editor features.

• Event pane.

• Event graph.

• Parameter detail pane.

• Script list pane.

• Parameter value linking.

• Source and target parameter identification.

• Manual parameter linking.

• HRequest handle value linking.

• Thread identification.

• Timing interval maintenance.

• JD Edwards Virtual Autopilot script generation.

Virtual Autopilot Script Editor Features

The Virtual Autopilot Script Editor enables you to create and generate a JD Edwards Virtual Autopilot script that you can use to simulate the activity of many concurrent users. Working with the Virtual Autopilot Script Editor represents the second step in a three-step process of producing a JD Edwards Virtual Autopilot script playback session. You create a JD Edwards Virtual Autopilot script playback session by completing these steps in order:

1. Capture data generated by JD Edwards Autopilot script playback and store the event stream in a results repository.

2. Use the Virtual Autopilot Script Editor to modify an event stream and to generate a JD Edwards Virtual Autopilot script that contains all the information required by the Virtual Script Player to simulate the activities of the system's runtime engine.

3. Play back a modified event stream (the JD Edwards Virtual Autopilot script) using the Virtual Script Player.

Event Stream

The event stream is a chronological, time-stamped record of every event that occurs during the playback of a JD Edwards Autopilot script, including:

• User input

• Processing performed by the runtime engine, such as thread creation

• Event rules; informative messages

• API calls to the JD Edwards EnterpriseOne middleware

JD Edwards Autopilot performs no editing during the process. The event stream represents a record of the events that have already occurred. You cannot edit it by adding, deleting, or reordering data. To change it, you must generate a new one by modifying an existing JD Edwards Autopilot script, or by creating a new script and then replaying it.

Virtual Autopilot Script Editor Capabilities

Using the Virtual Autopilot Script Editor, you can:

• View the titles of all the scripts whose results you stored in the Autopilot Playback Results Detail Table (F97214)

• Import an event stream

• View an event stream as a single, continuous record

• View the timing of events by category, represented in a horizontal bar graph

• Select an individual API call and view the input values sent to the server and the output values returned to the client workstation

• Create links between parameters of API calls so that parameter values can be passed between calls during virtual script playback

Virtual Autopilot Script Editor Problem Resolution

The Virtual Autopilot Script Editor helps you address problems that you encounter when trying to create a script that you can run to simulate activities in a dynamic client/server system. Problems that you might encounter include:

• Identifying API parameters that require dynamic values

• Providing a way to pass values dynamically between API call parameters to avoid data conflict and record contention

Automatic Scripting Tasks

The Virtual Autopilot Script Editor handles these virtual script creation tasks automatically:

• Linking values of parameters in separate API calls so that values can be passed, provided that the calls meet certain criteria

• Storing the values of hRequest handles

• Storing identification of threads

• Storing information about time gaps between events in a single thread and between interthread-dependent events

Manual Scripting Tasks

You perform these virtual script creation tasks manually:

• Linking values of parameters in separate API calls

• Identifying repetitive processes, such as database inquiry

After you have completed these manual tasks, you use the Virtual Autopilot Script Editor to generate the virtual script. The Virtual Script Player runs the virtual script.

Event Pane

You click the Import button on the Virtual Autopilot Script Editor form to import the results from a JD Edwards Autopilot script playback session. The Virtual Autopilot Script Editor populates the event pane with the event stream. The event stream contains a time stamping of each event. Therefore, you can review JD Edwards Autopilot events or API calls during playback that might have taken an unusual amount of time to run.

You use the event pane to view data about these kinds of playback events:

• CallObject APIs

• JDB APIs

• JD Edwards Autopilot events

• Event rules

• Informative messages, including system errors and warnings

• Thread creation

The event pane also contains this columnar information about each event:

• Timing information, such as the start, end, and elapsed time of an event

• Thread identification

• hUser handle identification

• hRequest handle identification

• Call level

• Message entry identifying the event

• Message information about an event, such as JDB call to open a table from memory cache

  The message entry for each event includes an abbreviation that identifies the type of event that occurred. This table summarizes the abbreviations and the type of event that each represents:

  Abbreviation in Message Column of Event Stream	Type of Script Event
  JDB	Database API call
  RTE	CallObject API call
  EVR	Event rule
  LOG	System warning message
  ERR	System error message
  MSG	JD Edwards Autopilot message
  AUT	Action in JD Edwards Autopilot (for example, typing to control)
  THR	Thread action

You use these buttons to change the view in the event pane:

Event Graph

You can view playback events by category in a horizontal bar graph by choosing the Graph option in the Virtual Autopilot Script Editor. While the event stream pane presents the events of a JD Edwards Autopilot script playback vertically, in a single chronological stream, the event graph presents the events horizontally across a time line.

You can display the chronology by message type, such as JDB API calls or event rules.

The event graph provides you with another detailed snapshot of activity that occurred during JD Edwards Autopilot script playback. You can focus on events of unusual duration, which can be helpful in debugging applications, analyzing network activity, or rewriting and rerunning the original JD Edwards Autopilot script.

Parameter Detail Pane

You can view the parameters that make up an API call by clicking an API call event line in the event pane. The pane that appears shows the name of each parameter in the call and its value, if any. For example, the detail pane might display the value of the user handle parameter that a JDB call passes to the database.

This detail pane provides a complete snapshot of each API call. For example, the pane shows arrows that indicate the flow of data that occurred during the call. An arrow on the left side of the box next to the name of a parameter indicates that the call passed the value into the business function or database driver. An arrow on the right side of the box indicates that the call returned data from the server. In some cases, a box contains both arrows, indicating that data flowed in both directions.

The parameter detail pane offers a before-and-after snapshot of script playback. Before playback, parameters for a CallObject API, such as BatchOpenOnInitialization, contain no batch number or batch date parameter values. After playback, these parameters contain returned values.

The parameter detail pane also displays the parameters of API calls that pass an environment handle to the database.

Finally, many API calls contain a request handle that points to a particular place in memory that the runtime engine has allocated for the call. The parameter for the request handle appears in the parameter detail pane if the API call used a request handle.

The ability of the JD Edwards Autopilot and JD Edwards EnterpriseOne software hooks to capture data at this level of detail is critically important to JD Edwards Virtual Autopilot because the goal of JD Edwards Virtual Autopilot is to simulate, as closely as possible, the actual activities of the system.

Script List Pane

The script list pane on the Virtual Autopilot Script Editor form displays in chronological order the JD Edwards Autopilot script playback results that you saved when you ran the JD Edwards EnterpriseOne application under JD Edwards Autopilot control.

The script list pane displays script result information in these columns:

After you select a script, you click one of these buttons to manipulate the form view:

See Also

Call Level

Parameter Value Linking

After you import an event stream into the Virtual Autopilot Script Editor, you are ready to create the virtual script. Using the Target Parameters and Source Parameters panes, you complete the task of value linking. Value linking ensures that the virtual script can pass parameter values from one API to another. You identify a value-containing parameter in a source parameter API call and link the value to a target parameter in another API call. This process ensures the passing of a parameter value from one API to another API that requires the value.

The values contained in many API call parameters must be dynamic. For example, each time a user performs voucher entry, the JD Edwards EnterpriseOne software creates a new batch number, a function that is essential to prevent the creation of duplicate keys. Value linking ensures that the Virtual Script Player can perform this function. When you link the parameter value of two API calls, the Virtual Autopilot Script Editor stores the value as a variable, and the value changes each time you run a virtual script.

For example, a script might call the business function BatchOpenOnInitialization. For the parameter ICU, which is the batch number, suppose the API returns the value 5056. In turn, the script might call the business function BeginDoc, which uses the value 5056 as an input to the ICU parameter. To simulate multiple script playback, the value 5056 must change in order to reflect the new batch numbers returned each time people using the system make these API calls. As long as you have linked the parameters, the batch number parameter value will change each time you run a virtual script.

Value linking simulates the application logic that is used to run JD Edwards EnterpriseOne software operations. It codifies the relationship between one API call and another. When you run the virtual script, the Virtual Autopilot Script Editor passes to the Virtual Script Player the ID number of the source parameter that you link to the target parameter. The Virtual Script Player uses this information to pass parameter values between API calls.

Several types of data necessary to run a virtual script are candidates for value linking:

• The client host name, which could change any time a script is played back.

• Next numbers, which must change each time a script is run in order to avoid producing duplicate data that would break the script.

• Valid values lists used in JD Edwards Autopilot scripts, which must be designated as such in a JD Edwards Virtual Autopilot script so that, during run time, the Virtual Script Player draws new values from the list rather than using the same value repeatedly.

Source and Target Parameter Identification

The Virtual Autopilot Script Editor provides detailed information about API calls in the event stream when you click the Link Parameters button in the toolbar. The Virtual Autopilot Script Editor identifies the API calls made during script playback as source parameters or target parameters. A source parameter contains a value that the system passes to a parameter in another API call. The parameter receiving the value is the target parameter.

Information about the source and target parameters appears in separate panes of the Virtual Autopilot Script Editor form. Each of the panes contains the following information about API calls made during script playback:

To see the complete set of parameters for an API call that occurred during JD Edwards Autopilot playback, click an item in either pane. The Virtual Autopilot Script Editor displays the parameter names and values for the selected call. Arrows indicate the direction of the flow of data.

The detail panes provide a snapshot of the API calls that the applications generated during JD Edwards Autopilot playback. You can examine the parameter values and the flow of the data to help determine, for example, a parameter value used in one API call that the system passed to another API call later in the script.

To find the parameter of an API call in an event line, you might have to click a node in the detail pane to expand a tree. For example, for a JDB call, find the Value node in the detail pane and expand the tree to expose all of the column parameters in the database table. You then can search the column parameters for the source parameter for which you are looking.

Automatic Value Linking of API Call Parameters

When you click the Link Parameters button on the Virtual Autopilot Script Editor, the tool automatically links some source parameters of API calls to target parameters of other API calls. The Virtual Autopilot Script Editor accomplishes this automatic linking according to a set of rules. These rules govern the automatic linking of API calls:

• Data must have been entered in JD Edwards Autopilot.

• The value of the target parameter must exactly match the value of the source parameter.

• The data dictionary ID of the target parameter must exactly match the data dictionary ID of the source parameter.

The Virtual Autopilot Script Editor finds those parameters that meet each of these conditions and automatically links them.

Manual Parameter Linking

To link parameter values manually:

1. Highlight an event in the target parameters pane.

2. Highlight an event in the source parameters pane.

3. Click the Link button.

Alternatively, to link all occurrences of the target parameter (where Label and Value are the same) with the selected source event, click the Link All button.

Note. Use the Link All feature carefully to avoid linking parameters unintentionally.

Manual Value Linking of API Call Parameters

You can link API call parameters manually by clicking a parameter in each pane, and then clicking the Link button in the Virtual Autopilot Script Editor tool bar.

• Source parameter must come from a JD Edwards Autopilot event (type to grid cell, for example)

• Data dictionary items (called label in Virtual Autopilot Script Editor) must match in source and target

• Values must match in source and target

In deciding the target parameter value to link to a source parameter value, you:

• Match data dictionary aliases

• Match parameter values

• Select, in general, the most recent event displayed in the Source Parameter pane whose start time is closest to the start time of the selected event in the Target Parameters pane

You do not have to link the values of source and target parameters when:

• APIs do not contain data dictionary items

• An API call returns a zero or null value for the source parameter that might be value-linked to a target

• The data flow of the source parameter is indicated as bi-directional, but the input value and the return values are the same

You may code as literal the values of any parameters by clicking the Mark Literal button.

Not all target parameters can be linked. The content of the JD Edwards Autopilot script plays an important role in your decisions on value linking. If the JD Edwards Autopilot script that you write contains a literal value that the script writes to a grid column or header control, you cannot make that literal value dynamic by linking. The Virtual Script Player will be forced to use that literal value repeatedly during JD Edwards Virtual Autopilot script playback.

The entry of the same value to a grid column or header control by multiple users does not accurately simulate the way people use the system. To set up a more realistic scenario when you write the JD Edwards Autopilot script, create valid values lists containing more than one value. During JD Edwards Virtual Autopilot script playback, the Virtual Script Player goes to the JD Edwards Autopilot data (.atd) directory on your hard drive to retrieve the list's values, and then it cycles through them, entering a different value in each simulated playback session until it reaches the end of the list, when it returns to the top of the list and repeats the cycle.

HRequest Handle Value Linking

The Virtual Autopilot Script Editor automatically stores hRequest handle parameter values for JDB API calls. This value represents the address of a memory block that the system allocates for storing information about an open table. The address provides you with entry to the database each time you need to open a table to perform a Fetch, FetchKeyed, SelectKeyed, FetchMatchingKey, or CloseTable function. However, when you create a JD Edwards Virtual Autopilot script and play it back, the hRequest handle parameter value changes. Playback could not continue if this value were constant.

The Virtual Autopilot Script Editor handles the problem by storing the hRequest handle parameter value as a small integer and passing the variable to the Virtual Script Player during playback. The value of the hRequest handle in the script changes to reflect the actual address of a database table opened during script playback.

If a database API call, such as OpenTable, leads to additional API calls, such as FetchKeyed and CloseTable, the Virtual Script Player passes the request handle of the opened table to these subsequent calls. During virtual playback, the subsequent APIs use the live request handle to run SQL statements and to close the table.

Thread Identification

The Virtual Autopilot Script Editor also stores the idThread numbers that JD Edwards Autopilot gathers into the event stream during script playback. These identifier numbers represent the synchronous and asynchronous threads generated by the runtime engine. The runtime engine assigns each event to a thread and tags each thread with a number.

During virtual script playback, the Virtual Autopilot Script Editor passes idThread parameters to the Virtual Script Player, which assigns different idThreads to each event and associates each script event with its new identifier.

Note. During JD Edwards Virtual Autopilot script playback, the Virtual Script Player renumbers the original threads generated during JD Edwards Autopilot script playback. The Virtual Autopilot Script Editor's role is to store the thread identification information and to pass it on through the virtual script.

Timing Interval Maintenance

The Virtual Autopilot Script Editor also automatically handles problems of timing that might emerge in the creation of a JD Edwards Virtual Autopilot script. The time-stamped event stream log of events captures the length of time elapsed between each event. However, after you create a JD Edwards Virtual Autopilot script, you do not know the different scenarios in which the JD Edwards Virtual Autopilot script runs. For example:

• The workstation on which the script runs might be simulating 50 users.

• The power of the workstation might differ from the one on which the original script data was captured.

• The server against which the JD Edwards Virtual Autopilot script runs might be more or less powerful than the server against which the original script ran.

These factors combine to make it likely that the time required by a JD Edwards Virtual Autopilot script to run will differ from the time that the original script required to run.

The Virtual Autopilot Script Editor handles this problem by preserving in the virtual script the time intervals that existed between events when you ran the original script. The time intervals represent the length of time originally required to carry out the processing between events.

The Virtual Script Player initialization file also contains timing parameters that govern the playback of the JD Edwards Virtual Autopilot script. You can adjust, to a limited extent, some of these parameters; for example, you can adjust how fast the JD Edwards Virtual Autopilot script plays back.

See Also

Virtual Script Player Initialization File Parameters

Playback Timing

JD Edwards Virtual Autopilot Script Generation

The JD Edwards Virtual Autopilot script is the output from the Virtual Autopilot Script Editor and the input to the Virtual Script Player. JD Edwards Virtual Autopilot scripts appear in text file form with a header and the edited list of events that you captured during script playback, imported into the Virtual Autopilot Script Editor, and edited, both manually and automatically.

For ease and consistency of interpretation, each event in the script is structured in a particular way. For example, each event begins with the letter e and is followed by a unique identifying number. However, it is not necessary that you look at a JD Edwards Virtual Autopilot script in order to run it.

JD Edwards Virtual Autopilot classifies these three types of events and identifies them as such in the script:

JD Edwards Virtual Autopilot divides each event into parts and, in turn, identifies each of the parts based on an assigned format and a unique value. In short, the JD Edwards Virtual Autopilot script contains the details necessary for the Virtual Script Player to exercise the JD Edwards EnterpriseOne software kernel.

JD Edwards Virtual Autopilot identifies transaction boundaries, which you can set in the original script by designating a script command as the start of the transaction and another script command as the end of the transaction. Setting transaction boundaries can help you to analyze system performance when running a series of tasks.

Virtual Script Player

This section discusses:

• Virtual Script Player overview

• Virtual Script Player initialization file parameters

• Virtual Script Player command line

• Environment initialization

• Modes of operation

• Preprocessing of valid values list data

• Date formatting

• Script failure

• Virtual Script Player limitations

Virtual Script Player Overview

The Virtual Script Player uses the JD Edwards Virtual Autopilot script that you generate in the Virtual Autopilot Script Editor to simulate the concurrent activities of one or more JD Edwards EnterpriseOne software users. It bypasses the presentation layer of JD Edwards EnterpriseOne software and reproduces the JD Edwards EnterpriseOne application calls to the JDB and CallObject middleware. This reproduction is based on the timing and the sequencing of data in the event stream that you generate with JD Edwards Autopilot, manipulate in the Virtual Autopilot Script Editor, and generate in modified form in the JD Edwards Virtual Autopilot script. In essence, the Virtual Script Player assumes the role of the JD Edwards EnterpriseOne software runtime engine.

Virtual Script Player Initialization File Parameters

The vap.ini file is a text file that contains the parameters that define the way that the Virtual Script Player runs. These parameters govern the paths that the Virtual Script Player follows to find files, synchronize playback timing, and set playback speed.

You can change the parameters, within established limits, to set the way the JD Edwards Virtual Autopilot scripts play.

Command

The Command section of the vap.ini file contains the parameters that are necessary for interaction between JD Edwards Virtual Runner, which manages script playback, and the Virtual Script Player, which runs playback. These parameters specify:

• User ID and password

• Environment

• Script name

• Log file of summary playback statistics

• Location of the Virtual Script Player executable

This table summarizes the [COMMAND] parameters and the meaning of each one:

Paths

The Path section of the vap.ini file identifies the directories for files that are needed by the Virtual Script Player. The contents of the needed files are:

• Log file, which gives detailed information about each JD Edwards Virtual Autopilot script playback session, the script name, and a line-by-line summary of each event in the script. The Virtual Script Player logs each event as it completes. The file also includes the start time and the date of the log.

• JD Edwards Virtual Autopilot script file, which stores all scripts that you might use for virtual playback.

• Valid values list file, which stores any valid values lists that the Virtual Script Player draws on for input values to run business functions. The Virtual Script Player uses valid values lists to get a new value each time it runs a business function.

The default file paths are as follows:

Timing

The Timing initialization parameters of the vap.ini file help you specify the terms under which JD Edwards Virtual Autopilot scripts play back:

• Rendezvous of multiple playback sessions, to control the amount of time the Virtual Script player delays a playback session following a rendezvous of multiple scripts running on a single workstation

• Synchronization of playback events, to set limits on the amount of time that threads can be inactive, events can occur behind the start time scheduled by the script, or that a thread has to wait for an API value or a handle parameter

• Playback speed, to adjust the amount of time between events to compensate for a fast or slow client workstation

This table lists the JD Edwards Virtual Autopilot timing initialization parameters, their default values, what they govern, and the kind of timing factor to which they relate:

Log

You use the Log section of the vap.ini file to specify the type of messages that the Virtual Script Player writes to a log file during a JD Edwards Virtual Autopilot script playback session. These messages can be important for debugging purposes. This table summarizes the available log parameters and the debug message level that each one represents:

Note. You can cause the log file buffer to flush after every message by adding 16 to any parameter less than 31. However, you should not routinely do this, as flushing increases file system overhead. You should not routinely set the log parameter at 31.

See Also

Launching and Managing Multiple Script Playback

Simulated Playback Issues

Virtual Script Player Command Line

You can launch the Virtual Script Player from LoadRunner, from JD Edwards Virtual Runner, or from a command prompt. Unless these values are specified in the vap.ini file, the command line must have entries that specify the user, the user's password, the environment, and the script name with a default extension of .vsx for any JD Edwards Virtual Autopilot script, although this extension is not required.

These four entries are required on the command line:

Environment Initialization

The Virtual Script Player does not immediately begin playing a JD Edwards Virtual Autopilot script upon launch. In fact, the Virtual Script Player reads the script and runs events that generate a JD Edwards EnterpriseOne software environment structure. The data that drives the generation of the environment comes from entries in the command line. During initialization, the Virtual Script Player passes in the user ID of the user playing the script, thereby creating the proper environment. Therefore, you can run the Virtual Script Player in an environment different from the one in which you or someone else created the JD Edwards Virtual Autopilot script. This is not recommended, however, because of likely differences between environment. In many cases, these differences will cause virtual playback to fail.

Environment initialization takes about 15 to 30 seconds. LoadRunner regards this passage as initializing time.

Modes of Operation

The Virtual Script Player automatically detects whether you have launched a JD Edwards Virtual Autopilot script from a command line, from JD Edwards Virtual Runner, or from LoadRunner. If LoadRunner launches the script, the Virtual Script Player responds to stop/pause commands and sends transaction times and log output to LoadRunner. In addition, the Virtual Script Player completes a LoadRunner rendezvous just after it has initialized the system environment.

Preprocessing of Valid Values List Data

JD Edwards Virtual Autopilot uses valid values lists during script playback. The user defines the location of any valid values lists that are referenced in the JD Edwards Virtual Autopilot script in the vap.ini file

When a JD Edwards Virtual Autopilot script specifies that a particular value originates in a JD Edwards Autopilot valid values list, the Virtual Script Player reads the valid values list file. All valid values lists are identified by the extension .atd. Before the Virtual Script Player plays the script, it performs preprocessing that includes looking up the database values in the valid values list and storing them until they are required as parameters for API calls. When the Virtual Script Player runs the JD Edwards Virtual Autopilot script, the stored list supplies the parameters needed for JDB or CallObject calls.

Preprocessing plays an important role in the JD Edwards Virtual Autopilot scheme because it takes care of the lookup and load of the valid values that the Virtual Script Player needs for JD Edwards Virtual Autopilot script execution. This ensures that the required values exist before playback. If the Virtual Script Player had to run database lookups at the time of script playback, the result would be artificial load on the database, which would, in turn, distort the simulation of activity that JD Edwards Virtual Autopilot seeks to achieve.

The Virtual Script Player reads valid values lists that are 64K or smaller into memory. If the file is larger than 64K, the Virtual Script Player must read it from the file. During virtual playback, if the Virtual Script Player reaches the end of a valid values list, it starts back at the beginning of the list, reuses the first value, and continues in sequence until virtual playback is complete.

Date Formatting

The Virtual Script Player expects a certain format for date strings for valid value lists and for literal typed-in values from JD Edwards Autopilot. Therefore, the Virtual Script Player supports different date formats that might appear in the JD Edwards Virtual Autopilot script, including mm/dd/yyyy and Julian date strings (that is, 102343 or 12/09/2002).

Important! The Virtual Autopilot Script Editor correctly formats date entries for literal values but not for date entries in valid value lists.

Script Failure

Script failure might occur during the initialization process. For example, a branch event in the script might not refer to a valid event, or the events might not occur in the same thread. In the first example, the script fails before it is launched because the Virtual Script Player cannot validate the events. On initialization, the Virtual Script Player also validates function parameters. For example, a parameter such as Fetch might accept only 0 (zero) or 1 as values. If a different value is used, validation fails and, thus, the script fails before launching.

If the script fails during playback, the failure shuts down script processing. For most API calls, failure to return a success code causes the playback process to halt. The shutdown occurs without user intervention. LoadRunner, for example, returns a failure report, and the Virtual Script Player sends an error message to the log file, for example: LoadRunner/Test Name/Local1/Subdirectory Name. One subdirectory exists for every LoadRunner test session, which means that 50 simulated user test sessions produce 50 subdirectories.

If you launch the Virtual Script Player from a command line or from JD Edwards Virtual Runner and script failure occurs, no error message appears on the screen. You must open the log file that stores the test session results and examine the messages. Search for the keyword Error.

Virtual Script Player Limitations

The overriding consideration for JD Edwards Virtual Autopilot script playback is that client workstations must not impede the playback process. You must determine how many processes the workstation can realistically support, based on an analysis of workstation memory and CPU capability. Running either Task Manager or Performance Monitor can assess these capabilities.

Other Virtual Script Player limitations are hard-coded. If the Virtual Script Player gets a script that exceeds these limitations, you receive error messages. First, the Virtual Script Player supports up to a certain maximum number of user handles and request handles per session. Second, the Virtual Script Player can process only a certain number of status messages per second under LoadRunner. If the playback exceeds that number, some of the log messages are lost, but the Virtual Script Player does not shut down.

VSMEditor

This section discusses:

• VSMEditor features.

• All Virtual Scripts list box.

• Master Scripts list box.

• VSM files.

VSMEditor Features

After you create a number of JD Edwards Virtual Autopilot scripts, the VSMEditor enables you to concatenate any number of those scripts into a single master script. Concatenating single scripts into a single master script is advantageous because you can run a series of tasks during testing.

All Virtual Scripts List Box

The All Virtual Scripts list box contains all JD Edwards Virtual Autopilot script files that you have created; these files have a .vsx extension. In addition, any master scripts that you have created appear in this list box; master scripts have a .vsm extension. The location of any JD Edwards Virtual Autopilot script files that appear in the All Virtual Scripts list box is determined by the value of the VirtualScripts parameter of the PATHS section in the vap.ini.

You enter the path to the location of your virtual scripts to set the VirtualScripts parameter.

You can use any script in the All Virtual Scripts list box to create a master script.

Select script files on the left and click the Add button to add the files that you chose to the Master Script list box.

Master Scripts List Box

The Master Scripts list box shows all the scripts that you have currently chosen for addition to a new .vsm (virtual script master) file. You can manipulate the script list in the Master Scripts list box by using the buttons adjacent to the box:

VSM Files

The VSMEditor creates a .vsm text file when you save a master script. You can change these files only through the VSMEditor because the file contains a checksum value that verifies the file's integrity. The JD Edwards Virtual Autopilot scripts always run in the sequence listed in the .vsm file. However, the first script to run is chosen randomly when the RandomStart parameter in the text file is set to 1.

The .vsm master file contains the file names of the JD Edwards Virtual Autopilot scripts, not the actual scripts themselves. Therefore, you should not delete scripts from the folder that contains the .vsx files.

JD Edwards Virtual Runner

This section discusses:

• JD Edwards Virtual Runner features.

• Player session columns.

• Actions tools.

JD Edwards Virtual Runner Features

JD Edwards Virtual Runner controls the Virtual Script Player sessions on a single workstation and provides the these command and control functions for Virtual Script Player testing:

• Enables users to start one or more Virtual Script Player sessions on a single workstation

• Enables users to play multiple iterations of a single script

• Reports Player session status (pass/fail) to user

• Summarizes performance statistics over all Virtual Script Player sessions in a test

You use the action tools and the columns in the detail area of the JD Edwards Virtual Runner form to manage the JD Edwards Virtual Runner session.

Player Session Columns

After you finish setting up the parameters for the Virtual Script Player session, JD Edwards Virtual Runner displays the names of the scripts that you want to run. Initially, the status of the script is Down, indicating that you have not yet run it.

After you run a test, JD Edwards Virtual Runner changes the status to indicate success or failure.

Each column displays information about the Virtual Script Player sessions. These descriptions summarize the purpose of each player session column:

• The State column indicates the current state of the player session. For example, after you successfully execute a player session, this column displays the word Success.

• The Env column indicates the specified environment for the current session. The environment is specified using the Options button or when you use the JD Edwards Virtual Runner Wizard.

• The User column displays the User name that you specified using the Options button or the JD Edwards Virtual Runner Wizard.

• The Repeat column specifies the number of times the script is repeated when you execute the player session. You specify this parameter when you use the JD Edwards Virtual Runner Wizard.

• The Script column specifies the path and file name of the script for the current player session. You specify these parameters when you use the JD Edwards Virtual Runner Wizard.

Actions Tools

You use the Actions tools to set up and launch a JD Edwards Virtual Runner session. You can select the scripts that you want to run as well as the number of script playback iterations. In addition, following playback you can access a log that contains pertinent information about the playback session.

The JD Edwards Virtual Runner toolbar contains these six buttons: