Event-Based OIEP Order of Delete Events

The order of processing delete events via an event-based OIEP is guaranteed in the following cases:

  • For hierarchies (products, classifications, etc.), the deletion of a child occurs before deleting the parent.
  • For references, the deletion of the reference occurs before the target can be deleted. A source owns a reference, which means triggering a delete event on the source must be completed before deleting the target.

Impact of Transactions

The method used to create transactions also determines if each transaction generates its own event, or if multiple transactions are collected to create a single event. For more information about transactions, refer to the Database Transaction Methods section of the Core Events topic in the System Setup documentation here.

The order of events being processed is influenced by the generation and commitment of transactions.

  • If the same user makes multiple deletions for the same object from the same Web UI, the deletions order is guaranteed.
  • If the same user makes multiple deletions for different unrelated objects from the same Web UI, the deletion order is not guaranteed.

Unrelated Object Event Order Processing

When working with unrelated objects, processing occurs based on the order events are read from the queue. This means that the order for processing delete events for unrelated objects can vary.

For example, consider the following time line and results for products in different hierarchies and without any references between them.

Time Line

The following two users log into their own Web UI and make the following edits:

  • 8:00 a.m. - User 1 logs into Web UI 1 and deletes Product A
  • 8:15 a.m. - User 2 logs into Web UI 2 and deletes Product Z
  • 10:00 a.m. - User 1 continues to use Web UI 1 and makes changes to Product B

Results

Since two users are making the edits, the deleted products are not related, and considering the transaction impact (defined below), the processing order of the events could be:

  • If the queue is read at 9:00 a.m., the processing could start with the deletion of Product Z, and then the deletion of Product A.
  • If the queue is read at 11:00 a.m., the processing could start with the deletion of Product A, then the deletion of Product Z, and finally the changes to Product B.