Each Precedent Change Set goes through a simple lifecycle as follows:
- Open
The state of a precedent change set when it is initially created. In this state new precedent change items can be added to the precedent change set.
- Submitted
The precedent change set has been submitted into dependent-identification processing. No more precedent change items can be added to the precedent change set.
- Complete
The recalculation of all dependents affected by the precedent changes has been completed. The precedent change set is kept for historical purposes only.
The transitions between each state occur differently depending on the mode in which precedent changes were captured:
- Queue for Deferred Processing:
- the transaction that captures the precedent changes opens a new precedent change set and submits it by requesting a deferred process; and
- the deferred process accepts the submitted precedent change set, identifies and recalculates affected dependents, and completes the precedent change set.
- Queue for Batch Processing:
- the transaction that captures the precedent changes writes them to the currently- open batch precedent change set;
- the suite of Dependency Manager batch processes performs the following steps:
- retrieves the currently- open batch precedent change set and submits it into the next step in the batch process, and creates a new open batch precedent change set to capture any further precedent changes identified1;
- performs streamed batch processing to identify and recalculate the dependents affected by the changes in the now- submitted batch precedent change set; and
- completes the batch precedent change set.
1 In a running system this is the way that a new batch precedent change set is created - i.e. by its predecessor being submitted.
Note though that the initial open batch precedent change set is supplied by a DMX file included in the application.