IBM FileNet P8, Version 5.2.1            

Reassign object stores validation

Check all restrictions, prerequisites, and dependencies so you can validate object store reassignment.

In general, the global configuration that is used by the object stores and other entities that are reassigned must match between the source and destination FileNet® P8 domains. If the configuration must be present before the reassign operation can complete, then the destination domain configuration must be properly preconfigured. If the reassign operation validation phase detects a missing known prerequisite, the validation phase fails with errors.

Validation phase overview

After you specify everything to be reassigned, the reassign object stores operation proceeds to the validation phase. The validation phase compares information in the source and destination domains to ensure that all prerequisites are met and no restrictions are violated. In general, the global configuration that is used by the object stores and other entities that are reassigned must be compatible between the source and destination FileNet P8 domains. When you use the wizard from the graphical user interface, the user is immediately presented with any validation information, warnings, and errors. For the command-line interface, a validation operation can be run independently from the reassign object stores operation. You can then use the logs to review information, warnings, and errors.
  • If any restrictions are violated, the validation phase stops with errors.
  • If the validation detects missing prerequisites, the destination domain must be corrected or the reassign operation that is adjusted to meet the prerequisites before the reassign operation can proceed.
  • If a particular configuration is a dependency, a warning or informational statement is produced but the reassign object stores operation can proceed. However, the dependency must be correctly configured in the destination domain before you can use the object store.

Restrictions

For the reassign operation to proceed, the following conditions must be met:

Prerequisites

Items that must pass validation for the reassign operation to proceed.

Dependencies

In addition to the restrictions and prerequisites that are previously stated, you must be aware of any dependencies between the reassigned items and other application artifacts. You must develop a plan for handling these dependencies before you perform the reassigning object stores operation. For example:
  • Custom code that is not maintained in the reassigned object store as a code module. That code might need to be deployed into the new environment.
  • Custom launch or step processors might need to be deployed and configured in the new environment.
  • Configuration settings, such as application server JDBC data sources.
  • IBM® Case Manager solution deployment definitions. The definitions must be migrated to the staging object store of the destination environment that uses the documented IBM Case Manager tools and processes and the solution that is redeployed in the destination environment.
Some of the destination global configuration data the object stores and other entities depend on will be handled by the reassign object stores operation and others must be manually addressed after the reassign operation completes. The reassigned entities might not be fully functional until these configurations are provided.
  • To ensure the Global Configuration Data in the source and destination domains are updated to reflect the reassignments, use the Remove from source domain after reassignment option of the reassign object stores operation. If you do not select this option, it is your responsibility to ensure that the object store entries are removed from the source domain global configuration data before the Content Platform Engine at the source can access the object stores and their database, which is now assigned to the destination domain. Failure to do so can result in unpredictable behavior since the Content Platform Engines at the source and destination do not communicate and do not coordinate their access to the database.
  • When the object stores are reassigned to the destination, if the site they belonged to in the source does not exist in the destination, they are assigned to the default site for the destination domain.
  • If the database connection object the entities shared at the source does not exist at the destination, a new database connection object is automatically created by the reassign object stores operation by using the same named data sources as were present in the source environment.
  • All isolated regions and connection points for a reassigned workflow system will be created in the destination domain and removed from the source domain if the options Remove from source domain after reassignment and Reassign associated isolated regions and event export stores are both selected.
  • The destination domain and source domain have matching Rendition Engine connection specifications.
  • The destination domain and source domain have matching fixed content device configuration specifications.
  • The destination domain and source domain have matching content federation configuration specifications.
  • The destination domain and source domain have matching replication configuration specifications.
  • The destination domain and source domain have matching full text indexing server connections and configuration specifications.
  • The destination domain and source domain have matching IBM Enterprise Records configurations and versions. You cannot split record object stores and its file plan object stores to different FileNet P8 domains. A file plan object store with its associated record object store must be in the same domain.

For more information about FileNet P8 assets and potential dependencies when they are reassigned into a new environment, see FileNet P8 assets. If your application includes assets that were developed outside of FileNet P8 tools, consult with your application developer for assistance. These assets might include assets that are managed by other IBM products and tools or assets that are managed by external products and tools. Examples include analytics, rules, data services, custom widgets, and custom deployable code.



Last updated: March 2016
p8pcc267.htm

© Copyright IBM Corporation 2016.