Silk Performer Page-Level API

Note: To take advantage of Silk Performer advanced context management techniques, you must use the page-level Web API (the default option when you set up a new Web business transaction Web testing project in Silk Performer).

The basic idea behind page-level API is to describe user actions at a higher level of abstraction.

Low-level API describes network interactions in terms of single HTTP requests. For single Web pages, browsers typically send numerous HTTP requests to servers. Low-level scripts therefore tend to be rather long, with each single function containing a parameter that specifies a URL from which to download. This makes low-level scripts unsuitable for automatic context management. Low-level scripts can also be difficult to read because they do not describe actions from the user perspective.

In contrast, high-level page-level API describes user actions in terms that are familiar to Web users. For example:

WebPageUrl - Enter a URL in the address bar
WebPageLink - Click a link
WebPageSubmit - Submit a form
WebPageBack - Click the Back button

One main feature of page-level API that differs from low-level API is that it incorporates an HTML-parser that parses HTML documents and locates embedded objects, frames, links and forms. Embedded objects and frames are downloaded automatically. Links and forms can be used for context-full function calls.

A single function call in a script can download a complete HTML page, even one that includes complex framesets.

Web Page History

Scripts utilizing page-level API emulate histories by logging previously downloaded pages, just as browsers do to enable their Back buttons. The maximum number of pages that are tracked for each virtual user can be limited to manage system resources (the default value is 5).

Note however that this limit does not affect the accuracy of load tests because the history's purpose is to facilitate advanced context management. It has nothing to do with network traffic.

If a page needs to be available for a longer period of time than its life-time in the history allows, it can be locked using the WebPageStoreContext function. While the page will still be dropped from the history if necessary, it will not be deleted from memory and it can be referred to by a handle that is returned by the WebPageStoreContext function. When the page is no longer needed it can be unlocked (and thereby deleted from memory) using the WebPageDeleteContext function.