Identifying application artifacts and assets

Document what is needed for the application migration and deployment process, including relevant information for all artifacts and assets in the application.

During the design and development phase, it is important to create and maintain an application package and supplemental material that lists all assets in an application. Any supplemental information that is needed for the application migration and deployment process must also be documented. This documentation is needed during the deployment phase and for future tracking and change management purposes. After this documentation is created, it can be used to track, manage, package, migrate, and deploy the application and its supporting components.

As you create this document, limit the selections to the application-specific classes and objects. In addition, include only the assets that are required in the destination environment. Do not include any assets that are unrelated to the source environment.

Gather the following information when you are documenting the application artifacts and assets that are related to the migration and deployment process:
  • The roles and the LDAP users or groups that are required to associate with the roles. Especially for an application that is deployed into a production environment, there might be a significant difference in roles, users, and user groups between the source environment and the destination environment.
  • A description of the application components. These descriptions consist of application assets that are created during development and the tool that is used to develop them.
    Tip: For application assets that are stored in an object store, create a single folder to file the assets. This practice makes it easier to locate and migrate those assets.
  • Any environment-specific references within the application, such as a URL embedded in a form template or workflow definition. These references must be mapped as part of the application migration and deployment.
  • Any customizations of the Content Cortex applications, including applications and Enterprise Java™ Beans (EJB) components that use one of the Java APIs and JAR files that implement workflow adaptors.
  • The object store content, which can include the following objects:
    • Documents (including unfiled documents), stored searches, search templates, workflow definitions, external objects, and other customer-generated content.
    • Folders or folder hierarchies that are created for the application.
      Tip: Ensure that you export the complete folder hierarchy for your application. Errors can occur if you export a single folder that is then imported into a different folder hierarchy in the destination environment.
    • Custom objects, such as Custom Root Class instances.
    • Class definitions that you created and, if you changed them, the system class definitions that were created for each object store.
    • Custom Root Class definitions. Custom root classes share the general attributes of any other root classes in the Content Platform Engine class hierarchy, such as Document, Folder, CustomObject, Annotation, and Link.
    • Custom properties and property templates.
    • Choice lists.
    • Event actions, subscriptions, and associated scripts.
      Tip: When you create a code module for an event action, you can either attach the associated Java class to the code module or you can specify the Java class, which then must exist in the class path on the server. If you use the first approach, the Java class is included in the export files. If you use the second approach, you must ensure that the Java class is transferred to the destination environment.
    • Document classification actions.
    • Security policies.
    • Document lifecycles actions and policies.
    • Storage policies.
      Tip: When you import an object that references another object, ensure that the referenced object exists in the source object store before you import the referencing object. For example, to successfully import a property template that references a choice list, ensure that the choice list exists in the destination object store before you import the property template. If the referenced object does not exist in the source object store but is included in the export manifest, then during the import process, FileNet® Deployment Manager attempts to sequence the imports properly to satisfy the dependent references. However, some dependencies are not known to FileNet Deployment Manager. For example, dependencies that are introduced by custom applications are not known to FileNet Deployment Manager, or some dependencies might be especially complex. If the first import operation fails due to reference dependencies, an attempt to run the import again might succeed. The successive import operation can import the referencing objects because the referenced objects were imported during a previous import.

For more detailed information about the deployable assets to consider, see Content Cortex assets.