Processing mapping sets

Last modified 12 Mar 2021 10:22 +01:00

See Mapping for background information.

Evaluation of mapping sets converts source object into a set of item deltas to be applied on this (or other) object. It consists of evaluation of the mappings (probably chained because of mutual dependencies) and of consolidation of output triples into item deltas.

Compared with single mapping evaluation it provides the conversion of output triples into item deltas, applying settings for individual mappings, namely the strength (normal, strong, weak).

Mapping set evaluation

Mapping set evaluation

This is basically repeated evaluation of individual mapping, with the only exception: mapping chaining.

Mapping chaining

Individual mappings in mapping set can have mutual dependencies: target item of mapping A can be a source of mapping B. Such cases have two consequences:

  1. A must be evaluated before B.

  2. Before starting evaluation of B, we must create an intermediate version of sources for mapping B. Sources derived from original source object are no longer adequate. When determining updated sources, interim consolidation has to be run.

(This interim consolidation is currently implemented not very precisely. We need to analyze it in more depth eventually.)

Consolidation

Consolidation is a process of converting output triple map to item deltas, considering source object along with its pre-existing delta. Because this process is executed independently for each item in question, we can describe item consolidation that converts single output triple to an item delta, considering source item-delta-item. In some cases the actual value of item is not known: this can occur if we are consolidating values for resource object attribute, and we do not have full shadow for the object.

Item consolidation

Item consolidation

Item consolidation goes strictly "by value". In each step we take one of values present in the delta set (from plus, minus, and zero sets) - let’s call it v0 - and identify its presence in the delta set triples as well as in existing item. By "presence" we mean set of values equivalent with v0 under specified value matcher or comparator (or IGNORE_METADATA comparison if none of these two is specified). [1]

Item consolidation detailed

The algorithm then goes like this (slightly simplified - assuming mapping selector is ALL and exclusiveStrong is false):

Let:

Symbol(s) Meaning

P, M, Z

Sets of values in plus, minus, and zero sets, respectively. So P = { v1plus, v2plus, …​, vkplus }, M = { v1minus, v2minus, …​, vlminus }, Z = { v1zero, v2zero, …​, vmzero }

P0 ⊆ P, M0 ⊆ M, Z0 ⊆ Z

Sets of values-with-origins having values equivalent with v0 in P, M, and Z, respectively. Because of value equivalence we can view these as simply origins or mappings. In the figure above they are depicted in pink. (In real algorithm implementation they are filtered using strength selector and construction validity check.)

addUnchanged

Consolidation parameter that tells that all unchanged (zero-set) values should be considered for "add" part of resulting item delta. It is typically set to true when the whole target object is being added. (And also for attribute reconciliation when apriori delta is REPLACE.)

addUnchangedValuesExceptForNormalMappings

Consolidation parameter that tells that some of the unchanged values should be considered for "add" part of resulting item delta. In particular, all values backed by strong, weak, and sourceless normal mappings. It is set for object template evaluation for focus or personas and assigned focus mappings evaluation. It may be renamed/changed in the future.

existingItemKnown

Consolidation parameter that tells that we know the existing item. It is false for resource object mappings that operate on non-full shadows.

vex

Presence of v0 in existing item. (May be null if v0 is not present there or if existing item is not known.)

Deletion of strongly-mandated values

Before the value is consolidated the following check is executed:

If v0 is deleted by apriori delta and, at the same time, it is present in P or Z in connection with strong mapping (i.e. there is a strong mapping for v0 that thinks the value should be added or unchanged) then we throw an exception. This is to avoid conflict between user-provided delta and a strong mapping. [2]

See IvwoConsolidator.checkDeletionOfStrongValue() method.

Value consolidation

First, we determine A0 - origins that suggest we need to put v0 to the delta "add" set. These are:

Condition A0 (add-suggesting origins for v0)

addUnchanged

P0 ∪ Z0

¬ addUnchanged ∧ addUnchangedValuesExceptForNormalMappings

P0 ∪ { z ∈ Z0 | z.isStrong ∨ z.isNormal ∧ z.isSourceless ∨ z.isWeak }

otherwise

P0

There are the following cases:

Condition Description Action

A0 ≠ ∅

At least one mapping indicates that v0 is being added.

We invoke "value being added" part of the algorithm (see below).

A0 = ∅

No mapping indicates that the value is being added.

We invoke "value not being added" part of the algorithm (see below).

Value being added

We have to check if we really have to add the value. See IvwoConsolidator.shouldAddValue() method.

ID Condition Description Action

AW

All mappings in A0 are weak.

We don’t know if we should apply v0. We can do it only if there is no other value for the item.

We wait until all values are consolidated. Then weak mappings are considered. (I.e. we skip v0 now.)

ExS

existingItemKnown ∧ vex ≠ null

We know the value v0 is present in the existing item.

We skip addition of v0.

ExA

¬existingItemKnown ∧ ∃z ∈ Z0: ¬z.isWeak

We assume the value v0 is present in the existing item. (Although we do not know the current value of the item, we have at least one non-weak mapping that thinks the value was unchanged.)

We skip addition of v0.

NSwA

There is no strong mapping in A0 and there is apriori delta for this item (with any value).

In order to prioritize user-specified values before the ones that are computed by mappings we skip v0 and do not pass it to the resulting delta. [2]

We skip addition of v0.

Other

(all other cases)

We should add v0.

We put v0 to the "add" set of the delta.

From the metadata processing perspective, cases NSwA and ExS/ExA are different. In the former, the value v0 is really discarded, along with its metadata. However, in the latter, metadata of v0 should be taken into account and merged with the metadata of the existing value that is equivalent with v0.
Value not being added

If Z0 = ∅ ∧ M0 ≠ ∅ i.e. no mapping thinks that v0 should be kept and at least one thinks that v0 should be removed, then the following is checked. (See IvwoConsolidator.shouldDeleteValue() method.)

ID Condition Description Action

AW-Ex

All mappings in M0 are weak and existing item has a value.

???

We skip deletion of v0.

ExS

existingItemKnown ∧ vex = null

The value v0 is not present in the existing item. We are requested to delete a value that is not there.

We skip deletion of v0.

NSwA

There is no strong mapping in M0 and there is apriori delta for this item (with any value).

In order to prioritize user-specified values before the ones that are computed by mappings we skip v0 and do not pass it to the resulting delta. [2]

We skip deletion of v0.

Other

(all other cases)

We should delete v0.

We put v0 to the "delete" set of the delta.


1. The implementation seems to be not quite correct when it comes to comparing values.
2. It is not quite clear if this behavior is 100% correct, because in this way we prioritize not only user-specified values but all values that were computed by (any) previously evaluated mappings. However, we are not going to remove this behavior now.