Debugging Documentum ADTS Transformation Failures

A client recently encountered an issue with their Documentum 6.7 environment where PDF renditions for certain document types were not being created. The client’s environment was leveraging Advanced Document Transformation Services (ADTS) 6.7, which utilizes Adlib as its underlying renditioning engine for rendering PDFs. As we discussed in a previous blog post, Documentum had announced end of life for support for ADTS at the end of 2016, and thus we at TSG were tasked with figuring out exactly why these renditions were failing.

Our investigation of this issue began with viewing the ADTS instance’s log files located on the ADTS server at %ADTS HOME%/CTS/logs. Specifically, we looked at the CTS_log.txt. Unfortunately, yet all too common, we only encountered a generic set of errors that didn’t really shed light on exactly why documents were failing to rendition. The errors simply stated that the renditions were, indeed, failing.

After further testing, we were able to uncover that the documents that were believed to be failing to rendition were actually producing renditions after all. By viewing the cache folder that ADTS utilizes – located at %ADTS HOME%/CTS/cache and defined during installation of ADTS – we were able to find temporary PDF files whose content matched the files that Documentum was attempting to rendition.

So that posed the question: if the renditions were being successfully created, why weren’t they appearing in Documentum? And after a myriad of tests, we finally uncovered the root cause of the problem: timing.

By referring to the Adlib logs, a set of log files that are located outside of the CTS/logs location mentioned above within the %Adlib Express Directory%/logs directory, we confirmed that the documents were indeed being successfully renditioned. No errors were being thrown and the logs even indicated a success message:

We then referenced the AdvancedPDF_log.txt located back in the %ADTS HOME%/CTS/logs directory. This log is produced by ADTS and contains logs that pertain to ADTS’s communication with Adlib. Here, we were able to find an error that indicated a timeout was occurring during the renditioning process. This seemed odd. Why would ADTS be timing out when everything points to the rendition actually being successfully created? Our answer was found by comparing the timestamp of the Adlib logs with the timeout error thrown in the AdvancedPDF_log.txt.

It appeared that ADTS was timing out before Adlib completed its entire renditioning process. Notice how after the bolded success message in the Adlib logs above, the job continues to process before closing the ticket. Clearly, the renditioning process handled by Adlib includes more than just creating the rendition itself; it is also responsible for creating and setting any bookmarks that may be present in the word document (which, as it turned out, the template that was being used for the documents that were failing in our client’s environment, contained 80+ bookmarks), as well as any post processing that occurs. So it seems that while the PDF rendition was being created within the allotted timeout parameter set in ADTS, the entire renditioning process was taking longer than that and was therefore timing out and not completing the upload of the document’s rendition from the cached folder to the docbase.

We were able to alleviate this issue by increasing the timeout parameter located in %ADTS Install Home%/CTS/config/advancedpdf/advancedpdf.xml. (View the official Documentum ADTS Installation Guide for more information on configuring this timeout).

ADTS debugging can be a very cumbersome process given the lack of support and outdated engine (Adlib is no longer what’s used by Documentum in 7.x and beyond). Please refer to our previous blog for more options in regards to reliable transformation options.