When to Use Customized Session Handling

Assuming that a WebPageUrl call in your script uses a URL that contains a session ID as part of the query string of the URL. When replaying the script, this hard coded static session ID is sent to the server. Because the session ID does not correctly identify your replayed session—it still identifies the recording session—the replay won’t work correctly. By not replacing static session IDs in your script with dynamic values that had been generated at runtime, your Web application will usually generate errors such as We are sorry, your session has expired. Please return to the login screen and try again.

The good news is that with Silk Performer, session customization is not often necessary and, even if manual session customization is needed, Silk Performer's TrueLog Explorer will guide you through the process.

Most often when you record a script, it will work without any modifications necessary for the customization of session handling. Silk Performer therefore uses multiple, highly sophisticated methods that prevent the user from manually handling hard coded session IDs:

• Cookie Management: When your server uses cookies to exchange session information, Silk Performer will automatically handle dynamic session ID values. Because Silk Performer exactly emulates the cookie management of a browser, it will send cookies the same way a browser sends them to your server. No manual interaction is needed for state management.
• page-level web API: Using the Page-level API when recording (which is the default setting) will generate scripts that mainly generate context-full Web API function calls such as WebPageLink and WebPageSubmit. Context-full Web API calls are working on the HTML level, not the HTTP level, and thus they do not use URL's as parameters. For all context-full API calls, manual session customization is not needed. The page-level API is used if you choose the application type Web business transaction (HTML/HTTP) in the Outline Project dialog. Therefore it is strongly recommended that you use Silk Performer's page-level API instead of the low-level web API.

Due to the heavy use of client side Java Script for dynamically generating HTML, the Silk Performer Recorder sometimes loses the HTML context and scripts context-less Web API calls. Context-less Web API calls, such as WebPageUrl and WebPageForm, contain URL's as parameters. In these rare cases, your script may contain hard coded session IDs. You will find them in the URL parameters of Web API calls and in the form fields declared in the dclform section of your script.

transaction TMain
  begin 
    WebPageUrl("http://lab38/ShopIt/"); // first call is always context-less
    WebPageLink("Join the experience!"); 
    WebPageSubmit("Enter", SHOPIT_MAIN_ASP001);
    WebPageLink("Products");
  end TMain;

 dclform
 SHOPIT_MAIN_ASP001:
    "SessionID" := "" <USE_HTML_VAL>, // hidden value:
    "LGIJALLCGEBMIBIMFKOEJIMM" 
    // recognized as a hidden form 
    // field, the value is taken from 
    // the actual HTML form field.
    "name" := "Jack", // changed
    "New-Name-Button" := "" <USE_HTML_VAL> ; //unchanged
    value: "Enter"

transaction TMain
  begin 
    WebPageUrl("http://lab38/ShopIt/"); // first call is always context-less
    WebPageUrl("http://lab38/ShopIt/main.asp", NULL, SHOPIT_MAIN_ASP001);
    WebPageForm("http://lab38/ShopIt/main.asp", SHOPIT_MAIN_ASP002);
    WebPageUrl("http://lab38/ShopIt/products.asp");
  end TMain;

 dclform
 SHOPIT_MAIN_ASP001:
    "from" := "welcome";

    SHOPIT_MAIN_ASP002:
  "SessionID"       := "LGIJALLCGEBMIBIMFKOEJIMM",
    "name"            := "Jack",
    "New-Name-Button" := "Enter";