Simulated Playback Issues
This chapter discusses:
Simulated playback issues.
Playback timing.
Call level.
Synchronous and asynchronous calls.
Think times.
Simulated Playback Issues
JD Edwards EnterpriseOne Virtual Autopilot from Oracle solves several simulated playback issues. All of the issues in one way or another revolve around the tool's ability to simulate accurately the workings of the JD Edwards EnterpriseOne runtime engine. The Virtual Autopilot Script Editor and the Virtual Script Player work together; the Virtual Autopilot Script Editor stores key playback information and passes it to the Virtual Script Player, which in turn uses the information to assume the role of the runtime engine. This section explains important simulated playback issues and the ways that JD Edwards Virtual Autopilot resolves them.
Playback Timing
This section discusses:
Event synchronization.
API playback timing.
Interthread timing.
Event Synchronization
To accurately simulate system activities, JD Edwards Virtual Autopilot must keep script events synchronized during playback. This presents a challenge because JD Edwards Virtual Autopilot attempts to simulate multiple users who are stressing the server and the network, while the data upon which JD Edwards Virtual Autopilot scripts are based is captured from a single user's script playback. This means that event start times and duration might change significantly during a virtual script playback session.
To meet this challenge, JD Edwards Virtual Autopilot must solve two separate problems:
Manage changes in the duration of individual API calls and the lengths of time between these calls within a single thread. This involves accurately simulating the process time required as the runtime engine handles user load.
Handle timing differences that might affect interthread dependencies. These interdependencies occur when, for example, an API call in one thread has a data dependency on an API call in another thread.
API Playback Timing
The goal of JD Edwards Virtual Autopilot is to accurately simulate the stress that users place on the server and on the network. However, the JD Edwards Autopilot script, which contains the data upon which the JD Edwards Virtual Autopilot script is built, is not designed to create this stress. The time intervals between events in the JD Edwards Autopilot script reflect the running of a single script against the runtime engine. When you run a JD Edwards Virtual Autopilot script, the duration of events, and therefore the time intervals between those events, will likely change due to the server and network stress that the script is trying to simulate. The CPU power and memory capability of individual workstations can also affect the playback timing of JD Edwards Virtual Autopilot scripts.
JD Edwards Autopilot provides the base for the Virtual Script Player to time the execution of events during virtual script playback. When JD Edwards Autopilot processes a script, it captures each kernel function call, and it captures the start time and duration of each API call. Therefore, the script contains the gaps of time between each call, which occur as the system carries out other processes. The API calls within a thread might be represented as blocks of time of various lengths with intervening spatial gaps that symbolize the time duration between each call.
Preserving these chronological gaps during data capture provides the basis for simulating playback by many users, a situation that is likely to increase the length of time that is required to execute the same API calls.
For example, suppose that virtual playback on a single workstation simulates 10 users using a server that is not as powerful as the server that was in use when the JD Edwards Autopilot script playback session originally occurred. In this scenario, the duration of API call is likely to lengthen, which could cause one API call to overlap another, halting playback.
However, since the event stream has preserved the intervals between each call, virtual playback can proceed, regardless of the duration of any or all of the calls within a thread.
JD Edwards Autopilot's ability to record the duration and length of time between API calls is also important because it can accurately determine the number of virtual users who can be simulated on a single workstation. For example, lengthy API calls might indicate an underpowered server, a workstation lacking the CPU and memory capability to handle the number of virtual user sessions that you desire, or an application bug. In each of these instances, you would likely scale back the number of users you want to simulate in a JD Edwards Virtual Autopilot playback session.
Interthread Timing
The Virtual Autopilot Script Editor also plays a role in handling script playback timing so that JD Edwards Virtual Autopilot can simulate a stressed environment. The runtime engine might, for example, create a thread that contains an API call with a data dependency on another call, which might, in turn, exist in a separate, asynchronously running thread.
In a stressed environment, however, the duration of API calls might lengthen unpredictably. This might result in a data-dependent API call in one thread starting before the API upon which it depends has finished.
To deal with this potential problem, the Virtual Autopilot Script Editor notes the data dependency when you forge value links between two API calls and preserves the timing interval between the calls.
When you run the virtual script, the Virtual Script Player increases the interval between APIs in one thread so that an API in one thread has time to complete before a data-dependent API in a thread running asynchronously to it is called.
In this way, JD Edwards Virtual Autopilot preserves the necessary time interval that existed between the data-dependent calls when you originally ran the script.
Clearly, the Virtual Script Player, in this scenario, manipulates the time interval between API calls in the first thread. However, the manipulation represents an attempt to fairly simulate what the system does in reality. The runtime engine manages data-dependent APIs so that they can run without breaking the system. It is, therefore, appropriate that the Virtual Script Player, in assuming the role of the runtime engine, simulate the runtime engine's responsibility-for example, the delay of one APIs completion based on its logical relationship to another API.
Call Level
Some API calls invoke other API calls automatically within the same thread. Call level refers to an API call's position in the sequence of calls. For example, an EditLine business function might invoke a JDB Fetch call for a company number. In this example, the call level of the EditLine business function is 1, the call level of the JDB Fetch call is 2, and the JD Edwards Autopilot event stream records the two separate API calls.
However, while the runtime engine handles two separate API calls in this example, the processing occurs seamlessly: the second call follows immediately from the first without additional input from the user. For this reason, a JD Edwards Virtual Autopilot script contains only those API calls with a depth of 1. The Virtual Script Player automatically handles any API calls invoked by the original call, just as the runtime engine would.
This JD Edwards Virtual Autopilot capability is important for playing scripts back in batch mode. If APIs with a call level greater than 1 were treated separately, repetitive processing would occur. Such repetition would not correctly simulate system processing.
The Virtual Autopilot Script Editor provides a convenient way for you to view call level in the event stream. Each line that displays an initiating API call shows a call level of 1. Any calls that are invoked by the initiating call show a level of 2 or greater.
Note. The Virtual Autopilot Script Editor displays API calls with a call level greater than 1 only if you select the Capture Performance Statistics option when you configure playback in JD Edwards Autopilot. If you do not wish to view call levels greater than 1, select the Capture Virtual Script event stream option.
If you click the detail line of an API call that has a call level of 2 or greater, the event stream detail pane displays no parameters, meaning that you cannot value link any API call with a call level greater than 1. Therefore, no API calls with a call level greater than 1 appear in the Target Parameters pane.
Synchronous and Asynchronous Calls
As part of simulating JD Edwards EnterpriseOne software operations, JD Edwards Virtual Autopilot must be able to manage synchronous and asynchronous API calls, an important management responsibility of the runtime engine. This ability ties into the Virtual Script Player's management of threads because an asynchronous call generates a separate thread.
A typical example of synchronous and asynchronous API call generation occurs when you enter data in a sales order line. You generate a synchronous call for each line edit; that is, the CallObject API for line 1 in a JD Edwards EnterpriseOne grid precedes the CallObject API for line 2, and the CallObject API for line 2 does not occur until you have completed line 1. However, when you reach the end of a line, click the tab button, and proceed to line 2, you also generate an asynchronous API call that includes the data structure for the line that you just completed. The asynchronous CallObject API validates the data that you entered in line 1 through a series of related API calls. Meanwhile, you move ahead and begin entering sales order data in line 2.
The runtime engine manages this situation by generating a new thread for asynchronous calls and sending these calls to a queue to manage on a first-in, first-out (FIFO) basis. For example, you might enter 20 lines to the sales order entry grid. As you reach the end of each line and tab, the system will likely generate a new asynchronous call. Therefore, a number of asynchronous calls might queue for managing. When the runtime engine finishes processing the asynchronous calls, it stops the thread.
JD Edwards Virtual Autopilot manages the simulation of asynchronous call management through the operation of each part of its architecture. The JD Edwards Autopilot and JD Edwards EnterpriseOne software hooks capture the timings of the synchronous and asynchronous calls that script playback generates. The Virtual Autopilot Script Editor preserves the thread identifiers produced during playback, and the Virtual Script Player generates thread synchronization events in the JD Edwards Virtual Autopilot script based on the temporal relationships among events in the captured event stream.
The Virtual Script Player also manages the threads generated during virtual playback. When virtual playback yields an asynchronous call, the Virtual Script Player queues the calls in a new thread and manages them on the same FIFO terms that the runtime engine uses, thereby managing interthread synchronization as well as event timing within threads.
Synchronous and asynchronous call management provides another example of the JD Edwards Virtual Autopilot's ability to accurately simulate the system, thereby providing you with a realistic picture of network and server stress.
See Also
Think Times
You insert wait periods while writing a JD Edwards Autopilot script in an attempt to accurately simulate the way people use JD Edwards EnterpriseOne software. You click the Wait Before Proceeding button and insert pauses into the playback. These pauses are in millisecond increments.
One possible reason for inserting wait periods in the script is to simulate the pauses that might occur as a user enters vouchers. A user might pause to answer the phone or tend to other tasks, and then return to making the entries.
The event stream generated during JD Edwards Autopilot script playback records these wait times. They do not appear, however, with a label in the event stream pane if you import the event stream into the Virtual Autopilot Script Editor. Rather, you recognize them by noting in the event stream pane the duration of time between the end of one event and the beginning of the next.
The JD Edwards Virtual Autopilot script that you create contains the waits inserted in the original script, and the Virtual Script Player manages the delays during script playback. The inclusion of think times provides another element that helps JD Edwards Virtual Autopilot simulate the JD Edwards EnterpriseOne environment, which includes many users performing different tasks under a variety of circumstances.
You might want to analyze the event stream to see the length of time the events in the JD Edwards Autopilot script took to complete. Think times that you insert into the script do not interfere with event duration analysis because the Virtual Autopilot Script Editor's event graph does not reflect any wait times. If, for example, a five-second wait occurs between a CallObject API and an OpenTable API, the event graph displays only the amount of time required to run the APIs. Thus, you get a true picture of the time that the system required to process the API calls.