-
ManualWorkflowSchedulerService
By default, workflow runtime use DefaultWorkflowSchedulerService as scheduler, what this means is that the workflow instance run in a separate thread. So if you want to wait for the workflow to finished, you need AutoResetEvent object to synchronize the thread. But in asp.net you make want to use a single thread. Here is an article Using Workflows with ASP.NET.
-
WF runtime engine
The workflow runtime is just a class, you create a instance of the class in your application, make it a static or global, so the instance live through all the live of your application, in this case, your application is hosting the workflow runtime. In fact your application can create more than one runtime. However, you typically won't need to do that. A single instance of the workflow runtime is capable of managing the execution of multiple workflow instances. One possible reason to create multiple runtime instances in a single appDomain would be if each instance required a different set of conflicting runtime services or configuration settings. You can also extend the WorkflowRuntme class to initialize the runtime engine.
-
Get the output from a workflow
The output of the workflow instance is can be obtained by the OutputParameters like the following.
-
Debugger WF
To debug a workflow, you need to set the workflow's host project to be the startup project. If this project is class library project, you need to set the default start action, so that the start action trigger a process.
-
Workflow are different
Workflows represent a different programming model. It’s a model that promotes a clear separation between what to do and when to do it. This separation allows you to change the when without affecting the what. Workflows generally use a declarative programming model rather than a procedural one. With this model, business logic can be encapsulated in discrete components. But the rules that govern the flow of control between components are declarative.