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.