AppNeta Synthetic Scripting

  1. Prepare your environment
  2. Create a script
  3. Test the script
  4. Declare variables
    1. Declare a variable related to a workflow
    2. Declare a variable related to a source Monitoring Point/interface
    3. Declare a variable related to a target
  5. Use variables in the script
  6. Specify milestones
  7. Save the workflow
  8. Run the script on a Monitoring Point
  9. Maintenance
  10. Examples
    1. Wikipedia example
    2. Login to APM example

Use the AppNeta Synthetic scripting language to create scripts used for Experience monitoring. Before you can create a script you need to create a web app group containing the web application you want to test and the Monitoring Points you want to test it from. You can then edit the Workflow associated with the web app group to create the script. Creating the script involves entering the scripting commands then using the Preview feature to test it. Once you are happy with the script and complete the script creation process, the script runs automatically on the Monitoring Points associated with the web app group.

Prepare your environment

There are several points you should consider before you start scripting:

  1. Script against the target URL - During script creation, make sure that you script against the same version of the site that the Monitoring Point will access when it runs the script.
  2. Script against an accessible target - Remember that the script you create will be run on a Monitoring Point and it needs to be able to access the target.
  3. Obtain the login credentials - We recommend that you set up a dedicated account for the script to log into the application being tested. Give it the minimal permissions required for your script to run.
  4. Use a clean browser - Remember that each time it runs, your script will be starting from a blank slate, so you’ll need to make sure the browser you are creating the script with is equally clean:
    1. Close all unnecessary tabs.
    2. Clear out your browser’s cache and cookies.
    3. Disable any plug-ins you don’t need or that could interfere with the script, particularly script blockers and ones that automatically enter text into fields, such as password managers.

The following additional points are recommended, but not compulsory:

  1. Plan ahead - As with any coding endeavor, it’s best to plan out what you’re trying to do ahead of time. Spend some time thinking about what you want to test, and what results you expect to see from it.
  2. Use two different browsers on two different monitors - Have the site you’re testing against open on one monitor, and APM open in a different browser on another monitor. This ensures you don’t lose your work if the site you are testing against hangs or crashes the test browser. Also, you can restart the test browser and clear your cookies without affecting your APM session. While troubleshooting, perform an action on the testing browser and observe the result. Then edit your code accordingly in APM on the other browser and monitor.
  3. IP address logging/alerting - If you log authentication requests, consider excluding alerts on attempts to authenticate from your testing workstation’s IP address and the public IP addresses of the Monitoring Points running the script. Not doing so can fill the event log with unnecessary entries.

Create a script

This step assumes that you have already created a web app group.

To create an AppNeta Synthetic script:

  1. Navigate to Experience > Web App Groups.
  2. Click Configure for any web app group (Create a web app group if necessary).
  3. In the Workflows… pane, click to create a new workflow or click next to the workflow you want to edit.
    • The Edit Workflow page opens.
  4. In the first field, specify the workflow name.
  5. Click Add Description, to add a description for the workflow (optional).
  6. In the Type section, click AppNeta Synthetic.
    • The AppNeta Synthetic scripting commands and their descriptions are listed above the script editor.
  7. Select the command you want to enter and click + Add to add the command to the editor.
    • You can also type commands directly into the editor.

Test the script

Once the script is created, you need to test it on a Monitoring Point.

To test the script:

  1. In the Preview section of the Edit Workflow page, select a Monitoring Point and a target.
    • The Monitoring Point should be one of those in the Monitor from… section of the web app group. The target should be one of those in the Monitor to… section of the web app group.
  2. In the Timeout (sec) field, specify how long to wait for the script to complete before automatically terminating it.
    • Set it to slightly longer than the worst case script execution time. The maximum Timeout is testing interval / 3. NOTE: Avoid setting an overly long timeout period. If the script does time out, it will consume resources on the Monitoring Point for the full duration of the timeout period.
    • The timeout counter starts once the script begins executing.
  3. Click Preview.
    • The script is sent to the Monitoring Point and queued for execution. Be aware that, depending on Monitoring Point jobs currently queued and executing, the script may queued for several minutes before it is executed.
    • As the script executes, APM captures a screenshot approximately every second.
    • Confirm that the screenshots are what is expected and that the script completes properly with no errors.

