Script Synchronization and Serialization
There may be need to avoid parallel execution of a script / multiple scripts because they may influence each other. Possible reasons:
- One execution generates a lock, 2nd (parallel) execution is blocked by this lock or cannot modify the content because it is read-only.
- Multiple logons with the same user ID are prohibited by profile parameter.
1. Use different user accounts for the same script on different robots: One account per robot, customized as variable in scope Robot.
schedule.offset.secs to set offsets.
Problem: The offset is relative to the script start. If not all robots are started at the same time the offset is arbitrary and only reliable within a single robot.
3. Use synchronization on robot level via semaphore parameters.
You want to avoid concurrent execution of script s1 and s2 on a single robot r.
semaphore.define.x = 1(type
integer) on scope robot r.
Defines a semaphore
xon this robot with 1 permit. Only one script execution assigned to use this semaphore
xcan be executed in parallel.
boolean) on scope script s1 and script s2.
Flags the script
sthat it must check out the semaphore
xfor execution. If some other script o has currently checked out x, the starting script s is blocked until script o has finished.
semaphore.define.y=5 would indicate that at most 5 scripts may be active in parallel on the robot.
A default semaphore
semaphore.define.default=1 is defined by default.
semaphore.use.default=true on scope Global would mean that on each robot there may be only one script active. But in total, multiple scripts may be active: one per robot.
You want to have two groups of scripts:
- Scripts s1 and s2 in group 1 may not be executed in parallel
- Two out of scripts s3, s4, s5 may be executed in parallel, independent from scripts in group1.
semaphore.use.default=false(do not use the default synchronization)
semaphore.define.group1=1(one at a time out of group 1)
semaphore.define.group2=2(two in parallel for group 2)
Scope script s1, script s2:
Scope script s3, s4, s5:
4. Use global synchronization across robots:
Global EEM semaphores reside once globally on the Solution Manager Java stack, whereas local EEM semaphores exist once independently on every robot. Global semaphores are identified via the infix
global in the configuration parameter:
semaphore.use.global.x. Do not confuse global semaphores with the configuration scope Global: global sempahores must be defined in scope Global, but you can also define a local semaphore y in the Global scope: This has the effect that the semaphore y is defined once on every robot - used for script synchronization on the robot, and users of the semaphore (scripts) can still execute concurrently on different robots.
semaphore.use.global.x=true defines a global lock with identifier
x for a script / several scripts.
Enqueue is used for locking: Use the Locking Adapter in Visual Admin to view locks or remove hanging locks.
Upon robot startup/shutdown, all locks for the robot are removed.
Locks older than 30 minutes are removed automatically when a script tries to acquire a lock.
Script will not be executed if no connection to Solution Manager is available (because lock cannot be obtained).
You can use multiple global locks for the same script, e.g.,
Unlike the robot local semaphores, global semaphore only authorize the execution of one script at a time.
I.e. the value value of the definition must be "1".
If another value is used, the semaphore initialization will fail when the robot starts.
5. Use absolute offsets:
Indicates that the
schedule.offset.secs is calculated relative to the operating system time of the robot. Time zones are ignored, .i.e., always UTC is used.
Prerequisite: system clocks on robot hosts are more-or-less in sync (use NTP!). Do sync the robots using NTP, you need to enable the robot PCs to sync their local time with a dedicated time server.
With this VBS Script you can easily sync a WIN XP client with your companies time server (some adjustement may be required for other OS). You have to change the file exentsion to .VBS in order to be able to execute it. Read the included Microsoft KB articles for more information !
6. Use CRON scheduling (new 7.2 SP08 and above)
CRON scheduling gives the possibility to define CRON-like expressions to indicate exactly when a script has to be executed.
A CRON like expression is composed of five sub-expressions for:
- months: which months of the year the script has to be executed,
- days of month: which days of the month the script has to be executed,
- days of week: which days of the week the script has to be executed,
- hours: which hours of the day the script has to be executed,
- minutes: which minutes of the hour the script has to be executed.
This is the union of the sub-expressions that indicates when the script has to be executed.
e.g. if an expression indicates the following sub-expressions:
- every month,
- every days of month
- days of monthdays of week = Monday, Tuesday, Wednesday, Thursday, Friday
- every hours
- every 10 minutes
The script will be executed from Monday to Friday.
And, on these days, every 10 minutes of the day hours. I.e.: at 00:00, 00:10, 00:20, 00:30, ..., 18:40, 18:50, 19:00, ....
Syntax of the expression
Supported CRON-like expressions have this format:
*:<months>:<days of month>:<days of week>:<hours>:<minutes>
- The sub-expressions are separated by a colon character (":")
- The expression always start with a "*" character.
Syntax of the sub-expressions
Sub-expressions are composed of the following characters:
- numbers (0 to 9)
- comma (,)
- dash (-)
- star (*)
- slash (/)
|sub-expression||meaning||example (if set in hour sub-expression)|
* = every hour of the day
|<number>||an exact matching item||10 = only at 10 AM|
|<number>,<number>||a list of matching items||10, 15, 17 = only at 10 AM, 3 PM and 5 PM|
|<number>-<number>||a series of matching items||10-17 = only between 10 AM and 5 PM (included)|
|*/<number>||every <number> items (starting at zero)||*/2 = every 2 hours of the day.|
i.e.: 0 AM, 2 AM, 4 AM, 6 AM, ... , 8 PM, 10 PM, ...
|<number a>-<number b>/<number x>||every <number x> items, between <number a> and <number b>|
8-18/4 = every 4 hours between 8 AM and 6 PM
i.e.: 8 AM, 12 AM, 4 PM.
The supported numbers depends on the level of the sub-expression.
|sub-expression level||allowed numbers|
|month||0 to 11|
0 = January, 1 = February, ...
|days of month||1 to 31|
|days of week|
1 to 7
0 to 23
|minutes||0 to 59|
Example of CRON expressions
|every minute||..., 10:00, 10:01, 10:02, 10:03, ...|
|every 10 minutes starting at the beginning of the hour||..., 10:00, 10:10, 10:20, 10:30, 10:40, 10:50, 11:00, 11:10, ...|
|every 10 minutes starting at the 5th minute of the hour||..., 10:05, 10:15, 10:25, 10:35, 10:45, 10:55, 11:05, 11:15, ...|
|every 10 minutes between 9 AM and 6 PM||..., 17:40, 17:50, 18:00, 09:00, 09:10, 09:20, ...|
How to use CRON scheduling
In the UXMon configuration,
- Go to Step 4 - Monitoring
- Select either the Script or Script on Robot tab
- Select the Script (or Script on Robot) to schedule with a CRON expression.
- In the Configuration Parameters, click the [Add] button
- In the "All Available Parameters" popup, select the schedule.cron.expression parameter and click [OK]
- Set the schedule.cron.expression parameter with the CRON expression you want to apply
The date / time considered by the CRON expression are in the robot local time.
If both the schedule.cron.expression and the standard schedule.period.seconds are set, then the CRON expression has the priority.
If semaphores are set, they have the priority over the define schedule (including the CRON schedule).