ACL script development workflow in Analytics and Robots

Analytic script (ACL script) authoring takes place in the Analytics app. You create analytic scripts in Analytics, and as required you update them in Analytics.

When you are ready to upload analytic scripts from Analytics to the Robots app, you commit the scripts to a specific ACL robot. For detailed information, see Committing ACL scripts (uploading) to Robots.

When you commit scripts, a new version of the scripts is added to the ACL robot and the version is accessible in development mode. The new version contains the exact content of the scripts that you commit. The version is self contained, and does not merge with any previous version of the scripts. If you removed a script in Analytics, it is no longer available in the new version of the scripts in Robots.

Once you are satisfied that a script version is working correctly in development mode, you can activate it for use in production mode.

An iterative workflow

You can edit one or more scripts and re-commit them to Robots. Each time you re-commit scripts, you create a new version of the scripts. You can use either of these methods for editing and re-committing scripts:

Edit an existing script or scripts in an Analytics project associated with a robot and commit the scripts again.
Download scripts from a robot to Analytics, edit one or more of the scripts, and commit the scripts.

How script versions work

Versions are sequentially numbered
Each time you commit one or more scripts to the same robot you create a new, sequentially numbered version of the scripts: version 1, version 2, and so on.

By saving successive versions of scripts, the Robots app ensures that you do not lose any of your scripting work, and allows you to easily access older versions, if necessary.
Versions are self-contained
Each committed version is completely self-contained. Earlier versions of scripts are never overwritten, and scripts are never merged across versions.

If you remove a script from a project, all subsequent versions that you commit do not contain the script.
Versions contain all scripts
A version contains all the scripts that are in a project when you commit the scripts to Robots: all the analytic scripts, and any auxiliary scripts. You cannot selectively commit scripts from a project.
Version changes are recorded
In the Script versions tab in development mode, you can select a script version to see the names and categories of the individual scripts that are in the version. Names of newly added, deleted, or modified scripts are highlighted.

Example of script versions

Scenario

You want to automate a set of analytical tests that your department currently performs manually on the bi-weekly payroll file. The tests check that employees are paid correctly, proper payroll deductions are made, no phantom employees are paid, and so on.

The script development workflow

In Analytics, you develop a script that imports the payroll file, performs some preliminary data preparation tasks, and then performs all the analytical tests.
You commit the script to Robots, where you run it in development mode against a copy of the actual data to ensure that it is working correctly.
Once the script is working correctly, you activate it for use in production mode and schedule it to run automatically every two weeks.

Analytics	Action/Result	Robots
Commit Scripts >>	Commit You commit script 1, which imports, prepares, and analyzes bi-weekly payroll data. Test You test script 1 in Robots development mode, and it seems to be working correctly. Problem You recognize that script 1 contains so much functionality that it might be difficult for someone else to easily understand or edit.	>> Version One
Commit Scripts >>	Edit You divide script 1 into three separate scripts (2, 3, 4): one each for the import, prepare, and analyze phases. You delete script 1. Commit You commit the scripts in the project. Test You test the three scripts, and you realize some of the results that should be in the output are not included. Problem The data cleansing performed by script 3 is not comprehensive enough, and you are losing some results.	>> Version Two
Commit Scripts >>	Edit In script 3, you use Analytics functions to create computed fields that perform additional data cleansing. You make no changes to scripts 2 and 4. Commit You commit the scripts in the project. Test You test the three scripts, and all the results that should be in the output are now included. Success You are satisfied that all three scripts, and the overall process, are working correctly. You activate Version Three of the scripts for use in production mode.	>> Version Three
edited script unchanged script

Best practices when editing and committing scripts

Treat the scripts on Robots as the master versions

Scripts are protected from alteration once they are committed to Robots. As a best practice, you should treat the scripts on Robots as the master versions. If you want to edit scripts, you should first download the scripts from Robots rather than using locally saved copies.

You are not limited to downloading the most recent version of the scripts on Robots. You can download whatever version of the scripts you want to work with.

The risk of beginning work with a local copy

The risk of beginning your editing work with a local copy of scripts is that the copy may not match the version on Robots:

you may have inadvertently altered the local copy, or forgotten that you altered it
someone else may have committed a version of the scripts to Robots, subsequent to your last commit of the scripts

When is it safe to skip downloading?

After downloading a script version, it is generally safe during a single scriptwriting session to commit iterative versions of the scripts directly from the Analytics project, without downloading between iterations.

If someone else could be working on the scripts at the same time as you, then download between iterations. It is recommended that only one person at a time work on a script version.

Test edited scripts that are part of scheduled tasks

You should always test an edited script or scripts that are part of a scheduled task in Robots to make sure that the edits have not broken the task.

For example, making any of the following edits to an analytic header in a script can break the associated task, and the task must be recreated:

adding or removing an input parameter
adding or removing an input file, table, or field
changing a hard-coded input file, table, or field name

Syntax validation

Every time you commit scripts to Robots, Analytics automatically performs two types of syntax validation or checking:

Analytic header validation
Script syntax checking

If any script does not pass the validation or checking, committing the scripts is prevented, and a message appears that identifies the location of the problem.

Analytic header validation

The analytic header in an analytic script must conform to certain requirements. If it does not conform, the analytic script fails when run.

Analytic header validation cannot be disabled.

For more information, see Working with analytic headers.

Script syntax checking

Certain elements in analytic scripts, such as run-time user interaction commands and absolute file paths, are not supported, or not recommended.

Script syntax checking is enabled by default. If you want to turn it off, select Disable Script Syntax Check Before Commit Scripts in the Options dialog box (Tools > Options > Interface).

For more information, see Analytic development best practices.