Windows Workflow - PersistableIdle

Question

In our company we have a business process that needs to:

1. Get data from X
2. Wait for user Y to do research
3. Get data from Z based on step 2 data

In researching this, it seems like there are a few options to implement this in workflow.

1. Add a delay activity between Step 1 (workflow activity) and Step 3 (workflow activity). Then during the PersistableIdle event, unload the worklow. When the user is done with step 2, re-load workflow from database.
2. Same as #1 except use a bookmark instead of a delay activity.

Is there a better approch (1, 2 or another option)?

All of our other activities are AsyncCodeActivities, so I'm fairly sure they will not fire the PersistableIdle event (since they are in a no-persist zone), but I want to make sure the workflow is not accidentally unloaded in other cases. Is there any risk here? Is there anyway to create an activity that forces the workflow to unload?

Answer 1

Is there a better approach (1, 2 or another option)?

At first glance, #2 sounds like necessary. The reason to use bookmarks (or bookmarking activity of some kind, like Receive) is that they can be resumed any time. This allows for user Y's research to end and the workflow to resume execution at any time (instead of being blocked until a Delay expires).

The counterargument, that #1 may be necessary too, is that you may wish to set a time limit which triggers workflow actions (reminders being fired off, exceptions, cancellations, etc).

How to decide? I think the answer is usually #3: Both

Using Pick Activity is a great way to do both. Using Bookmarking activity in one PickBranch trigger, and Delay activity in the other PickBranch trigger, you can compose a workflow which will 'handle whichever happens first - user Y, or timeout'.

A secondary question you raise is 'How do I stop a Workflow being unloaded when I don't want it to be - is surprise workflow unloading a risk'?

Well, that depends. If you are using WorkflowServiceHost, having your workflow unloaded doesn't feel like a big risk, because the WorfklowServiceHost is smart enough to reload your workflow when it needs to do more work (handle an incoming message, or resume from delay).

If you are not using WorkflowServiceHost, you are probably writing your host, you can either achieve the same effect with some work, or you can just prevent unloading from happening ever - when you write the host, you control the unload policy, via the events on WorkflowApplication

Other miscellaneous points: -Asynchronous Code Activities do indeed prevent your workflow from persisting while they are doing asynchronous work. I don't think they should be deliberately used as an anti-persistance mechanism though - if you want one of those, check out NoPersistZone activity.

-There is no 'Unload' activity, but there is a 'Persist' activity. Workflows can say they want to save progress, but only the host gets to make the finally decision on when unloading happens.