Workflow engine - transactions and events

Any operation on an entry in a collaboration area (such as release, reserve, move to next step, check in, and check out) is considered a workflow event. Certain workflow events are permitted to run inline, meaning, the events bypass the requirement to post to the database and process on the current Java™ virtual machine (JVM) within a transaction.

These workflow events are "posted" to the IBM® Product Master database and processed by a separate part of Product Master called the workflow engine. The workflow engine is a separate JVM. This means that while an event might have been "posted", it will not take effect until it is picked up and "processed" by the workflow engine. In some cases, Product Master processes the event immediately on the application server rather than posting the event to the workflow engine.

You can view the events that have taken place to an entry in a collaboration area so far by looking at the Collaboration Area Entry History.

The workflow engine will only pick up and process an event if it can see it. This means it must have been saved (posted) to the database. Therefore, a transaction can only exist within one JVM any work that is performed by the workflow engine cannot form part of a unit-of-work that is contained on Product Master main JVM (the application server). This means that if the event posting forms part of a transaction, it will not be seen until the unit-of-work is committed.

When you request a check in, check out, reserve, release, or move to a different step, you are posting an event to the workflow engine. If this posting is part of a transaction, the requested workflow event does not happen until the transaction is committed. This is known as asynchronous processing of the workflow event. However, in some cases, Product Master processes the event immediately on the application server rather than just posting the event for later processing. This is known as synchronous or "inline" processing of the workflow event, and in this case, the event takes effect immediately. When writing workflow step extension point logic containing workflow event functions, you need to consider whether each operation is synchronous or asynchronous, to ensure the correct behavior of your script. For more information, see Asynchronous and synchronous processing for workflow events.

Important: For greatest efficiency on workflow event processing, it is important that each workflow event contains an optimized item volume to process so the overhead that is associated with workflow event processing is amortized across the item collection. Also, ensure that workflow events are not posted at a rate faster than the rate at which workflow events can be processed from the workflow engine.