As a follow up to my session while speaking at Orlando's Codecamp, here is a cheatsheet on the different events that happen with workflow instances and the WF Runtime. In each event I share some explanation on "when","why" and "what happens" during workflow execution.
One of the important jobs of the workflow runtime is to manage running workflow instances events. You can think of the events as a workflow’s lifecycle. Let’s take a look at what workflow instance events we should be interested in following, whilte a workflow instance is running.
A workflow has been spun up or “created” when this event fires, however none of its activities have executed. In most cases, this event is so below the covers in the WFRuntime that it is not important to track.
After the workflow instance has been started, scheduling of it’s root activity for execution occurs, therefore the WF Runtime raises the WorkflowStarted event. In most cases, this event is so below the covers in the WFRuntime, and is not important to track.
A workflow instance has been loaded into memory, however this occurs from a pre-existing workflow instance that has been previously persisted. Once the workflow instance has been loaded, it is now ready for it’s activities to be executed. In most cases, this event is under the covers in the WFRuntime, and is not important to track.
Just because a workflow is loaded into memory, it does not mean that it is not doing work. A workflow instance can become idle as it is waiting to do work. For instance, it might be delayed or simply waiting on external events to set it in motion once again. This is an important feature of WF, because with WF’s persistence mechanisms, it can unload the workflow from memory releasing precious computer CPU cycles. Once a workflow instance becomes idle, it will raise this event, therefore it is very important to track.
Workflows can be persisted, allowing memory to be freed up from the CPU. Persisting a workflow is important when important work has been completed, the workflow has become idle, and when the workflow needs to be unloaded from memory. This is an important event to track because it lets you know when the workflow has been saved to the persistence store, however it can still fire even if a persistence store has not been enlisted by the WFRuntime. In most cases, this event is under the covers in the WFRuntime, and is not important to track.
A workflow is said to be “unloaded” once it has been unloaded from memory. This can happen as the workflow becomes idle and by setting the UnloadOnIdle can be set to “True”. It can also happen once the workflow has been persisted, however a workflow can also be unloaded from the workflow host as well by calling WorkflowInstance.Unload. This is an important event to track because it lets you know when the workflow is no longer executing and has been freed up from memory.
Sometimes a running workflow instance can run into problems during execution and needs to be aborted. Now don’t get confused with aborting and workflow and termination, because an aborted workflow is not terminal. Instead, the workflow runtime decides to go back to the last point from when the workflow was persisted. That way, the workflow can always be restarted from it’s last persisted point again. A workflow instance can also be aborted from it’s host during appropriate situations for ending a workflow’s execution. This event could be one you might want to track for a workflow instance’s execution.
Workflow instances that are running can be suspended from execution, however the instance is not unloaded. This is because a suspended workflow instance allows for changes to be made to the application, so the workflow instance can be resumed. In most cases, this event is under the covers in the WFRuntime, and is not important to track. Windows AppFabric is usually where you see these events tracked.
After a workflow has been suspended, and the appropriate changes have been made to help the workflow run better, it can be resumed. Once the workflow has been resumed WorkflowResumed is fired. In most cases, this event is under the covers in the WFRuntime, and is not important to track. Windows AppFabric is usually where you see these events tracked.
A terminated workflow is cleared from memory and is not allowed to be reloaded. Terminating a workflow can occur, by calling the workflow instance to terminate from the workflow host or unhandled exceptions during workflow execution. WorkflowTerminated event is raised after the workflow instance has been terminated. In most cases, this event is under the covers in the WFRuntime, and is not important to track, however the WorkflowApplicationHost does have an OnUnhandledException event that should be tracked so you are aware when any exceptions occur, that are not accounted for so the workflow host can react accordingly.
Once a workflow has completed its execution from start to finish, the WorkflowCompleted event fires letting you know it has completed successfully. There are parameters that can be gathered as results of the workflow and the work that it has completed. This event is one you would definitely want to track for a workflow instance’s execution.