The following is based on the PDC CTP of WF 4.0 and as such might change or be missing in futures releases.
In Parts 1 and 2 we looked at the different types of Workflow and their respective designers available in the CTP of WF 4.0. In the next couple of parts we will look at how we go about creating our own custom Activities.
As previously mentioned, there has been a shift in the way we create and implement our Workflows. We no longer need to write C# to create a workflow, instead we use XAML. This is also true for Activities, as there are 2 kinds of Activities we can create in WF 4.0 which are Composite and Workflow Elements.
The Composite Activity is built up from other Activities and uses one of the Workflow types as it’s basis. This is a change in the way we think about Workflows, in 3.x we saw Workflows as containers that could only contain Activities, now Workflows can contain Workflows which contain Workflows etc. This new approach will allow us to capture and declare far more complex Processes and State Machines than in 3.x.
So lets start by creating a Composite Activity. In this example we’re going to create a new Activity that is going to be used in the theoretical process of a User Group member arriving at a meeting and signing in. The Activity will basically be in charge of asking them there name, some sort of password and saying hello to them.
So first off we create a new Blank Activity and its designer is displayed. At this point we can either add in a single existing Activity or a Workflow.
Because my Activity is essentially making decisions, I am going to add a FlowChart Workflow to be the basis of my new Activity, this will allow me to add multiple Activities that will execute in a specific order.
Now the steps needed to perform our activity are as follows:
- Greet the User
- Ask for their confirmation code (given to them when they registered)
- Depending on whether the code is valid
- Welcome the user
- Give them another attempt to register
Now this Workflow is actually going to loop forever until a valid code is input, but in real life we’d give the user some sort of option to give up.
I’m going to be using our old friends the WriteConsole and ReadConsole Activities for this, as well as a new custom activity that checks the Users input against a confirmation code. The process is exactly the same as creating a Workflow, I drag the Activities on I want to use and connect them together. This leaves me with an Activity that looks like this:
Here are Variables and Arguments:
So what does the XAML look like for this?
As you can see that’s a fairly comprehensive bit of XAML, which is understandable as there is no code behind anywhere in this Workflow. We can now use this Activity on a Workflow, and this is what it will look like.And if we look at the Properties for the placed Activity, we can see our AttendeeName argument that we added to allow us to greet individuals by name.
As this is an InArgument, it allows for expression binding. Had we used just a plain String property on there, we would not be able to use the expression functionality.
In the next part, we will look at creating our own custom Activities in code (items called Workflow Elements) and how to skin them.