On making workflows robust and flexible...

Topics: Customizing Orchard, Troubleshooting, Writing modules
Jul 23, 2014 at 4:44 PM
Edited Jul 23, 2014 at 4:55 PM
Working with the workflow functionality in Orchard I can see it has a lot of potential to be something great and make orchard stand out from the crowd.

But it lacks robustness that does not allow it to be used for real business world scenarios.
A typical scenario is when workflow definition needs to change to accommodate new business requirements.
Let me explain with an example.
You have a typical workflow definition with an approval step (or waiting activity in orchardy terms).
Lets say this workflow has run 10 times thus creating 10 awaiting activity records in the database.

Now if you simply go into the workflow definition , simply change the position of a shape in the diagram and hit save .Now if you go to your content item which has workflows hanging off of it and try to view the running workflows it will crash because its corresponding activity record has been deleted and you'll see an error message :
"No row with the given identifier exists[Orchard.Workflows.Models.ActivityRecord#130]"

The reason is because when you hit save in workflow definition the previous activity and transition records are wiped out of database and new row definitions are created .
So any awaiting records have lost the id's of the previous activities and will just remain as ghost records creating a mess.This is very nasty.

In the real world you want to be able to define workflows , execute them , change the workflow (because business conditions change) and be assured that consistency in the database will remain.

I would like to work on improving this functionality and would like to hear any ideas to make workflows flexible and robust.

The main idea I'm leaning towards is to keep versioned records of workflow definitions.
So every time you hit save on a definition a snapshot of the workflow graph is created in the database.
Now when a new workflow Record instance is created (with awaiting activities) it stores along with the workflow definition id the current workflow version (e.g. version1) and will execute on that version until all instances have been resolved.
So when you go and change the workflow definition it will create a new version 2 ,3 and so on.
Any new workflow awaiting instances will lock onto the current version while the version 1 instances will still be able to be resolved using the version 1 definition.

Any thoughts or ideas before I start working on this concept ?

Jul 24, 2014 at 2:15 PM
Thanks for the feedback - we should put this under discussion. Please don't start the development just yet - I have a lot of workflows updates to be pushed (there will be a separate feature branch for this).
Jul 24, 2014 at 3:08 PM
Ok piotr,
please let me know when the feature branch is up, so i can merge any work on the same branch.
Jul 24, 2014 at 3:51 PM
Aug 2, 2014 at 5:17 PM
I think versioning can be good idea to resolve this important problem. Any awaiting activity must continue to run unless the user removes it explicitly.
Workflow is very very strong and valuable feature of Orchard but it needs some reviews and corrections.
Aug 2, 2014 at 11:35 PM
Edited Aug 2, 2014 at 11:35 PM
This definitely has to be addressed. Can someone open an issue for this with repro steps as provided by Giannis? Thanks
Aug 3, 2014 at 5:28 AM
Since there is some situation that causes the awaiting activity cannot run at the time (ex. Recycling of IIS worker process),
I suggest to create an option for this situation like that exists in Windows task (See below image):

"Run task as soon as possible after a scheduled start is missed."

I think this is needed for web environment.
Aug 3, 2014 at 1:09 PM
sfmskywalker wrote:
This definitely has to be addressed. Can someone open an issue for this with repro steps as provided by Giannis? Thanks
related issue : https://orchard.codeplex.com/workitem/20851

Sipke, do you think audit trail can be leveraged here for versioning workflow definition records ?

Aug 3, 2014 at 6:54 PM
Edited Aug 3, 2014 at 6:54 PM
@mehranrezaei - Are you saying that this is not currently the case? Can you provide repro steps where a timer activity is not executed even after the await time has expired?

@Giannis - No, the purpose of the audit trail module is just to capture events, which will at some point be archived, so no other system should rely on audit trail data except for auditing. The issue needs to be addressed within the Workflows module itself.
Aug 4, 2014 at 8:50 PM
Edited Aug 4, 2014 at 8:51 PM
@sfmskywalker - Thank you for your comment. I did some new test with fresh Orchard installation. Now i can confirm tasks run as soon as possible after their scheduled start are missed. Also i faced some new issues during these tests. I will report them after doing more required tests.
Aug 4, 2014 at 8:56 PM
Perfect, thank you.