Documentum – Unable to configure IDS 7.3 for a docbase

In this blog, I will talk about an issue with the IDS 7.3 which is installed on a Content Server 7.3. The IDS is the Interactive Delivery Services. It is a product provided by OpenText that needs to be installed on a Content Server (for the “Source” part) and on a Target Server (for the “Target” part). The IDS can be used to publish content from a Documentum repository to a target machine for use in another application or something like that.

When installing/configuring an IDS, there are several things to do:

1. Install the Source + patch if needed
2. Configure a docbase on the Source (basically install DARs)
3. Install the Target + patch if needed
4. Configure a docbase on the Target (basically setup of an agent which will use a DB + file system for the exported documents)

In this blog, I will only talk about an issue which will occur if you try to execute the step 2 with an IDS 7.3 on a Content Server 7.3. Once the IDS is installed and patched (if needed), you can configure a docbase using the config.bin file:

[dmadmin@content_server_01 ~]$ cd $DM_HOME/webcache/install/
[dmadmin@content_server_01 install]$ 
[dmadmin@content_server_01 install]$ ./config.bin

On the IDS Source Configurator, you just have to select the docbase you want to configure and it will start the configuration of the docbase. As mentioned above, the main thing it is doing is to install the DARs that are placed under “$DM_HOME/webcache/install/SCSDar/”. For that purpose, it will use the Headless Composer. When you do that, an error message will be printed saying the following:

DiWAWebcsConfigureDocbase failed! - Could not deploy $DM_HOME/webcache/install/SCSDar/SCSDocApp.dar.
 Please check dar installation log file $DM_HOME/webcache/install/SCSDar/DocBase1_SCSDocApp_dar.log for the installation exceptions.
Errors occured while invoking Headless Composer.; Runtime execution failed with child process "$DOCUMENTUM_SHARED/java/1.7.0_72/jre/bin/java" exit code of 13; For more detailed information, see the error log: $DM_HOME/webcache/install/setupError.log

So what’s the issue? To understand how twisted/evil the IDS is, let’s first talk about the CS 7.3. When you install a Content Server 7.3, it will install the binaries, the JMS, the Headless Composer and a single Java which is: $DOCUMENTUM_SHARED/java64/JAVA_LINK. Well this is actually a symbolic link to the real Java version installed by a basic CS 7.3: $DOCUMENTUM_SHARED/java64/1.8.0_77. So for a Content Server 7.3, it’s simple, everything is using Java 8u77.

[dmadmin@content_server_01 install]$ echo $JAVA_HOME
$DOCUMENTUM_SHARED/java64/JAVA_LINK
[dmadmin@content_server_01 install]$
[dmadmin@content_server_01 install]$ ls -l $JAVA_HOME
lrwxrwxrwx. 1 dmadmin dmadmin 39 Oct  5 08:07 $DOCUMENTUM_SHARED/java64/JAVA_LINK -> $DOCUMENTUM_SHARED/java64/1.8.0_77
[dmadmin@content_server_01 install]$
[dmadmin@content_server_01 install]$ $JAVA_HOME/bin/java -version
java version "1.8.0_77"
Java(TM) SE Runtime Environment (build 1.8.0_77-b03)
Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)
[dmadmin@content_server_01 install]$

Now why am I saying that the IDS is twisted? Well as you can see in the error message above, the path to the Java mentioned is “$DOCUMENTUM_SHARED/java/1.7.0_72”. Where is this coming from? One might think at first look that this is the java from a CS 7.2… And indeed it is the same version since a CS 7.2 was using Java 7u72 but it’s not even the same path… A CS 7.2 was using “$DOCUMENTUM_SHARED/java64/1.7.0_72” (notice the “java64” for 64 bits OS).

[dmadmin@content_server_01 install]$ $DOCUMENTUM_SHARED/java/1.7.0_72/bin/java -version
java version "1.7.0_72"
Java(TM) SE Runtime Environment (build 1.7.0_72-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.72-b04, mixed mode)

But it’s not all! If you take a look at the start script of the IDS 7.3 (below $IDS_HOME = $DOCUMENTUM_SHARED/wildfly9.0.1) you will see another Java!

[dmadmin@content_server_01 install]$ grep JAVA_HOME $IDS_HOME/server/startWEBCACHE.sh
JAVA_HOME="$DM_HOME/webcache/jre/linux"
export JAVA_HOME
[dmadmin@content_server_01 install]$
[dmadmin@content_server_01 install]$
[dmadmin@content_server_01 install]$ $DM_HOME/webcache/jre/linux/bin/java -version
java version "1.8.0_91"
Java(TM) SE Runtime Environment (build 1.8.0_91-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)
[dmadmin@content_server_01 install]$

