Synchronously execute and get return parameters from Workflow

In my DropThings project, I have used Workflows to develop the business layer that run synchronously and do most of the work in the middle-tier. The business layer facade named DashboardFacade has no code but to call different workflows. Each of the workflow serve a particular operation like new user visit, existing user visit, adding a tab, moving a widget from one column to another etc. ASP.NET page calls DashboardFacade for each user action and DashboardFacade inturn calls a workflow to respond to that user action.

“This is insane!” you are thinking. I know. Please hear me out why I went for this approach:

Architects can “Design” business facade functions in terms of Activities and developers can just fill in small amount of unit code in each activity.

This is a really good reason because Architects can save time in writing Word Documents explaining how things should work. They can directly go into Workflow Designer, design the activities, connect them, design the flow, and verify whether all input and output are properly mapped or not. This is lot better than drawing flow-charts, writing pseudocode, explaining in stylish text how an operation should work. It is also helpful for developers because they can see the workflow and easily understand how to craft the whole operation. They just open up each activity and write small amount of very specific reusable code. They know what will be the input to the Activity (like function parameters) and they know what to produce (return value of function). This makes the activities reusable and architects can reuse one activity in many workflows. Workflows can be debugged right on Visual Studio Workflow Designer. So, developers can easily find out defects in their implementation by debugging the workflow. Architects can enforce many standards like validations, input output check, Fault handling on the workflow. Developers cannot but comply with those and thus produce really good code. Another great benefit for both architect and developer is that there’s no need to keep a separate technical specification document up-to-date because the workflow is always up-to-date and it speaks for itself. If someone wants to study how a particular operation works, one can just printout the workflow and read it through.

“But what about performance”, you say? Both you and I have heard workflow foundation is a pretty big library and can be memory hog. Also the workflow runtime is quite big and takes time to start up. I did some profiling on the overhead of workflow execution and it is very fast for synchronous execution. Here's proof from the log you get in Visual Studio output window:

   1: b030692b-5181-41f9-a0c3-69ce309d9806 Activity: Get User Guid        0.078125

   2: b030692b-5181-41f9-a0c3-69ce309d9806 Activity: Get User Pages       0.0625

   3: b030692b-5181-41f9-a0c3-69ce309d9806 Activity: Get User Setting     0.046875

   4: b030692b-5181-41f9-a0c3-69ce309d9806 Activity: Get Widgets in page: 189 0.0625

   5: b030692b-5181-41f9-a0c3-69ce309d9806 Total: Existing user visit     0.265625

First four entries are the time taken by individual activities during data access only, not the total time taken to execute the whole activity. The time entries here are in seconds and the first four entries represent duration of database operations inside activities. The last one is the total time for running a workflow with the four activities shown above and some extra code. If you sum up all the individual activity execution time for database operations only, it is 0.2500 which is just 0.015625 sec less than the total execution time. This means, executing the workflow itself along with overhead of running activities takes around 0.015 sec which is almost nothing compared to the total effort of doing the complete operation.

An example of such workflow is as following:

   1: public void MoveWidgetInstance( int widgetInstanceId, int toColumn, int toRow )

   2: {

   3:   using( new TimedLog(this._UserName, "Move Widget:" + widgetInstanceId) )

   4:   {

   5:     var properties = new Dictionary<string,object>();

   6:     properties.Add("UserName", this._UserName);

   7:     properties.Add("WidgetInstanceId", widgetInstanceId);

   8:     properties.Add("ColumnNo", toColumn);

   9:     properties.Add("RowNo", toRow);

  10:     

  11:     WorkflowHelper.ExecuteWorkflow( typeof( MoveWidgetInstanceWorkflow ), properties );

  12:   }

  13: }

MoveWidgetInstance is a method in DashboardFacade. It just calls a workflow named MoveWidgetInstanceWorkflow which does the job for moving a widget from one column to another, rearrange the widgets on the new column, pull up widgets on the old column to remove the empty space, and update all widgets positions. If I wrote all these code in one function, it becomes quite a big function and requires documentation. But having a workflow means I have a flowchart of what's going on and I have some handy reusable Activities which I can reuse in other operations.

Implementing business layer as workflows has three important requirements:

1. Execute workflow synchronoulsy within the ASP.NET request thread
2. Get output parameters from workflow which is returned as return value from Business Facade methods
3. Get exceptions raised from Activities in a synchronous manner inside the same request thread

WorkflowHelper is a handy class I made, which makes use of Workflow a breeze, especially from ASP.NET. In the business layer, I need synchronous execution of workflow where the default implementation of Workflow Foundation is to work asynchronously. Moreover, I need return values from Workflows after their execution complete, which is not so easily supported due to asynchronous nature of workflow. Both of these require some tweaking with workflow runtime in order to successfully run in ASP.NET environment. You will find the source code of WorkflowHelper in the code zip file from www.dropthings.com.

