Strongly typed workflow input and output arguments

When you run a Workflow using Workflow Foundation, you
pass arguments to the workflow in a Dictionary form where
the type of Dictionary is Dictionary.
This means you miss the strong typing features of .NET languages.
You have to know what arguments the workflow expects by looking at
the Workflow public properties. Moreover, there’s no
way to make arguments required. You pass parameter, expect it to
run, if it throws exception, you pass more arguments, hope it works
now. Similarly, if you are running workflow synchronously using
ManualWorkflowSchedulerService, you expect return arguments
from the Workflow immediately, but there again, you have to rely on
the Dictionary key and value pair. No strong typing there as
well.

In order to solve this, so that you could pass Workflow
arguments as strongly typed classes, you can establish a format
that every Workflow has only two arguments named
“Request” and “Response” and none other. Whatever
needs to be passed to the Workflow and expected out of it,
must be passed via Request and must be expected via Response
properties. Now the type of these arguments can be workflow
specific, it can be any class with one or more parameters. This
way, you could write code like this:

"/wp-content/images/417C161718F96F396EF6E066D3681CC0.png">
"border-right:0px;border-top:0px;display:inline;border-left:0px;border-bottom:0px;"
height="100" alt="Running workflow with strongly typed argument"
src=
"/wp-content/images/86272AB2B2D7E72E6082CBA3684E96BD.png"
width="657" border="0">

The advantages of these strongly typed approach are:

  • Compile time validation of input parameters passed to workflow.
    No risk of passing unexpected object in Dictionary’s
    object type value.
  • Enforce required values by creating Request objects with
    non-default constructor.
  • Establish a fixed contract for Workflow input and output via
    the strongly typed Request and Response classes or interfaces.
  • Validate input arguments for the Workflow directly from the
    Request class, without going through the overhead of running a
    workflow.

If we follow this approach, we create workflows with only two
DependencyProperty, one for Request and one for
Response. Showing you an example from my open source project
"http://www.codeplex.com/dropthings" target=
"_blank">Dropthings
, which uses Workflow for the entire
Business Layer. Below you see the Workflow that executes when a new
user visits href="http://www.dropthings.com" target=
"_blank">Dropthings.com
, creates a new user and setups all the
pages and widgets for the user. It has only two Dependency
property – Request and Response.

"/wp-content/images/DDB46705FB217D8CAF45D53E8FD8FD8B.png">
image src=
"/wp-content/images/7167DAC7525BBD25A5E53E1755BCD578.png"
width="595" border="0">

The Request parameters is of type
IUserVisitWorkflowRequest. So, you can pass any class as
Request argument that implements the interface.

"/wp-content/images/93813C1CC5D9A8B666307FF400A8D073.png">
image src=
"/wp-content/images/DE6446D78B8953BEBDA6BCA23AA83E50.png"
width="637" border="0">

Here I have used fancy inheritance to create Request object
hierarchy. You don’t need to do that. Just remember, you can
pass any class. You don’t even need to use interface for
Request parameter. It can be a class directly. I use all these
interfaces in order to facilitate Dependency Inversion.

Similarly, the Response object is also a class.

"/wp-content/images/2287149C2B55EBA512E5D908C4D5ACD3.png">
image src=
"/wp-content/images/20A985D39A2762502F3D6AA9900A1FA8.png"
width="656" border="0">

The Response returns quite some properties. So, it’s kinda
handy to wrap them all in one property.

So, there you have it, strongly typed Workflow arguments. You
can attach properties of the Request object to any activity
directly form the designer:

"/wp-content/images/03C2B2C1D7FD88B5E9D3480F6A00C6F4.png">
image src=
"/wp-content/images/6DF37389A9723787236436FB28ADDEAB.png"
width="534" border="0">

There’s really no compromise to make in this approach.
Everything works as before.

In order to make workflow execution simpler, I use a helper
method like the following, that takes the Request and Response
object and creates the Dictionary for me. This Dictionary always
contains one “Request” and one “Response”
entry.

"/wp-content/images/96CAF71D4A51ABEF9697D31594365158.png">
image src=
"/wp-content/images/9ED56181BF628C3145A67C3AE756ECF9.png"
width="498" border="0">

This way, I can run Workflow in strongly typed fashion:

"/wp-content/images/8C2E4A6EF75C0DCF48304F72A4622ABD.png">
image src=
"/wp-content/images/4FF2CB37A834BDA33D7A35298F4F5967.png"
width="646" border="0">

Here I can specify the Request, Response and Workflow type using
strong typing. This way I get strongly typed return object as well
as pass strongly type Request object. There’s no dictionary
building, no risky string key and object type value passing.
You can ignore the ObjectContainer.Resolve() stuff, because
that’s just returning me an existing reference of
WorkflowRuntime.

Hope you like this approach.

3 Comments

  1. Thanks for this. This is really cool technique that we can use. Using validation app block, we can validate the class instance coming into WF to make sure we have all the data we need to proceed.

    Harsha
    idispensable.blogspot.com

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>