Examples of Sync Objects

This topic describes two typical application areas of Sync objects.

Example: You want to control the access to the database

In this example you want to make sure of the following

  1. Create a Sync object with the following two states:

    • EXCLUSIVE
    • SHARE

  2. Associate these states with the following values:

    • 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 topic).

    XXX

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

    • 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

  5. The following happens:

    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.

Example: You want to synchronize the execution of two Jobs in two different Workflows

Two processes in your organization are completely independent from each other. You have created two Workflows to automate them, which also run independently. They are WORKFLOW_A and WORKFLOW_B.

Workflow A has two Jobs, JOB_A1 and JOB_A2. Workflow B has two Jobs, JOB_B1 and JOB_B2.

The Jobs cannot run simultaneously. They must be executed one after the other, each in its respective Workflow.

WORKFLOW_A must finish before WORKFLOW_B can start, which means that JOB_B2 cannot start before JOB_A1 has ended.

  1. Create the SYNC object.

    The EXAMPLE_STATE SYNC object maps the state of JOB_A1 and contains two states:

    • DONE, which means that processing is completed
    • READY, which allows processing

    XXX

    Executable objects to which you assign this object can trigger its predefined actions. In our example, we do not use values but we define the following actions:

    • SET_READY

      When the SYNC object has state DONE, this action is triggered. As a result of this action, the READY status is set.

      Thus, this action can only be executed when a process has been completed.

    • SET_DONE

      When the SYNC object has state READY, this action is triggered. As a result of this action, the DONEstatus is set.

      Thus this action can only be executed when it is ready for processing.

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

  3. 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).

  4. Execute the workflows and watch the result.

    • WORKFLOW_A and WORKFLOW_B run simultaneously. Their status is ACTIVE.
    • JOB_A2 is waiting for JOB_A1 to complete. This is the normal processing order of the Workflow.
    • JOB_A1 is running. Its status is ACTIVE.
    • JOB_B2 is waiting for the state of the Sync object to change to DONE. As JOB_A1 is still running, the Sync object has the state READY. Only when JOB_A1 has ended will the Sync's state changes to DONE. This is when the JOB_2 starts.

See also: