Audience: IT Support Staff

When used: When creating, modifying and supporting web transactions.


Mapping Transactions

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.

The following steps are a guideline and not a complete collection of all the steps, variables and possibilities that could affect the mapping of a transaction:

  1. Obtain the steps or URLs to be mapped from the customer.
  2. Log on to test server (216.58.225.31) as vwpoint.
  3. cd /home/vwpoint/transaction and create a directory for the customers transaction.
  4. Inside the customers directory start the proxy process:
    /home/vwpoint/proxy/gnwProxy -f  [output file name]
    
    Example:  /home/vwpoint/proxy/gnwProxy -f  sprint_trans
    Press return key and the proxy is ready to record. 
    NOTE: the cursor will NOT return to the prompt – if it does the proxy server is NOT active.
    
    This will capture the processes taking place between the browser and the website.
    

    NOTE: A program such as ieHTTPHeaders may be useful in addition to or in place of the GNW proxy.

  5. Open a web browser on a PC desktop. In “tools” select “Connections” tab, click on “LAN Settings”, click the check box on “Use a Proxy Server”, then enter the following in the address window “216.58.225.31” and port=”8000”. Click “OK” to save changes. The browser will now be able to connect to the proxy server on the test box.
  6. Click through the steps provided by the customer or requestor. During this process the proxy will be recording the data to the output file on the test server.
  7. Once steps are completed, go to the test server screen and do ctrl –c to stop the recoding process. The raw data file is now ready to be edited to create the transaction script.


Review and Edit Proxy Output File

Once the mapping is complete review the raw data file through vi editor or by doing a more on the file name:

vi [output filename]
more [output filename]

The goal is to locate the URLs, GETs, and POSTs from the raw data. It is important to also have all of the IP addresses for the URLs, Ports used, any redirects, etc., in order to create a complete script. Again, this is not a complete list – there are many elements that could come into play – each script is unique depending on the customers request.

Example of the raw data from the output file:

***recv***4, 445*********
GET http://portal.corp.sprint.com/ HTTP/1.0
If-Modified-Since: Tue, 04 Feb 2003 17:13:12 GMT; length=170
Proxy-Connection: Keep-Alive
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.19-7.0.8 i686)
Host: portal.corp.sprint.com
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
Accept-Encoding: gzip
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8
Cookie: WEBTRENDS_ID=10.188.130.117-1055777122.12427
__________________________
***recv***5, 120*********
HTTP/1.1 304 Use local copy
Server: Netscape-Enterprise/6.0
Date: Mon, 16 Jun 2003 15:38:15 GMT
Connection: close
__________________________
***recv***5, 0*********
__________________________
***recv***4, 397*********
GET http://portal.corp.sprint.com/amserver/login HTTP/1.0
Proxy-Connection: Keep-Alive
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.19-7.0.8 i686)
Host: portal.corp.sprint.com
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
Accept-Encoding: gzip
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8
Cookie: WEBTRENDS_ID=10.188.130.117-1055777122.12427

In the example there are several elements that will be extracted and modified to create a transaction. Each section of the transaction contains four lines the browser uses to communicate with the web server:

Line 1: URL, IP Address, Action [GET,POST], Port, URL Path, SSL (Y/N)
Line 2: ACCEPT STRING [Content checking]
Line 3: REJECT STRING [Modifiers to make script perform search & replace, read text]
Line 4: POST response to web server

Line 1: portal.corp.sprint.com 10.184.145.102 POST 80 /amserver/login?module=Sprint N
Line 2: Login
Line 3: [blank]
Line 4: iPSPCookie=true&TOKEN0=dxh8486&TOKEN1=sprint

In line 4 the script is posting the logon id and password to the web server.

Editing example #1:

GET http://portal.corp.sprint.com/ HTTP/1.0
If-Modified-Since: Tue, 04 Feb 2003 17:13:12 GMT; length=170
Proxy-Connection: Keep-Alive
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.19-7.0.8 i686)
Host: portal.corp.sprint.com
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
Accept-Encoding: gzip
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8
Cookie: WEBTRENDS_ID=10.188.130.117-1055777122.12427

GET http://portal.corp.sprint.com/ HTTP/1.0

becomes

portal.corp.sprint.com 10.79.46.12 GET 80 / N

portal.corp.sprint.com   10.79.46.12          GET                 80          /             N
            |                 |                |                   |          |             |
           URL            IP Address      Browser Action         Port    Server Path       SSL (Y/N) 

NOTE: Set SSL to 'Y' if this is a secured URL / Set to 'N' if this is NOT a secured URL

Using a text editor scan the output files for the URLs that correlate to the requested steps and paste them in the proper format. There should be two (2) blank lines at the start of the transaction and each step should contain 4 lines (including empty lines).

