Rationale: by default, simply setting "notifyRelationships" is not sufficient to trigger a sync of the notified object to external system.
Let's take this example :
Updating the organisation's name property will cause a notifyUpdate to the object mapping component, but it will not propagate to an actual sync operation, as the old and new objects do not differ.
Current workarounds are :
- set the reverse relationship with "returnByDefault" true. This however, is incidental, as a close look shows that the old object does not include the dependent relationship, while the new does, so objects will always differ.
- Define a virtual attribute in the user object with some computation from the organisations relationship, returnByDefault = true. Both old and new objects have now both the virtual attribute included, and cause the objects to differ correctly.
The above workarounds are not satisfying because:
- setting the reverse relationships to return by default seems to depend on internal behaviour subject to change
- declaring a virtual attribute is redundant, and causing extra cpu cycles whenever the resource is retrieved, not only when syncing the resource to the target
- If the mapping defines a transform which collects state from dependent resources to compute the target attribute, a reconciliation will cause an actual synchronisation to the target. But not an implicit sync.
- There is no placeholder in this process where a designer can place some code to force the sync. The old way in previous releases was to cause a sync from dependent objects (roles) thru the triggerSyncCheck action. This was supposed to be gone for the sake of simplicity in 6.0. Using the onSync hook in the user schema is not a valid option either, since this happens "after" and not "before".
- Declaring a virtual attribute is mixing different concerns in a single bag. It is introduced for the purpose of syncing to a target and therefore logic should belong to the mapping model, not the object model. The user object should not be polluted with artefacts introduced for the sole purpose of provisioning a target system.
The possible enhancements are :
- Do not block the sync from the notifyUpdate receiver, but let the mapping be the final judge. At the end, nothing will be sync'ed to the target if the computed target candidate does not differ from the current one.
- Or provide an additional hook per mapping like "shouldSync" as an added condition to decide wether to propagate or not the notification to the mapping sync operation, return "true" means force the sync.