Determining When to Customize Session Handling

When a WebPageUrl call in a script uses a URL that contains a session ID as part of the query string, that same hard-coded static session ID will be sent to the server when the script is replayed. The session ID, however, will not correctly identify the replay session. It will only identify the earlier recorded session, causing the script replay to generate an error.

Without replacing static session IDs in scripts with dynamic values generated at runtime, Web applications are likely to generate errors, such as Your session has expired. Please return to the login screen.

Because of Silk Performer session-handling methods, session customization is not required for most Web applications. In the rare instances where manual session customization is required, TrueLog Explorer facilitates the process.

Silk Performer uses two session-ID handling methods that reduce the need for manual handling of hard-coded session IDs:

Cookie Management

Silk Performer automatically handles dynamic session ID values for servers that use cookies to exchange session information. Because Silk Performer accurately emulates browser cookie management, it can send cookies to servers in the same way that browsers do, and thereby eliminate the need for manual interaction to maintain state.

Page-level Web API

Using page-level API for recording (the default setting) delivers scripts that generate context-full Web API function calls, such as WebPageLink and WebPageSubmit. Context-full Web API calls work at the HTML level, not the HTTP level, and therefore don't use URLs as parameters. Manual session customization isn't required for context-full API calls. The Silk Performer page-level API is used when the application type Web business transaction (HTML/HTTP) is selected in the Outline Project dialog box.

Note: It is strongly recommended that the Silk Performer page-level API be used rather than the Silk Performer low-level, browser-based API.

When client-side JavaScript is relied upon for the dynamic generation of HTML, the Silk Performer Recorder occasionally loses HTML context and scripts context-less Web API calls. Context-less Web API calls, such as WebPageUrl and WebPageForm, contain URLs as parameters. In these rare instances scripts may contain hard-coded session IDs that can be found in the URL parameters of Web API calls and in the form fields declared in the DCLFORM sections of scripts.

Example

The following context-full script does not require customization.

transaction TMain
  begin
    WebPageUrl("http://myHost/ShopIt/"); // first call 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: 
                                            // LGIJALLCGEBMIBIMFKOEJIMM2
                                            // recognized as a hidden
                                            // form field, the value is
                                            // taken from the actual
                                            // HTML form field.
    "name"            := "Tester",          // changed
    "New Name Button" := "" <USE_HTML_VAL>; // unchanged value: "Enter"

Example

Following is a script with context-free functions (static session data that needs to be customized is included in the DCLFORM section):

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

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

  SHOPIT_MAIN_ASP002:
    "SessionID"       := "LGIJALLCGEBMIBIMFKOEJIMM2",
    "name"            := "Tester",
    "New Name Button" := "Enter";