Sample:

   1 0
   2 0
   3 v2o.valmont.com 63.167.107.6 GET 80 /v2o/Source/login.asp?PAGE_NAME=/v2o/source/v2o/default.asp?app=v2o N
   4 Valmont Industries Inc. 
   5 
   6 
   7 v2o.valmont.com 63.167.107.6 POST 80 /v2o/Source/checkuser.asp?PAGE_NAME=/v2o/source/v2o/default.asp?app=v2o N
   8 
   9 
  10 name=dealer&password=global&B1=Login 
  11 v2o.valmont.com 63.167.107.6 GET 80 /v2o/source/v2o/default.asp?app=v2o N
  12 V2O
  13 
  14 
  15 v2o.valmont.com 63.167.107.6 GET 80 /v2o/source/v2oinstall/installer.asp?APP_NAME=Chart&PAGE_NAME=../VChart/default.asp?executeCommand=201 N
  16 
  17 
  18 


Testing the Completed Transaction Script

Once the transaction has been edited it is ready for testing to ensure the script is built correctly, uses the correct format and syntax the application is expecting.

  1. Ensure that the script has an even amount of lines. The script will not run properly without the correct about of lines. (e.g. 5 Steps should be 22 lines with the two blank start lines) wc -l [filename] wc -l v2o 8 v2o (Equals 4 steps each with 4 lines and two blank lines to begin with: 4 x 4=16 + 2 =18.)
  2. Next test the script against the httptAgent (Transaction Agent) to ensure that the formatting and syntax are correct. Do the following step:
     $/home/vwpoint/viewPoint/bin/httptAgent -d 2 -t [file name]
      (the -d is the deboug level: 1,2,3)
     As the httptAgent tests the script if there is an error it will stop on the step that is incorrect:
    
    --------httpTresultStrut-----------
    serviceId: 100
    nodeId: 0
    checkTime: 10/27/2003 13:27:20
    step: 1
    conTime: 63
    authTime: 0
    fPackTime: 114
    dataTime: 4252
    packetSize: 1388
    totalData: 13888
    retData: 
    emsgId: 1401 
    ------------------------------------
    
    In the example above there is an error with Step 1 and the script has stopped testing in order for the issue to be addressed. The emsgId field is showing the error code 1401. 
    

See Transaction Error Codes for a list of the error codes and their meanings.

In this instance the error code 1401 is defined as:

HTTP Error : Content Check - Accept String Not Found.

The error is in the second line of Step 1 which is the "Accept String" line that looks for a particular item within the web page has been moved or changed. The solution is to review the web page and locate a new item on the page, place it in the transaction and retest the script.

This process will continue until all errors have been addressed.


Implementation of the Transaction

The next step in the process is to enter the transaction into the database so that the request can be propagated out to all the nodes and the data collection process can begin. Before the transaction can be entered gather the following information:

  1. Subid
  2. Nodes for monitoring
  3. Title of the transaction (Namealias, e.g. Sprint LD Orders V5)

Entering the Transaction

  1. Start the process
    • At the prompt type: /home/vwpoint/viewPoint/tools/enterHttpTransAuto.pl [transaction file name]

  2. The script will ask the following questions [NOTE Some commands are case sensitive]:
     MultipleIP [Y/N]: Y= allow multiple IP's to appear in customer's report displays.
                       N = not allow multiple IP's to appear in customer's report displays. 
    
      THIS IS CASE SENSITIVE!  
    
     STEPNAME [1- ?]:   Each step needs a description of the activity being monitored.
    
     Sub ID?
    
     NameAlias?  [Transaction Name, (version data)]
    
     Is there any previous version of the transaction [y/n] 
    
      THIS IS CASE SENSITIVE! 
      
       If "y": What is the current service count : [Enter # here]
       What is the new service count ?:  [Enter # here] 
       (Can be left blank - system will automatically assign service count)
    
       Output: You can now deactivate the previous service cnt.
     
       If "n":
        Give new nodeList with no spaces (1,3,5,10)
     
        Node Threshold: 
     
  3. Once this has been successfully entered, the script will return to a shell prompt.
  4. To ensure that the transaction loaded properly and to propagate it out to the nodes:
    • cd /home/vwpoint/viewPoint/bin OR type 'gnwbin'
    • Then type 'sndNetWatchData', if it returns to the prompt the transaction was entered into the database properly and updates should be propagating to the nodes correctly.
    • If sndNetWatchData returns the following:
      • sndNetWatchData.cc:No tServiceList data found for(serviceid,step)

        Then the transaction failed to load properly and could keep other services from propagating out to the nodes. This needs to be remedied immediately! See Data Fails to Propagate

Creation and Support of Transactions (last edited 2006-03-17 21:02:17 by Eric)