Merging and master data computation

The following workflow describes how mergings and master data in incoming messages are computed.

Mandator and index evaluation

  1. Lists, indexes, masterdata (values that are read from storage), and doublets are computed for the head mandator first.
  2. A list of mandators is created for the evaluation:
    • If the transaction does fit for submandator conditions, then those submandator will be added to the list.
    • Lists, indexes, masterdata values and doublets are also computed for each mandator that was newly added to the list.
    • The list of mandators is not sorted strictly. Siblings are sorted by their unique identifier (UID). Lower-level mandators are later in the list than their upper-level mandator to allow inheritance of attributes and rules. Siblings are only next to each other in the list if they don't have any submandators.

Mergings and Masterdata delivery evaluation

  1. After the list of mandators is created, mergings and masterdata deliveries are computed one after another for each mandator in the list.
  2. Both mergings and masterdata are computed per mandator. The computation in the submandators only starts after the computation in their upper mandator completes.
  3. All mergings in a mandator are executed first, sorted by UID.
  4. Then all masterdata in the same mandator are executed, sorted by UID.
  5. The next mandator is evaluated as soon as all its mergings and masterdata are computed. There will be no evaluation anymore as soon as some merging target is found.
  6. After the first merging source was hit, there is no more masterdata delivery possible anymore for the whole transaction.
  7. Mergings may still be executed, even if a masterdata (delivery) was executed.
  8. One merging can have multiple merging targets. As soon as one merging found at least one target, all further mergings are cancelled for the whole transaction.
  9. As soon as one masterdata or one merging is configured to always store source and its computation / source condition was hit, there will be a new URID for the transaction. Also, there will be a new URID if store source if no target found is configured and the current merging does not find a target. Even if a later merging finds some merging target. The URID creation is irreversible.
  10. The merging conclusion is always executed on the merging target. Even if the merging has store source enabled and creates a new URID.
  11. The recompute target instead is executed on a newly created URID, if a previous merging or masterdata created a new URID. It is not possible to configure store source always or merge to all fitting targets together with recompute target in the same merging. Recompute target will only use the URID of the merging target, if no new URID was created by masterdata or merging yet.