Registration

Dear SAP Community Member,
In order to fully benefit from what the SAP Community has to offer, please register at:
http://scn.sap.com
Thank you,
The SAP Community team.
Skip to end of metadata
Go to start of metadata

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.

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 (new 7.1):

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.define.global.x and 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
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

Use absolute offsets (new 7.1, downported to SP23P1 (SP07P1), SP08  and up):

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 !

  • No labels