WorkflowHelper.Init function initializes Workflow Runtime for ASP.NET environment. It makes sure there’s only one workflow runtime per Application Domain. Workflow Runtime cannot be created twice in the same application domain. So, it stores the reference of the Workflow Runtime in Application Context.

   1: public static WorkflowRuntime Init()

   2: {

   3:   WorkflowRuntime workflowRuntime;

   4:  

   5:   // Running in local mode, create an return new runtime

   6:   if( HttpContext.Current == null )

   7:     workflowRuntime = new WorkflowRuntime();

   8:   else

   9:   {

  10:     // running in web mode, runtime is initialized only once per 

  11:     // application

  12:     if( HttpContext.Current.Application["WorkflowRuntime"] == null )

  13:       workflowRuntime = new WorkflowRuntime();

  14:     else

  15:       return HttpContext.Current.Application["WorkflowRuntime"] as WorkflowRuntime;

  16:   }   

The initialization takes care of both ASP.NET and Console/Winforms mode. After the initialization, it registers ManualWorkflowSchedulerService, which take care of synchronous execution of Workflow. Activities.CallWorkflowService is a handy service that executes workflow synchrnously from another workflow. Read this post for details. These two services make Workflow Foundation usable from ASP.NET environment for practical scenarios.

   1: var manualService = new ManualWorkflowSchedulerService();

   2: workflowRuntime.AddService(manualService);

   3:  

   4: var syncCallService = new Activities.CallWorkflowService();

   5: workflowRuntime.AddService(syncCallService);

   6:  

   7: workflowRuntime.StartRuntime();

   8:  

   9: // on web mode, store the runtime in application context so that

  10: // it is initialized only once. On dekstop mode, ignore

  11: if( null != HttpContext.Current )

  12:   HttpContext.Current.Application["WorkflowRuntime"] = workflowRuntime;

  13:  

  14: return workflowRuntime;

  15:  

Workflow Runtime is initialized from Application_Start event in Global.asax. This ensures the initialization happens only once per App Domain.

   1: void Application_Start(object sender, EventArgs e) 

   2: {

   3:   // Code that runs on application startup

   4:  

   5:   DashboardBusiness.WorkflowHelper.Init();

   6: }

The runtime is disposed from Application_End event in Gloabal.asax:

   1: void Application_End(object sender, EventArgs e) 

   2: {

   3:     //  Code that runs on application shutdown

   4:     DashboardBusiness.WorkflowHelper.Terminate();

   5: }

The most interesting function is the ExecuteWorkflow function which does the following:

• Execute workflow synchronously
• Pass parameters to workflow
• Upon completion, get output parameters from workflow and return them
  Handle exceptions raised in Workflow and raise to ASP.NET exception handler

First ExecuteWorkflow creates an instance of Workflow and passes input parameters to it:

   1: public static void ExecuteWorkflow( Type workflowType, Dictionary<string,object> properties)

   2: {

   3:   WorkflowRuntime workflowRuntime = Init();

   4:  

   5:   ManualWorkflowSchedulerService manualScheduler = workflowRuntime.GetService<ManualWorkflowSchedulerService>();

   6:  

   7:   WorkflowInstance instance = workflowRuntime.CreateWorkflow(workflowType, properties);        

   8:   instance.Start();

ManualWorkflowSchedulerService service executes the workflow synchronously. Next step is to hook WorkflowCompleted and WorkflowTerminated events of Workflow Runtime so that I can capture output parameters and exceptions and handle them properly.

   1: EventHandler<WorkflowCompletedEventArgs> completedHandler = null;

   2: completedHandler = delegate(object o, WorkflowCompletedEventArgs e)

   3: {

   4:   if (e.WorkflowInstance.InstanceId ==instance.InstanceId)

   5:   {

   6:     workflowRuntime.WorkflowCompleted -= completedHandler;

   7:     

   8:     // copy the output parameters in the specified properties dictionary

   9:     Dictionary<string,object>.Enumerator enumerator = e.OutputParameters.GetEnumerator();

  10:     while( enumerator.MoveNext() )

  11:     {

  12:       KeyValuePair<string,object> pair = enumerator.Current;

  13:       if( properties.ContainsKey(pair.Key) )

  14:       {

  15:         properties[pair.Key] = pair.Value;

  16:       }

  17:     }

  18:   }

  19: };

When workflow completes, WorkflowCompletedEventArgs gives me the OutputParameters dictionary. It contains all the public properties of Workflow. I read all the entries in the OutputParameters and update the input parameters Dictionary with the new values. This is required in the AddWidget function of DashboardFacade where I need to know the widget instance created by the workflow.

WorkflowTerminated fires when there’s an exception. When any activity inside the workflow raises exception, this event fires and workflow execution aborts. I capture this exception and throw it again so that ASP.NET can trap this exception using its default exception handler.

   1: Exception x  = null;

   2: EventHandler<WorkflowTerminatedEventArgs> terminatedHandler = null;            

   3: terminatedHandler = delegate(object o, WorkflowTerminatedEventArgs e)

   4: {

   5:   if (e.WorkflowInstance.InstanceId == instance.InstanceId)

   6:   {

   7:     workflowRuntime.WorkflowTerminated -= terminatedHandler;                    

   8:     Debug.WriteLine( e.Exception );

   9:  

  10:     x = e.Exception;

  11:   }

  12: };

  13: workflowRuntime.WorkflowCompleted += completedHandler;

  14: workflowRuntime.WorkflowTerminated += terminatedHandler;

  15:  

  16: manualScheduler.RunWorkflow(instance.InstanceId);

  17:  

  18: if (null != x)

  19:   throw new WorkflowException(x);

This helps me get exceptions shown in ASP.NET Exception handler like this:

The WorkflowHelper is a reusable class that you can use in your work project. Just copy the class file out of my project and add in your own.