We've been trying to find information about the best way to write FileNet properties onto documens so that users can see these properties when viewing or printing.
We will focus primarily on Microsoft Office files (.doc and .docx) but we wish to find a more general solution for other formats as well (PDF, images with EXIF etc).
Assuming we are writing to the content object at some point, there are basically two ways we can accomplish this.
Writing to custom properties of the Microsoft Office documentWe write to custom properties using Apache POI. This approach of course means that the document has to have the appropriate custom properties defined. Fields in the header and footer of the document then refer to these custom properties. At some point the fields must be updated, though. This can hopefully be done with Apache POI as well, but a solution using an embedded macro might be sufficient.
Writing directly to the appropriate elements in the Microsoft Office documentThis approach requires the Apache POI code to be more intimately coupled with the Microsoft Office document at hand, but basically means substituting the actual text in the document at the appropriate places. This seems awfully brittle, but might work.
The following are possible solutions that we've come up with including pros and cons.
1. Writing to the document on retrieveThis seems to be the most attractive solution. The document residing on the actual content element would not have the most recent FileNet properties, but we would modify the stream "in flight" if you will. This would work for users viewing, printing, checking out and downloading. However, there seems to be no way to hook in to retrieval using a Code Module or other mechanisms.
2. Using Event Actions on document check in
- According to the documentation, Synchronous Event Actions may not modify the content elements, so that seems to be out of the picture.
- Modifying content through the CE API without checking out the document can never be done, even as an administrator.
- Asynchronous Event Actions would require checkout out the document and checking in the modified version. This would mean that for every version checked in by a user, a new version is created which supersedes the one the user checks in. It also becomes problematic with major and minor versioning.
- A user checks in version 0.1
- An Asynchronous Event Action creates a new version 0.2 (depending on major/minor policy in the Code Module)
- The user decides to check out 0.2 (which creates a 0.3 Reservation)
- The user checks in the document as major version and 0.3 becomes 1.0
- The Asynchronous Event Action creates version 2.0? Creating version 1.1 would create problems for users only seeing major versions.
3. Using a Servlet to modify contentDeveloping a Servlet to create a temporary file, modify the document using the above mentioned methods and then forwarding that to the user. This would require adding a custom action in Workplace XT to view the document. It would also not be transparent to other clients such as FIMO or when using Rendition Engine.
4. Using Rendition EngineSomehow hooking into the rendition pipeline and modifying the document using the above mentioned methods could be a feasible solution, but have the obvious drawback that there would be a discrepancy between the source document and the rendered version (properties show in the header of the rendered PDF, but not in the original document).
5. Using FileNet Integration for Microsoft Office (FIMO)Earlier versions of FileNet integration with Microsoft Office had the feature to insert and update properties. This feature seems to have been dropped. There might still be some script object we can access from macros, but the documentation seems to be lacking quite a bit here.
Updating properties when editing the document would also mean possible discrepancies regarding the major and minor version (these refer to the Reservation Object when working with the document and checking in as Major version would increment the major version number as well as making the minor version 0) as well as properties changed outside of Microsoft Office without checking in and out. For example, a workflow might update a property representing a document status.
6. Updating the document directly on the File StoreLet's pretend that this solution never crossed our mind and leave it at that...
Thank you for any contributions to this discussion and sorry for the wall of text.