Affects Version/s: OpenIDM 3.2.0
Fix Version/s: None
As an OpenIDM Administrator, I would like to be able to efficiently request information stored within managed objects which are related to the main managed object I am working with.
When using the managed service to model complex relationships between entities, the need for efficiently viewing data across these entities is critical.
For example, consider the out-of-the-box relationship between managed/users and managed/roles; this is a many-to-many relationship, whereby a user can have any number of managed/roles associated with it and a role can have any number of users associated with it.
Consider these managed/role entries:
The association between users and roles is maintained in the "roles" property of the managed/user, like so:
Presently there is no way to make a request for managed/user/wajih that also includes the details for the roles that he is assigned. For example, a request that returns a response like so:
Such an operation is conceptually very similar to a "join" query in a relational database. It is important that such operations can be performed as part of the request for the base object rather than as separate read requests for the related items, as it is possible that there are a large number of related items (which would make individual read calls for each one very costly in terms of performance).
A join-type request as described above would have several uses. One is for a UI to edit the managed/user record - in this case, with a single request all of the data necessary to present the information would be available. At present, a separate request for each role assignment would be necessary.
Another use could be during provisioning. The managed/user <-> managed/role relationship is not a good case for that, since it is unlikely that roles themselves would be provisioned. However, consider the case of managed/group <-> managed/user. It is very plausible that a user could desire to create a mapping to a mailing list system, whereby each managed/group translates into a particular mailing list. Imagine the managed/group records are structured like so:
In your sync config, you may wish to map this group to the mailing list like so:
This would work because the "_join" flag in the "sourceQuery" instructed the system to replace the values for "members" with the content from their related entities, in this case the "managed/user" records. Then within the transform the "mail" attribute is read out of each member and ultimately joined to produce a csv of all the email addresses for the members. Performing such a mapping without the use of a "join" operation in the backend would be much more tedious and have very poor performance, comparatively.