Run Script Actions

The script is run in parallel with all actions that are being executed for the event. In other words, the Basic Control Engine does not wait for the script to complete before it initiates the next action defined for the event.

To add an existing script:

1. Select the Browse button .

2. Select the script you want to add to the action.

3. Select OK.

To add a new script:

1. Select the Popup Menu button .

2. Select New.

3. Select the Script type.

4. Enter a name for the script in Script text box.

5. Select OK. The corresponding script editor opens.

6. Edit and save the script.

When the event to which the script is added occurs, the script gets executed. You can view the status of the script execution in the BCE User Interface.

Note: The selected script name cannot have more than 48 characters. If you try to select a script with a name longer than 48 characters CIMPLICITY will display an error message and will not allow you to use it.

Types of Script Execution

When a configured event with a script action is triggered, the script can be executed in the following ways:

• In sequence
• In parallel (includes thread pool)

To configure an event with the type of script execution, see Step 3.2. Enter Advanced Event Specifications.

You can run scripts in parallel if they wait on Input/Output (I/O) operations for extended periods of time. This will support running more threads.

You can run scripts in sequence if they interact with an external system that cannot perform multiple operations in parallel.

The set of threads used to run scripts in parallel or in sequence are managed by a common thread manager. The CE_MAX_THREADS global parameter controls the maximum number of threads the thread manager will use to run scripts, and decides when and if the script will be run.

• If there are fewer than CE_MAX_THREADS scripts currently running in parallel, the script will be run immediately.
• If there are CE_MAX_THREADS or more scripts running in parallel, the script is discarded and a Too many executing threads, action ignored message is logged to the status log.
• If there is another script running in sequence for a configured event and there are fewer actions queued than the maximum queue size of the configured event, the script is queued.
• If there is no other script running in sequence for a configured event and there are fewer than CE_MAX_THREADS scripts currently running in sequence, the script is run immediately.
• If as many actions as the maximum queue size of the configured event are queued, the script running in sequence is discarded and an alarm is generated and/or a message is logged to the status log depending on the configuration of the event.
• If there is no other script running in sequence for a configured event and there are CE_MAX_THREADS or more scripts currently running in sequence, the script is discarded and a Too many executing threads, action ignored message is logged to the status log.

• If there are fewer than CE_POOL_THREADS scripts currently running, the script will be run immediately.
• If there are CE_POOL_THREADS or more scripts running, the script is queued.

To configure the CE_MAX_THREADS and CE_POOL_THREADS global parameters:

• Select Project, and then select Properties.
• In the Settings tab of the Project Properties dialog box, select Event Editor, and then select Settings.
• In the Setup dialog box, select the Set thread pool size to option, and enter a number.

Notes

• The thread pool size ranges between 0 and 200, and when calculated automatically will be twice the number of logical processors in the system. When the size is set to 0, its size is automatically calculated.
• CE_MAX_THREADS should be set to the expected number of simultaneous events. The actions of the surplus events triggered will be ignored.
• The maximum number of script actions that can run simultaneously is CE_MAX_THREADS + CE_POOL_THREADS.
• BCL and .NET scripts share the same set of threads.
• When a script is started, it can run in any available thread.
• The CE_THREAD_TIMEOUT global parameter controls the number of seconds a thread managed for parallel and sequential events will be idle before it is freed. This period should be long enough so that regularly executed events do not need to create threads, but short enough so that infrequent events do not cause the event manager to consume an abnormal amount of memory for extended periods of time.
• The CE_MIN_STANDBY_THREAD_COUNT global parameter controls the number of threads allowed by the event manager to be idle indefinitely. Threads that are idle for CE_THREAD_TIMEOUT seconds will not be freed if there are CE_MIN_STANDBY_THREAD_COUNT or fewer threads in the idle state.

Variable scope and lifetime

In BCL, you can declare public or private variables at the module level, outside of any function. In .NET, you can declare static or instance variables at the class level, outside of any function.

The following table provides the differences between BCL and .NET variables:

In the previous table:

• Scope of variable - Denotes the visibility of the variable to other script files, such as modules and AppDomains.
• Lifetime of variable value - Denotes how long the value of a variable will last.
• Shared - Denotes if two or more event instances will share the value of the variable.
• Multi-threading issues - Denotes if multi-threading issues occur when multiple instances run at the same time.