Recommendations: Interview the business users and SMEs and record their comments as a set of initial requirements for the system. Use a proof-of-concept (POC) to validate the requirements and design in the early phases of the project.

Recommendations: Even if you start with a top-down approach, keep SMEs informed and involved at an appropriate level. Let them know that they will be vitally involved as you get to the more concrete layers. An information vacuum can create genuine misunderstandings that can make everyone’s job more difficult.

Recommendations: Put the naming standards in place prior to the creation of any design or organizational objects in a repository and ensure that they are adhered to throughout the lifetime of the repository. Ensure that names are as descriptive as possible with consideration for the consumer of the label.

Recommendations: Use a unique prefix for symbolic names that you create. The choice of prefix is yours. It is typical to use something short but meaningful.

Recommendations: Prefix the document class with the common prefix for the system, department name, and the purpose so that it is easy to find out the purpose of the class by looking at the name.

Recommendations: Use the Category field in the property template for categorizing the properties. Property template names need to follow the standard naming scheme and topology established at the enterprise level. Property template names need to be generic enough that they can be used in a number of design classes but not so generic that they cannot be given a meaningful name.

Recommendations: If you create applications that use IBM Content Navigator, considering using External Data Services (EDS) to control user interface elements instead of choice lists. An EDS is more flexible for application developers.

Recommendations: Complete the design as much as possible prior to actually creating the design elements in the system.

Recommendations: If your design calls for more than a single object store, create a metastore that can contain all of the design objects that are common across all of the stores and replicate this as changes are made. If a meta object store is used, do not roll this store out into production, because it is strictly a development object store. When creating an object store, always set the object store administrator to a valid administrator logon and grant the administrator all permissions.

Recommendations: Using the database store can help with operational efficiency in some cases, but it almost always represents a performance cost over file storage.

Recommendations: The media type and cost must be clearly understood from the file store name to eliminate content storage area errors.

Recommendations: The Content Platform Engine guarantees that application access to cached content always follows the normal security controls, and it also guarantees that applications will not access stale content. Therefore, you can use a content cache area wherever it provides a benefit. You do not have to worry about compromising security or data integrity.

Recommendations: Avoid making many subclasses for a custom document class. Changes to a higher level custom document class will be propagated to all its subclasses.

Recommendations: There needs to be a single, top-level document class that extends the base document class and from which all other document classes will be derived. All property templates, choice lists, storage policies, and storage areas need to be created prior to creating any document classes that utilize them. Each document class encapsulates a single design aspect. Create all the metadata in the meta object store and export and import the metadata from the metastore by using IBM FileNet P8 Deployment Manager as described in Chapter 9, “Deployment” on page 271. Never skip the step of designing high-level abstract objects that are for aspect encapsulation and that most likely are never instantiated.

Recommendations: Use a search paradigm to search for documents with as much metadata information as possible to get a small result set. As much as possible, avoid using wildcard searches, which give you a large result set.

Recommendations: In most cases, the search paradigm offers a much better model for performance and maintenance. Avoid too many layers of too many folders (keep the total number to tens of folders, not hundreds), which can impact retrieval performance. There needs to be a single, top-level folder class that extends the base folder class and from which all other folder classes will be derived. All property templates and choice lists must be created prior to creating any folder classes that utilize them. Create all the metadata in the metastore and export and import the metadata from the metastore using the deployment tool. When using a browse paradigm, make sure to file the documents in a meaningful foldering hierarchy. Each folder class encapsulates a single design aspect.

Recommendations: There must be a single, top-level custom object class that extends the base custom object class and from which all other custom object classes will be derived. All property templates and choice lists need to be created prior to creating any custom object classes that use them. Each custom object class encapsulates a single design aspect.

Important: The two subclasses created by any custom root class are disjoint because they are in separate table. Deleting the class definition for a custom root class will drop the associated tables.

Recommendations: Property templates need to follow a standardized naming scheme and topology established at the enterprise level. Property templates need to be generic enough that they can be used in a number of design classes, but not so generic that they cannot be given a meaningful name. Avoid the creation of property templates that are named in such a manner that it might be confusing to know which template to use. Avoid the creation of property templates that encapsulate the same informational data but have distinct names.

Recommendations: Group choice list elements logically with the user experience in mind. Limit the number of elements in each group to a small enough set that it can be easily displayed and scanned. Avoid assigning the same value to more than one item in a choice list. Do not use choice lists for properties where the values are expected to change frequently.

Recommendations: Assign lifecycle policies to a document class whenever possible, instead of assigning them to individual documents. This practice helps the operator select the correct policy by choosing the document class associated with the desired lifecycle policy. This practice also prevents problems that can occur if you need to delete a lifecycle policy.

Recommendations: Add properties to subclass event actions and subscriptions. Keep event actions short to ensure quick completion. This is especially true for synchronous subscriptions where the subscription processor waits for an event action to complete before moving on to subsequent processing. Do not rely on priority to guarantee the order of execution for subscriptions. Ensure that you thoroughly test your events and subscriptions before implementing them. Set up each event action with code stubs that specify each event trigger (Create, Update, Delete, CheckIn, CheckOut, File Event, Unfile Event, Mark for soft delete, and recover to restore from recycle bin), even if you do not define functions for every trigger. The subscription controls which of the triggers call an action. You need to prepare the action to handle all triggers gracefully.

