There comes a time when SAP Business Objects report instances/history is well…too much history. We really do get pretty effective controls in the form of limits (controlled via the CMS of course). However, retention requirements for SOX or other regulatory rules may be dictated from on high which can cause the amount of content in XI to get slightly out of hand.
There are a number of industry standard, enterprise content management systems (ECMS) on the market today, and quite possibly, already in your organization’s hands (this post isn’t really about them specifically). Commercial products like Documentum or Filenet P8, or even open source solutions like Alfresco, are optimized apps used specifically for long term document retention, versioning, etc. These platforms are a perfect solution, and likely already a standard in an organization which requires retention of documents. The challenge is really only in publishing the content there from XI.
Remember my post on my thoughts on the best BI team structure? I hope by now you either have that SDK guru on staff now or have nuzzled up close to your application developer group. You are going to need them. With a combination of the BOBJ Enterprise SDK and your ECMS tool SDK, an elegant solution can be constructed.
Consider the following, simple, high level flow of content:
Seems pretty straight forward. We move stuff from point A to point B.
A good architecture here needs to take into account a few things:
- Identify the desired age of the instances requiring archival.
- Identify if all aged content should be archived or should only select history. In other words, do you target inbox docs, favorites, or just specific public folders?
- Have a thorough understand of the available parameters in the target system that it needs to archive and properly index the document.
- Figure out what file types should get archived considering the fact that XI stores agnostic content as well.
- Do you need to keep an archive log as well as pointers back to the ECMS from within XI? Maybe in the form of regular hyperlinks?
That said, we can paint a picture for a one possible version of this process flow for our program based on some of this logic:
* This type of capability should be attainable whether using the .NET or Java SDK.
Not to shamelessly plug, but consider tools like Sherlock® to dig into better ways to develop the archive strategy. Using tools that document the XI CMS and reports, combined with Auditor, you can further refine the process to identify unused, or not frequently used content that may make sense to shift to an ECMS for long term retention.
The takeaway here is I’m not sure XI is really an appropriate fit for a long term retention tool. DO NOT MISTAKE THIS POST. I actually really do like the concept of integrating content from disparate reporting systems into XI (or other, more approprate portal if available). It really gives the end user community a feeling of consistency if daily reports an be consumed from a single location vs. visiting 10 different systems. Like the idea but missing the SDK developer component? Ping us and let us know if we can help. This sounds like a fun project now that I’m proofing my blog post 🙂