Time for one of those posts that I originally thought would be more dominant in my blog, using Documentum Technology. After all, it doesn’t matter how well your system interacts with the outside world if it falls on its face when it is used.

It is time to talk about renditions. A heavily used feature that people rarely actually think about. For most, it is just a way to have a PDF version of your favorite Word document for review or publishing. For some, it is a critical piece of a Digital Asset Management solution. However, it can also be an easy way to create a relationship.

For today’s example, think back in time to the old Card Catalog sitting in the Library. If necessary, call your parents and ask them what it was if needed. The card catalog was full of cards that helped you find books or periodicals in a library.

Now comes the digital age. All the cards are pieces of electronic data. We can now expand the card data and add a summary field. What if the information in our new virtual card catalog is from external sources and point to references throughout the Web? Well, we may want that data in XML format to keep it consistent. Sometimes, we may grab the referenced document if it is in a nice PDF format to facilitate searching and to insure that it is available at all times.

So, what do we have now? An XML document that may or may not have a PDF associated with it. The XML document could be updated if the summary is changed. However, that PDF document is still the same.

There are many ways to store this in Documentum, but this approach has the benefit of not requiring any work outside of Administrator and the ingest code. Since you have ingest code regardless of the approach, try using a Rendition.

1. Create a new format type. Model it after the PDF format type. The only difference is in the name.
2. When ingesting the XML document and it’s content, use the IDfSysObject.addRenditionEx2(…) method. The 7th parameter is a boolean that allows you to determine if the Rendition should move forward when a new version is created. Setting this to true allows the user to version the XML document without re-connecting the Rendition to the document.
3. From here, you can set the default view for that object type to your custom format. This will allow your interfaces to pick-up the PDF if it is present.

Now, there are other approaches to this challenge. You could store the XML as meta-data and attach the PDF as content. If you have a field going over 2000 characters, you may have a problem. You would also lose the original XML file and not every object would have content. You could use a Virtual Document as well, though I’ve been over that one.

You can go round and round on this with different approaches. I am just showing you one that you may not have considered. I ran across another situation where this applied once before, but I can’t remember the details anymore since it has been awhile.

Just remember this, renditions are cheap labor for forming relationships. The key detail is that the rendition that you are storing needs to be secondary to the primary object. They will share the same metadata and will live, and die, together.