Declare variables

If the script captured user credentials that have a password you do not want visible, you can declare a password variable to mask its value. Those variables that contain the string “password”, “passwd”, “pwd”, or “secret” have their values masked (for example, “my_secret_variable”). All other variable names do not have masked values.

Variables can be declared per workflow, per source Monitoring Point/interface, and per target. If you specify the value of a variable in more than one of these, the order of precedence is workflow then source then target.

  1. In the Workflows… pane of the Web App Groups page, click next to the workflow you are editing.
  2. Click Need Any Variables?.
  3. In the Variables section, add the variable Name and Value.
  4. Click + to add a new variable (optional).
  5. Click Update.
  1. In the Monitor from… pane of the Web App Groups page, click next to the Monitoring Point/interface you are editing.
  2. Click Need Any Variables?.
  3. In the Variables section, add the variable Name and Value.
  4. Click + to add a new variable (optional).
  5. Click Update.
  1. In the Monitor to… pane of the Web App Groups page, click next to the target you are editing.
  2. Click Need Any Variables?.
  3. In the Variables section, add the variable Name and Value.
  4. Click + to add a new variable (optional).
  5. Click Save.

Use variables in the script

Once variables have been declared, they can be used in the script. For example, let’s assume a variable called “password” was created above.

To add a “password” variable to the script:

  1. At the top of the script, add declare $password.
  2. Within the script, replace the actual password with ${password}.

Specify milestones

A milestone is a collection of one or more commands that represent a unit of work that you want to measure. For example, accessing a web app, logging in to the web app, and performing various actions within the web app. Assigning a milestone to each of these actions allows you to narrow down where a slowdown is occurring. Without timing data for each milestone, all you know is that the web app is slow.

A script can have up to 20 milestones.

To specify a milestone in a script:

  1. Add the milestone directly to the script in one of two ways:
    • Add '<milestone-name>' to the end of clickAndWait, typeAndWait, open, or wait commands. For example, clickAndWait id='login-button' 'Milestone 2: Login'.
    • Add startMilestone and endMilestone '<milestone-name>' around blocks of ajax or javascript operations that do not cause a page transition.

Save the workflow

If you have added variables or milestones you should use the Preview to retest and confirm there are no errors. Once this is done you can complete the process.

To complete the process, save the workflow:

  1. Click OK
  2. Click Save

Run the script on a Monitoring Point

Once the script is saved in APM, it is automatically downloaded to the Monitoring Point(s) associated with the web app group and is queued for execution. It takes some time (based on the test interval configured) to see test results.

To see the web path status:

  1. Navigate to Experience > Web App Groups.
  2. Select the web app group containing the script you created.
  3. The status is in the left column of the individual web paths in the web app group.
    • You can also click the web path for detailed test results.


For the script to continue to run without problems, the target environment must be stable. Some things to consider are:

  • Password expiry—Some web applications require new passwords periodically. Set a reminder to change passwords used in your scripts before they expire.
  • Web application changes—Changes to a web apps can cause your script to fail. Be sure to check that the script continues to run successfully when your web app changes.
  • Staging environment—Test against your staging environment as well as your production environment. This allows you to catch changes that affect script execution as well as to benchmark changes in application performance before it is run in production.


The following examples can be used within APM.

To use the examples below:

  1. Click the Script link in the example you want to use.
  2. Copy the script source.
  3. Follow the steps above (from Create a script) but, rather than entering the commands manually, remove any existing code then paste the copied script. Use the other information included in the example (i.e., Target URL and Variables) as appropriate in the steps that follow.

Wikipedia example

Target URL: Script: Wikipedia example

Login to APM example

Target URL: Variables: username, password Script: APM login example