Web Application Parsing Rule - Example

ShopIt, the sample Web application, was deliberately built so that the Silk Performer recorder must script the context-less function WebPageUrl() with a form definition that contains a session ID. This is achieved by having JavaScript assemble the URL. Recording ShopIt without recording rules results in a script that has a hard-coded session ID.

In this guided HTTP parsing rule example the context less function WebPageUrl() is scripted with a form definition that contains a session ID. Upon executing a Try Script run, the hard-coded session ID causes a replay error.

The session-handling customization feature of TrueLog Explorer solves this problem by modifying the script as shown below:

var
  sFormSid1     : string (100);
  sSessionInfo1  : string (100);

  ...

  WebParseDataBoundEx(sSessionInfo1, STRING_COMPLETE,
    "name=\"", 5, "\"", WEB_FLAG_IGNORE_WHITE_SPACE, 1);
  WebPageLink("Check out", "ShopIt - Check Out"); // Link 3
  Print("sSessionInfo1: " + sSessionInfo1);

  ...

  sFormSid1 := sSessionInfo1;
  WebPageUrl(sParsedUrl,
    "Unnamed page", SHOPITV60_KINDOFPAYMENT_ASP004);

  ...

dclform
  ...
  SHOPITV60_KINDOFPAYMENT_ASP004:
    "choice"                    := "CreditCard",
    "price"                     := "115.8",
//     "sid"                       := "858891471";
    "sid"                       := sFormSid1;

Custom Recorder Details

The script runs correctly now that it has been customized. However a problem exists in that each script that is to be recorded in the future will also have be customized.

HTTP parsing rules enable the Silk Performer recorder to continue this type of customization automatically in the future; recorded scripts can be generated automatically without manual interaction.

To do this, research must be done into how each session ID can be parsed. The customization offered by TrueLog Explorer reveals the API calls where each session ID first occurs, and the boundaries that can be used to parse each session ID.

Using TrueLog Explorer, the first occurrence of each session ID can be located in the HTML code.

<script LANGUAGE="JavaScript">
  function doProcess(mylink)
  {
    scheme="http://";
    server="lab3";
    serverport="";
    path="/ShopItV60/";
    file="kindofpayment.asp?";
    name="858891471";
      price="115.8";
    choice="CreditCard";
    mylink.href=scheme + server + serverport + path + file + "choice=" +
      choice + "&price=" + price + "&sid=" + name;
  }
</script>   

The left boundary name=" and the right boundary " identified by TrueLog Explorer are good choices for the parsing of the session ID.

Now an initial version of an HTTP parsing rule can be written for the Recorder.

<?xml version="1.0" encoding="UTF-8"?>
<RecordingRuleSet>

  <HttpParsingRule>
    <Name>ShopIt V5.1 Session Id</Name>

    <Search>
      <SearchIn>Body</SearchIn>
      <LB>
        <Str>name=&quot;</Str>
      </LB>
      <RB>
        <Str>&quot;</Str>
      </RB>
    </Search>

    <ScriptGen>
      <VarName>ShopItSessionId</Varname>
    </ScriptGen>
  
  </HttpParsingRule>

</RecordingRuleSet>

Since ShopIt session IDs do not appear in HTTP response headers, it is specified that only response bodies are to be searched (using the Search\SearchIn attribute).

A single quotation symbol marks the end of the session ID. This is specified with the Search\RB\Str attribute. Here again, the quotation symbol has been encoded.

Finally, specifics have been defined regarding how the variable for the parsing result is to be named. The name is specified using the ScriptGen\VarName attribute.

This rule file can be saved to the Silk Performer Include directory to make it globally available to all projects. The file name can be of any length, but the file extension .xrl must be used. Alternatively, if the recording rule is to be used with only one project, the file can be saved to the Documents directory of a specific Silk Performer project.