Keyvan Nayyeri

Normally writing a custom workflow is a common task in Windows Workflow Foundation because there are many situations that we need to apply a development process to workflows.  There are several references about writing a custom workflow but I see many newbies who can't understand the process easily.  In my opinion the reason is most resources try to talk about all aspects of writing a custom activity at a glance without simple examples.  So I want to test my chance and write about this topic in this post and some future posts.  I'll begin with a simple custom activity which doesn't have any optional or advanced part of a custom activity.

There are two general types of custom activities: basic and composite.  Both basic and composite activities can work with properties, events and ... but composite activities can do something more.  Composite activities can contain basic or composite activities.  There are some examples of basic and composite activities in built-in workflow activities.  Delay or Suspend are two examples of basic activities and While or Parallel are two examples of composite activities.

It's possible to write a custom basic activity or composite activity but process to write a composite activity is a bit longer than basic activity.

Each activity is constructed of some components but for an activity it's not essential to have all these components:

• Definition: Main definition for an activity where you define properties, events and ...
• Executer: This component defines the execution logic for an activity.  For example you can use this component to run child activities in a special order.
• Validator: Validator components helps you to validate workflow information before runtime so it can let you to prevent from some exceptions as a result of wrong input.
• Toolbox Item: This component defines default values to be added to a workflow when it's being added to workflow.  For example you can use this component to set a default integer value for a property.
• Designer: Designer component is all about visual presentation of a workflow and what you see when you're working with it.

Only first component (Definition) is required for an activity to work but usually other components are implemented for an activity.  As you can guess from above description it's not always necessary to have an execution logic, validation logic, default values or a good visual presentation so you can ignore these components based on your needs.

In this post I just want to introduce the core by giving a simple example that only needs first and second components (Definition and Executer).  I write a custom workflow activity that gets two string values: a file path a text.  On execution it creates a text file and writes text value into it.  Before doing anything I create a Class Library project and add appropriate references to it then create a new class file and name it CustomActivity

Alright, I begin with definition component.  To design a custom activity I have to derive my definition from a base class.  For basic activities I must inherit it from System.Workflow.ComponentModel.Activity and for composite activities I must inherit from System.Workflow.ComponentModel.CompositeActivity base classes.  As I want to design a base activity, derive my class from System.Workflow.ComponentModel.Activity:

Next step is to define my properties.  I'll use DependencyProperties to define my properties and show them in Properties window.  My class also has a getter and setter for these properties but calls GetValue() and SetValue() methods from base class to get or set these dependency properties.  I also put a constructor for my class and set Name property from base class to have a default Name for my activity in Properties window.

Well, now I write my execution logic for the activity.  To do this I must override Execute() method from base class.  It has an ActivityExecutionContext parameter and returns an ActivityExecutionStatus enumeration.  My logic is simple and just calls File.WriteAllText() method to write text value into file.  At the end my code returns an ActivityExecutionStatus based on what has happened.

So my final code looks like this:

After writing my code it's time to compile my project and get an assembly.  I create a Sequential Workflow Console Application to test this custom activity and create a new tab and add this activity to my Toolbox.

I drag and drop it to my Sequential Workflow and set my properties in Properties windows.

I run this workflow and check the path specified!  So far so good!!

As you see neither I didn't define any validation component, didn't put any logic for Toolbox Item component and didn't declare a custom presentation for my workflow and Visual Studio draws a default shape for my workflow.  Hopefully in future posts I'll extend this example to add these capabilities to it.