Request Type Migrator

The Request Type Migrator has additional import behavior options from which to choose.

Figure 10-13. Request Type Migrator

The additional import behavior options are as follows:

• Replace existing req hdr type?

  If the request type to be migrated references a request header type that already exists in the target OpenText PPM instance, you can decide whether or not to replace it. The default value is No.

• Replace Existing special cmds?

  If the validation to be migrated references OpenText PPM special commands that already exist in the target OpenText PPM instance, you can decide whether or not to replace them. This includes both parent and children special commands. The default value is No.

  Regardless of their values, OpenText PPM automatically re-creates special commands that are missing from the destination instance.

• Add missing request statuses?

  If the request type to be migrated references request statuses that do not exist in the target OpenText PPM instance, you can decide whether or not to create them. The default value is No.

  In the execution log, a message is displayed for each referenced request status that is not created.

Configuration Considerations

The Request Type Migrator also transfers the following information:

• Request header types referenced by the request type

• Special commands referenced by command steps

• Validations referenced by fields of the request type or request header type

• Environments referenced by validations

• Special commands referenced by validations

• Special commands referenced by other special commands already referenced elsewhere

• Request statuses referenced by the request type

• Security groups referenced by the request type (on the Access tab)

• Workflows referenced by the request type

• Notifications referenced by the request type

• Ownership group information for the request type

The Request Type Migrator transfers references to environments from validations, but does not create an environment. If the referenced environment does not exist in the destination instance, the migration fails. In this case, you must create the missing environment manually in the destination instance.

Simple default rules, defined in the request type Rules tab, might reference users, workflows, or other objects. The Request Type Migrator transfers these references, but does not create a missing user or workflow. If the referenced user or workflow does not exist in the destination instance, the reference is discarded in transit, and a message to that effect appears in the migration's execution log. You must manually reconfirm advanced default rules after migration.

Circular references between request types and workflows could make it necessary to migrate either a request type or workflow twice:

• A new request type referring to a new workflow is migrated. Because the new workflow does not exist in the destination instance, not all references to that workflow are included in the new instance destination.

• The new workflow is migrated.

• The new request type is migrated again. This time, since the workflow it refers to exists, the references are included in the destination instance.