Many Documentum Compliance Manager (DCM) 5.3 users are reaching a decision point on upgrading to DCM 6.5. The typical driver is primary support for DCM 5.3 expired on 12/31/2009 while DCM 6.5 will be supported until 08/31/2012. Typically DCM is used by companies operating in regulated industries (ex: pharmaceutical manufacturing) to meet regulatory requirements around managing their documentation (SOPs, Specifications, etc.) electronically. The product consists of extensions of the current core Documentum client application, originally WorkSpace and currently Webtop, along with other software integrations to provide required features for document control including dynamically applied watermarks (PDFAqua), electronic signatures, security, lifecycle and other additions to the typical Documentum client. Given reliance on Webtop, some common issues with DCM include:
- Its tendency to lag behind in release dates compared to the rest of the product stack, evident with the late release of the 6.5 version
- The general difficulty clients have had in upgrading between major releases.
This post will discuss some of the things to look for when considering the upgrade to 6.5.
Complexity of the DCM 6.5 Upgrade
The complexity of any DCM 6.5 upgrade varies dramatically based on the current version. The upgrade is simpler for those who already went through a major upgrade to get to DCM 5.2.5 or 5.3. For those who are still on a pre-5.x version of the product (e.g., based on Desktop Client or WorkSpace) the upgrade can be very complex. Users moving from pre-5.x versions will need to perform some re-architecting to move into the new framework and while the scope of that re-work is beyond this blog post, most who have undertaken it already would likely say it is not insignificant.
For users currently on the DCM 5.3 release, the overall upgrade should be much less painful. The core 5.3 framework items (Business Applications, Document Classes, Lifecycle Extensions, etc.) remain the same in DCM 6.5 and there are only a few changes that will require a closer look:
- Watermarks – PDF Aqua is no longer included with DCM 6.5 and watermark functionality is now delivered through Documentum PDF Stamping Services (PSS). This means the PDF Aqua templates and policies for applying watermarks have to be implemented from scratch in PSS. Documentum does not provide a migration tool for moving from Aqua to PSS at the current time.
- Controlled Printing – This is the ability to restrict printing of documents (e.g., only to certain printers or by certain people). Not everyone implemented this in the past, but it used to be supplied by Aqua but is now a module of PSS in 6.5. If Controlled Printing is in use, the configuration would have to be rebuilt with PSS.
- Electronic Signatures – Similar to watermarks, there is a new mode for creating the PDF signature page in 6.5. This means any signature page templates need to be re-worked into the new model.
- Application Customizations – There are minimal new DCM specific UI items so the majority of interface changes are inherited from Webtop 6.5. What this means is if the implementation has a lot of WDK-based configuration or customization of the 5.3 interface (e.g., removing buttons from screens, etc.) then these updates would need to be evaluated to make sure those WDK components still exist in 6.5, have the same configuration options, etc.
What this typically means is the DCM 5.3 to 6.5 upgrade looks like a lot of other Documentum upgrades regarding application (WDK) customization, with the addition of items around reconfiguring watermarking, electronic signatures and controlled printing. How much additional complexity that introduces will be driven by how much this functionality was used – for example moving 5 watermark policies from Aqua to PSS will take less time than moving 50 watermark policies.
Are There Other Concerns?
The primary additional concern from clients has resulted from EMC announcing the following at EMC World this year:
- They are not investing in Documentum WDK applications
- DCM features will eventually be part of the core product
Many clients are wondering if they should upgrade to 6.5 at all. As we have mentioned in other posts, some clients have remained on the 5.3 release either paying for additional support or not paying for support. For DCM clients with a stable application, reasons to consider delaying the upgrade include:
- Cost of the Upgrade (effort, PSS configuration)
- Risk of errors with a new system (stability, training)
- Similar Functionality between 5.3 and 6.5
Clients should evaluate their current installation and consider if adding better functionality to their current infrastructure would provide more benefit. Innovative clients have added consumer portals and PDF Aqua Replacments to their current installation both in preparation for an eventual upgrade as well as to provide immediate business benefits for their existing client base.
Conclusion
When examined from a technical standpoint, upgrading to DCM 6.5 should be a manageable process on par with other Documentum upgrades provided the upgrade is from the DCM 5.x product. Prepare for more work, potentially a lot more, if it is from a pre-DCM 5.x release. Regardless of the technical feasibility, in light of the uncertainty over the future of DCM, it will also be useful for clients to consider the ultimate costs of upgrading against other options available depending on how much DCM functionality they currently utilize and needs for delivering additional functionality to their customers.
If you have any questions, concerns or thoughts about your DCM upgrade, please attach a comment.
Russell Serbagi says
On the issue of watermarks/overlays: It is also true that DCM 6 does not provide an easy method of applying watermarks/overlays based upon the document attributes/properties as does PDFAqua. PDFAqua like functionality can be achieved using a custom JAVA plug in.
Sankar says
Thanks TSG for this article which provide more insight on DMC upgrade But we have found some issue with DCM PSS that the e-Signature created by PSS is not below meeting FDA PDF standers.
1. PDF should be Optimized for Fast web view.
2. Embed all fonts.
Do you have any suggestions for creation of the eSignature file using any other software?
Jon says
Hi Sankar,
The PSS product is using the Open Source iText software package to handle creating the signature page. We have used iText on multiple projects and it forms the foundation of our Open Source OpenOverlay product for applying overlays to PDFs and have found it to be very reliable.
The iText library does allow for specifying all kinds of PDF settings when working with PDF files, but unfortunately I have not found a way to configure many of these types of things through PSS – it does not appear to offer a way to configure them out-of-the-box beyond the properties that are available on the dmc_pss_esign_config object type. There is a property on this type (enable_compression) which is false by default – perhaps setting it to true will give you the compression you need. You may also have to update the pdf_version property to 1.5 or greater to use this compression flag. There does not appear to be a property on this type to specify embedding fonts though.
An alternative approach would be to implement a custom Signature Page method. In a custom method you could use the iText library and specify whatever types of settings you wish. You would likely then have to configure DCM to use this custom signature page method instead of its default one.
Jon
Sankar says
Hi Jon,
Thank you for your suggestion. I tried that setting enable_compression of pss config object value to true but still the PSS is creating signature page with Fast webview disabled.
I’m still not clear on your alternative approach to implement a custom Signature Page method . As you are saying that custom method would use iText library, if this is a case then we still have same issues since the default PSS is using iText API. As per as I know iText does not provide options to create fully embedded fonts and Fast webview .
I’m thinking that use the AddSignature( which we get when we enabled Trusted content services in docbase) method of documentum to create a signature page and then append that esig page to actual rendition by some third party tools. What do you suggest on this approach? Would there be any impact ? if so how?
Are the default lifecycle and DMC lifecycle would behave in same way , the reason I am is that if both are same then we can use the post action method to invoke that signature method?
Thanks
Sankar.
Jon says
Hi Sankar,
Do you need the PDFs to have embedded fonts and be optimized for fast webview (linearized) for electronic submissions to the FDA, for example regulatory submissions according to the eCTD specification?
I am asking because if that is the case I probably would look to update the PDFs you are using in submissions that come from DCM as part of the publishing process as opposed to trying to customize DCM processes to automatically produce PDFs in that format. For example, if you are using or plan to use electronic publishing software like eCTDXpress or Liquent InSight Publisher or others – they commonly have publishing engines that can export PDF content from Documentum and convert it into PDFs that meet the eCTD guidelines as part of the publishing process.
An approach like this might allow you to isolate the PDF conversion more than overriding or replacing core DCM functionality like eSignatures with customizations which can become complex pretty quickly….
Jon