9 March 2015

Building Hierarchical Relationships with OpenIDM

One of the common use cases I've seen recently, is the ability to link statically provisioned objects to one another.  Commonly known as linking or hierarchical linking, this provides a basic parent to child relationship, in an "1-to-many" style relationship.  For example, a literal parent, may have several children in his family, which needs to represented in a permanent or solid format.

If you apply that concept to identity, this could be required for things like production lines (parents) to sensors (children), bill payer (parent) to content subscriber (child) in the media world or perhaps floor manager (parent) and operator (child) in a retail setting.

The main idea being, is that the parent may have different characteristics (different schema, different policy validation, delegated administration rights) from the child, but still has a very permanent relationship with the other object.

OpenIDM has the ability to very quickly create different object types.  This feature is popular in the
complex and relationship device driven world of internet of things.  The concept of types, allows your identity framework to accommodate objects with different characteristics, such as those requiring different administrators or have different data syntax and policy validators.

Within the OpenIDM admin UI (http://openidm-server:port/admin) you can simply create a new vanilla object type.

This simple task, opens up the OpenIDM API to now accomodate the basic CRUDPAQ operations against your new object.  For example I could now do a GET on ../openidm/managed/parent/_id to retrieve a JSON of a parent.

In this case, I also created a child entry too.  Now, the interesting bit comes with a basic example of how we link these two together.  Each managed object has a number of hooks that come with OpenIDM, that allow us to apply logic via our scripting framework.  An interesting one with respect to linking is the onRetrieve hook.  This basically gets called on a GET or read of the object in question.  As a little food for thought, I can do the following to link my parents to their children using this hook.

When I create a child (perhaps via delegated admin as a parent), I add in a parent_id attribute, that simply contains the parent object _id.

We can use the child's parent attribute in the linking process.

To do so, simply add in a few lines of script within the parent managed object's onRetrieve hook.

The onRetrieve script (which can be JavaScript or Groovy), does a few things.  Firstly it finds and stores the parent _id as a variable.  That parent _id is then used to do a query against the managed/child objects list, using a default out of the box query: the get-by-field-value query.  This is basically a catch all search that allows me to filter the list of all managed children, for those with a specific criteria.  Basically, those that have a parent attribute as my parent _id.

The script can either be inline or saved to an external file.  In general I save as an external file as it makes it easier to manage in large deployments and allows for greater portability - but that's just my preference.

Once the query has completed, the results (which will be an array []) are simply dumped in to the parent object as a children attribute.

The end result is super simple - when you do a GET on a parent, there is a children attribute that contains an array of all the children objects that have the same parent _id!  You could probably cut that attribute down, to simply full out only the children _ids for example to make it cleaner, but that is for design.




The full onRetrieve example script is here:

//Save the current parent object _id
var parentId = object._id;

//Search all children for those with specific parent_id
foundChildren = openidm.query("managed/child", {"_queryId": "get-by-field-value", "field": "parent", "value": parentId } );

//All children [] - note this is full object
children = foundChildren.result;

//Populate against the parents children attribute
object.children = children;

2 comments:

  1. Great job Simon - you've really demonstrated that flexibility is the key to handling common (and unique) scenarios with OpenIDM. I know you opted for simplicity in storing the child objects whole as an attribute in the parent - but would it be possible to store just the _ids of the child object and make referral calls to get their attributes on an as needed basis? Thank you for your post - I know people really look forward to these practical demonstrations!

    ReplyDelete
  2. Thanks Tim - would be pretty trivial to just add the child _id and not the full object. Just need to split the the foundChildren.result and iterate over it. That's the flexibility of IDM :-)

    ReplyDelete