See also Synthetic Scripts FAQ (Part I).
|On-premises (v4.5.4+)||On-premises (v4.5.4+)||On-premises (v4.5.4+)|
Yes. The Synthetic Credential Vault securely stores credentials used for synthetic jobs. When you create a synthetic job with a synthetic script, you can retrieve a stored key/value credential pair, like a username and password, and inject the credential into the synthetic script. Then when the synthetic job runs, the synthetic script executes and retrieves the credentials stored in the Synthetic Credential Vault.
See our documentation to learn more about the Synthetic Credential Vault.
The short answer is that scripts and their results always go over encrypted channels. The scripts and results are stored in clear text in various databases, so a database breach could compromise the information, but, of course, we try very hard to prevent database breaches.
For the long answer, see the summary of the data path of a script and its results below. (Foo) denotes data at rest.
Each of the -> links uses HTTPS, with two possible exceptions which are determined by the user:
If you can write Python code to do something using the standard libraries, you can do that in your script. For example, you can use Python's requests library to make REST calls to fetch a password.
You can wait for the iFrame element to be clickable as shown in the snippet below.
No, the snapshot retention period cannot currently be extended on SaaS.
As of April 2016, API testing is in the long-term vision for Synthetic, but the feature is not on any roadmaps yet. If the customer's use case involves monitoring the API from inside their network, then Service Availability is the preferred solution. Monitoring from outside their network is not an option at this time.
Virtual pages are not yet supported in Synthetic (possible future feature), so virtual page naming is not supported.
Multiple windows or tabs with loaded HTML documents are only partially supported. You can create scripts to handle multiple windows, but the session results will combine the waterfall metrics and the resources from all of the windows into one page. Thus, you will not be able to view the individual results for each browser window.
We recommend doing your initial debugging locally: that’s always the easiest place to debug. We capture the stdout and stderr streams from your script, so you can debug that way. And we show partial sessions for scripts that failed part-way through, so you can see what the browser did up until the script failed.
Timeouts in scripts can be prevented by explicitly waiting for specific element states (e.g., clickable). See also the paragraph Expected Conditions discussed in Explicit Waits.
If your script has an assertion failure, the session status is “Failed”, which indicates a problem with your site. If your script crashes, the session status is “Broken”, which indicates a problem with your script. If we can’t run your script, the session status is “Internal Error”. We hope you’ll never see that. For single-URL measurements, a 5xx is “Failed,” and a 4xx is “Broken”.
There are currently two known issues regarding visual metrics: