In the past, one of the weak points in IBM WebSphere Portal is its handling of documents or files. Prior to verison 6.1, Portal came with a Portal Document Manager (PDM) portlet that did a fair job in letting you manage a file store in Portal. PDM had many faults too – it wasn’t all that integrated with web content management except from a link and the user interface was horrible.
Since version 6.1, IBM has been trying to get us to use Quickr for the document store. Quickr for Portal brought a nicer user interface, but still lacked good integration with WCM and was a completely different server to install and maintain.
Alternatives to Quickr included using IBM WCM’s built-in features to store documents. WCM has a file resource component that lives in the content repository and is easy to include in content. However, the file resource was a component, so it lived outside the content tree. This made it difficult for users because you could not store files in the same site area as content. You also could not create lists of these files using out-of-the-box navigators and menus.
If you wanted to store files in the regular site ares, you could create a content item and attach a file to it. This way you could build a list of links to the content items using a menu component. But, unfortunately, you could not create a link directly to that file to launch it without going through extra coding!
So it would be very nice to be able to store files in site areas as regular content, but be able to create links to the file directly. This way, you can create many files in a site area and create links to those files either in other content or through navigators and menus.
Now, with Portal 7, all that pain is behind us (hopefully!). In Portal 7 IBM added a new feature called a Resource Template. A resource template is really an Authoring Template designated to be a resource. When content is created using a Resource Template, the resource (a file) is opened instead of the content item.
A Perficient colleague of mine, Shyam Vishwanathan, and I were collaborating over this concept in one of our internal forums. Here are the steps that Shyam worked out:
- Create an authoring template and add a file resource element to the authoring template (using manage elements).
- As soon as a file resource element is added, the authoring template provides you the option to change the type of template from a content template to a “Resource” template. This shows up as Template Type under Item Properties.
- If you change the default selection from “content” template to a “resource” template, you will have to select the file resource element to be opened instead of the content.
- Create a new content item using the authoring template that you created earlier. Select a file (XLS, DOC, etc) to attach to the content item and save.
- Now you can link to this “content’s” file directly in a few different ways.
- From rich text editors you can select this content item to link by creating a hyperlink to this content.
- You can also link to this “content” from another content item by using the Link element. To render the link – you just render it like you would render any link element – and wallah you have the document opening up on clicking the link.
- You can also create a link to the uploaded document from a menu or navigator component using placeholder tags (title link or href)
- You can now have workflows with the document – since it is essentially a content piece.
Since you are using a regular Authoring Template for this feature, you can add additional meta data for your files. You can then use that meta data in search, menus, navigators, etc. For example, if you want a description for your file, add a text item to your authoring (resource) template. Then in a menu, you can display a link to the file and a description.
Using this feature, you can surely create a compelling document store right in WCM. Using WCM’s locking and versioning features, you might also be able to create a pretty nice digital asset library in WCM. Of course, Shyam reminded me that you need to keep your document storage needs in mind before jumping on to this.
- Large number of documents could considerably increase the table space allocation needs in the JCR databases.
- WCM is not optimized for document retrieval and other Document management suite features. So you need to use judgment while deciding between the need for a document management system vs. WCM.
Hi Mark,
Thanks for posting this! This approach helps with an interim solution approach at my current client. The long term approach is to use FileNet for doc management, and build a seamless FileNet integration with the WCM content authoring environment. But for the first release, we know we probably won’t have the available time/resources to get there yet. So this approach will work in the interim.
Bryan, let me know how you implement this. I’d like to see how you did it.
Pingback: upload files
Hi Mark, What do you suggest ideally how much documents one should keep in WCM and approximately of what size ? We are also uploading documents in WCM as an interim solution but we are not able to determine about what should be our hard stop. Like maximum number of documents and apprx. size we can upload in WCM without impacting performance ? Can you share your thoughts on this ?