Disabling a Workflow?

Developer
Sep 17, 2010 at 11:23 AM

I'm trying to use the client to disable a workflow as part of a data-migration exersize. Of course this resource doesn't have a nice little "Disabled" attribute, that would be far too helpful. What I've tried doing instead is wiping out the XOML attribute, which seemed to have the desired affect when I viewed the workflow in the Portal, but upon running the script fully which went like this:

  • Disable workflow
  • Load data
  • Enable workflow

It turned out the workflow had still run. And to make matters worse, the service now won't start after I tried restarting it.

Microsoft.ResourceManagement: Microsoft.ResourceManagement.WebServices.Exceptions.UnwillingToPerformException: Other ---> Procedure: ReRaiseException.  Line number: 37.  
Message: A Sql failure occurred during Workflow processing., State 1, Procedure ReRaiseException, Line 37, 
Message: Reraised Error 50000, Level 16, State 1, Procedure DoRefreshWorkflowDefinitionCache, Line 216, 
Message: WorkflowSqlOperationException: A WorkflowDefinitionVersionKey mismatch exists in one of the workflow instance cache tables. You must restore the specified version to [WorkflowDefinition] or remove the instance from the cache tables before executing this procedure..

 

I'll just restore the database to get around this, but does anyone know how I would go about disabling a workflow? This workflow is associated with a ton of MPR's. I initially thought about trying to cycle through the MPR's and remove the workflow and then re-add it after, but I don't see how I can do that through the client.

Developer
Sep 17, 2010 at 12:45 PM

I fixed it by re-writing the code to remove the ActionWorkflowDefinition entry from the MPR's instead.

Coordinator
Sep 17, 2010 at 1:12 PM

The far-too-useful Disabled attribute exists, but it's not in the Workflow, it's in the MPR... maybe you could try this solution, unless you really need to disable/remove just one workflow in an MPR which contains several.

Developer
Sep 17, 2010 at 4:17 PM

Yes, I needed that level of control. MPR was too brute-force and turned off too many essential work-flows.