Applying changes details

This section describes the rules PolicyCenter uses when applying changes for preemption (and future renewals). In this topic, the phrase the same object means objects with the same fixed ID (matching FixedID property values). The fixed ID is discussed further in Policy revisioning.

To continue a preempted job PolicyCenter needs to:

  1. Create a new branch based on the most recently bound branch. PolicyCenter does this to ensure that no legally-binding changes are lost.
  2. Next, PolicyCenter calculates changes between the preempted branch (the one that did not yet bind) and the one it was based on.
  3. Finally, PolicyCenter applies those changes to the new branch.

To calculate branch differences, PolicyCenter generates a set of difference item objects (DiffItem objects) at a low-level database level. Each difference item represents a change, such as a new object, a deleted object, or a change in a property. PolicyCenter represents these different types of differences with subclasses of DiffItem:

  • New entities generate a DiffAdd object.
  • Removed entities generate a DiffRemove object.
  • Changed properties generate a DiffProperty object.
  • Window changes (effective/expiration window) changes generate a DiffWindow object.

PolicyCenter uses different rules for applying changes for preemption based on each difference item subclass. The rules are similar but slightly different between preemption and applying changes to a future renewal.

The rules cover two aspects of applying the difference item in different cases:

  • Can this difference item subclass apply to the new branch? Whether the DiffItem can apply to the target branch. This essentially attempts to detect whether there is a potential conflict. This corresponds to each DiffItem subclass’s method canApplyDiffToBranch.
  • How to apply this difference to the branch? If a difference item can apply to the target branch, how to perform it? This corresponds to each DiffItem subclass’s method applyDiffToBranch.

The rules for applying changes to a renewal period are similar to the rules that govern handling a preemption. The major difference is that for applying changes to a renewal period, PolicyCenter only cares about applying changes effective at the end of the prior period. Only changes at the end of the period would naturally extend into the future renewal period. If a change in the prior period does not extend to the end of the period, PolicyCenter ignores it and does not consider it a conflict. PolicyCenter handles future renewals based on whether the future renewal is already bound. For information on how PolicyCenter handles the timing of applying changes, see Applying changes to future renewals.

The following table lists the rules for each difference subclass for both preemption and also for applying changes to future renewals:

Type

For preemption, can apply change?

For preemption, how to apply change?

For future renewal, can apply change?

For future renewal, how to apply change?

DiffAdd

Yes.

Add entity instance to the new branch. In very rare cases where the period ranges of the preemption branch is different than the preempted branch, the entire entity instance does not fit into the new range. In this case, it shrinks or expands as necessary.

Yes.

Add entity instance to the new period as it looked at the end of the prior period. In the renewal branch it adds for the entire period range. Scalable properties adjust accordingly. If the entity instance terminates in the prior period before the period end, it does not add to the renewal period.

DiffRemove

Only if the removed entity instance exists in the new branch at the date when it was removed in the preempted branch.

Remove the entity instance on the new branch at the expiration date.

Only if the removed entity instance exists at the start of the renewal period.

Remove the entity instance at the start of the renewal period. This effectively removes it entirely from the new branch.

DiffProperty

For a slice mode edit:

  • Only if the changed entity instance exists on the preemption branch at the effective date of the change.

For a non-slice edit:

  • Only if the changed entity instance exists on the preemption branch at the effective date of the change and two entities effective ranges match. This means that the entity instance has not sliced differently in the new branch (a rare case).

Get the entity instance on the preemption branch at the effective date of the change and set the property.

If the changed entity instance exists at the start of the renewal period.

Apply the property change only if the change in the prior period is effective through the end of the prior period’s range. If it is, then set the property at the start of the renewal period. Otherwise, the change is ignored.

DiffWindow

No. It is always a conflict.

Not applicable.

No. It is always a conflict.

Not applicable.