Customers may request a series of URLs and processes to be monitored on a regular basis and receive reports regarding those URLs. This is called a transaction. A script has to be created so that the application can monitor the transaction requested by the customer.

Typically the customer will provide the path of the transaction to GNW, who will in turn create, test and integrate the script into the production environment. The process of mapping a transaction can be challenging as there are many variables and items that need to be captured.

Transaction File Format

The following shows the file format. Lines 3 thru N are grouped in record sets of 4 lines each.

 * Line 1: browser information ==> (0, 1, and 2)  * Line 2: transaction type ==> (0 normal, 1 all images grouped, 2 all images with detail)  * Line 3-N: Transaction Steps ==> (each step represented by 4 lines). 

Currently lines 1 and 2 must exist, but are ignored by the Perl script used to load the transactions into the database. Browser values tell the transaction agent to send a corresponding browser description when connecting to the web site.

Browser ID



netWatch Agent,


compatible; MSIE 6.0; Windows NT 5.0


X11; U; Linux i686; en-US; rv:1.0.1

Transaction Step Records Format

A single step in a transaction consists of 4 lines of data.

 * Line 1: Hostname, IP Address, Action (GET,POST), Port, URL Path, SSL (Y/N)  * Line 2: Accept String  * Line 3: Instructions  * Line 4: Post Data 

Transaction Step Line 1 Format

The format of line one is as follows with white space separating each component string.

<Hostname> <IP Address> <HTTP Action> <Port URL> <Path> <SSL Flag> 

The HTTP Action can be one of GET, POST, PUT, PATCH or DELETE. There is a limit of 4 characters for this field - see below for mapping


GNW Agent Format











The SSL Flag value can contain Y or N.

Transaction Step Line 2 Format

The format of line two is simply the accept string as it should be found in the downloaded html document.

Transaction Step Line 3 Format

Line 3 can be used for a reject string and/or optional instructions to allow values to be scraped from the contents of a page and re-used at a later point in the transaction. This functionality allows us to accommodate dynamically changing values such as session ID's and other values that change each time a transaction runs.

If the instructions are longer than the database allows (50 characters) then the line 3 instructions can all be moved to a file and stored locally on each node that will run the transaction. The method for referencing a file with line 3 instructions is similar to the method used for storing long post data in step 4. To reference the optional line 3 file the line should start with '&&'.



The formatting instructions and usage of Line 3 Instructions are as follows.





A literal ‘c’ or 'C'. This is an optional instruction to disable 'c' or enable 'C' cookies. If disabled, the agent will remove all cookies from its cache and none will be sent back to the server. Cookie processing is enabled by default.


A literal ‘p’. This is an optional instruction for this line. This options Instructs the agent to use the same hostname, ipAddress, and port as in the previous transaction step.


A literal ‘r’. An optional instruction for this line that tells the agent to process this transaction step as a redirect.


A literal ‘x’. An optional instruction for this line that tells the agent to process the following string as a reject string. If the <rejectString>; is found on the html page cause an exception to be thrown and the termination of the transaction. The semicolon ; is a mandatory delimiter to signify the end of the search string.


A two digit number representing the number of commands to follow


A command to execute. Current options are
s for search
L Load data


If the <cmd> is s then the <subCmd> values specified how to search within the HTML document.
I - search the HTML input tag
A - search the HTML frame tag
F - search the HTML form tag looking for an action with a value of <string>
H - search the HTML href tag
f - search for a javascript function
E - search for a javascript equation
r - search using a regular expression
c - search for a cookie using name immediately following and copy cookie value (used with 'h' action to add cookie value to a header named for the cookie)
x - just move the data

If the <cmd> is L then the <subCmd> specifies where to load the data from.
F - filename to load data from.


Usage depends on the <cmd> and <subCmd> options specified. When searching it is used as the string you want to search for. How it is used depends on the <subCmd> context specified previously. The semicolon ; is a mandatory delimiter to signify the end of the search string.


Which instance of the <search text> string within the document to match on.


Once the <cmd><subCmd> has been executed and the data has been loaded then the <action> indicates what to do with the data. The newly found can be added to one of the following
p - add data to path
c - add data to content
m - convert data to hexadecimal and add to content
h - add data to request header (used with 'c' subCmd to create a request header that uses the name of the cookie as the name of the request header and the value of the cookie as the value of the request header)
v - add data to variable where variable name is based on the search string up to but not including the equal sign
Vn - add data to variable named Vn where n is a single character. For example, if Vn is specified as V1 then you can reference it in the path, accept and reject strings, and content as ${V1} NOTE: To turn on url-encoding of the scraped data add a # before the V in the variable name. Example: ${#V1}

Example line 3:

01srsessionSync" value="*";01V1

Example of searching for a cookie named "q2token" and creating a request header using the name and value of the cookie for the respective name and value of the request header:


Transaction Step Line 4 Format

This line contains the form data the should be POST’d to the web site specified in the url on Line 1. Putting this POST data directly into the transaction is sufficient for a majority of the transaction steps.

Putting POST data in a separate file

There is a limit to the size of the step 4 POST data that can be stored in the database. If this data will not fit, you can put POST data content into a file under the $VIEWPOINT folder on the production server and then specify a relative path as follows:

In this example the && signifies to the transaction agent that the following content can be found in the file under $VIEWPOINT/postData/

The post data file will need to be copied to all nodes that are being used for the transaction and placed in the same directory as specified in the transaction. ie. $VIEWPOINT/postData/

Structure of POST data file

It is not necessary for the main content to be a single line if using a content type such as XML.

The POST file can also be used to send multipart/form-data. For information about using this capability to support multipart/form-data see Posting Multipart Form Data

Mapping Transactions (last edited 2019-08-23 21:29:07 by EricC)