Consider your business requirements when you plan the content federation
system.
- Who will access the federated content from a FileNet® P8 application and how?
- Which external repository will be mapped to which object store?
- Which custom properties and document classes in the external repository will map to properties
and classes in the Content Platform Engine object stores?
- Do you need to create new properties or document classes in Content Platform Engine?
- Will users navigate to content by browsing folders? Do you need
to create new folder structures for the federated documents?
- Will users search for text in document contents or property values?
Do you need to create store searches and search templates?
- Will security for the federated document be applied according to the document class that is
associated with a document, or according to the folder in which the document is contained?
- Will the document properties in the external repository be updated,
thus requiring an update to the federated document properties?
- Will the federated document content consist of a version series?
That is, will the federated document content need to be updated when
the content in the external repository is updated?
For best results, set up your basic FileNet P8 environment
first, and then build the data maps and federation rules to populate the FileNet P8 environment with your federated data.
Restrictions: - Content federation does not support compound documents. Although each component of a compound
document can be federated, the relationship is not maintained.
- Access control lists are not federated from the source repository. You must manually configure
security for the federated documents in the target Content Platform Engine
object store.