Examples of Sync Objects

This topic describes a typical application area of a Sync object. It shows how a Sync object controls access to a resource (in this example, a database).

ClosedExample 1: You want to control the access to the database

In this example you want to make sure that

1. Create a Sync object with two states:

It is important to give the states names that you can later on easily recognize.

2. Associate these states with the following values:

State Value
EXCLUSIVE

0 - only one task can use the database

SHARE 3 - up to 3 tasks can access the database simultaneously

The value numbers are not explicitly written to the Sync object, they are integrated as soon as actions are defined (see below in this document).

XXX

3. Define the following 4 actions in the Action Definition section:

State Value
USE

Normal (shared) database access.

This action can be triggered if the Sync object is in SHARE status with a value below three. It keeps the current status, but the value increases by one. It is intended for normal tasks that access the database.

The tasks check whether multiple database usage is possible; they also check if the value lies below three because only three tasks are allowed to access the database simultaneously. The value increases by one because one more task is now using the database.

USE_EXCLUSIVE This action can be triggered when the Sync object is in SHARE status with value zero. This action is only possible if no other task uses the database.
RELEASE

Release after normal (shared) access

A normal task has used the database and is now terminating. The existing status remains but the value decreases by one.

RELEASE

Release after exclusive access

A task that has used the database exclusively now terminates and, in doing so, shared use of the database is possible again.

XXX

The order in which you define the actions is relevant; the first one is the start status of the Sync object when applied to an executable object.

4. Assign the Sync object to an executable object

In our example, we assign the Sync object to a job. When processing this job, access to the database should be possible for other tasks, so we will choose the USE action:

XXX

And this is how it works:

  1. The job starts and executes the USE action.
  2. It checks whether the database can currently be used multiple times (shared use) and counts the number of tasks using it. The job can only be started if fewer than three tasks are using the database.
  3. The action defined in "Else" is processed if the limit of 3 tasks has been reached. In this case, the job waits until one of these tasks has ended.
  4. As soon as that occurs, the waiting job starts, and either accesses the database successfully or aborts and the RELEASE action is processed.

ClosedExample 2: You want to synchronize the execution of two jobs in two different workflows

The order of tasks within a workflow is clearly defined by the lines linking them. But what about tasks which are part of different process plans and should still be executed interdependently?

There are two methods to solve this issue:

The first method is easily implemented and provides a clear structure and overview; it is therefore highly recommended. This example shows how to use the second one.

In our example, two workflows (WORKFLOW_A and WORKFLOW_B) include jobs (JOB_A1, JOB_A2 and JOB_B1, JOB_B2) that cannot run simultaneously. They must run one after the other each in its respective workflow, namely JOB_B2 must not start before JOB_A1 has ended.

1. Create the SYNC object

We create the EXAMPLE_STATE SYNC object, which maps the state of JOB_A1 and will contain two states:

XXX

Executable objects that have this object assigned can trigger its predefined actions. In our example, we will not use values. We define the following actions:

2. Assign the SYNC object to JOB_A1

This job is part of WORKFLOW_A; it has no START action. When it ends, it triggers the SET_DONE action in the Sync object. As a result, the state DONE (end of processing) is set. A necessary precondition is that the current state is READY (for processing).

2. Assign the SYNC object to JOB_B2

This job is part of WORKFLOW_B2. It starts with the SET_READY of the Sync object. This action can only be carried out when the current status is DONE. This can only be the case when JOB_A1 has been completed. At the same time, this action sets the status READY (for processing).

3. Execute the workflows and watch the result

See also: