Workflow Migrator

The Workflow Migrator is shown in the following figure.

Figure 10-17. Workflow Migrator

This migrator provides the following additional import behavior options:

  • Replace existing special cmds?

    If the workflow to be migrated references PPM special commands that already exist in the target PPM instance, you can replace them. This includes special commands that the workflow references directly, as well as special commands that these special commands reference. Special commands in validations that the workflow references are also migrated.

    The default value is No. Regardless of the value, any special commands missing from the destination instance are created automatically.

  • Replace existing step sources?

    If the workflow to be migrated references workflow decision and execution step sources that exist in the target PPM instance, you can choose to replace them or leave them in place. However, if workflows in the destination instance are using the existing step sources, you cannot change certain options (such as Workflow Scope,Validation, and Decision Type), even if you set Replace Existing Step Sources? to Yes.

  • Replace existing sub workflow?

    To overwrite an existing subworkflow in the target environment when subworkflows are migrated (with or without the main workflow), set this option to Yes.

  • Add missing environments?

    If the workflow to be migrated references environments or environment groups that do not exist in the target PPM instance, you can create the environments or environment groups. However, only the environment header information and user data are transferred. Application codes and extension-specific Environment tabs are not transferred. The default value is No.

    Similarly, environment group application code information is not transferred. If an environment group exists in the destination instance, it is not updated with environments added to the source instance. If the migrator has created environments, then after migration, make sure that you confirm and complete the environment data manually.

  • Add missing request statuses?

    If the workflow to be migrated references request status values that do not exist in the target PPM instance, you can create the status values. The default value is No.

For information about controls in this migrator, see Defining Entity Migrators.

Configuration Considerations

The Workflow Migrator also transfers the following information:

  • Subworkflows that the workflow steps reference

  • Special commands that the command steps reference

  • Workflow step sources that the workflow steps reference

  • Validations that the parameters or workflow step sources reference

  • Environments and environment groups that the workflow steps reference

  • Environments that the environment groups referenced by workflow steps reference

  • Environments that validations reference

  • Special commands that validations reference

  • Special commands that the workflow step sources reference

  • Special commands referenced by other special commands referenced elsewhere

  • Security groups that the workflow steps reference

  • Request statuses that the workflow steps reference

  • Notifications that the workflow steps reference

  • Notification intervals that notifications reference

  • Security groups that notifications reference

  • Ownership group information for the workflow and workflow steps

If a notification in a workflow uses a notification interval that does not exist in the destination instance, the migrator creates this notification interval. The workflow migrator does not replace existing notification intervals in the destination instance.

The Workflow Migrator transfers entity restriction references to object types, but does not create an object type. If the referenced object type does not exist in the destination instance, the migrator discards the reference and records the event in its execution log.

The Workflow Migrator transfers references to request types, but does not create request types. If the referenced request type does not exist in the destination instance, the migrator discards the reference and records the event in its execution log.

If there are circular references between workflows and request types, you may have to migrate either a workflow or request type twice:

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

  • The new workflow is migrated.

  • The new request type is migrated again. This time, because the referenced workflow exists, the references are preserved.