Workflow Runtime Events

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. 

 

WorkflowCreated

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.

 

WorkflowStarted

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.

 

WorkflowLoaded

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.

 

WorkflowIdled

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.

 

WorkflowPersisted

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.

 

WorkflowUnloaded

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.

 

WorkflowAborted

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.

 

WorkflowSuspended

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.

 

WorkflowResumed

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.

 

WorkflowTerminated

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.

 

WorkflowCompleted

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.

 

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Posted by: BayerWhite
Posted on: 3/24/2014 at 1:46 AM
Categories: Windows Azure AppFabric
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (0) | Post RSSRSS comment feed

Versioning Workflows in WF4.5

I am almost finished with my book, "Pro WF4.5" for Apress. Right now I am finishing up on my current chapter, "Versioning Workflows", and I noticed that a fellow Microsoft MVP, Maurice has blogged about how versioning is done. If you have not clicked on his link already here is a little background. Workflows can now be versioned using WorkflowIdentity. By specifying a version, name and package information (metadata about the version of the workflow), this information can be persisted within a persistence store so it can be queried later. Versioning workflows allows them to be run either side-by-side, which means that a new version of a workflow can execute new workflow instances, and executing persisted workflow instances that were executed using an older workflow definition version. A workflow definition can also execute workflow instances and while the instances are persisted, the workflow definition can be dynamically updated so that persisted instances from the older version of a workflow definition can be updated to run within the new version. 

Currently rated 2.8 by 8 people

  • Currently 2.75/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Posted by: BayerWhite
Posted on: 10/16/2012 at 8:47 AM
Categories: Windows Azure AppFabric | Windows Azure AppFabric
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (0) | Post RSSRSS comment feed