Understanding Object Identifiers: Anchor and DN
Objects are identified with up to two different identifiers, anchor and dn. An anchor is an immutable (cannot be changed) unique identifier and is mandatory for an object. Which attribute, or attributes, is used for the anchor is defined on the management agent. Which attribute is used for the dn is defined in the schema. The dn is the attribute which other objects will use to refer to this object and it is mutable (can be changed). The dn attribute is despite its name not necessarily in LDAP dn style. If the anchor is also the value used by other objects to reference it, then no DN is needed.
The existence and format of the dn attribute is defined by the MA Capability dnStyle. dnStyle can have the following values:
| Value | Description |
|---|---|
None |
The management agent does not have a separate dn attribute. The anchor is used for references between objects. Objects cannot be renamed. |
Generic |
The management agent has a dn. It can be of type string, integer or binary but it is not in LDAP style. Object renames are allowed. |
LDAP |
The management agent has a dn and it is of LDAP style. An LDAP style dn allows the interface GetHierarchy to be used and that Provisioning Hierarchy is enabled. Object renames are allowed. |
Setting anchor and dn values
The anchor is set either in provisioning code or returned from the connected system during export. If the anchor is a constructed (concatenated) anchor then all components of the anchor must have a value. For Generic and LDAP dnStyle the dn must be set in provisioning code. An object must have an anchor after export. If there isn’t an anchor for an object, an error will be thrown.
The provisioning code will be different depending on the scenario:
Example: Connected Data Sources that Expect server to Provide the Anchor Attributes
Example: Connected Data Sources that Generate the Anchor Attributes
Example: Connected Data Sources that Generate the Anchor Attributes
The MA’s export code will also be different depending on the scenario:
Example: Connected Data Sources that Generate the Anchor Attributes
Example: Connected Data Source Changes the dn during export
Anchor attributes cannot be changed in provisioning code or EAF once the object has been exported.
The following table lists errors the Sync Engine can return with respect to anchor issues.
| Error | Description |
|---|---|
E_MMS_MA_MULTI_VALUED_ANCHOR_COMPONENT |
The anchor attribute is made of multi-valued attributes. |
E_MMS_MA_MISSING_ANCHOR_COMPONENT |
One of the anchor attributes is empty and was not returned by the connected system during export. |
E_MMS_MA_ANCHOR_TOO_LONG |
|
E_MMS_STORE_EXPORT_ASSIGN_DUPLICATE_ANCHOR |
During export an anchor was returned already in use. |
The following table lists errors the Sync Engine can return with respect to dn issues.
| Error | Description |
|---|---|
E_MMS_MA_INVALID_DN |
Returned when the dn is not valid LDAP. |
E_MMS_STORE_EXPORT_ASSIGN_DUPLICATE_DN |
During export an anchor was returned already in use. |
Import changes to anchor and DN
During full and delta import it is possible that a change to an attribute which is making up the anchor is read. If an anchor attribute is changed it is treated as a new object. During Full Import the new object is created and the old object is obsoleted (deleted at the end of Full Import). During Delta Import and if an update to an anchor attribute is received the cs object is transformed into a transient object and the MA Import method will be called with an ObjectFullImport request with the new anchor value. The transient object will be removed by an explicit delete or during Full Import.
If a change to the dn is detected and the dnStyle is Generic or LDAP then this is treated as an object rename.