Impact of reject levels and exit localizations

When executing a DML Block or an event, the following endings are possible:

  • All operations succeed, the DML Block execution is completed successfully.
  • Something failed, an error is detected.
  • reject exception is raised because exit reject was executed.
  • rejectMessage exception is raised because exit rejectMessage was executed.

Both reject and rejectMessage exceptions lead to transaction rollback and might trigger the error event. The main difference lies in the scope of the rollback.

The scope of the reject exception is always limited to the current transaction. When raised in data processing, only actions performed while mapping the current instance (if recovering is enabled) or the complete input message (if recovering is disabled) are canceled. Operations related to start and end events are out of scope.

With this exception, the error event is triggered if defined and then control is transferred back either to the processing of the next instance, when recovering is enabled, or directly to the end event. If no end event is defined while recovering is disabled, the whole process is finished.

Used in conjunction with error recovering, the reject exception might lead to the acceptance of the input message with the segregation between correct and faulty instances it contains. When error recovering is disabled, the input message is always rejected.

The rejectMessage exception scope is always global: wherever and whenever this exception is raised, all actions related to the processing of data contained in the input message are discarded. Although start and end transactions are still segregated, the raise of rejectMessage cancels all instance transactions.

As a consequence, when error recovering is enabled, a global rollback operation might be performed that rolls back transactions related to each already processed input instances. In such situation, instance transactions are distinct but bound together and therefore rolled back as a whole.

Unlike reject, the rejectMessage exception always rejects the input message. When occurring in the start event, no input data is processed: control is directly transferred to the end event if defined, or directly finished otherwise.

With multiple situations and actions, the behavior of the engine is quite complex to describe. The following diagram tries to make things clearer:

Impact of reject levels and exit localizations

In this diagram, the process begins and ends with the double-circle steps start, message accepted, and message rejected. The blue boxes symbolize the execution of sub-networks of DML Blocks that are related to events or data processing main stream.

Commit and rollback actions are pictured with green and brown circles; they usually operate on the current transaction, except for global rollback that cancels all instance transactions when error recovering is enabled.

The empty blue circle is there for ease of reading: it concentrates several incoming paths before the definition of the end event is determined.

Related Links