So when you install an IDS 7.3 on a CS 7.3 (that is already using Java 8u77), it will run using a Java 8u91 and it will also install a Java 7u72… Why would you make it easy when you can make it complicated! Since the IDS will only run using the Java 8u91, what’s the purpose of the Java 7u72 then? Well the only purpose I could find is precisely linked to this issue: to install DARs.

By default the Headless Composer – since installed with the CS 7.3 – will use the Java 8u77 ($DOCUMENTUM_SHARED/java64/JAVA_LINK) but the IDS isn’t able to install the DARs with Java 8. I don’t know where the Java version to be used by the IDS during the installation is defined but it might very well be hardcoded because the Installer is using the file /tmp/dctm_dmadmin/install_xxxxx/istempxxxxxyyyyyyyy/bundledLinux.jvm to know which Java to use and it’s always the Java 7u72 (the bundled one). You can try to update the file “$DM_HOME/webcache/install/install_info.ini” with a different “BUNDLED_JAVA_HOME” but it won’t change anything.

So then how can you control which Java should be used by the Headless Composer? That’s done in the java.ini file!

[dmadmin@content_server_01 install]$ grep -E "^java_library_path|^java_classpath" $DM_HOME/install/composer/ComposerHeadless/plugins/com.emc.ide.external.dfc_1.0.0/dmbasic/linux/java.ini
java_library_path = $DOCUMENTUM_SHARED/java64/JAVA_LINK/jre/lib/amd64/libjava.so
java_classpath = $DM_HOME/dctm-server.jar:$DOCUMENTUM_SHARED/dctm.jar:$DOCUMENTUM_SHARED/config:$DOCUMENTUM_SHARED/java64/JAVA_LINK/jre/lib
[dmadmin@content_server_01 install]$

As you can see above (and I already said that above), the Headless Composer is using the Java that comes with the CS 7.3, so it is by default Java 8u77 ($DOCUMENTUM_SHARED/java64/JAVA_LINK). If you try to change the Java used in the java.ini file from Java 8u77 (CS 7.3) to Java 8u91 (IDS 7.3), it will still not work. What you need to do is changing the Java used to the value that the IDS expect and you can do it like that:

[dmadmin@content_server_01 install]$ grep -E "^java_library_path|^java_classpath" $DM_HOME/install/composer/ComposerHeadless/plugins/com.emc.ide.external.dfc_1.0.0/dmbasic/linux/java.ini
java_library_path = $DOCUMENTUM_SHARED/java64/JAVA_LINK/jre/lib/amd64/libjava.so
java_classpath = $DM_HOME/dctm-server.jar:$DOCUMENTUM_SHARED/dctm.jar:$DOCUMENTUM_SHARED/config:$DOCUMENTUM_SHARED/java64/JAVA_LINK/jre/lib
[dmadmin@content_server_01 install]$
[dmadmin@content_server_01 install]$ cp $DM_HOME/install/composer/ComposerHeadless/plugins/com.emc.ide.external.dfc_1.0.0/dmbasic/linux/java.ini $DM_HOME/install/composer/ComposerHeadless/plugins/com.emc.ide.external.dfc_1.0.0/dmbasic/linux/java.ini_orig_before_IDS
[dmadmin@content_server_01 install]$
[dmadmin@content_server_01 install]$
[dmadmin@content_server_01 install]$ export IDS_JAVA="$DOCUMENTUM_SHARED/java/1.7.0_72"
[dmadmin@content_server_01 install]$
[dmadmin@content_server_01 install]$ sed -i "s,$JAVA_HOME,$IDS_JAVA," $DM_HOME/install/composer/ComposerHeadless/plugins/com.emc.ide.external.dfc_1.0.0/dmbasic/linux/java.ini
[dmadmin@content_server_01 install]$
[dmadmin@content_server_01 install]$ grep -E "^java_library_path|^java_classpath" $DM_HOME/install/composer/ComposerHeadless/plugins/com.emc.ide.external.dfc_1.0.0/dmbasic/linux/java.ini
java_library_path = $DOCUMENTUM_SHARED/java/1.7.0_72/jre/lib/amd64/libjava.so
java_classpath = $DM_HOME/dctm-server.jar:$DOCUMENTUM_SHARED/dctm.jar:$DOCUMENTUM_SHARED/config:$DOCUMENTUM_SHARED/java/1.7.0_72/jre/lib
[dmadmin@content_server_01 install]$

After doing that, you can try to execute the IDS Source Configurator again and this time, it will be able to install the IDS DARs into the target docbase. Don’t forget to restore the java.ini to its initial value afterwards…