Post Data Handling
Post data derived from HTML forms is handled automatically by the Web script generator. The form data is normally extracted from a previously returned page as a RequestData object if the required Web Generation Option has been selected. Hidden values in the form are indicated as code comments, other values are set in the RequestData object to allow easy parameterization. Here is an example part of a script for a user login that has been parameterized:
// Page Title: Login
// Recorded cookie(s) sent from client
// Matching form with name 'loginForm' found on page index: 1,
// Original form values follow:
// Control: HIDDEN, contextPathString=/WebApp
// Control: TEXT, loginID=
// Control: PASSWORD, password=
// Control: HIDDEN, timeZoneID=
Other forms of post data are either represented by a string passed to the script method navigatePost() or as an external file that is accessed at runtime and whose name is passed to navigatePostFile() (see below). The criteria for deciding between these approaches are:
- Serialized Java objects are held as files.
- Data > 64K bytes is usually held in a file.
- Otherwise a string is used. This can contain binary (non-printable) data expressed as escaped characters or hexadecimal values following the normal C/C++ conventions.
Handling File Based Post Data
The Web recorders save copies of binary post data as part of the web log, which consists of a set of files and folders.
The default action of the Web script generator is to create code like this for an HTTP post command that sends binary data:
The file "MyScript1_0" is a copy of the recorded data placed in the projects data folder by the wEB SCRIPT generator. The generator ensures that only one copy of the data exists. This means that the same file might be referenced in multiple script statements. Note that the generator does not check whether suitable data files already exist from other scripts. This means that data can be easily identified and deleted if a script is deleted. The data file name consists of the script name plus an index number.
Decoding File Based Post Data
To assist parameterization, the contents of post data files are displayed as comments prior to the navigatePostFile() statement.
Serialized Java Objects
Serialized Java objects are also decoded as comments if the WebGenJavaDecode generator module is selected.
The generator module can be specified by setting the FC_WEB_GEN_CLASS environment variable. For instance to specify the WebGenJavaDecode generator you can place the following line in a .bat file used to execute Eggplant Performance Studio:
set FC_WEB_GEN_CLASS=facilita.gen.WebGenJavaDecode. WebTraceJavaDecode
As the WebGenJavaDecode generator extends the normal Web generator all other functionality is the same.
Modifying File Based Post Data
Like other HTTP commands within scripts it is sometimes necessary to modify (parameterize) the post data so that the contents are varied at runtime. A runtime mechanism exists where a sequence of edits are passed to navigatePostFile(). Edits are added to the sequence in order and consist of:
The byte offset within the data file to be altered.
The length in bytes of the data to be replaced.
A string containing the replacement sequence. This can contain binary data and can differ in length from the data it is replacing.
Modifying Serialized Java Objects
To assist with the replacement of data within serialized Java objects the following functions have been implemented within the utils namespace:
string createJavaInteger(int n):
Takes an integer as a parameter and returns a string containing the sequence of bytes of the equivalent Java value.
string createJavaString(string s):
Takes a string as a parameter and returns a string containing the sequence of bytes of the equivalent Java value, including the preceding character count. N.B. Java String objects are limited to 64K bytes and have a two byte count.
As an example here is the code to modify an integer to value1234567 at offsets 657 and 1381 and to modify a string at offset 684 to a value returned from the current data dictionary:
_offsetEditSequence.add(657, 4, utils::createJavaInteger(1234567));
_offsetEditSequence.add(684, 6, utils::createJavaString(getString("S1")));
_offsetEditSequence.add(1381, 4, utils::createJavaInteger(1234567));
navigatePostFile(_url, " MyScript_3", _offsetEditSequence);
Note that the
clear() method is needed if the
OffsetEditSequence object is re-used.
Specifying Java Edits
Edits to serialized Java files can be specified in a text file so that the generator can create the code to create edit sequences automatically within the script.
The edit specification files are held in the project traces folder. An (optional) global edit file has the name edits.csv. Edits in this file are applied to all scripts. Per-script edit files are named scriptnameEdits.csv. The files have a csv (comma separated variables) format.
The example below creates the code sequence above. All strings "VAL" (quotes are not included as part of the string match value) are replaced by a string extracted from the runtime data dictionary (getString("S1")), the integer 1812 is replaced by 1234567. Of course we could have replaced 1812 with a variable value.
Java Decoding Environment Settings
To enable the Java decoding function the following environment variables must be set:
CLASSPATH=<application specific class path>
For Bond-specific use