Workflow Soluiton

Hi,
I have simple workflow process, as on the attached picture.
The process contains long lasting procedure which is executed between two Dialog Workflow tasks. Sometimes during executing long lasting procedure occurs IIS app pool crash or IIS restart (because of administration works). After such an event the currently executed instances of process are lost - instances of that process contains no tasks. We have several other similar processes and after every IIS restart or crash we lose a lot of instances. Is is possibility of reactivation of lost instances? Does the worfklow engine can automatically reactivate such instances?

I suspect the timeout route to the end component is why you are experienceing this.  To test this theroy simply add an e-mail component to send you an e-mail for each of these routes.  Then wait for or force the issue to happen again.

The Timeout is essentialy your IIS process timeout.  Each IIS session generates a unique session ID, when the session times out or IIS is restarted that session ID is gone (forever).  Workflow reporting is one measure of how session state data is stored and how it can be retreived. 

You will likely need to change your flow so that your timeout route does something and then brings you back into your flow or design it such that you park the data and then retreive it at another point.

Don, thanks for your replay.
I have checked the timeout paths again and running instances of process doesn't go into them. By simple logging I am sure that "Long lasting process" starts but doesn't finish when IIS restart occurs. After IIS restart I have a situation where for broken process instances I have no active tasks (Dialog 1 is already finished and Dialog 2 is not created yet). I'm sure that tasks wasnt' timeouted.

We use the wait on external event to put out long lasting processes to sleep and then wake up every once and while and check on them. 
If IIS gets restarted (which we do not do if possible.) then the workflow que will pick up the check next time in its sequence.

Not sure if that would work for you. 

Thank you for the suggestion.

You have a right that the Wait On External Event is a kind of solution. However, it does not solve the problem completely, but only reduces its incidence. It's still possible that IIS restart or IIS crash occurs between Dialog 1 and the next component (i.e. Wait On External Event). In that situation the workflow queue already doesn't contain Dialog 1 task and doesn't contain yet the next component task. As a result, we remain without a state of process instances. It's not a very comfortable situation, but it occurs on our production server where we have a lot of instances of different types of parallely executed processes.

An example of long-lasting task was to display the essence of the problem. Similar situation can occurs when the unhandled exception was raised between tasks.

Is it really the workflow engine doesn't support reactivation of corrupted process instances?