views:

227

answers:

1

Hi

I have a running workflow that is using both the parallell and OnTaskCreated Activities. The solution has bee deployed at multiple clients, I was recently working on an upgrade which required to swap out the workflow assembly. I had some running workflow instances on the server when I did the upgrade.

Since then nothing has been working, I can't seem to geta a new workflow finishing normally. I always gets this error here:

01/14/2010 16:14:33.73  w3wp.exe (0x1928)                           0x2514  Windows SharePoint Services     Workflow Infrastructure         936l    High        Engine RunWorkflow: System.Workflow.Activities.EventDeliveryFailedException: Event "OnTaskChanged" on interface type "Microsoft.SharePoint.Workflow.ITaskService" for instance id "7697ee64-7286-46f3-992e-cf3c18731f15" cannot be delivered. ---> System.NullReferenceException: Object reference not set to an instance of an object.     at Microsoft.SharePoint.Workflow.SPWorkflowHostServiceBase.LoadInstanceData(Guid instanceId, Boolean& compressedData)     at Microsoft.SharePoint.Workflow.SPWinOePersistenceService.LoadWorkflowInstanceState(Guid instanceId)     at System.Workflow.Runtime.WorkflowRuntime.InitializeExecutor(Guid instanceId, CreationContext context, WorkflowExecutor executor, WorkflowInstance workflowInstance)     at System.Workflow.Runtime.WorkflowRuntime.Load(Guid key, CreationCont...  
01/14/2010 16:14:33.73* w3wp.exe (0x1928)                           0x2514  Windows SharePoint Services     Workflow Infrastructure         936l    High        ...ext context, WorkflowInstance workflowInstance)     at System.Workflow.Runtime.WorkflowRuntime.GetWorkflow(Guid instanceId)     at System.Workflow.Activities.WorkflowMessageEventHandler.EventHandler(Object sender, ExternalDataEventArgs eventArgs)     --- End of inner exception stack trace ---     at System.Workflow.Activities.WorkflowMessageEventHandler.EventHandler(Object sender, ExternalDataEventArgs eventArgs)     at Microsoft.SharePoint.Workflow.SPWinOETaskService.RaiseEvent(SPWinOeWorkflow workflow, SPWorkflowEvent workflowEvent, Object workItem, IPendingWork workHandler)     at Microsoft.SharePoint.Workflow.SPWinOeHostServices.Send(SPWinOeWorkflow winoeworkflow, SPWorkflowEvent e)     at Microsoft.SharePoint.Workflow.SPWinOeEngine.RunWorkflow(Guid trackingId, SPWorkflowHostService ho...   
01/14/2010 16:14:33.73* w3wp.exe (0x1928)                           0x2514  Windows SharePoint Services     Workflow Infrastructure         936l    High        ...st, SPWorkflow workflow, Collection`1 events, TimeSpan timeOut)   

I've been googling the problem and I've found multiple solutions where people are advising to terminate all workflow instances before the upgrade is made. In my opinion that solution is not acceptable, because I could have an unmanagable number of running workflows.

I was wondering if this might be related to the Sharepoint Workflow Host, can I terminate all running workflow programmatically during upgrade ?

Does someone have an idea how I can solve this issue ?

A: 

You should have listened to those people, or at the very least investigated for yourself why they are saying these things. They are right, and now you know why; you have effectively screwed all of your running workflows.

SharePoint serializes a binary workflow to the database when the workflow is inactive/idle and/or waiting for an event. If you swap out the assembly while it is sleeping/serialized, when the WF hosting infrastructure in sharepoint tries to deserialize the workflow to revive it, it will fail because the target type has changed (because you "upgraded" it.)

There is NO easy way to upgrade binary workflows in sharepoint; side-by-side is the only manageable way to do it. You bump the assembly version, create a new WF assocation and set the old wrkflow associations to stop accepting new requests. The old workflows will complete with the old code, and new workflows use your new code. No other way, sorry.

-Oisin

x0n
Thanks for the answer, I bumped the assembly version from 1.1.0.0 go 1.1.1.0, could it be that the workflow host uses only major or minor versions and therefore thinks that I'm still using the same version ? What's strange for me is that I can't seem to finish new workflows normally
armannvg
I assume you have both workflow binaries in the GAC, and have created a new workflow association and feature (not replaced the old ones?) MY bad for not mentioning that you must create a new feature to keep everything separate - many people incorporate the version into the feature name, e.g. "workflow 1.2"
x0n
No I didn't create a new feature. I only updated the version nr. for the workflow assembly and then changed workflow.xml to have the version nr's in sync. The workflow association itself is configured in an event handler in my code and I didn't change anything there. One more question :) I removed the web application this error was occurring in (didn't contain any data, so that was ok), then created a new web application and still getting the same error. Is some workflow type information being stored in the configuration database ?
armannvg
Don't forget to restart the SPTimerV3 Service also (every time you deploy etc) - it will also have a copy of your workflow assembly loaded into memory too. And yes, lots of stuff is persisted in the database - your guiding rule should be that workflow upgrades are really in fact a completely _new_ workflow, side-by-side with the old one.
x0n
Do I have to create a new feature ? I've created a new workflow in workflow.xml, given it a new guid and updated the code that does the workflow association so it uses the new version but still with no luck. Workflow still hangs at in progress, any ideas ? I restarted the timer service and IIS
armannvg
Thanks for your help X0n. I havn't completely figured this out yet and I'll be issue-ing a case at Microsoft about this problem. If I get an answer I'll post it here :)
armannvg