Archives for August 2011

SharePoint 2010 in Visual Studio 2010 has made creating Windows Workflow Foundation (WF) workflows an awful lot easier. There are still one or two areas that can be confusing to new developers

One such region of confusion surrounds the Initiation Form – the form displayed whenever a user launches your workflow, that you can use to prompt for more information required to run your workflow. Similar uncertainty surrounds the Association Form – one that is displayed whenever a list administrator attaches your workflow to their list.

Thanks to the tooling in Visual Studio, it’s now easy to add either of these forms. Right-clicking your Workflow item in Solution Explorer and choosing “Add-> New Item” will give you:

Selecting either Initiation Form or Association Form will add the appropriate artefacts to your code and also configures the Element manifest of the Workflow accordingly:

Let’s say we wanted to ask the user a series of extra questions when they launch our workflow, such as their manager’s First Name, Last Name and Email Address, such that we can have access to that data within our running workflow later on.

We can now edit our new Initiation Form as an aspx page in Visual Studio. Let’s add some text boxes to capture the extra information:

The next question is often “how do we get this information to the workflow?” Inside the workflow itself is a SPWorkflowActivationProperties object which exposes two strings: InitiationData and AssociationData, which is respectively the data captured from the user during launch and association phases of the workflow.

The code behind for the Initiation Form has a string method called GetInitiationData(). Whatever string you return here is then available from inside your workflow using workflowProperties.InitiationData. It’s the same principle with Association Forms, GetAssociationData and AssociationData properties.

Clearly, we could go low-rent here and return a semi-colon delimited string or something naff of that ilk.

Alternatively you could store your properties temporarily in a class and then serialise that class to a string and return that. Then later in your workflow you could deserialise that back to an instance of your object.

You could put a lot of effort into this to get it really efficient, but the general principle is why not create a utility class to hold Serialise and Deserialise methods?

I’ve implemented the following candidate code using Generics to show how powerful the technique is:

public static string Serialise<T>(T item)
{
    XmlSerializer ser = new XmlSerializer(item.GetType());
    TextWriter sw = new StringWriter();
    ser.Serialize(sw, item);
    return sw.ToString();
}

public static T Deserialise<T>(string xml) where T : new()
{
    T returnObject = new T();
    XmlSerializer ser = new XmlSerializer(returnObject.GetType());
    XmlTextReader xtr = new XmlTextReader(new StringReader(xml));
    return (T)ser.Deserialize(xtr);
}

So, given a class, for example, to hold contact information:

public class Contact
{
    public string FirstName;
    public string LastName;
    public string Email;
}

You could put the following in your code behind for the Initiation Form:

// This method is called when the user clicks the button to start the workflow.
private string GetInitiationData()
{
    contact.FirstName = firstName.Text;
    contact.LastName = lastName.Text;
    contact.Email = email.Text;
    return Serialise<Contact>(contact);
}

Then in the code beside for your workflow you can get at the data again like this:

private void codeActivity1_ExecuteCode(object sender, EventArgs e)
{
    Contact contact = Deserialise<Contact>(workflowProperties.InitiationData);
    historyDescription = string.Format("Received Contact information: {0} {1} {2}",
        contact.FirstName, contact.LastName, contact.Email);
}

Hopefully this code will save you some searching and typing.