Migrating In-Flight BPM Instances
Authored by: Zachary Fieroh
Migrating instances can prove to be very useful for users that want to transfer instances from one snapshot to another. This prevents the user from having to re-enter the data that already exists in the existing instances.
There are two ways to migrate instances while in flight:
– Migrate instances programmatically: This method allows the user to migrate instances one by one, or many at a time. There is a very easy to use toolkit that already exists for this functionality.
– Migrate instances from the Process Admin Console: This out of the box functionality allows you to migrate all instances in a snapshot at once, and will be discussed in this article.
Orphaned Tokens:
When going from and old snapshot to a newer version, the existing process may have been streamlined to eliminate unnecessary tasks or activities. An orphaned token exists in the case that you are attempting to migrate a token to an activity that no longer exists.
Figure 1 shows an orphaned token. As you can see, token #4 does not have an activity associated with it in the updated BPD.
Policy Files:
In order to handle orphaned tokens, we must create a policy file to specify what should happen to the orphaned tokens. See the following steps for creating a policy file, and in turn migrating instances:
1. Check to see if we will encounter any orphaned tokens using BPMCheckOrphanedTokens command. This command is run through wsadmin scripting. The command compares the two snapshots, and outputs a policy file. This XML file that is outputted will list all of the potentially orphaned tokens.
Figure 2 is a sample Policy File. Notice the source snapshot, the target snapshot, and the tokens that will be orphaned.
2. Manage the orphaned tokens by using a policy file. We must specify what we want to do with the tokens that will be orphaned. These decisions are specified in the Policy File that we will used during migration. The default action is to delete the orphaned token, as highlighted in the below figure.
Figure 3 shows the default action to delete this token.
To move the orphaned token to a particular task, replace the command with . See the following example:
The stepID for the activity you are looking to move the token to can be found by clicking on the activity, under the properties tab, “System ID:”.
3. Once you have created your Poilcy File, you are now ready to migrate your instances. From the Process Admin Console, locate the snapshot you are looking to migrate to under “Installed Apps”. Click on “Migrate Inflight Data” and select the snapshot which you would like to migrate your instances from. Upload your policy file and click Migrate. Verify that your instances have migrated correctly by using the Inspector.
Nice Article.
Could you please tell me how to migrate the instances in below scenario.
1. Old snapshot contains a human service which has set of UI Controls.
2.Now in new snapshot i have added few more UI controls.
3.Now i want to migrate all instances from old snapshot.But in all instances the human activities which are picked by user should also refer the new coach.i.e with additional UI controls.
How to achieve this ?
Good article
A bit more detail can be found here:
http://www.ibm.com/developerworks/bpm/bpmjournal/1305_norelus/1305_norelus.html
Hi,
I need to capture a new info in my process but i don’t have any extra field to capture it. Should i create a new private variable at process level and pass it to my Human task by creating new input or should i modify my existing Business object to include that field.
my only concern is which approach will not result into failure cases in instance migration.