Microsoft .net workflow engine

Skip to main content. This browser is no longer supported. Download Microsoft Edge More info. Contents Exit focus mode. Is this page helpful? Workflows can be constructed from built-in activities as well as from custom activities.

The topics in this section step through creating a workflow that uses both built-in activities such as the Flowchart activity, and the custom activities from the previous How to: Create an Activity topic. The workflow models a number guessing game. Only one of the topics in this section is required to complete the tutorial; you should pick the style that interests you and follow that step. However, you may complete all of the topics if desired. This work passes through the model from start to finish, and activities might be executed by people or by system functions.

Every running workflow instance is created and maintained by an in-process run-time engine that the host process interacts with through one of the following:. A WorkflowInvoker , which invokes the workflow like a method. A WorkflowApplication for explicit control over the execution of a single workflow instance. A WorkflowServiceHost for message-based interactions in multi-instance scenarios.

Each of these classes wraps the core activity runtime represented as a ActivityInstance responsible for activity execution. There can be several ActivityInstance objects within an application domain running concurrently. Each of the preceding three host interaction objects is created from a tree of activities referred to as a workflow program.

The problem is at least in my experience — business people prefer to delegate programming to software engineers for some reason. And for software engineers, creating imperative algorithms workflows using declarative languages, or using designers is not at all the optimal way. One redeeming quality of this type of Workflow Engines is that you could basically have a DSL as XML, and thus limit what is allowed in your workflows.

You can take a look at the nice interactive demo of workflowengine. A straightforward way to define a workflow in C would be to use some kind of a builder:. This example is taken from Workflow Core. A builder is a good match for the problem because you need some way to define your activities workflow steps and to persist workflow state between activities.

The problem is — when using a builder to define workflows you cannot use the standard control flow statements if-else , for , etc. You would have to use builder methods instead. For a more realistic example take a look at the so-called Simple Document Approval Workflow of Elsa workflows. I'm not saying anything bad about Elsa — it is simply a fact that even relatively simple workflows become pretty verbose and unwieldy when using this approach.

So, can we do better? This example is from Neon. The IEmailActivity methods are just plain C methods, nothing special there. The magic happens in activity stubs which will execute activities and persist their results after an activity is successfully executed.

Workflow Engines should be able to restore any workflow state, if for example a workflow had to wait for a long time and was unloaded from memory or if a Workflow Engine node fails. How would we restore a workflow state if all we have is the results of individual activities? The only way to do it is by replaying the workflow from the beginning and using previously saved activity execution results.