I have a situation where a user group really wants old processes to be updated with changes to the model.  They expect the models to change quite a bit.  In fact they have changed one of their Process Designs 3 times in the past month based on external requirements from a governmental agency.  Minor changes, but changes none-the-less.  This group is only in the development stage of using Captaris Workflow and see this issue as a show-stopper.  If there is no good stragedy to update old processes to the new design, I am told they want to keep using their old spreadsheet method.

The issue is very similar to this post:
http://www.captaris.com/DeveloperProgram/forums/thread/13775.aspx

No one answered that one, so I thought I would bring it up again, despite the fact that I am pretty sure no one will answer.

Does anyone out there have any strategy or hint as to how to accomplish updating processes to new workflow model designs?

At the moment, I think my choices are to:

1.   Write very complicated sql update and insert statements and keep my fingers crossed that I do not screw something up.

2.   Kill all the existing processes and recreate new processes for each one.  Somehow, I would then have to determine where in the model each process needs to be and somehow figure out how to get the new processes close to where they were to begin with.


Any thoughts or details on how to accomplish either of those would be greatly appreciated.

Could you define what you mean by "old processes".  Are these processes which are still in progress or processes which have been completed.

I can't understand why you would want to update processes which are complete...

If they are already in progress then I can. I guess it comes down to what the model changes are.  If they are changes to data structure then you will have issues with current processes.  The best fail safe I have found is to to always  have a set of redudant nodes in your data structure that you can use as these "minor" changes come up.  As these redundant nodes exisit in the "old" in progress processes this minimises problems.

I have one very complicated flow where the change required involved moving a task from one part of the process to the other.  The important consideration was to determine which of the current in progress processes where at that stage of the process or a stage up to where the new task would move to.  Those we identifed and  after applying the model change, reset those processes to the task immediately preceding where the relocated task used to be.

This worked flawlessly.

 

Well, of course I meant processes that are not complete at the time of the change.

Thanks very much for the response.

 

Ok... so here is what I would like to know about the complicate work flow you had to change:

1)  How did you identify which processes were at the stage of the process where you would have to reset to this task?

2)  What method did you use to reset all those processes to that task?  API?  Manual?  SQL Script?

 

Moving a task is a relatively simple thing.  The thing I would be more interested in is handling a New Task anywhere in the model or (God forbid) deleting one. 

On a case-by-case basis between going straight into the teamplate SQL database, and writing update API code and / or having users manually reset tasks that need to be reset, I could figure out how to do this in just about any case that comes up, but I am told this user group will change their process so often that this is really going to be cost prohibitive for a developer to have to get involved every time to reset current processes to the new design.

Anyway, any hints at all to approaches are great. 

Thanks again for the response.

1) We push each process to a Sharepoint List with a column that shows which task the process is currently at.  This makes it easy for the users to create a List View for all processes which were at a stage needing a reset.  Alternatively a simple SQL query on the Workflow Task table would give you the same thing.

2) Resets were done manually via the Workflow Client.  You could assign a user as the admin for just that model.  This would give them the power to reset tasks as required.

 

A new task should be much the same - the question for the process owners is which of the currently running processes need that new task completed ?

Deleting a task would indeed be interesting ;) Particularly for audit type purposes. It sounds to me as an outsider that the process is poorly defined or at the very least imature ?  Again the key question is how do they want the currently running processes to behave?

Hi,

I wrote the post http://www.captaris.com/DeveloperProgram/forums/thread/13775.aspx that nobody answered.

I still have not a solution to this issue. I have a lot of "ongoing" processes with a model I have defined some time ago. Now, I have a step in the middle that I have to add. For those that do not understand I will write down an example:

Original model includes:

Create document - Finance Approval - Legal Approval - Delivery document

New model will include:

Create document - Finance Approval - Manager Approval - Legal Approval - Delivery document

For new requests, everything will work fine because the new model will be applied. Now, let's suppose that you have an "ongoing" requests that is under Finance Approval. Next step should be manager approval, however, next task will be Legal Approval because the process was created using the old (original) instance. I guess that this scenario will eventually happen a lot, I cannot a imagine an static situation. There are always changes.

In addition to your choices I can probably say that "ongoing" requests will continue the original path. Then, we will have to code something to get the process, check the model and go for Manager Approval or Legal Approval depending the model id. This is not very practical, though.

Have you got a solution to this issue, finally?

Thanks,

Juan

 

I would think the safest approach might be to create the new model, then create a process based on that model, and copy the xml from the old process to the new process, then destroy the old process. But you would have to have a lot of checks to verify that completed tasks have not changed in the new model, otherwise things may get very confusing.

---

Matthew Williams
Captaris International Trainer
Vianen, Netherlands
blog: technovangelist.com