At some of our customers, we often install new docbases for development purposes which are used only for a short time to avoid cross-team interactions/interferences and this kind of things. Creating new docbases is quite easy with Documentum but it still takes some time (unless you use silent installations or Docker components). Therefore installing/removing docbases over and over can be a pain. For this purpose, we often install new docbases but then we don’t uninstall it, we simply “deactivate” it. By deactivate I mean updating configuration files and scripts to act just like if this docbase has never been created in the first place. As said above, some docbases are there only temporarily but we might need them again in a near future and therefore we don’t want to remove them completely.
In this blog, I will show you which files should be updated and how to simulate a “deactivation” so that the Documentum components will just act as if the docbase wasn’t there. I will describe the steps for the different applications of the Content Server including the JMS and Thumbnail Server, Web Application Server (D2/DA for example), Full Text Server and ADTS.
On this blog, I will use a Documentum 7.2 environment in LINUX of course (except for the ADTS…) which is therefore using JBoss 7.1.1 (for the JMS and xPlore 1.5). In all our environments we also have a custom script that can be used to stop or start all components installed in the host. Therefore in this blog, I will assume that you do have a similar script (let’s say that this script is named “startstop”) which include a variable named “DOCBASES=” that contains the list of docbases/repositories installed on the local Content Server (DOCBASES=”DOCBASE1 DOCBASE2 DOCBASE3″). For the Full Text Server, this variable will be “INDEXAGENTS=” and it will contain the name of the Index Agents installed on the local FT (INDEXAGENTS=”Indexagent_DOCBASE1 Indexagent_DOCBASE2 Indexagent_DOCBASE3″). If you don’t have such kind of script or if it is setup differently, then just adapt the needed steps below. I will put this custom startstop script at the following locations: $DOCUMENTUM/scripts/startstop in the Content Server and $XPLORE_HOME/scripts/startstop in the Full Text Server.
In the steps below, I will also assume that the docbase that need to be deactivated is “DOCBASE1” and that we have two additional docbases installed on our environment (“DOCBASE2” and “DOCBASE3”) that need to stay up&running. If you have some High Availability environments, then the steps below will apply to the Primary Content Server but for Remote Content Servers, you will need to adapt the name of the Docbase start and shutdown scripts which are placed under $DOCUMENTUM/dba: the correct name for Remote CSs should be $DOCUMENTUM/dba/dm_shutdown_DOCBASE1_<ServiceName@RemoteCSs>.
1. Content Server
Ok so let’s start with the deactivation of the docbase on the Content Server. Obviously the first thing to do is to stop the docbase if it is running:
ps -ef | grep "docbase_name DOCBASE1 " | grep -v grep $DOCUMENTUM/dba/dm_shutdown_DOCBASE1
Once done and since we don’t want the docbase to be inadvertently restarted, then we need to update the custom script that I mentioned above. In addition to that, we should also rename the Docbase start script so an installer won’t start the docbase too.
mv $DOCUMENTUM/dba/dm_start_DOCBASE1 $DOCUMENTUM/dba/dm_start_DOCBASE1_deactivated vi $DOCUMENTUM/scripts/startstop ==> Duplicate the line starting with "DOCBASES=..." ==> Comment one of the two lines and remove the docbase DOCBASE1 from the list that isn't commented ==> In the end, you should have something like: DOCBASES="DOCBASE2 DOCBASE3" #DOCBASES="DOCBASE1 DOCBASE2 DOCBASE3"
Ok so now the docbase has been stopped and can’t be started anymore so let’s start to check all the clients that were able to connect to this docbase. If you have a monitoring running on the Content Server (using the crontab for example), don’t forget to disable the monitoring too since the docbase isn’t running anymore. In the crontab, you can just comment the lines for example (using “crontab -e”). On the Java MethodServer (JMS) side, there are at least two applications you should take a look at (ServerApps and the ACS). To deactivate the docbase DOCBASE1 for these two applications, you should apply the following steps:
cd $DOCUMENTUM_SHARED/jboss7.1.1/server/DctmServer_MethodServer/deployments vi ServerApps.ear/DmMethods.war/WEB-INF/web.xml ==> Comment the 4 lines related to DOCBASE1 as follow: <!--init-param> <param-name>docbase-DOCBASE1</param-name> <param-value>DOCBASE1</param-value> </init-param--> vi acs.ear/lib/configs.jar/config/acs.properties ==> Reorder the “repository.name.X=” properties for DOCBASE1 to have the biggest number (X is a number which goes from 1 to 3 in this case since I have 3 docbases) ==> Reorder the “repository.acsconfig.X=” properties for DOCBASE1 to have the biggest number (X is a number which goes from 1 to 3 in this case since I have 3 docbases) ==> Comment the “repository.name.Y=” property with the biggest number (Y is the number for DOCBASE1 so should be 3 now) ==> Comment the “repository.acsconfig.Y=” property with the biggest number (Y is the number for DOCBASE1 so should be 3 now) ==> Comment the “repository.login.Y=” property with the biggest number (Y is the number for DOCBASE1 so should be 3 now) ==> Comment the “repository.password.Y=” property with the biggest number (Y is the number for DOCBASE1 so should be 3 now)
So what has been done above? In the file web.xml, there is a reference to all docbases that are configured for the applications. Therefore commenting these lines in the file simply avoid the JMS to try to contact the docbase DOCBASE1 because it’s not running anymore. For the ACS, the update of the file acs.properties is a little bit more complex. What I usually do in this file is reordering the properties so that the docbases that aren’t running have the biggest index. Since we have DOCBASE1, DOCBASE2 and DOCBASE3, DOCBASE1 being the first docbase installed, therefore it will have by default the index N°1 inside the acs.properties (e.g.: repository.name.1=DOCBASE1.DOCBASE1 // repository.name.2=DOCBASE2.DOCBASE2 // …). Reordering the properties will simply allow you to just comment the highest number (3 in this case) for all properties and you will keep the numbers 1 and 2 enabled.
In addition to the above, you might also have a BPM (xCP) installed, in which case you also need to apply the following step:
vi bpm.ear/bpm.war/WEB-INF/web.xml ==> Comment the 4 lines related to DOCBASE1 as follow: <!--init-param> <param-name>docbase-DOCBASE1</param-name> <param-value>DOCBASE1</param-value> </init-param-->
Once the steps have been applied, you can restart the JMS using your preferred method. This is an example:
$DOCUMENTUM_SHARED/jboss7.1.1/server/stopMethodServer.sh ps -ef | grep "MethodServer" | grep -v grep nohup $DOCUMENTUM_SHARED/jboss7.1.1/server/startMethodServer.sh >> $DOCUMENTUM_SHARED/jboss7.1.1/server/nohup-JMS.out 2>&1 &
After the restart of the JMS, it won’t contain any errors anymore related to connection problems to DOCBASE1. For example if you don’t update the ACS file (acs.properties), it will still try to project itself to all docbases and it will therefore fail for DOCBASE1.
The next component I wanted to describe isn’t a component that is installed by default on all Content Servers but you might have it if you need document previews: the Thumbnail Server. To deactivate the docbase DOCBASE1 inside the Thumbnail Server, it’s pretty easy too:
vi $DM_HOME/thumbsrv/conf/user.dat ==> Comment the 5 lines related to DOCBASE1: #[DOCBASE1] #user=dmadmin #local_folder=thumbnails #repository_folder=/System/ThumbnailServer #pfile.txt=/app/dctm/server/product/7.2/thumbsrv/conf/DOCBASE1/pfile.txt sh -c "$DM_HOME/thumbsrv/container/bin/shutdown.sh" ps -ef | grep "thumbsrv" | grep -v grep sh -c "$DM_HOME/thumbsrv/container/bin/startup.sh"
If you don’t do that, the Thumbnail Server will try to contact all docbases configured in the “user.dat” file and because of a bug with certain versions of the Thumbnail (see this blog for more information), your Thumbnail Server might even fail to start. Therefore commenting the lines related to DOCBASE1 inside this file is quite important.
2. Web Application Server
For the Web Application Server hosting your Documentum Administrator and D2/D2-Config clients, the steps are pretty simple: usually nothing or almost nothing has to be done. If you really want to be clean, then there might be a few things to do, it all depends on what you configured… On this part, I will consider that you are using non-exploded applications (which means: war files). I will put these WAR files under $WS_HOME/applications/. In case your applications are exploded (meaning your D2 is a folder and not a war file), then you don’t have to extract the files (no need to execute the jar commands). If you are using a Tomcat Application Server, then the applications will usually be exploded (folder) and will be placed under $TOMCAT_HOME/webapps/.
– D2:
If you defined the LoadOnStartup property for DOCBASE1, then you might need to execute the following commands to extract the file, comment the line for the DOCBASE1 inside it and update the file back into the war file:
jar -xvf $WS_HOME/applications/D2.war WEB-INF/classes/D2FS.properties sed -i 's,^LoadOnStartup.DOCBASE1.(username|domain)=.*,#&,' WEB-INF/classes/D2FS.properties jar -uvf $WS_HOME/applications/D2.war WEB-INF/classes/D2FS.properties
Also if you defined which docbase should be the default one in D2 and that this docbase is DOCBASE1 then you need to change the default docbase to DOCBASE2 or DOCBASE3. In my case, I will use DOCBASE2 as new default docbase:
jar -xvf $WS_HOME/applications/D2.war WEB-INF/classes/config.properties sed -i 's,^defaultRepository=.*,defaultRepository=DOCBASE2,' WEB-INF/classes/config.properties jar -uvf $WS_HOME/applications/D2.war WEB-INF/classes/config.properties
Finally if you are using Single Sign-On, you will have a SSO User. This is defined inside the d2fs-trust.properties file with recent versions of D2 while it was defined in the shiro.ini file before. Since I’m using a D2 4.5, the commands would be:
jar -xvf $WS_HOME/applications/D2.war WEB-INF/classes/d2fs-trust.properties sed -i 's,^DOCBASE1.user=.*,#&,' WEB-INF/classes/d2fs-trust.properties jar -uvf $WS_HOME/applications/D2.war WEB-INF/classes/d2fs-trust.properties
– D2-Config:
Usually nothing is needed. Only running docbases will be available through D2-Config.
– DA:
Usually nothing is needed, unless you have specific customization for DA, in which case you probably need to take a look at the files under the “custom” folder.
3. Full Text Server
For the Full Text Server, the steps are also relatively easy. The only thing that needs to be done is to stop the Index Agent related to the docbase DOCBASE1 and prevent it from starting again. In our environments, since we sometimes have several docbases installed on the same Content Server and several Index Agents installed on the same Full Text, then we need to differentiate the name of the Index Agents. We usually only add the name of the docbase at the end: Indexagent_DOCBASE1. So let’s start with stopping the Index Agent:
ps -ef | grep "Indexagent_DOCBASE1" | grep -v grep $XPLORE_HOME/jboss7.1.1/server/stopIndexagent_DOCBASE1.sh
Once done and if I use the global startstop script I mentioned earlier in this blog, then the only remaining step is preventing the Index Agent to start again and that can be done in the following way:
mv $XPLORE_HOME/jboss7.1.1/server/startIndexagent_DOCBASE1.sh $XPLORE_HOME/jboss7.1.1/server/startIndexagent_DOCBASE1.sh_deactivated vi $XPLORE_HOME/scripts/startstop ==> Duplicate the line starting with "INDEXAGENTS=..." ==> Comment one of the two lines and remove the Index Agent related to DOCBASE1 from the list that isn't commented ==> In the end, you should have something like: INDEXAGENTS="Indexagent_DOCBASE2 Indexagent_DOCBASE3" #INDEXAGENTS="Indexagent_DOCBASE1 Indexagent_DOCBASE2 Indexagent_DOCBASE3"
If you have a monitoring running on the Full Text Server for this Index Agent, don’t forget to disable it.
4. ADTS
The last section of this blog will talk about the ADTS (Advanced Document Transformation Services), also called the Rendition Server. The ADTS is fairly similar to all other Documentum components: first you start with installing the different binaries and then you can configure a docbase to use/be supported by the ADTS. By doing that, the ADTS will update some configuration files that therefore need to be updated again if you want to deactivate a docbase. As you know, the ADTS is a Windows Server so I won’t show you commands to be executed in this section, I will just point you to the configuration files that need to be edited and what to update inside them. In this section, I will use %ADTS_HOME% as the folder under which the ADTS has been installed. It’s usually a good idea to install the ADTS under a specific/separated drive (not the OS drive) like D:CTS.
So the first thing to do is to prevent the different profiles for a docbase to be loaded:
Open the file "%ADTS_HOME%CTSconfigCTSProfileService.xml" ==> Comment the whole "ProfileManagerContext" XML tag related to DOCBASE1 ==> In the end, you should have something like: <!--ProfileManagerContext DocbaseName="DOCBASE1" ProcessExternally="false"> <CTSServerProfile CTSProfileValue="%ADTS_HOME%CTS\docbases\DOCBASE1\config\profiles\lightWeightProfiles" CTSProfileName="lightWeightProfile"/> <CTSServerProfile CTSProfileValue="%ADTS_HOME%CTS\docbases\DOCBASE1\config\profiles\lightWeightSystemProfiles" CTSProfileName="lightWeightSystemProfile"/> <CTSServerProfile CTSProfileValue="%ADTS_HOME%CTS\docbases\DOCBASE1\config\profiles\heavyWeightProfiles" CTSProfileName="heavyWeightProfile"/> <CTSServerProfile CTSProfileValue="/System/Media Server/Profiles" CTSProfileName="lightWeightProfileFolder"/> <CTSServerProfile CTSProfileValue="/System/Media Server/System Profiles" CTSProfileName="lightWeightSystemProfileFolder"/> <CTSServerProfile CTSProfileValue="/System/Media Server/Command Line Files" CTSProfileName="heavyWeightProfileFolder"/> <CTSServerProfile CTSProfileValue="%ADTS_HOME%CTSdocbasesDOCBASE1configtemp_profiles" CTSProfileName="tempFileDir"/> <CTSServerProfile CTSProfileValue="ProfileSchema.dtd" CTSProfileName="lwProfileDTD"/> <CTSServerProfile CTSProfileValue="MP_PROPERTIES.dtd" CTSProfileName="hwProfileDTD"/> <ForClients>XCP</ForClients> </ProfileManagerContext-->
Once that is done, the queue processors need to be disabled too:
Open the file "%ADTS_HOME%CTSconfigCTSServerService.xml" ==> Comment the two "QueueProcessorContext" XML tags related to DOCBASE1 ==> In the end, you should have something like (I'm not displaying the whole XML tags since they are quite long...): <!--QueueProcessorContext DocbaseName="DOCBASE1"> <CTSServer AttributeName="queueItemName" AttributeValue="dm_mediaserver"/> <CTSServer AttributeName="queueInterval" AttributeValue="10"/> <CTSServer AttributeName="maxThreads" AttributeValue="10"/> ... <CTSServer AttributeName="processOnlyParked" AttributeValue=""/> <CTSServer AttributeName="parkingServerName" AttributeValue=""/> <CTSServer AttributeName="notifyFailureMessageAdmin" AttributeValue="No"/> </QueueProcessorContext--> <!--QueueProcessorContext DocbaseName="DOCBASE1"> <CTSServer AttributeName="queueItemName" AttributeValue="dm_autorender_win31"/> <CTSServer AttributeName="queueInterval" AttributeValue="10"/> <CTSServer AttributeName="maxThreads" AttributeValue="10"/> ... <CTSServer AttributeName="processOnlyParked" AttributeValue=""/> <CTSServer AttributeName="parkingServerName" AttributeValue=""/> <CTSServer AttributeName="notifyFailureMessageAdmin" AttributeValue="No"/> </QueueProcessorContext-->
After that, there is only one last configuration file to be updated and that’s the session manager which is the one responsible for the errors printed during startup of the ADTS because it defines which docbases the ADTS should try to contact, using which user/password and how many tries should be perform:
Open the file "%ADTS_HOME%CTSconfigSessionService.xml" ==> Comment the whole "LoginContext" XML tag related to DOCBASE1 ==> In the end, you should have something like: <!--LoginContext DocbaseName="DOCBASE1" Domain="" isPerformanceLogRepository="false"> <CTSServer AttributeName="userName" AttributeValue="adtsuser"/> <CTSServer AttributeName="passwordFile" AttributeValue="%ADTS_HOME%CTSdocbasesDOCBASE1configpfilemspassword.txt"/> <CTSServer AttributeName="maxConnectionRetries" AttributeValue="10"/> </LoginContext-->
Once the configuration files have been updated, simply restart the ADTS services for the changes to be applied.
And here we go, you should have a clean environment with one less docbase configured without having to remove it on all servers. As a final note, if you ever want to reactivate the docbase, simply uncomment everything that was commented above, restore the default line from the custom “startstop” scripts and rename the Documentum start scripts with their original names (without the “_deactivated”) on the Content Server and Full Text Server.