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, 2^nd (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.

Solutions

1. Use different user accounts for the same script on different robots: One account per robot, customized as variable in scope Robot.

2. Use 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.

Example 1:

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 x on this robot with 1 permit. Only one script execution assigned to use this semaphore x can be executed in parallel.

• semaphore.use.x=true (type boolean) on scope script s1 and script s2.
  Flags the script s that it must check out the semaphore x for 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.

Example 2:

A default semaphore semaphore.define.default=1 is defined by default.

Setting 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.

Example 3:

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.

Scope robot:

• 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:

• semaphore.use.group1=true

Scope script s3, s4, s5:

• semaphore.use.group2=true

4. Use global synchronization across robots:

semaphore.use.global.x=true
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., semaphore.use.global.x=true and semaphore.use.global.y=true

5. Use absolute offsets:

schedule.absolute.offset=true

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>

Note:

• 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 (/)

The supported numbers depends on the level of the sub-expression.

Example of CRON expressions

How to use CRON scheduling

In the UXMon configuration,

1. Go to Step 4 - Monitoring
2. Select either the Script or Script on Robot tab
3. Select the Script (or Script on Robot) to schedule with a CRON expression.
4. In the Configuration Parameters, click the [Add] button
5. In the "All Available Parameters" popup, select the schedule.cron.expression parameter and click [OK]
6. Set the schedule.cron.expression parameter with the CRON expression you want to apply
7. Save