Scenario 1 – Federation of Users and Groups
In the first example, we setup a simple “governing” docbase. All users and groups will be created in the governing docbase and pushed out to the member docbase. Documentum handles the variations on this scenario in the following manner:
- Simple user creation: In the governing Docbase, if a dm_user.globally_managed attribute is set to true, a replica of the user is created in all of the member Docbases. This new dm_user object has a different r_object_id than the corresponding user in the governing docbase, as every Docbase assigns a unique r_object_id to its objects. However, the user name and user os_name are the same, as are all other general attributes.
- Simple group creation: If in the governing Docbase, a given group’s dm_group.globally_managed attribute is set to true, the group is created in all of the member Docbases. Any users who where members of the group in the governing Docbase are also added as members of the group in the member Docbase. Users or groups who were members of the group in the governing Docbase but who do not exist in the member Docbase are ignored. In order to have these created in the member Docbase, then their individual globally_managed attribute would need to be set to true.
- Adding a user to a group that exists in the target: If both the group and the user exist in the member Docbase, then the user is added to the group as expected.
- Adding a user to a group that does not exist in the target: Since the group does not exist in the member Docbase, the change is not reflected in the member Docbase.
- Modifying a user’s OS Name: The user’s OS Name in the member docbase is updated accordingly. Similar behavior occurs on any other change to a modifiable user attribute.
- Simple delete of a user: The user is deleted as expected in the member docbases.
- Delete a user who is a document owner or part of an ACL in a member docbase: To avoid this problem the recommended action is to change a user to inactive instead of performing a delete. However, in the case where you still perform the delete, the user will also be deleted from the member docbase. This could potentially leave documents or ACLs referencing a user name that does not exist as they will retain there reference to the previously existing user. This reference is based on the “user_name” attribute and essentially has no impact of the system.
Scenario 2 – Federation of ACLs
A Federated environment not only pushes Users and Groups but also ACLs. Documentum handles ACL Federation as follows:
- Simple ACL creation: If the ACL is flagged as globally managed, it will be copied the the appropriate member docbases.
- Creation of ACL with users or groups that don’t exist in the member docbase: The ACL is copied as normal. The references to the missing users and groups are retained. Therefore, in your member Docbase, you will have an ACL that references users or groups that don’t exist in that Docbase. This does not seem to be a problem as the additional permissions are essentially ignored.
Scenario 3 – Object Replication
In this example, we have extended our Federated environment to include object replication. These scenarios assume that you have selected “Preserve” as your option for assigning security on the replication job. Situations where you have selected to remap to the target ACL are not covered as their behavior is obvious, you will always be assigned the pre-defined target ACL as per the configuration in the replication job.
- Simple object creation: the replica object is created. As expected, this object would have a different object ID than the original source object.
- Object created with an owner that does not exist in the target docbase: The object is created as normal, with the owner set to the same value as in the original Docbase. The result is that this document has an owner that does not exist in the current docbase, and therefore the “owner” aspect of the object’s ACL is essentially ignored.
- Object created with an ACL that does not exist in the target docbae: The object is created as normal and the object retains the ACL of the source docbase. The ACL is replicated from the source docbase to the target, therefore maintaining the integrity of the document’s permissions.
Scenario 4 – Attribute Based Associations
In many cases you have attributes within a given object that provides a reference, or pointer, to another object. This can be done in a couple of different ways with Documentum handling each approach slightly differently:
- Replicate an object with an ID attribute datatype, and the referenced object exists in the member docbase: The object is replicated as expected, however, the ID datatyped attribute is updated to reflect the fact that the referenced object has a different ID in the member docbase. Therefore, the integrity of the relationship is maintained, even though the referenced object has a different r_object_id in each docbase.
- Replicate an object with an ID attribute datatype, and the referenced object does not exist in the member docbase: The replication of the main object occurs as normal. In addition, the referenced object is also replicated (even though it was not specifically targeted by the replication job). The referenced object is placed into a folder titled “Related Objects”. This folder is placed just below the root defined in the “To Source” folder path of the replication job.
- Replicate an object with a reference attribute that is not an ID datatype: As you would guess, the object is replicated but with no change to the values of the attributes themselves. Therefore, if this relationship scheme is used, you must be sure to reference attributes that do not change during the replication process.
Scenario 5 – dm_relation based Assocations:
A dm_relation contains two ID datatype attributes that relate two Documentum objects. If you are using a dm_relation and an object is replicated, then Documentum performs in the following manner:
- Replicated object has a dm_relation to an object that already exists in the member docbase: The dm_relation object is also created in the target docbase. The attributes of the dm_relation object are updated to reflect the correct values of those attributes on the replica objects.
- Replicated object has a dm_relation to an object that does not exist in the member docbase: The related document is also replicated to the target docbase (even though it is not specifically targeted by the replication job. The related object is placed into the “Related Objects” folder, just as it would have been if using an ID datatype relationship.