Skip to main content

Main Object Scope

The main idea of the Main Object Scope solution is that the transactional scope is implicitly determined by the main persistent object of the transaction. This pattern, found in customer implementations, is easy to implement but can be tricky. It is likely only valuable when data changes are highly localized to one primary object and its immediate, associated children.

Example: Main Object Scope

Imagine you update several Order-lines in an Order, and the total Order amount needs to be recalculated based on those order line amounts. Both the updated Order-lines and the Order itself, which changes automatically, must be saved in a single transaction. In this situation, the Order can be used as the Main Object. The Commit Microflow Typology (CMT) can then use the Order to find all related order lines that need to be committed.

warning

If an item isn't connected to the Main Object, the system won't know to check it, defeating the "all or nothing" principle.

1. Core Mechanism and Discipline​

This pattern requires discipline to ensure that Atomicity (the "all or nothing" guarantee) is maintained:

  1. Scope Definition: The scope includes the Main Object itself and all associated objects that have been created, modified, or deleted during the process.
  2. Mutation Tracking: Each associated object (such as an OrderLine) must be tracked using a MutationStatus attribute (e.g., Created, Changed, Deleted).
  3. Commit Logic: The Commit Microflow Typology (CMT) must retrieve the Main Object and then retrieve all associated objects. It then filters this collection based on the objects' MutationStatus before executing the final commit actions.

2. Implementation choices​

Resetting the object MutationStatus​

The MutationStatus should only be reset (to 'Empty' or 'Processed') after the final commit succeeds. While using an After-Commit Microflow is a common way to implement this cleanup, caution is required. If the cleanup fails, the original commit is not rolled back, which can cause status inconsistency.

Implementing Atomicity:​

To guarantee Atomicity, the CMT Microflow must include robust Error Handling to explicitly abort the entire server transaction if the database commit action fails. This ensures that the system does not leave data in a partially saved state.

3. Advantages & Disadvantages of the Solution​

Advantages​

  • There is no need to create and pass lists of changed objects through the microflow hierarchy.
  • All objects possess a mutation status that clearly indicates their state.

Disadvantages​

  • The retrieve action executed by the CMT microflow pulls a large number of non-mutated objects into memory before they are filtered to find the mutated objects.
  • If objects that need to be committed are not associated with the Main Object, you still need to use elements of the List Based Scope pattern.