About Suspension Stages

Suspend-validating stage

When an application event is suspended, in what is known as suspend-validating stage, the system:

1. Begins a database transaction.
2. Performs an update to the database to validate pertinent data against any SQL constraints or triggers.
3. Validates the data by running all effective event handlers that are synchronous and not suspended in the current transaction.

   This process involves both application and event system changes:

   • At the beginning of this process, in a separate event transaction, the system copies the event handler to a new revision, if necessary.

     The reason for this is that both the suspend-validating mode and the suspend-committing mode must use the same metadata. However, the validating transaction will be rolled back, and the master transaction may be rolled back. So, the current event handler revision must be available, in case someone edits the handlers between execution of the two modes.

   • During this process, a non-output event parameter named Suspend_ValidatingMode with a value of 1 is made available to handlers.

     You can test this on any synchronous, non-suspended handlers that you do not want to execute at this time (perhaps because its actions would irreversibly affect something not controlled by our database transaction), using the expression CONDITION( E(Suspend_ValidatingMode)<>1).

     Note: At this point, the application event system treats any failure as an error and exits the execution of the application event.
4. Rolls back the transaction
5. Places a task on the event queue to run all involved handlers in suspend-committing mode.

   If the collection update is rolled back due to a later error, this suspension is also rolled back with it and results in a state identical to one in which this update was never requested.

   When the application event service picks up the queued event, it knows that a suspension is in effect by checking the EventQueue.Suspend attribute.

6. The system marks the record involved in the update/deletion request to have the InWorkflow property set to 1. This prevents any user from attempting another change to the suspended record. Note that suspended insertions do not reach the database at all unless and until the suspended event finishes successfully.
   Note: Suspended records in a workflow are indicated as such by a purple icon in the status indicator column of a grid.
7. The thread in which the event was generated continues as if the change request succeeded. This occurs even if the thread originated from an event handler executing an UpdateCollection or ExecuteIDORequest type event action. In other words, suspension affects only one level of event execution.

Suspend-committing stage

Once the suspended event completes the suspend-validating mode successfully and is placed on the event queue, the system processes the event using these rules. This is known as the suspend-committing stage.

• Any failure or error condition prevents further event handlers to execute and prevents the standard processing (requesting for insertion, update, or deletion) to occur. However, the InWorkflow attribute is cleared.
• After each event handler finishes successfully, execution proceeds to the next event handler.
• The system queues any asynchronous event handler and execution proceeds to the next event handler.
• When the last event handler is finished, or is queued successfully, the standard processing is committed and the application event is finished.
  Note: For an update request, the InWorkflow attribute is cleared.