Dated Effectivity Based Consolidation: Default Behavior
One of the major aspects of the consolidation engine of ShareAspace is the capability to update or not to update the period of validity of the data (i.e. dated effectivity start and end dates) in regards to the data being uploaded.
There are a series of consolidation settings that work on this aspect and this article details the default behavior of the consolidation engine (i.e. when no settings are actually used).
Here is the statement of principle:
Important
The ShareAspace Consolidation engine default logic regarding effectivity controlled data is such that it always adds data to the history making it possible to maintain an audit trail of the information.
Any conflicting and overwriting situation is not allowed by default and will stop the consolidation process of such a data. This can be forced using an appropriate consolidation setting.
In the article, the following graphical conventions are used:
- A square shape represents a root object (or a Unit of Information) of the ShareAspace model
- A circle shape represents an effectivity controlled relationship (or characteristic) that the root object is having with another object
- A dotted end line represents the effectivity timespan of the corresponding relationship
Please note that the different ECR (Effectivity Controlled Relationship) are matching according to their uniqueness evaluation (same type, same identifier or same referenced object, same role, etc ...).
For simplification reasons, those details are hidden in the following diagrams.
Appending information to the end of an open history
When the end date of an effectivity controlled relationship is open in the ShareAspace store and an imported relationship, which satisfies the uniqueness to be the same, is set to start after the start of the one in the ShareAspace store, the consolidation engine is, by default, closing the one in the store and adding the incoming one to the store.
The following sample shows a root object with a single instance of an effectivity controlled relationship (ECR1) valid from a given start date (no end date) in the store.
The same root object is imported with the "same" effectivity controlled relationship (ECR2) valid from a date after the one in the store (no end date).
The consolidation engine will set the end date effectivity of ECR1 to the start date of ECR2 and will add ECR2 to the root object.
The previous case would work in a similar way if the imported effectivity controlled relationship was closed (i.e. effectivity end date set).
The following sample shows a root object with an existing history of an effectivity controlled relationship (ECR1 and ECR2) for which the last historical entry (ECR2) has no end date.
The same root object is imported with the "same" effectivity controlled relationship (ECR3) valid from a date after the last historical entry in the store (no end date).
The consolidation engine will set the end date effectivity of ECR2 to the start date of ECR3 and will add ECR3 to the history of the root object.
Same "Child" Situation
A same "Child" situation is a case when the imported data is matching the existing data with an additional criteria to the ones used by the uniqueness rules. That additional criteria is simply the same pointed at value or object (i.e. the same child).
Note
In the following, actual details are intentionally hidden for the purpose of clarity.
Let's illustrate this with the NextAssemblyUsage (NAU) object which is an Effectivity Controlled Relationship (ECR).
The following 2 NAUs are the same according to the uniqueness rules if they are conflicting in the effectivity time span.
It basically means they cannot exist within the same effectivity time span according to the uniqueness rules.
The same "Child" situation is the case when Part B and Part C are the same.
In some same "Child" situations, there is a need to update the NAUs instead of creating 2 NAUs.
Here are the cases supported by the default behavior of the consolidation engine.
Case 1
The same "Child" is imported with an open ended effectivity span starting after the one already open ended effectivity in the store.
In this case the imported data will be simply ignored by default.
Case 2
The same "Child" is imported with a closed ended effectivity span starting after or exactly on the same start date as the last one already open ended effectivity in the store.
In this case the imported data will be considered as a "close effectivity instruction".
Note
To summarize, in same "Child" situation, the default behavior keeps the effectivity start date in the store unchanged.
Inserting information in a discrete history line
When the history line of an effectivity controlled relationship in the ShareAspace store is not continuous (i.e. discrete), and the imported relationship is marked out and fitting in between 2 discrete steps or outside all steps (before or after), the consolidation engine is, by default, inserting the imported relationship into the store.
The following 3 samples are illustrations of such a case.
The following sample shows an insert into a discrete history line:
The following sample shows an insert "after" into a discrete history line:
The following sample shows an insert "before" into a discrete history line:
Failing consolidation cases
Any incoming information that modifies either the beginning or existing effectivity marked out time spans will be blocked by the default behavior of the consolidation engine.
The history line that was in the store before the incoming data is left unmodified.
In some cases those modifications are actually required. For such situations, it is recommended to use an appropriate consolidation settings to bypass the default behavior of the consolidation engine.
The following samples are illustrations showing when the default behavior of the consolidation engine will block the incoming data to be added to the store.
Conflict with the history start
The following sample shows a tentative of redefining the beginning of the history that is already in the store.
This situation is blocked by the default behavior of the consolidation engine but can be allowed by the ForceRedefineHistoryStart setting (see next article).
Conflict with the history end
The following sample shows a tentative of redefining the end of the history that is already in the store.
This situation is blocked by the default behavior of the consolidation engine but can be allowed by the ForceRedefineHistoryEnd setting (see article).
Partial and total conflicts
The following sample shows a tentative total overwrite of the existing marked out effectivity timespans in the store.
This situation is blocked by the default behavior of the consolidation engine because it would result in deleting existing entries.
The following sample is another illustration of the previous case.
This situation is blocked by the default behavior of the consolidation engine because it would result in deleting existing entries.
Effectivity Consolidation Error Messages
Whenever a failing effectivity consolidation case is hit the error message will indicate:
- the evaluated effectivity consolidation rule
- the source (imported) object and its characteristics
- the target object (in the store) and its characteristics
- the
evaluation code
Below is the list of possible evaluation codes for effectivity consolidation situations. The last 5 columns indicate which consolidation setting allows the corresponding matching situation:
- RC: ForceReplaceHistoryForSameChild (->)
- DE: Default behavior (->)
- FC: ForceRedefineConflictingEntries (->)
- FS: ForceRedefineHistoryStart (->)
- FE: ForceRedefineHistoryEnd (->)
| Evaluation Code | Effectivity Situation | RC | DE | FC | FS | FE | |
|---|---|---|---|---|---|---|---|
| NoMatchJustAfter |  |
⚫ | |||||
| NoMatchJustBefore |  |
⚫ | |||||
| NoMatch |  |
⚫ | |||||
| PartialMatchEnclosing |  |
⚫ (3) |
⚫ (4) |
⚫ | |||
| PartialMatchSameStart |  |
⚫ (3) |
⚫ (4) |
⚫ | ⚫ (1) |
||
| PartialMatchSameEnd |  |
⚫ (3) |
⚫ | ⚫ (2) |
|||
| PartialMatchAtStart |  |
⚫ | ⚫ (1) |
||||
| PartialMatchAtEnd |  |
⚫ | ⚫ (2) |
||||
| FullMatchFromStart |  |
||||||
| FullMatchSameEnds |  |
||||||
| FullMatchAtEnd |  |
||||||
| FullMatchBothEnds |  |
(1) only when the target is the first entry in the history
(2) only when the target is the last entry in the history
(3) only when the target and source have the same "Child"
(4) only when the target and source have the same "Child" and target effectivity is open ended