GSL concepts

GSLv2 XML serialization

A GSL script is a transaction serialized into XML that the Dynatrace Portal recognizes as a Dynatrace transaction after you upload it to the network. All scripts recorded in the Recorder are converted to GSL before they are sent to the Dynatrace Portal.

The GSL model is based on page requests, which means that transactions need to be broken down into multiple page requests or pages. When this model was originally designed, web transactions could be broken down into distinct pages, and each script step corresponded to a brand new page load. As web applications evolved and AJAX was introduced, the concept of a page no longer existed. A step could be made up of a click that makes an asynchronous call and modifies a single element on the page (instead of loading a brand new page and all its assets); or a step could contain several actions that should be logically grouped together for measurement but that cause multiple full page loads. The GSLv2 script model and the browser agents had to accommodate this functionality, while still adhering to the GSL XML structure for the scripts to be properly recognized by the Dynatrace Portal and stored in the databases.

The GSLv2 script is different from a GSLv1 script in the following ways:

  • All GSLv2 scripts must have these two configuration settings:

    • gsl_version — Value set to 2.

    • browser_version — Value set to the appropriate browser agent to run the test: IE7 for the IE agent, FF35 for the Firefox agent.

  • The URL stored in PageRequest is required for GSL compatibility but is ignored. The Recorder populates this field, but it has no effect on the execution of the script.

  • Content Match tags are no longer used. Validations have replaced content matches and are now part of the PageRequestpost_script (or user actions).

  • Pre-script in GSLv2 is reserved to store special configurations that cannot be represented elsewhere in the GSL model. These configurations can be defined on the script or step level. Script-level configurations will be stored on the first step.

  • POST content (POST data) is not stored in the script. The browser agents only look at the user script to determine what to do next; POST data is no longer used.

  • Non-parameter substitutions no longer exist. After the elimination of POST content, the need for substitutions (with the exception of parameter substitutions) was also eliminated.

GSLv2 JSON serialization

GSLv2 introduces the JSON script structure. The JSON formatted script is only used by the Recorder to properly map the transaction properties between the script file and the Recorder user interface.

The JSON format breaks the script down into lists of objects; those objects can be made up of other objects.

The script structure is broken down as shown in the following illustration.

image

Table 1. JSON vs. GSL Models

JSON Model GSL Model
Script Transaction
Configuration Configuration (no name attribute specified for standard configurations)
Mobile configurations Configuration where the name = http://www.gomez.com/mobile.
Step Page request
Headers Configuration where the name = http://www.gomez.com/mobile.
Parameter Substitution
Action Post-script
Host mapping Configuration (preload_dns_cache, host_host_map).
Certificate Pre-script

The breakdown goes beyond this illustration in that the child components can be broken down into their respective properties. For actions, the properties change depending on what type of action is defined.

This structure makes it possible to locate script elements by referencing their indexed positions within the JSON structure. For example, to reference the target property of the fifth action on the third step, you can do so within a custom JavaScript code block, through the following notation:

 script.steps[2].actions[4].target

GSLv2 JSON scripts must be standards-compliant to properly open in the Recorder. If the JSON code has been manually modified and it does not open successfully in the Recorder, validating the code is a good starting point to figuring out the problem. An online tool for JSON validation is available at http://www.jsonlint.com/.

We do not recommend saving scripts as JSON, because that format is specific to the Recorder only and is not guaranteed to be compatible between releases. Also, Dynatrace has produced some tools specifically for working with GSL that do not work with JSON. GSL scripts are guaranteed to be compatible between releases and GSL is the preferred serialization format. GSL is the default format for saving scripts in the Recorder.