OK Ive tried my best - please help!  
Author Message

PostPosted: Windows Workflow Foundation, OK Ive tried my best - please help! Top

I may have missed something!


My scenario - I’m trying to build a system whereby all the workflows and activities execute on a server and never on the client machines (only the server has access to resources needed by the activities).   However I need to start the workflows with relevant parameters from the client machines UI.   I know I could probably achieve this by means of MSMQ client(s) a server, but I don’t want to (see part 2).


I’m using out of box SQL Persistence and Tracking.


I can “start” a workflow on the client with ….


WorkflowRuntime runtime = new WorkflowRuntime();

ManualWorkflowSchedulerService MSS = new ManualWorkflowSchedulerService();

String connString = "Data Source=XXXXX;Initial Catalog=Workflow;Integrated Security=True";

SqlWorkflowPersistenceService Persistor = new SqlWorkflowPersistenceService(connString, true, TimeSpan.FromSeconds(30), TimeSpan.FromSeconds(60));

SqlTrackingService Tracker = new SqlTrackingService(connString);

SharedConnectionWorkflowCommitWorkBatchService BatchService = new SharedConnectionWorkflowCommitWorkBatchService(connString);






Type WorkFlow = GetType("Workflows.OneOff");   //Uses reflection to a loaded DLL

WorkflowInstance inst = runtime.CreateWorkflow(WorkFlow);





Which seems to work OK, and nothing gets executed on the client - good, however … the server workflow runtime does not seem to be aware of the new workflow that has just been persisted and is ready to run – it does not load it unless I stop and restart the runtime on the server.  I naively thought the server runtime would poll for this situation in the same way it polls for expired timers.


Is this the behaviour I should expect or do I need to give the server runtime a prod (say via MSMQ) to say that it should load the instance     For info, the server runtime is setup exactly as above but using the default scheduler and left running.


Part 2.

I know some may scoff, but for UI related activities I am including the relevant windows forms in my custom activities DLL (I have my reasons), these “UI activities” create a queue using the WorkflowQueuingService, store an “I’m waiting” input status in a DB table and leave the Execute method in the “Executing state” causing the server to Persist on idle at that point.   The client can then load the instance, get the activity in question via GetActivityByName and use reflection to invoke a method on the activity to display the form, and after, write an appropriate value into the activities queue and unload (a similar technique to the above, with the runtime on the client in manual scheduling mode).     The point is that this works but again I suffer from the same problem as above in that the client persisted workflow does not continue unless I stop and restart the runtime on the server, at which point the activity picks up the clients message and continues as expected.     Again - do I need to stimulate the server runtime to pickup the workflow again

Any help / education much appreciated, but please try if possible to avoid alternate architectural advice, beat me up on poor system architecture if need be, but only if you can also explain my misconception and answer the question.


Many thanks 

Alan Smith.



Software Development for Windows Vista16  
Khalid Aggag - MSFT

PostPosted: Windows Workflow Foundation, OK Ive tried my best - please help! Top

Hello Alan,

The feature you are asking for, polling for intances that are ready to run,is not provided out of the box by the Sql persistence service. We only do this first time the runtime is started.There are many way to achieve what you are asking for though. You could implement a custom persistence service that does this or as you said give the server a signal that a new instance is ready and needs to be loaded. Or simulate a timer by having a delay activity at the beginning of your workflows and unloading them when the hit the idle state, this way they will be picked up by the runtime on the server.

Hope that helps.