Uploaded image for project: 'OpenIDM'
  1. OpenIDM
  2. OPENIDM-11785

Syncing change notifications from "notifyRelationships" is too complicated

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 6.5.0, 6.0.0.2
    • Fix Version/s: 7.0.0
    • Component/s: Module - Relationships
    • Labels:
    • Target Version/s:
    • Verified Version/s:
    • Support Ticket IDs:

      Description

      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 :

      {
                  "name" : "organisation",
                  "schema" : {
        [...]
                      "properties" : {
                          "name" : {
                              "title" : "Organisation Name",
                              "type" : "string",
                              "viewable" : true,
                              "searchable" : true,
                              "userEditable" : true,
                              "notifyRelationships" : [
                                  "users"
                              ]
                          },
                          "users" : {
      [...]
                                  "resourceCollection" : [
                                      {
                                          "notify" : true,
      

      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.

       

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              dhogan Dirk Hogan
              Reporter:
              patrickdiligent patrick diligent
              QA Assignee:
              Chris Drake Chris Drake
              Votes:
              1 Vote for this issue
              Watchers:
              7 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: