IBM BPM, V8.0.1, All platforms > Get started with IBM BPM > Key concepts > Versioning > BPEL processes > Migrating running process instances to a new version of the BPEL process > BPEL process model changes and runtime migration
BPEL process migration: Changes to the business logic of a process instance
If a new version of a BPEL process contains business logic changes, a process instance can be migrated if the process navigation has not yet reached any of these changes.
The following business logic changes are supported.
Basic activities
A basic activity implements a singular aspect or task within a BPEL process. Unlike structured activities, basic activities do not embed other activities within them. When you create a new version of a process, you can add or delete the following basic activities. You can also modify the properties of an activity in addition to its descriptive properties and quality-of-service properties.
- Assign
- Empty
- Human task
- Invoke
- Java snippet
- Reply
- Rethrow
- Terminate
- Throw
- Wait
Structured activities
A structured activity is an activity that contains one or more other activities. When you create a new version of a process, you can add or delete structured activities. Additional considerations apply to these activities and their constructs when you migrate an existing process instance to a new version of that process.
- Sequence activities
- You can add and remove activities in a sequence activity, and you can change the properties that affect the business logic of the sequence activity. To migrate an existing process instance, the process navigation must not yet have reached any of the changed activities in the sequence.
- Flow (parallel) activities
- In addition to the considerations that apply to sequence activities, you can also add and remove links in a flow activity, and make changes to the properties of a link that affect the business logic of the flow activity.
To migrate an existing process instance, the process navigation can have reached the source activity of the link, but this activity must not yet be complete. In addition, if the new version of the process contains a new link, the process navigation must also not have reached the target activity.
- Generalized flow activities
- If a change that affects the business logic of the generalized flow is part of a cycle, then the entire cycle must be after the current position of the process navigation for existing process instances to be migrated. In addition, if the gateway type is changed in the new version of the process, the process navigation must not yet have reached the gateway.
If the new version of the process contains any changes that affect the business logic of the generalized flow, then the entire generalized flow must be after the current position of the process navigation for existing process instances to be migrated.
- Scope activities and the process scope
- Fault handlers
- For changes to the fault handlers on either the process scope or a scope activity, for example, the addition, deletion, or modification of catch or catchAll elements, the process navigation must not have reached the end of the process or scope activity, or have entered fault handling for the process or scope activity.
- Event handlers: onEvent branch
- If a business logic change is made to the implementation of an onEvent branch, for example, an activity is added, modified, or deleted, the scope activity must be after the current position in the process navigation for existing process instances to be migrated.
- Event handlers: onAlarm (timeout) branch
- If an onAlarm branch is added, removed, or its properties are modified, the entire scope activity must be after the current position in the process navigation for existing process instances to be migrated.
- Scope activity properties
- If a change is made to a scope activity property, for example, the setting of the Isolated property is changed, the entire scope activity must be after the current position in the process navigation for existing process instances to be migrated.
- Switch (choice) activities
- If the new version of the process contains a change to a switch activity, for example, a case element is added or removed, the order of the case elements is changed, or the condition of a case element is changed, then the switch activity must be after the current position in the process navigation for existing process instances to be migrated.
- While loop activities, repeat until loop activities, and for each activities
- If any of the nested activities within these activities are added or deleted, or changes to activity properties are made that affect the business logic, the entire loop construct must be after the current position in the process navigation for existing process instances to be migrated.
- Branches
- Business logic changes can be made to the implementation of branches of the process that are not in the current navigation path, for example, within fault handlers while another fault handler branch is being navigated, within a branch of a case element while another case element is being navigated, or within a pick activity while another onMessage or onAlarm branch is being navigated.
An existing process instance can be migrated as long as the current navigation position is before other business logic changes in the current branch. In addition, if the scope, switch, or pick activity that contains the branch has been navigated, the process instance cannot be migrated.