Federation is a distributed configuration where there is one governing repository and member repositories. The advantage of federation is global users, global groups and global ACL's created on governing repository will be replicated on to member repositories. User will have access to all repositories though he was created only in governing repository.
General issues seen in Federation:
User or group or ACL does not get created on a member repository.
Reason: Federation update job failed to execute on member repositories.
Make sure federation object on member docbase is not checked out.
select r_object_id, r_lock_owner, r_lock_date, r_lock_machine from dm_federation
Whenever federation job runs on member repository it checks out federation object and copies over newly created/changed user, group, ACL and check back in federation object. Sometime due to sudden outage or if environment was restarted in the middle when federation job was running then federation object remains checked out due to which next time when federation update job runs it fails to get hold on federation objects as it is already checked out.
To resolve this issue touch the user or group in governing repository.
Touching means incase of users to make some modifications like "Workflow disabled" and save the changes so there is a r_modify_date current date stamp on the user object. Similarly, on groups add yourself and delete yourself from the groups that failed which does nothing to the group but creates a current r_modify_date.
Then run the Fed update job manually that will pick up the changes.
The log_entry attribute of dm_federation is what is used to pick up the last run. This is the same for governing repository or all the member repositories. You cannot modify that attribute via API, so go to "dmadmin" home cabinet, then show all object and versions, then choose show hidden objects in preferences. You can then do properties of the "governing repository" object and modify the "User_comments" attributes that corresponds to log_entry.
The above is the only way to change the start time of next run of Fed Update.
------------------------------------------------------------------------------------------
MANUAL STEPS FOR FED UPDATE IF IT FAILS:
Make sure all federation jobs are inactive and the dm_federation object is not locked on both repository using the command given below.
select r_object_id, r_lock_owner, r_lock_date, r_lock_machine from dm_federation
Logon to Content Server and do the following from command prompt.
set ClassPath=%ClassPath%;
This operation creates the ldif file in "D:\Documentum\share\temp\ldif" directory and trace file in "D:\Documentum\share\temp\ldif\< Governing Repository >" directory. You can modify the from and to dates to make short multiple runs If the data is too much. For date format, 12-6 or 12-06 is OK. For time format, always use 01:38 instead of 1:38.
PLEASE PICKUP THE TO_DATE FROM THE LAST SUCCESSFULL RUN OF FED UPDATE LOG AND USE IS AS THE FROM_DATE IN THE MANUAL RUN.
java dm_ldif_export -docbase_name <Governing Repository> -user_name dmadmin -password <password> -domain_name <domain> -trace_level 10 -from_date "2010-09-15 00.00.00" -to_date "2010-9-22 00.00.00"
Copy the ldif file in "D:\Documentum\share\temp\ldif" location to "D:\Documentum\share\temp\ldif\<repository_name>" location for each member docbase on Content Server.
Get the r_object_id of dm_federation object by running the following commands on the governing repository
select * from dm_federation (or) select r_object_id from dm_federation
Run the following API commands using the r_object_id from previous step. You will need to update keywords[0] through keywords[4] to update member docbase
API:>fetch,c,5e01a5cc80004101
API:>dump,c,5e01a5cc80004101 - Verify what is in keywords[0]. It would FAILED or status of last run
API:>set,c,5e01a5cc80004101,keywords[0]
SET:><name of the ldif file without the extension> - example: "ldif_2008-01-24 08.00.00"
API:>save,c,5e01a5cc80004101
API:>fetch,c,5e01a5cc80004101
API:>dump,c,5e01a5cc80004101 - to verify that the keywords[0] got updated.
Run the below command in Content Server in the other command window where you ran the ldif_export method. If you closed that window, make sure you run the set ClassPath command before running the below. This operation will copy the ldif file to each member docbase.
java dm_ldif_copy -docbase_name < Governing Repository > -user_name dmadmin -password <password> -trace_level 10
The LDIF file will be in the member docbases, but not retrieved to filesystem yet. The ldif import method will retrieve the file and copy it into the file system.
Run the below command from the content server for each member docbase. This will retrieve the ldif file from repositories and stage it in the"d:\Documentum\share\temp\ldif" location, import the users, groups and ACLs identified in the ldif file. Depending on the size of the ldif file and the size of groups worked on, it might take time.Typically, if the changes are not huge, it completes in less than 5 minutes.
set ClassPath=%ClassPath%;D:\Documentum\product\5.3\bin
Execute below command for the member repository where federation job failed.
java dm_ldif_import -docbase_name <Member Docbase> -user_name dmadmin -password <password> -trace_level 10
Run the below command now from Content Server in the same command window where you ran
the other ldif methods. If not set ClassPath before executing the command below.
EVEN IF THE IMPORT HAD WARNINGS, YOU HAVE TO RUN THIS COMMAND AS IT COMPLETES THE FULL CYCLE.
java dm_ldif_status -docbase_name <Governing Repository> -user_name dmadmin -password <password> -trace_level 10
Set r_member_refresh attribute of fed object to the end date of ldif_export method. Even if you set it here, the from_date for ldif_export defaults to last run of Fed update irrespective of whether it was success or failure. So, this step does not really add any value. r_member_refresh[0]-[4] needs to be updated.
select r_object_id from dm_federation
API:>fetch,c,5e005ffd8016b628
API:>dump,c,5e005ffd8016b628 - Verify what is in r_member_refresh[0]. It would usually have the date of last run of Fed Update even if it was a failure.
API:>set,c,5e005ffd8016b628,r_member_refresh[0]
SET:><to_date of last manual run of ldif_export> - Format is like "1/25/2008 13:45:00"
API:>save,c,5e005ffd8016b628
API:>fetch,c,5e005ffd8016b628
API:>dump,c,5e005ffd8016b628
-----------------------------------------------------------------------