Note: Make sure the asset that will run the scripts contains support for the programming language in which the related scripts are written. For example, the Linux operating system comes with the Perl engine and can run Perl scripts. If an asset does not support a specific programming language, you can use the DOS batch language to run batch scripts (for example, .bat).
Typically, a sequence script consists of at least one and possibly three sections: REGISTER, RUN, and UNREGISTER. The sections do not have to be defined in any particular order, though it is good practice to list them as shown here:
o [REGISTER] - When the Axeda® Platform sends a "register script" command, the Agent executes all commands in this section. The Agent verifies that the script name and path are accurate, and then modifies its configuration to reflect the newly registered script. In this section, the paths specified for the scripts to register must be relative to the asset's path. Finally, the Agent sends an updated list of its registered scripts to the Platform.
o [RUN] - When the Platform sends a "run script" command, the Agent executes any commands in this section. If the sequence file has no sections, all commands in the script sequence file are run, in sequential order.
o [UNREGISTER] - When the Platform sends a "unregister script" command, the Agent executes all commands in this section, deletes the script file at the registered path, and then sends an updated list of its registered scripts to the Platform.
The Platform sends a command when an Applications user selects to run one of the corresponding Actions.
Note: An Axeda Agent sends its list of registered scripts to the Platform upon startup. The name of your script sequence is registered with the Platform within the Agent's scripting registration message. Each script is identified by a unique (per-model), case-sensitive name. Two scripts with the same name are assumed to be duplicates of the same script.
The Axeda Agent can perform parameter substitutions on specific strings (case insensitive) defined in the script sequence file, replacing them with information from the asset.
In addition, the script sequence file can include internal commands to the Agent that are not passed to the operating system. One of these internal commands is the timeout directive, which is described in the next section. For complete details on all the directives, refer to the Axeda® Script Developer's Reference Guide.
To prevent a script from executing without end (for example, the rare "run-away" Perl script), add the following timeout directive to the sequence file.
${timeout
= x}
where 'x'
is the number of seconds the Agent will wait before timing out the process
The timeout directive defines the maximum number of seconds that a process is allowed to run before it is terminated by the Agent. You can add the timeout directive to the [RUN] section of your sequence file. You can configure the directive to be used alone or for specific processes. If used alone, each process defined after the directive will time out.
The following is an example of using the timeout directive on a per process basis, in which all processes (for example, Perl processes) will run for 21 seconds before being timed out:
[RUN]
${timeout = 21}
perl startup.pl ${device.modelNumber} ${device.serialNumber}
The following is an example of using the timeout directive to set the timeout for a specific script process (for example, Perl process) at 21 seconds:
[RUN]
perl startup.pl ${device.modelNumber} ${device.serialNumber}${timeout = 21}
If the process is terminated, the following message appears on the command console:
INFO
EScriptManager: Script [script name] timeout.
Terminated process: perl startup.pl model xyz, serial number abc
where:
o [script name] is the name defined for the script
o perl startup.pl is the name of the process being run
Note: Although the term "asset" is used instead of "device" in the Axeda Applications, the Axeda® Connected Product Management Applications SDK and Web services and the Axeda Agent SDK and Web services continue to use the term "device". This usage in code preserves backwards compatibility for existing deployments.
At this point, the script itself is terminated and status information for the script is updated to reflect the timeout.