locked
How To Reload a Persisted Workflow with WorkflowServiceHost RRS feed

  • Question

  • We are using Workflow Foundation 4 Beta 2 with a client / server architecture where the client runs workflow through the server  using a WorkflowServiceHost. The client itself runs no workflow. The workflow is long running, requiring that it persist while awaiting user input. We have set up correlation and persistence such that the user can successfully move the workflow from one activity to another. The problem occurs when the workflow is unloaded or the server application is restarted; we are unable to determine how to continue a workflow that has been unloaded. We have looked at numerous samples such as the Hiring Request Process (http://msdn.microsoft.com/en-us/library/ee622985(VS.100).aspx) and the samples demonstrate the same issue…everything works great until the workflows are unloaded or the server (application running the workflowservicehost) is restarted. There is no exception thrown by the client call, the workflow simply doesn’t move forward.

    Monday, February 1, 2010 7:42 PM

Answers

  • AppFabric is not required for 4.0 workflow persistence - XP and 2003 should work fine.

    How do you know that the server workflow doesn't move past the receive?  It sounds like the workflow could be failing - such as throwing an exception - at some point after the receive but before the next persist.  Do you know which unhandled exception policy you are using?  I think Beta 2 defaulted to "Abandon," which would result in the behavior you are seeing.  If you switch it to "SuspendAndAbandon," then if the workflow fails due to an unhandled exception, then the instance will be marked as suspended and the exception will be recorded in the database.

    Thanks -
    Justin
    • Marked as answer by joe.mancuso Friday, February 12, 2010 2:07 PM
    Tuesday, February 9, 2010 9:15 PM

All replies

  • I have the same issue.  I would also like to know if and how using a delay in the workflow changes the solution.
    Monday, February 1, 2010 8:39 PM
  • If you have not yet configured and started the Workflow Management Service then that is probably the problem.  See this article http://msdn.microsoft.com/en-us/library/ee383990(VS.100).aspx .

    Note that there have been some hints on this board that the Workflow Management Service will ship as a Dublin/AppFabric component rather than a .Net 4.0 Framework component. Also This thread indicates that more changes are on the way post-Beta2.
    • Edited by PaulG Monday, February 1, 2010 9:33 PM fixed typo
    • Proposed as answer by PaulG Monday, February 1, 2010 9:34 PM
    • Unproposed as answer by joe.mancuso Wednesday, February 3, 2010 2:03 PM
    Monday, February 1, 2010 9:33 PM
  • Yes, I configured WMS and was able to get the Durable delay sample project to run but my project still does not function. I am running Windows XP with IIS 6, so all I could do was install / start the service and point the config to the correct database. Are there any other known pitfalls?

    Monday, February 1, 2010 9:55 PM
  • Are you using the messaging activities (Receive, etc.) in your workflow?  Is that where the workflow gets stuck - waiting for a message in a Receive activity?  If so, what happens when the client sends the message - does the client get a reply?

    Thanks -
    Justin

    Monday, February 8, 2010 11:59 PM
  • Can you check the command queue and the command queue execution log for Run commands? Both of them live in the persistence DB. If the WMS is running and configured to service your persistence DB it should create Run commands in the commadn queue. The command queue execution log should contain the failure reason in case the WMS is unable to execute these commands.

    Something you can look into: The WMS issues the commands via the service hosts's Instance Control Endpoint. You have to grant wms access to that endpoint. The endpoint security is set in the sqlWorkflowInstanceStore behavior. 
    Tuesday, February 9, 2010 12:22 AM
  • Yes, we are using receives. The client call returns without error, but the server workflow does not move past the receive. Is AppFabric required to perform persistance of long running workflows? Are Windows XP / Windows Server 2003 acceptable platforms for hosting 4.0 workflows?
    Tuesday, February 9, 2010 2:28 PM
  • AppFabric is not required for 4.0 workflow persistence - XP and 2003 should work fine.

    How do you know that the server workflow doesn't move past the receive?  It sounds like the workflow could be failing - such as throwing an exception - at some point after the receive but before the next persist.  Do you know which unhandled exception policy you are using?  I think Beta 2 defaulted to "Abandon," which would result in the behavior you are seeing.  If you switch it to "SuspendAndAbandon," then if the workflow fails due to an unhandled exception, then the instance will be marked as suspended and the exception will be recorded in the database.

    Thanks -
    Justin
    • Marked as answer by joe.mancuso Friday, February 12, 2010 2:07 PM
    Tuesday, February 9, 2010 9:15 PM
  • Once I changed the policy to SuspendAndAbandon I started to get exceptions in the database.

    Is there a way for the client application who is making the call know if there was an error?

    Wednesday, February 10, 2010 1:49 PM