Records Manager – Bulk Declaration

The FileNet Records Manager product addresses an organisation’s need to manage archival and retention of paper and electronic documents. It also assists in the automation of a lot of the tasks required to meet regulatory compliance legislation. If you’ve never heard of it, that may be because more recently, IBM have renamed it InfoSphere Enterprise Records.

The very first step in creating a record is to declare it to Records Manager – effectively this is a reference to the original record. One of my previous customers was a Records Manager user, and had over a million recently migrated documents in one of their Object stores, so they had a requirement to declare all of these into Records Manager. In this situation there are three potential solutions:

• AutoDeclare. This would have been the ideal facility to have in place before the migration, but unfortunately this did not happen. AutoDeclare is a downloadable component that is implemented as an Event Action handler within the object store, and can be configured to automatically declare specific classes of documents.
• Workflow. As with the option above, there is a Component Integrator step that addresses record declaration, but again this would have been needed to be deployed in advance of the migration, along with a workflow subscription. Although there is an extraneous overhead of having to use the Process Engine, it has the advantage that sophisticated processing logic can be applied quickly. One would also have to question the suitability of using a workflow in dealing with large bulk volumes of documents.
• Bespoke utility. The last resort was to create a custom Java application that searches for all migrated undeclared documents, and declares them, and this was the adopted solution.

Of course, the main Records Manager API contains appropriate methods for declaring documents, however, in this scenario this would entail going through each individual document within a results batch, and declaring it in turn. Taking such an approach would massively impact performance, so not recommended.

Step forward BDS, or Bulk Declaration Services. This uses a Batch approach, so when requesting an individual document be declared, the request is stored within an internal queue until the whole batch is executed. Compared to using the vanilla Records Manager API, performance is boosted dramatically.  There is scope for tuning this though – the key parameter being batch size – through trial and error.  And the API doesn’t just deal with electronic records, it can process physical records too.

Curiously, despite BDS being bundled with RM, it also supports the creation of new documents, meaning that it can be used to create high-performance bulk migration applications.