In a previous blog, I discussed one of the patterns that helps avoiding instance migration and orphaned tokens in the process. In this blog, I will discuss another pattern that I see quite often and hoping you would find it useful.

In general this is a more advanced topic around instance migration. Instance migration occurs when a new snapshot is deployed and the previous deployed snapshot has instance on a task that was edited or removed. The platform would recognize this situation and provide the facility to decide on the best possible action, the steps are as follows:

• Prior to deployment perform an assessment to the areas where orphaned tokens can occur. This can be performed using the migration policy editor.
• Define the possible actions for the identified areas:
  • Ideally all instances can be migrated.
  • Some tokens might be deleted as those tasks are not needed and don’t stop the flow of the process.
  • Another set might be required to be moved.
• Define a migration policy file that would automate those activities.     

The reality is that it is not usually as simple as that. It requires more thought process into it to ensure that instance migration is possible and it won't cause any issues. One of the possible outcomes of the assessment is that there will be orphaned tokens and that it would need more adjustment to the process. This can become more challenging at this stage as likely the development and testing activities have ended and it can be challenging to move it back to a full development cycle.

Moving tasks pattern:

This a common scenario where the developer decides to move a task into a different part of the flow. For a new process it would be obvious to just move a task around the canvas to a different location. In a process that is already deployed, this would mean that the tokens that were at that specific task would move to the new location of the flow. In this situation the business would need to be involved to decide if this affects the integrity of the flow. It is common to be in the situation where the business decides that the new instances should go through the new flow but the old instances should resume from their location.

In this situation it can be useful to keep 2 active snapshots but usually there are changes that would benefit the users and fixes that are needed. In this scenario, the pattern below can offer an approach to implement that.

The following example shows a useful implementation of that pattern.  Consider the initial process flow as shown below:
 

The objective is to move the 'Third Path' before the parallel path. If the same task is re-wired before the parallel path. This would mean that all the process instances that are at the 'Third Path' task will moved to be before the parallel path. This might affect the logic of the implementation and will only be discovered after the development activities are performed.

In this example, moving the tokens with the 'Third Path' would mean that there are tokens at 'First Path' and 'Second Path' but when the 'Third Path' tokens are executed there will be new tasks called 'First Path' and 'Second Path' showing once more. It is definitely going to affect the logic of the business process.

The development pattern to avoid that is to make a copy of the task, then delete the original task. Though subtle but it means that the engine will know that the instances that were at the 'Third Path' are now orphaned. At that point, the migration policy editor will offer options to resolve those tokens and you will have the chance to decide where to locate those instances.

The steps to perform this pattern:
•    Copy the task that is required to be moved (highlighted in red above)
•    Paste it in the location where it is required (before the parallel flow)
•    Wire the copied task as shown in the diagram below

•    Delete the original task to leave the following process

•    Create a new snapshot
Now we use the migration policy editor, create the migration policy and move the token to the appropriate place as required.