Validating object stores for reassignment

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:

  • The version of Content Platform Engine for the destination domain cannot be at a level lower than the source domain.
  • If the version of Content Platform Engine for the destination domain is a later version, then the source domain, and any workflow system, Case Analyzer store, or Case History store is included in the reassignment, the version of the source domain must be at least version 5.2.0.
  • The application server that hosts the Content Platform Engine must be the same vendor, type, level, and version.
    Tip: WebSphere® Network Deployment edition is considered as the same type as the base edition of WebSphere.
  • The source domain and destination domain cannot be the same.
  • You cannot reassign an object store to a destination domain when the global configuration database for the destination domain is offline.
  • When the global configuration database for the source domain is offline, you cannot use the option Remove from source domain after reassignment.
  • Object store (or any of its associated entities) cannot exist in the destination domain. If the intention is to replace the entities in the destination domain with the entities from the source domain, remove the entities at the destination to allow the reassign operation to proceed. If the entity is a workflow system, ensure that the destination domain does not have access to the underlying database that is used by the source. Ensuring that there is no access prevents the deletion of data that occurs when the last connection point for a given isolated region is deleted.
  • The source or the destination domain cannot be a tenant domain.
  • Reassign object stores is only supported when all items that share a database connection object are reassigned in a single operation.
    • Object stores sharing the application server data sources with the Global Configuration Data database cannot be reassigned.
    • Object stores sharing a database connection with a workflow system that references multiple object stores cannot be reassigned.
    • Object stores sharing a database connection with a legacy workflow system cannot be reassigned.
    • Object stores with an explicitly associated workflow system, Case Analyzer store, or Case History store, must use the Remove from source domain after reassignment and the Reassign associated isolated regions and event export stores options of the reassign object stores operation.
  • If the database connection object used by the reassigned items exists in the destination domain, the names of the data sources that are specified must match the data sources that are used by the database connection object in the source domain.
  • If a workflow system is referenced by objects in an object store, or contains workflows that reference objects in object stores, do not reassign those object stores unless the object store associated with the workflow system is also reassigned. In this situation, appropriate options must be selected to cause the reassign object stores operation to also reassign the associated workflow system. FileNet Deployment Manager might not be aware of all references between an object store and a workflow system. The user is responsible for determining when such indirect references exist and ensuring all related entities are included in the reassign operation.
  • The destination domain and source domain have matching versions of the same directory service provider.
  • Any addOns installed into the object stores being reassigned must be already registered in the destination domain. If any addOn is missing, the reassigning object stores operation fails with an error at the destination.
  • (V5.5.3 and later) If the source domain is configured for external key management, the destination domain must be configured to use the same external key management service. Reassigning from a domain with external key management to a destination domain with any of the following configurations is not allowed:
    • Content Platform Engine internal key management.
    • A different key management provider.
    • A different instance of the same key management service.

Prerequisites

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

  • The version of the FileNet Deployment Manager that runs the reassign object stores operation must be at the same level as the Content Platform Engine version of the destination domain.
  • The version of Content Platform Engine for the destination domain is at least the same version or later as the version of Content Platform Engine of the source domain. If the destination version is later, the reassigned object stores, workflow systems, Case Analyzer stores, and Case History stores are automatically upgraded to match the release level of the destination domain. This upgrade begins as soon as the Content Platform Engine at the destination detects the presence of the reassigned entity.
  • Data sources with the same names as those used by the database connection object in the source domain must connect to the appropriate database and by using a database connection user to ensure that the Content Platform Engine server can access the database schema and tables that hole the data.
  • If the chosen object stores are associated with any workflow systems, Case Analyzer stores, or Case History stores, the Reassign associated isolated regions and event export stores option of the reassign object stores operation must be chosen to cause the implicit inclusion of these associated entities into the reassign object stores operation. You can select this option only if the Remove from source domain after reassignment option is also selected.
  • The destination domain and source domain have matching marking sets. The GUID of the marking sets in the source and target FileNet P8 domain must match; it is not sufficient for the marking sets to have the same name. You can use the FileNet Deployment Manager export/import processes to migrate Marking sets between domains.
  • (V5.5.3 and later) For key management configuration, one of the following prerequisites must exist for reassignment:
    • Both domains use the default Content Platform Engine internal key management.
    • The source domain uses Content Platform Engine internal key management, and the destination domain uses an external key management service. In this instance, existing keys remain in the object store database, and new keys are created in the external key management service.
    • Both source and destination domains are configured to use the same external key management service. In this instance, both existing and new keys are in the shared external key management service.

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.