Workflow foundation is used to write reactive programming in a better way using declarative code. That means, we can write the functionalities to achieve the business need and we can decide when we want to execute. The heart of the WWF is nothing but “Workflow Runtime” and “Scheduler Queue”. Workflow runtime provide lot of built in services like Scheduler Services, Persistence Service, Tracking Service etc. These services help the runtime to execute the activities.
Windows Workflow foundation is a collection of activities, which will be executed in schedule. If you want to understand what an activity is, then you can compare the activity with the method we write in regular .net application. There are Composite activities which will have multiple activities grouped into single activity and they may also have control flow activities like “If” and “Else” activities.
Windows workflow foundation needs a “Workflow Runtime” to execute the activities. But the Workflow runtime can be created in any type of application like, Console application, Winforms, WPF, WCF Service etc.
But unlike WCF host, Workflow Runtime can be created by the client application itself. Of course, the Workflow runtime can be hosted using WCF service (WorkflowServiceHost class) and any other client can use that Workflow runtime.
There are different ways to create workflow in WWF. It can be create just only with XAML, or XAML and C# or XAML and VB.NET or Just only with C# or just only with VB.NET. Declarative code can be written in XAML as well as C# or VB.NET.
Here are the steps when we run any workflow.
1. If any client application wants to run a workflow, first it will load the workflow from XAML or from code using either WorkflowInvoker class or using WorkflowApplication class into Workflow Runtime. Whenever a workflow is created new, then the workflow runtime will create a new GUID for that workflow instance.
2. If the client is going to execute the workflow which is already started by saved in the middle of the execution, then it will load that particular workflow using workflow instance.
3. Even though the new instance of the workflow is created and loaded into runtime, the activities will not be start executed directly. Workflow runtime will start from the top activity and schedule that activity for execution “Scheduler Queue”.
4. Unless the first activity or the activities loaded into the scheduler has completed the execution and marked as closed, runtime will not schedule the next activity.
5. If the activity which is added in to queue is waiting for the input from external resource (for example, if there is a software request raised by one activity and if the next activity is waiting for the Manager’s input) then it will be waiting on the queue until it receive the input. Until then no other activity will be scheduled or executed. (Of course, if there are some parallel activity and if there logic is satisfied then the current activity may be cancelled based on the process flow what we have written).
6. Once the input is received from the external or from anywhere it suppose to come, then the scheduler will inform the runtime to execute the activity.
7. Runtime will execute the current activity and mark it as closed.
8. Runtime will schedule the next activity in the queue and start from the Step 3
Note: If multiple clients try to execute the same workflow instance, then there will be a lock for that instance. So, only one can do the execution and the other one has to wait until the lock released. But when the lock released and the client get the chance, if the workflow is completed by the time by the other client, then the second client will not execute again.