Recommendations: Marking sets need to contain no more than 100 markings. Marking sets are domain objects. Having more marking sets affects the performance and the memory footprint of Content Platform Engine server.

Folder option	Impact
Unfiled content (does not use folders)	•Content is only accessible by search. •There is no need to organize repository content using folders. •Transactions that add content are slightly faster. •Appropriate for high-volume image applications where access will be by search only.
Filed content (uses folders)	•Users can browse or search for content. •There is a need to organize the repository content. •A single version of a content object can be filed in more than one folder. •Appropriate for lower volume applications, or applications where users will be manually adding content.

Recommendations: When designing a central repository folder structure, we suggest that you start with the first three levels of the structure. Build this out for your entire organization.

Recommendations: Create a folder structure that makes sense for your entire organization. Develop your folder structure to at least the third folder hierarchical level. This structure forms the framework for your repository organizational scheme.

Recommendations: Limit the number of subfolders at every folder level. Create a hierarchy of subfolder levels rather than using many folders at the same level. Do not create a folder that contains more than 100 - 200 subfolders. Use a search paradigm wherever is appropriate, and limit the search result size.

Recommendations: Try to give meaningful name properties to objects to assist users in navigating through collections of documents returned in a search or a browsing session. Try to match content with storage media in a meaningful way. Internal memos and other short-lived pieces of content without lots of business value can be stored on a simple network-attached storage (NAS) device. Content that is critical to the business operation can utilize a high-speed, highly available storage subsystem that also has a higher cost associated with it.

Important: P8 Content Manager does not support direct writes (updates) to the P8 Content Manager catalog database.

Note: When selecting a property to index, the object store search must be case-sensitive, or the index is not created correctly. You must create additional indexes in Oracle and DB2 to avoid full table scans.

Note: The file names of the content written to this directory will be based on Global Unique Identifiers (GUID) associated with the document.

Recommendations: Use storage policies with the class definition to save the content.

Recommendations: Use Content Platform Engine administration tools to configure storage policies and storage area farms.

Recommendations: Set up a separate, database object store for IBM FileNet Records Manager. This object store is commonly called the file plan object store (FPOS).

Note: Use aligned mode when you want strict enforcement of retention on the content object in the document. Use unaligned when all you need is enforcement by Content Platform Engine.

Note: Initially, set the sweep to preview or preview only counters mode to determine the objects that are going to be disposed of. Use the FileNet System Monitor to monitor the sweep activity and sweep rate.

Note: A policy-based sweep combines all policies, including the retention update policy and disposal policy for a certain base class, into a single sweep.

Note: You can create a covering index for better performance of policy-based and job sweeps on the base table being swept. The covering index needs to include all the columns that are included in the selection list and define the object_id as a unique value. The selection list for sweep is in the P8 database trace logs with Sweep.SQL. A sweep that includes the overflow table has to include a covering index for the overflow table.

Note: When users modify their search criteria, the system remembers the settings and will display them again on the next visit to the site.

Note: When IBM Content Collector is used with the Content Platform Engine, text extraction for the binary documents occurs on the CSS server via the IBM Content Collector plug-in.

Important: Content Platform Engine load balances and fails over within the affinity group and among the indexes that are not part of any affinity group. Consider the high availability feature when using affinity groups.

Important: Specify the complete list of languages used within the object store’s content. Identifying the correct language for a document improves the tokenization and search. Use CSS in a dedicated mode, such as index or search. Avoid using it in the dual mode of index and search. By default, each CSS server is configured to use four CPUs for indexing. Consider this configuration when deciding how many CSS server instances to create on the system.

Recommendations: If query criteria includes partitionable properties, consider using index partitions to reduce the number of indexes to search by increasing the speed of the search. Index partitioning increases the number of indexes created. If there are no partitionable properties on the query criteria, we advise that you not use the partition. Search with order by rank reduces the performance, so use this search only when required. Ranking is determined by the CSS server. Content-based searches tend to be slower when searches are run concurrently with indexing. Dedicate servers for content search because I/O and memory are the important factors in the search operation. We advise that you have up to 6 GB of memory for each CSS server. Content-based searches on property will perform better than the content and XML searches.

Important: Index area root directories need to be unique among index areas even if the root directory path is on the local disk.

Important: The location specified for the index areas needs to be accessible for read and write for all the CSS servers. If an index area is assigned to an affinity group, it needs to be accessible to all the servers in the affinity group.

Tip: To aid administrators using SQL View, the P8 Content Manager help files contain P8 Content Manager database view schema.

Best Practice: To ensure that database-first searches execute efficiently, set database criteria on indexed properties. The database-first searches require database indexes on at least one property in the WHERE clause for good performance. Otherwise, queries perform inefficiently during the database-only portion of the search. Specify limiting conditions on database criteria to achieve relatively small hit counts. Database-first searches are most effective when the database hit count is relatively small.

---