Rules for Attribute Merging
Novell Cool Solutions: Tip
Digg This -
Posted: 20 Oct 2003
I have a general question about the DirXML attributes merge functionality. Is there a way to control which attributes are leading when executing a User matching rule or stylesheet?
When a matching rule is executed and a match is found in either eDirectory or the application connected, I can see that the values from both the eDir side and the application side are concatenated. The result is an undesirable set of duplicate values in the attributes. I run into this problem every time I have to match existing users.
Is there a way to control this behavior? I would like to set a leading data source (either eDirectory or the application) for each attribute in the filter or turn off the merge of a particular attribute.
Rules for merging attributes as a result of a re-sync are as follows.
For associated objects...
a) If an attribute is in neither filter then it is not affected by merge.
b) If an attribute is in one filter and not the other then all existing values on the non-authoritative side will be removed and replaced with the values from the authoritative side. If the authoritative side is multi-valued and the non-authoritative side can only accommodate a single value, then only one of the values will be used on the non-authoritative side, though it is undefined which of those values will be used.
c) If an attribute is in both filters and both sides can accommodate multiple values, then each side will end up with the union of values present on either side.
d) If an attribute is in both filters and both sides can accommodate only a single value, the application will end up with the value from eDirectory unless there is no value in eDirectory in which case eDirectory will end up with the value from the application (if any).
e) If an attribute is in both filters and only one side can accommodate multiple values then single valued side's value will be added to multi side's value if not already there, unless there is no value on the single side in which case one of the values (undefined which) will be added to the single side.
For non-associated objects...
a) The driver will run the create rule for all objects who class is in the subscriber filter. New objects created from this event will have attributes populated in the disparate directory as the subscriber filter allows. Objects who were matched will merge as indicated above.
If you wish to block the cases where the "from-merge = true" then use your command transformation rules. This example will strip from-merge from the lemon attribute. <xsl:template match="*[@attr-name='lemon'][parent::modify/@from-merge='true']"/>
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com