Version Control With Workflow Solution
Filed under:
Workflow Solution
Best Practices
Submitted by blollich on 30 July, 2008 - 10:26
So you've built a few workflows. Of course, you tested them thoroughly and they passed with flying colors. Now they are running in your environment, people are using them and everyone is happy with the way you've automated some process. Finally you can walk away from that process 'cause it's never going to change or require the slightest modification...WRONG!
Business processes are dynamic, so it's a good idea to build your workflows the same way. Building version control into your workflows is a great way to avoid shooting yourself in the foot when it comes time to modify a workflow.
First let's take a look at a simple workflow. In this example, a user submits a request for a new PC. The manager approves or rejects the request and then IT is notified of the approval.
This workflow is part of the primary model, which we will get to in a second.
For demo purposes, I submitted 3 requests for a new PC. By looking at the WorkflowManagement.aspx page for this project, I can see that 3 tasks are in progress. Each of these are waiting for manager approval.
Stop the presses! IT has just requested that the New PC Workflow be modified. They want to see assets associated with the user in the email request. So you make the necessary changes and publish the new version up to your workflow server. Here is what the new version looks like, and again it is part of the primary model.
This doesn't look much different, but it has a profound effect on the 3 workflows we currently have in progress.
What happens when the manager goes to approve the New PC Request? In this example, the Approval form loads but the workflow terminates after the manager approves the request. The cause of the termination has to do with searching the helpdesk for a variable that didn't exist in Version 1 of our workflow, but now exists in Version 2.
Now you've got a New PC Request that has been approved, but IT has not been notified because of the version conflict associated with searching the helpdesk. Fixing a workflow in limbo is outside the scope of this article, but we can solve the whole versioning issue with a few simple steps.
First
Simply create a new model and call it Version 1.0. Build your workflow inside this model.
Second
Use the Primary model to control your versioning. The linked model component points to the Version 1 model.
Third
Create a Version 2 model and develop your new version. Once it is complete, change the Primary model to direct new workflows to Version 2.
The linked model component in your primary model would look like this.
Using this technique, you can safely deploy new versions without blowing up the workflows already in progress under your old versions.
(29 votes)
Very clever!
Blollich,
This is a very clever implementation. An alternative would be to modify the process normally, deploy it to a new virtual directory on the server 'xyzprocess2' and then redirect new requests into this new virtual directory.
You accomplish the same thing with your linked models, but might be overwhelming in the long run if there are lots of trivial edits.
Also look for workflow project versioning in the future!
Not a bad idea, but...
I was told of this approach by a Transparent Logic developer last year. It's a good idea if your project is not too complicated. One of my projects has over 20 models though. That would require 20 new models for every version! We actually use stuper's approach and post new versions to the server and re-route to the new URL via the calling application.