IBM FileNet P8, Version 5.2.1

Common dependencies between objects

Any Content Platform Engine object that you can add to the export manifest is dependent on the class definition and property definitions that were used to create the object. This dependency means that the class definition and property definitions must exist in the destination environment for the object to be functional. FileNet® Deployment Manager ensures that required objects are exported from the source environment along with the dependent objects listed in the export manifest, and that the dependent and the required objects are imported to the destination environment in the correct sequence.

Restriction: The Default Instance Security of class definitions is always imported.

Typically, a dependent object references the object that it requires by ID rather than by name. Therefore, when you import the required object, you must ensure that it has the same object ID in the destination environment. It is not sufficient for the required object to be in the same folder path and have the same content and property values if the object ID is different.

Object dependencies

A dependency exists between two objects when one object references the other. When such objects are imported, the object that is referenced must exist in the object store before the object that references that object is imported.

For dependent relationships that are defined by a FileNet P8 application, FileNet Deployment Manager ensures that the objects are imported in the correct sequence. However, if your custom application defines dependent relationships, FileNet Deployment Manager cannot determine the correct sequence for importing the objects unless those objects are exported by applying one or more include options. Therefore, you must export and import the objects separately.

For example, if your custom application defines a relationship in which object A references object B, then object B must exist in the destination environment before you import object A. The import fails if object B does not exist when object A is imported.

To ensure this sequence, you must deploy object A and object B as follows:

Create separate export files for object A and object B.
Convert the assets in each set of export files.
Import object B to the destination environment.
Import object A to the destination environment.

Circular dependencies

A circular dependency occurs when two object-valued properties from different object instances point at each other. For example, object A has a property that references object B and object B has a property that references object A. This dependency can cause the import of object A and object B to fail because each object requires the other to be available in the object store. To minimize possible import failures, the import operation deploys defensive processing of most circular dependency scenarios. The defensive processing enables successful importing of the objects. However, the following circular dependency scenarios are not supported, and, if attempted, result in an import error:

The IsValueRequired property is true on the two object-valued properties that reference each other.
The Settability property is set to SETTABLE_ONLY_ON_CREATE for the two object-valued properties that reference each other.

Folder references

The export and import operations in FileNet Deployment Manager use path-based rather than ID-based references to folders. Path-based references are used to reference the parent folder of the folder, the security folder of an object, the containing folder in a Referential Containment Relationship (RCR), or a folder in a system or user-defined property.

If you move or rename a folder that you imported to the destination, and then later attempt to update that folder (or the objects that reference it) with a subsequent import, you might experience a problem because the existing destination folder has the same ID but has a different path.

If you import the folder itself, regardless of whether it was moved or renamed, the import operation succeeds for that folder. However, if the value of the folders imported parent folder property is different from the value at the destination, importing the object import has the same effect as moving the folder. This situation occurs because the folder path is determined by its parent folder property.
If you import the contents of the same folder, or other objects that reference that folder (a parent folder or a security folder, for example), the import operation fails with "referenced object not found" errors if there is no other folder with the referenced path on the destination. The operation succeeds if there is a folder with the expected path on the destination, even if a folder with the original folder ID does not exist on the destination.
The import operation searches for a folder in the destination with the same path as the folder on the source. If you move or rename an imported folder, which changes its path, any objects that reference that folder causes an error when those objects are imported.