As readers who use EMC’s Documentum Compliance Manager (DCM) product will know, with the 6.5 release there was an architecture switch in the way dynamic overlays were applied to documents with the introduction of PDF Stamping Services (PSS). Prior to version 6.5, PDF Aqua was integrated into the product and customers used it to design and configure the overlays they needed to appear for documents as they moved through different stages of their lifecycle. These overlays could range from simple watermarks containing the current document status (e.g., DRAFT, APPROVED), to more advanced overlays including property and other related data of the document in dynamic headers.
In transitioning to PSS, many customers found that while it did provide many of the same capabilities as PDF Aqua there could still be certain scenarios where what was possible in a PDF Aqua overlay was not easy to duplicate in PSS. This post will describe one such situation and how leveraging OpenOverlay allowed the client to maintain their legacy overlay functionality with minimal system changes.
This particular pharmaceutical client had been using some advanced configuration to include a lot of information about manufacturing documents such as Standard Operating Procedures (SOPs) in their dynamic overlays. In addition to straight property data being including, for example the document number and title, they also were including additional data that was looked up dynamically from related documents. A specific example of this was including the document number of the Change Request that had been related to the SOP in the header of the SOP itself.
This became an issue when trying to translate this to a PSS overlay configuration. While PSS provided the ability to dynamically include property data, in this case the associated Change Request number was not being stored in a property of the SOP itself. It was being retrieved through a query against the dm_relation table utilizing the r_object_id of the SOP to find its associated Change Request. There currently is not a way to configure this kind of lookup in PSS.
The client considered updating their object model to add a property on the documents to store the Change Request number, but was hesitant due to the implications of doing this – having to populate the property for all their existing documents as well as design a way to make sure the property would be populated correctly going forward.
OpenOverlay has been a core TSG offering since 2007. It is used at many clients and enables key features such as electronic signatures, controlled printing, watermarking, overlay form responses, and letterhead and logo application. TSG has deployed it on Alfresco, Documentum, and portal systems. For Documentum users, OpenOverlay typically replaces the need for PDF Aqua or PDF Stamping Services. OpenOverlay is built on the Open Source iText engine for manipulating PDF files, similar to PSS. Overlay configurations are defined as xml files and indicate where on a document specific language or property information is to be displayed in the overlay.
The advantage OpenOverlay provided in this case was its ability to define any kind of placeholder, or token, in its overlay configuration files. There is no limit to only being able to specify actual document properties or static DQL or SQL statements. This allowed us to specify a placeholder in the overlay configuration, @CR_NUMBER, to display the desired information. Then at runtime when documents are viewed, this placeholder can be replaced by the dynamically looked-up information, which in this case was the result of a DQL query utilizing the r_object_id of the child document.
This solution allowed the client to maintain their legacy overlay functionality without requiring a major change in the object model and/or custom code in the system. And since TSG has integrated OpenOverlay with WebTop based solutions multiple times, its deployment for this client also had a minimal impact.
To see a demonstration of OpenOverlay – access our screen cam in our Learning Zone.
Robin East says
I’m pretty certain that the specific functionality mentioned is available with PSS although you’d be hard pressed to find it as the documentation of PSS is abysmal! It’s Friday night for me so I’m not inclined to open up the work laptop to see how we did it right now.
That said it’s nice to know that there are other alternatives out there as PSS still strikes me as an immature product. I also keep hearing colleagues lamenting the loss of PDf aqua.
One particular problem we have come across is where you want to display a version number on the overlay. Typically a controlled document changes to the next major version after signing but DCM makes it very difficult to change a document after it has been signed (for good reason). Dynamic overlays solve this problem however they are not persistent (because they are dynamic!) which causes a problem if you need to export the document to an external submission system . Any thoughts on ways to achieve this? Does open overlay handle this elegantly?
OpenOverlay allows for any placeholder to be defined in the overlay configuration, and then this placeholder can be dynamically populated at view time depending on the conditions. So for example, one could dynamically replace a field called “major_version” or something with a value of the next major version of the document instead of pulling directly from the r_version_label property. This would require some code to perform this evaluation though and determine the next major version label upon application of the watermark.
Also when you mention exporting, we have integrated OpenOverlay into our OpenMigrate product for multiple solutions – for example to bulk export documents with a watermark to a Learning Management System or other search-and-retrieval solutions outside of Documentum. So in a similar way one could use OpenOverlay to burn a watermark onto a document during the export process, and that watermark could be configured any way you wish. Although it might involve some more advanced configuration and/or light coding to dynamically lookup values depending on your requirements.