FileNet P8 Records Manager

In Enterprise Content Management (ECM), when a document processing is complete and business is sure that the document is no more needed for any further processing or references, it can be destroyed. But regulatory compliance rules require companies to keep these documents for a certain time before they can be destroyed, for legal purposes.

This requires organization to setup a process for reliable archiving and retention storage of documents which are no more active. The process of archiving and managing these archived documents is called Records Management.

Records Management refers to managerial activities, such as planning, controlling, and organizing for the creation, storage, usage, retrieval, and disposal of records. In other words, records management includes all of the activities that you perform to maintain records throughout their lifecycle of creation, active use, inactive storage, and disposition.

The purpose of the Records Management is multifold:

  1. Archived documents can be moved to cheaper storage (i.e. conventional tapes) to reduce the storage cost and to improve the performance of repository holding the documents in use.
  2. Records are disposed of (or document to be deleted) when they are no longer useful or no longer required by legal, regulatory, or administrative directive. For example, Insurance policy documents to be deleted after 15 years of insurance policy end date.
  3. To make records are easily accessible when needed across the enterprise for legal purposes.
  4. Change the security settings of the archived documents so that it cannot be updated or deleted by anybody except an administrator.

IBM FileNet P8 product suite provides an add-on component, IBM InfoSphere Enterprise Records, to manage enterprise records. It enables enterprises to create and maintain accurate, secure, and reliable records for both electronic and physical information.

FileNet P8 Records Manager has three key software components:

  1. File Plan Object Store (FPOS)

    FPOS is the repository of record management entities including records, record category, folders etc. This object store is created in FileNet Content Engine (CE).

    Each time a document in ROS is declared as a record, a RecordInfo object is created in the FPOS and it points to the document object in ROS that is declared as record.

    Note: FPOS only stores pointers to the documents (and not the physical document) and therefore doesn’t have any file storage.

    In other words FPOS only hold record objects (FileNet P8 CE Custom Objects), where each of these objects has document GUID (a pointer to document in ROS), certain document metadata’s and record specific data i.e. record creation date.

    Note: As FPOS is a separate object store in CE, it requires a new database.

  2. Records Manager Web Application

    RM web application is a J2EE application installed on FileNet P8 Application Engine (i.e. IBM WebSphere Application Server). It is used to create and manage records.

  3. Disposition Sweep processes (daemon processes)

    Disposition sweep processes are Java applications which can be schedule to run at appropriate times every day to delete the records (and documents associated with them) ready for disposition.

    On Windows, ‘Schedular’ and on UNIX, ‘Cron Job’ can be configured to schedule Disposition Sweep.

Key facts about FileNet Records Manager:

  • When a document is declared as record, a record object is created in FPOS (or in simple terms a row in added to RM database, the FPOS database) with a link to the document stored in CE (ROS). Once a document is declare as record in RM, the security setting of the document (stored in CE) are wiped out and new RM security setting are imposed on it. Thus previous users of the document loose all accesses.
  • Once document is declared as record, it cannot be deleted or its properties can’t be modified in FileNet CE. This can only be done by RM Administrator though Records Manager web application.
  • A repository that contains documents that can be declared as records is referred to as a Records-enabled content Object Store (ROS). Records created in IBM InfoSphere Enterprise Records are stored in repositories called File Plan Object Stores (FPOS). Both object stores are part of Content Engine.
  • To successfully declare a document as a record, the ‘document class’ of the document must be enabled for declaring records and the document must not already be declared as a record. A document class is enabled for declaring records when the value of its CanDeclare property is set to true. A document has not yet been declared as a record if its RecordInformation property does not have a value.
  • Custom coding can be done using CE API’s to move content to cheaper file storage after they are declared as record.
  • IBM FileNet Records Manager does not support the declaration of CE folders or CE custom objects as records.
  • Each record is mapped to a specific version of document in ROS.
  • Records Manager provides a role-based user security model, and includes roles for Records Administrator, Records Manager, Privileged User (DoD and Base) or Records Reviewer (PRO), and Records User. Each role determines which tasks a user belonging to that role can performed.
  • The Records Manager JAVA API provides access to RM for performing record-related operations such as declaration, navigation, and disposal.

What happen after the records are deleted in FileNet RM?

After disposition sweep successfully deleted the record, the metadata of the RecordInfo object in FPOS is retained while the document object along with its content and metadata is deleted from the ROS.

An administrator can periodically run an object search on Recordinfo objects in FPOS through FileNet Enterprise Manager (FEM) to locate the records that have been deleted. This information can be archived and deleted if needed.

RecordInfo objects found in above search can be added to export manifest and then exported to a XML file. This XML file with metadata can be archived just in case if needed at later stage.

Limitations of FileNet eForms

IBM FileNet eForms allow designers to create form which resembles to the conventional paper based forms and can be worked in online as well as offline mode (i.e. when user is not connected to the network.).

eForm Designer, a windows desktop based application, is used to design eForms. eForms can be easily integrated with both workplace as well as BPF.

While eForm provides many benefits, it has few limitations or issues. Some of these issues are discussed as below:

  1. The data synchronization between eForms and BPF Case Tab is one way. From eForm to Case Tab.
    However if you want some values from BPF Case Tab to eForm (i.e. BP8 Case ID), there is a way to obtain this information using the CE_Operations on Workflow. You can use setIntegerProperty operation to set this value to eForm field (as eForm will be Workflow’s attachment)
  2. If there are multiple tabs in an eForm, you can not hide / show tabs based on user role or security settings. For example if you have 10 tabs in an eForm which is integrated with BPF, this exact same eForms will be available to users across lifecycle of the case in BPF. You can not hide certain tabs based on user profile.
    But the fields in the eForm can be made read only using custom Java Scriptbased on certain condition including user role or the Inbasket where you are opening the case (eForm).
  3. Custom Java Scriptis used for validation, disable/enable fields and for loading lookup fields on load. But eForms designer has a limit of 32k char for custom Java Scriptfor an eForm.
  4. In case of database lookup, the database userid, password and connection information is kept in eForm template.
  5. eForm db connection string limited to 250 characters in eForm Designer. This issue arises specifically in case where user tries to connect to a database which is running on two instance and load balanced. In this case designer needs more then 250 characters to fit the db connection string.
    i.e. below script cannot be use for db lookup as its length exceeds 250 chars.

    One of the options available to resolve the 255 char db connection string length limit in eForms is to setup an ODBC DNS entry all the user machines. This is an overhead and is not feasible in case eForm is integrated with BPF and used by many users across multiple locations.


FileNet FAQs

FileNet FAQ’s / FileNet Interview Questions

FileNet P8 Frequently Asked Question(s) provide answers to commonly asked questions about FileNet P8 products. Information provided on this webpage may not be up to date. We recommend you to visit FileNet website for latest information.

All views and opinions expressed in user comments are solely those of the individual submitting the comment, and not those of the or its staff.