Are you passionate about optimizing your OpenText Documentum migration process? Welcome to the third episode of our blog series dedicated to simplifying OpenText Documentum migrations using dqMan. If you want, you can quickly dive back into the first and a second episodes – if not, just keep reading.
dqMan allows generating DQL and API scripts starting from the results displayed in the Results window. A real use case is described below, i.e. some migrations/upgrades need to be performed with inactive dm_job objects. It is therefore necessary to find out (and record) which jobs are active before the upgrade, make them inactive and then reactivate them after the upgrade step is finished.
This function is extremely useful when objects (with or without further modifications) need to be duplicated from one repository to another (e.g. new functionalities created in the DEV environment that require many configurations/groups/ACLs etc. that need to be copied to the TEST environment).
1. Add the id to compare list
Find the active jobs by executing the following query: Select * from dm_job where is_inactive = false;
2. Use results to generate the script to enable the found jobs
Use Ctrl+A in the Results window to select all the results and use the option Generate Script from the right-click menu.
The resulting script will look like below. It should be copy-pasted in a separate document for safe keeping (until the jobs must be enabled again).
3. Disable the jobs
Disable the jobs by executing the following query: update dm_job objects set is_inactive = true where is_inactive = false;
4. Enable the jobs after the jobs
Retrieve the DQL script created in section 2 above and execute it as follows:
A use case for an upgrade project is the need to repeat the same query in order to monitor when/if certain values or even objects were created. One good example would be monitoring the startup of ACS since an incorrect configuration (inside Tomcat) would generate new configuration objects in the repository (without this being treated as an error in the logs). Thus, during the initial startup after the upgrade it is required to monitor the number of the dm_acs_config object to know if a new configuration was erroneously created or the ones already configured after the upgrade are being used. Without this monitoring step, a new configuration could be created and used without anyone noticing the issue quickly.
Another real use case for a migration project is monitoring the number of migrated (imported) documents or monitoring the number/status of indexed documents (number of errors etc.). The functionality does not save the output of the execution, thus there is no risk of exceptions being generated outside the memory by executing this function.
1. Open the DQL window
2. Write a DQL and right-click directly on it (or select it)
3. Click on the Repeat Query every… option
4. Select a predefined time interval or define a custom one (5)
Whether you’re a seasoned Documentum administrator or just getting started, just reach out to us and we’ll be happy to guide you through every step of the way, ensuring you a migration journey with minimal stress and maximum results.
Simplify your OpenText Documentum migration with dqMan