Write scripts at the template level

Add additional functionality to a template by creating scripts. Scripts are written using the QuickScript .NET language. Refer to the Application Server Scripting Guide for detailed information about scripting.

Best Practice

The following best practice recommendations are cross-referenced to practical examples described in the following chapter.

• Segregate functionality by creating unique scripts for each segment required.

• When functionality within the script will require an extended amount of time to execute, set the script to run asynchronously with a timeout limit. Such functionality is sometimes required by COM objects and .NET objects (for example, file operations, SQL queries, and so on).

• When creating scripts at the template level, you may want to lock them. You can then make changes to the template script, and the changes will propagate to the next level. When a script is locked and there are no declarations or aliases, these sections should also be locked for improved propagation and deployment performance.

• When the field devices have a structured containment and addressing convention, create a script that will populate all attributes with an I/O extension at the time of deployment. If instances have been configured using this method, you can use the "Upload Runtime Changes" functionality to synchronize the changes back to the Galaxy Repository.

• When adding scripts to templates, use relative names (Me, MyContainer, MyEngine, MyArea, MyPlatform, and MyHost). Using relative names saves you from having to edit absolute references in every instance.

• Lock all inherited scripts, otherwise a copy of each assembly/script will be created for each object derived from the template and multiple copies of the same script will be running on the AppEngine object where they are deployed.

  Locking the scripts generates one single assembly to be deployed to the AppEngine. The assembly is then shared by all instances derived from that template.

  Note: For more information on scripting, methods, and practical examples, refer to the Application Server Scripting Guide.

Script Execution Types

The script execution types and when they should be used are as follows:

• Startup: Called when the object is loaded into memory. Primarily used to instantiate COM objects and .NET objects.

• OnScan: Called the first time an AppEngine calls this object to execute after the object scan state is changed to onscan. Primarily used to initiate attribute values.

• Execute: Called every time the AppEngine performs a scan and the object is onscan. Supports conditional trigger types of On True, On False, While True, While False, Periodic, and Data Change. Most run-time functionality is added here.

• OffScan: Called when the object is taken offscan. Primarily used to clean up the object and account for any needs that should be addressed as a result of the object no longer executing.

• Shutdown: Called when the object is about to be taken out of memory, usually as a result of the AppEngine stopping. Primarily used to destroy COM objects and .NET objects and clean up memory.