Mappings: Replacing and Removing Values

You can merge outputs from multiple mappings. This allows you to support multi-valued data in a relativistic way (see Mapping Relativity). However, there are cases when you need to do more than just relativistically transform input to output. MidPoint also needs to be able to reconcile values, e.g., to determine which values of a resource attribute are valid and which are invalid. For that, you need to compute the state of attribute values as they should be.

In reconciliation, the desired state is computed directly, instead of processing input changes (deltas) in a relativistic way. Similar situations can also arise in relativistic processing, for example, when a mapping stops producing a value that it has produced before, and we need to decide whether to remove that value or keep it.

In situations when the desired state is recomputed, or when a mapping no longer produces previously generated values, the problem is how to tell which of the existing values can be removed.

Currently, midPoint does not record data provenance (although a prototype exists, the functionality is not yet fully productized). Therefore, we cannot determine whether a specific value was produced by a mapping or entered by a user. As a result, there is no simple and reliable way to decide whether a particular value should be removed.

Even with data provenance, there would still be corner cases (e.g., migrations, or connecting new resources, data errors) where the origin of values is unclear.

Therefore, we need a mechanism for a mapping to decide which values to remove and which to keep.

Such mechanism exists in midPoint: it is called mapping range.

As mentioned above, a mapping range is used to define a set of values that the mapping is supposed to produce. This can be used to define whether a mapping should remove existing values or leave them unchanged.

We will demonstrate this principle using an example.

Let’s have a property with existing values [ A, B ], and a mapping that targets this property. The mapping will produce values [ B, C ], i.e., the values B and C should be set to the target property.

What about the value A? Should it be removed or should it be kept? This depends on how the mapping range is defined.

Most applications of mapping ranges apply to multi-valued properties where you may need to define which values a mapping can remove.

However, ranges also affect single-valued properties, particularly when a mapping produces no value.

In single-valued properties, mappings usually overwrite the existing value. As the target can only have one value, it generally makes sense to replace it with a value produced by a mapping (in relativistic processing), as that value is likely more recent and relevant.

But what should happen if a mapping produces nothing?

In some cases, the existing value should be preserved - for example, if it was entered by a user, or represents a reasonable output. In other cases, it should be removed - for example, to allow another mapping to provide a new value.

You can control this behavior using mapping ranges.

For multi-valued properties, mapping ranges are, by default, treated as empty. In the case of single-valued properties, the effective default behavior depends on the direction of the mapping: