Scripting considerations

• When failover occurs, attribute values keep their initial states.

• Scripts and SQL connections to databases that were interrupted by the failover must be restarted.

• OffScan scripts are executed in the event of a forced failover.

• Any state, such as local variables or calculated attributes, that is not kept in checkpointed attributes is not passed to the objects started on the newly-active engine.

• If an attribute value is being passed to the database when failover occurs, the attribute returns to its initial value when the object goes On Scan in the new active Engine.

• Before the attributes can be updated, the database connection must be restored.

Script Behavior When the Standby Engine Becomes Active

When a standby engine becomes active, it sets the Engine.StartupReason attribute to indicate the startup cause. The attribute string can be accessed in a script to determine the startup reason. The following reasons are possible:

• Starting_AfterDeploy: Engine starts from standard deploy.

• Starting_From Standby: Engine starts from failover.

• Starting_FromCheckpoint: Engine starts from reboot or AutoStart configuration.

These attributes can also be used to execute scripts that re-initialize variables and COM objects.

After a failover occurs, scripts in the new Active engine are executed based on the trigger type they use i.e. Startup, On Scan, Periodic and Data Change.

Use Startup and OnScan scripts to initialize conditions used later in the script. In many cases the initialization is required only when the object is deployed/redeployed, or when the AppEngine and or platforms are restarted. In the case of a failover, the requirement may be to continue operating using values from the checkpoint rather than re-initializing the conditions.

The Redundancy.FailoverOccurred attribute is set to "True" for the first scan right after the failover occurs; after the first scan the attribute is automatically reset to "False." Using this attribute as a script condition initializing the variables prevents the script from running when the system recovers from a failover.

Similarly, Data Change scripts execute when the object is deployed, the engine re-started and the Standby engine becomes active after a failover. Using the Redundancy.FailoverOccurred in an "If-then-else" statement will prevent the script from executing after the failover.

Any script that is set with an Execution type of Execute and a trigger type of Periodic will have the following behaviors after an AppEngine failover. The situation is described using a period of 60 minutes as an example time period:

• The script executes the first time when the engine is deployed. E.g. T0.

• The next execution time will be 60 minutes later. E.g. T60.

• The redundant engine fails over and the Standby engine is fully running in the Active state at T30.

• The Periodic script(s) will restart with the period reset to T0.

The period for the execution of the Periodic script(s) will be shorter than planned for, or possibly longer if an engine failover occurs shortly before the time period elapses.

Some applications may have critical data generated by a Periodic script. Do not use Periodic type scripts where the time period could be shorter, or longer, and this is critical information being managed by this script. Instead, set up the script to run using a condition and set up an attribute for the trigger.

Then for a time base, use System Time and calculate the time period from this to set the condition. The attribute current value is maintained in the failover and the System Time is real time versus an expiring timer.

Shutdown and OffScan scripts will execute after an orderly completed failover, such as using ForceFailoverCmd, or in the event of Primary Network failure.

Asynchronous Scripts

QuickScripts must be evaluated to anticipate likely delays (SQL Query completion, calling COM or .NET objects.) due to network transport or intensive database processing. When a delay in script completion is likely, set the QuickScript to run asynchronously.

If not set to run asynchronously, it is possible that the non-asynchronous QuickScript could cause the engine to miss the following scan while waiting for the script to finish executing.

Note: The "Runs asynchronously" option must be manually selected within the Scripts tab page of the Object Editor; it is not set by default.

Once set to run asynchronously, the QuickScript will not be cut off when the scan is completed. When a problem occurs, the script could "hang" if the process never completes, as in the case of a SQL query that never returns a rowset or even an error message. When the QuickScript's ExecuteTimeout.Limit value is reached, the ExecuteError.Alarmed and ExecuteError.Condition attributes are set.

In this context, it is useful to monitor these attributes and log a message when the maximum timeout threshold is exceeded.