Determining if Migration is Valid

Before performing process migration, you must make sure that process migration to an earlier or later process template is valid.

Determining if Process Template Data can be Migrated

When migrating a process template with data, note the following:

  • The BPM runtime does not perform any data migration from one version of a process template to another. This means that the data for the destination version of the process must be in place, before migration is performed.
  • The BPM runtime does not check whether data is valid from the source version to the target version of the process template.
  • If your process has an ad-hoc activity, you must define an initializer for the activity which executes after the migration. This could actually be the migration point itself.

Processes may function incorrectly or crash after migration if the data is not valid after migration. Therefore, TIBCO recommends that you do not do the following between source and destination process templates:

  • Do not change the types of data objects.
  • Do not introduce new fields that do not have default values.

Determining Valid Migration Points

Openspace only displays the valid migration points for the process templates. If a task or gateway is a valid migration point, its name is displayed. Points in the process template that are not valid migration points are not shown.

If you have a process template that contains any tasks or gateways that cannot be migration points then, you can either:

  • specify a point in the process template that is a valid migration point, or
  • design a valid migration point into your process template based on the rules described below.
    Note: There is no way at design-time to see what tasks, gateways and events will be valid migration points.

Valid migration points are points of the process template where a single process thread executes. If more than one task at a time could be active then those tasks cannot be migration points and will not be displayed as a migration point in Openspace. This is because, as the BPM runtime does not know which task is executing at any time, it is impossible to specify a particular task as a migration point.

Therefore, a task that starts a parallel path is a valid migration point but any tasks that follow are not. This means that the following are not valid migration points:

  • Tasks that follow these gateways are not valid migration points:
    • Inclusive
    • Complex
    • Parallel
  • Tasks following tasks that have Timer events placed on their boundary with Continue Task on Timeout selected are not valid migration points.
  • Tasks following tasks with multiple instance loops with ordering set to Parallel and flow conditions that are set to One. This is equivalent to an exclusive gateway, and means that only the completion of the first activity instance causes flow to continue.

Any tasks inside embedded sub processes cannot be migration points, but the embedded sub process itself may be a migration point. Migration takes place before starting the sub process.

The following events cannot be migration points:

  • start events
  • events placed on the boundaries of tasks.

The task name is used to identify a migration point. This means that:

  • all tasks must have names
    Note: By default, gateways do not have names. This means that you must specify a name for all gateways in your process if you want them to be valid migration points.
  • task names must not be duplicated.
  • task names in source and destination process templates must be the same. If the task names differ, they will not be listed in Openspace as valid migration points.

    Migration cannot be performed on pageflow processes. Pageflow processes are short-lived processes whose data is not persisted, therefore migration should not be required.

Examples of Processes That are Invalid for Process Migration

The example below shows a process that is invalid for migration.

A business process displays that has a parallel flow. It has a start event that starts Task1. Task1 has an event on its boundary and a flow of tasks that goes from its right boundary and its bottom boundary.

In this example, only Task 1 is a valid migration point. This is because Task 2 and Task 3 could be executing at the same time as Task 4. Therefore, as the BPM runtime cannot know which task is executing at any time, a specific migration point cannot be identified. You could make this process valid by amending it as shown below.

A business process of a parallel flow displays. It has start event that goes to Task 1 has tasks flowing from its right side and underneath. After task 1 is a gateway. The task underneath task1 is linked to the gateway.

All tasks in the process are now valid migration points. This is because Task 2 and Task 3 must wait for Task 4 before they can execute.

Similarly, the process shown below is also invalid for migration.

A business process displays. It has a start event that flows to a receive task that flows to task 1 and task 2 and then an end event.

This is because the BPM runtime cannot determine when the receive task will be received so a specific migration point cannot be identified.