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.
- 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.
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.