MSDN Updates

Get Microsoft Silverlight

Thursday, May 22, 2008

Workflow Versioning

One of my assignments required me to build a state machine workflow. I started going through the Workflow foundation and built the workflow definition. I must say that working with WF was amazing. I think its one of the best things that MS has done! Yes it still needs some work but hey ... who says life is perfect!
Anyways I used the external data service to pass parameters to the WF from the host. we now had this requirement to change the WF definition. I was under the impression that his will not lead to any issues. I thought that as long as I was not adding a new state, the existing data which was created using the old WF definition should work fine. Turns out.. it does not!
Which is fine, considering the security point of view, data built using one version of the dll should not work with another version. But what is the solution.
The solution it seemed was to go for versioning. There are quite a few posts which talks about that so i'll not get into the details here. So we tried to getthe versioning to work but unfortunately we hit a dead end there. We then came to know through reliable sources(I'm not at a liberty to mention who) that for versioning to work with External data services, we may need to use a concept called correlations. Remember that serialization has to be enables for this. Now I looked around for some samples and found that it looked like a pretty simple task (though understanding it is not!) and i tried the same with my workflow. Surprise surprise... it didnt work at all. I did see some posts about how getting correlation to work with a state machine workflow is not an easy if not impossible task. I have still not been able to solve it (pressed for time) and we had a workaround. We built a small appllication which would take all the workflow data which was built using the version 1 of the workflow, use the new version of the workflow and recreate them. In the process, we had to sensure that all the workflows were in the same state as before. Our workaround was aided since our application database was also holding the WFGUID's. WE have done some testing and it seems to be working fine.
In the meanwhile I'll need to get back to the original problem and see if I can actually get this to work with a state machine workflow.

My reliable source also mentioned that the instance state table stores the version of the dll in the binary data. Hence if you ever get this error "System.IndexOutOfRangeException: Index was outside the bounds of the array. ", this is a versioning problem and then when you try to fix it using correlation or whatever is the right solution, you may get this error
"System.Workflow.Activities.EventDeliveryFailedException: Event "CRApproval" on interface type ", and if you do get this error ....
"Run to the Hills....
Run for your lives .... "

A tribute to one of the greatest bands ever :)