Not a major component of performance monitoring but an important one none the less is the Script Recorder. The Script Recorder is a utility that generates the script that will be used to perform the automation of a transaction on a monitoring platform.
Generally this is a downloaded application that has two modes, record and playback (A co-worker of mine often compares it to the macro recording functionality in the Microsoft Office suite of products). You essentially interact with the Script Recorder as though it is a browser and your actions are recorded in the background. The playback mode will take the recorded script (or a previously recorded script) and process it, allowing the Script Recorder to playback the steps that were taken in a browser. Playback is intended for verification.
Very rarely does the Script Recorder become a crucial need with performance monitoring. The goal is to generate scripts, and if there is an easier way to do it without a Script Recorder then it’s irrelevant if a Script Recorder even exists. Though some power users prefer to have a Script Recorder available if their scripts need constant updating, if they want to perform some low level QA, or if they just want to have more control over the process of the scripting.
To help in the process of researching Script Recorders I have identified some requirements that are based off of monitoring best practices. Remember though, the Script Recorder is only a byproduct of the monitoring platform and should not be the primary deciding factor when looking for a monitoring solution. Here are some desirable requirements of a Script Recorder:
- Flexibility – Script Recorder should be easy to use and allow for the ability to enter custom code/steps/instructions by hand if necessary. The creators of a Script Recorder generally do not account for all the problems that someone may encounter when scripting, therefore it is beneficial to not limit script generation to just what the browser itself can do. Allowing the user to enter in custom instructions can be helpful particularly when trying to clean-up before or after a script is run.
- Fidelity – Record functionality should be capable of recording asynchronous (and non-interactive) events such as Ajax/JavaScript. This events are usually invisible to a user and therefore to monitoring. If a Script Recorder is worth its salt then it should be able to track these events.
- Completeness – Playback functionality should be capable of playing everything back. The monitoring platform will have to play it back so if there is a major discrepancy in playback between the Script Recorder and the actual monitoring platform then that is a sign that things are all copacetic.
- Openness – Ideally an open source platform is available. The script generated by the Script Recorder should be easily portable (open-source) and easy to understand. Immediately you have the support of an open source development community. If your script is open source then you’re not tied down to the implementation of the Script Recorder vendor. This will make it easier for you to up and leave if your needs change (or if you just don’t like your vendor!).
