Named object links
|
EXPERIMENTAL
This feature is experimental.
It means that it is not intended for production use.
The feature is not finished.
It is not stable.
The implementation may contain bugs, the configuration may change at any moment without any warning and it may not work at all.
Use at your own risk.
This feature is not covered by midPoint support.
In case that you are interested in supporting development of this feature, please consider purchasing midPoint Platform subscription.
|
Motivation
In a linked objects scenario one has to reference objects linked to current focus (link sources and/or link targets):
-
First, when he or she needs linked objects to provide data to mappings evaluated; using methods like
midpoint.findLinkedSource(s)andmidpoint.findLinkedTarget(s). -
And then when one wants to recompute linked sources/targets as a reaction to modifications in the focus object, he or she has again to specify these objects in
<linkSource>and<linkTarget>clauses in<executeScript>policy actions.
When referencing objects linked it has to be specified somehow. As minimum information, object type has to be given. However, more often, archetype OID needs to be provided as well. And if one is unfortunate enough, other, more complex, search filters have to be used.
What if we would be able to specify the link type in a single place, and then reference the type in all the situations that need to refer to objects linked to the current focus by given type of link?
Then one can imagine full scale of improvements stemming from this kind of definition, for example:
-
As part of the link definition one could specify the cardinality of the link: is it one-to-one, one-to-many, or any other? Is one or both the ends mandatory?
-
What action should be taken if cardinality is broken (too many or too few linked objects)? This is not a new concept. But instead of writing policy rules independently of the link type specification, why not put policy actions directly into the link spec?
-
Should links other than explicitly specified be allowed? What if one tries to create such a link? What if such a link exists but it should not?
-
GUI presentation: Should be the linked objects displayed in a special way? How?
-
GUI actions: Can be the link created (i.e. link source/target assigned) directly via GUI? What should be the GUI representation? (Icon, label, color, …)
Current status
In midPoint 4.2-M1 (milestone 1) we have implemented a proof of concept code for named object links.
For a set of self-explaining examples, please see Linked objects scenario 2: Devices owned by users and Linked objects scenario 3: Projects.
In midPoint 4.0 and 4.1 there are data structures related to GUI actions, namely assignmentRelation items in assignments and assignmentHolderRelationApproach in archetype policy.
These should be integrated somehow with the link type definitions.
Planned improvements
Named links are currently very limited in scope. So there is a lot of room for improvements:
Link definition features
First of all, use of link type definitions is limited to findLinkedSources / findLinkedTargets methods and <linkSource> / <linkTarget> scripting policy actions elements.
There is no support for cardinality specification, policy rules, nor GUI aspects in links definition.
These could be gradually implemented.
Object-wide link definitions
Each definition is currently bound to a single archetype and is visible only in objects having this archetype. The first extension is to apply the definitions to archetype-less objects by means of object policy configuration in system configuration.
Global (bidirectional) link definitions
Then links could be made visible globally. For example, target link AB defined in archetype A will be visible as a source link BA in archetype B. Such global links could be definable also in the system configuration.
Flexible link participants specification
Finally, links could be made configurable for subsets of archetyped objects by using object selectors not only for the other side of the links but also for the defining side.
(This opens up a lot of questions, like applicability of link type definitions in situations when object is modified, and so enters/exits ranges of individual link type definitions. But we’ll be able to sort these questions out eventually.)
Conclusion
We seem to be approaching the state where assignments (and links as their execution-time counterparts) will be first-class citizens in midPoint, just like objects are.
Named object links feature is a step towards this goal.