Creating a MOSS State Machine Workflow (Part 4 of 4: Workflow Deployment)

This post is the last in a four-part series on the development of a MOSS State Machine workflow and will quickly walk through the steps of deploying the workflow as a SharePoint feature.

If you’re starting here, the first three parts of the series can be found here:

1. Concepts and planning
2. Creating InfoPath forms (and an update to this one)
3. Workflow development

There are many resources available with explanations on packaging your workflow as a SharePoint features; the Visual Studio extensions include an XML snippet for the necessary feature.xml and workflow.xml. MSDN has a simple walkthrough of deployment of a workflow as a feature. Nick Swan has a blog post on it, as well.

Given those resources, I’m going to cover this topic quickly. Following are the general steps for deploying the workflow assembly and InfoPath forms.

SIGN THE ASSEMBLY

For this example, the workflow assembly will be installed to the Global Assembly Cache (GAC), so it must be given a strong name.

PREPARE THE WORKFLOW.XML FILE

The workflow.xml file is the heart of the definition of the workflow. This file is what bundles the assembly with the specific InfoPath forms, and it tells MOSS which forms to use for each task assigned by the workflow. The contents of the file for this demo is shown here:

<?xml version="1.0" encoding="utf-8" ?>

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">

<Workflow

Name="State Machine Demo"

Description="This workflow is a demonstration of a simple State Machine in SharePoint."

Id="9e5039dc-970a-44f5-8b50-02157aa3fd4c"

CodeBesideClass="State_Machine_Demo.DemoWorkflow"

CodeBesideAssembly="State Machine Demo, Version=1.0.0.0, Culture=neutral, PublicKeyToken=af961c24987a1562"

TaskListContentTypeId="0x01080100C9C9515DE4E24001905074F980F93160"

AssociationUrl="_layouts/CstWrkflIP.aspx"

InstantiationUrl="_layouts/IniWrkflIP.aspx"

ModificationUrl="_layouts/ModWrkflIP.aspx">

<Categories/>

<MetaData>

<Association_FormURN>urn:schemas-microsoft-com:office:infopath:AssocForm:-myXSD-2007-05-15T02-39-52</Association_FormURN>

<Instantiation_FormURN>urn:schemas-microsoft-com:office:infopath:BeginForm:-myXSD-2007-05-15T02-39-52</Instantiation_FormURN>

<Task0_FormURN>urn:schemas-microsoft-com:office:infopath:BeginForm:-myXSD-2007-05-15T02-39-52</Task0_FormURN>

<Task1_FormURN>urn:schemas-microsoft-com:office:infopath:ReviewForm:-myXSD-2007-05-15T15-43-08</Task1_FormURN>

<Task2_FormURN>urn:schemas-microsoft-com:office:infopath:SubmittedForm:-myXSD-2007-05-15T15-53-15</Task2_FormURN>

<StatusPageUrl>_layouts/WrkStat.aspx</StatusPageUrl>

</MetaData>

</Workflow>

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

</Elements>

A few of the attributes within the <Workflow /> tag are worth providing additional mention:

• Id – A GUID that identifies your workflow to the SharePoint workflow engine.
• CodeBesideAssembly – This is the full assembly name of the compiled DLL output of the workflow project you created in step 3 of this series. To find the full name of the assembly, I recommend using Lutz Roeder’s Reflector for .NET.
• CodeBesideClass – This is the full class name of the workflow class that inherits from StateMachineWorkflowActivity or SequentialWorkflowActivity. Note that in this example, there’s only one class in the assembly that you created, but there’s nothing that prevents you from deploying an assembly with multiple workflow classes. You would need to include a workflow.xml for each class within that assembly.
• TaskListContentTypeId – The SharePoint content type referenced here tells the workflow that InfoPath forms will be used for the tasks generated by the workflow. You will not generally need to change this, unless you choose to use the standard SharePoint task forms or create your own ASPX pages.
• AssociationUrl, InstantiationUrl, and ModificiationUrl – These attributes define the page that will be displayed when the workflow is associated, instantiated, and modified (respectively). The values shown here are the standard ones for InfoPath forms; you would only need to change them if using another type of form.

Note the entries in the <MetaData /> tag. First, you’ll note that each item references the URN of each InfoPath form. To find the URN, select File | Properties from within InfoPath. You’ll see the URN in the modal dialog that appears:

The InfoPath form URNs specified here tie the value you used for the TaskType properties in the workflow to the specific InfoPath form.

For example, there’s code in the workflow that looks something like this:

Note that the the TaskType property is set to "3." To specify the InfoPath form for this task, you would put the following entry in the <MetaData /> tag in the workflow.xml file:

This page on MSDN has additional information. In this workflow, you developed InfoPath forms for the Association and Initiation screens, and there are three additional tasks for which forms are specified (Task0_FormURN, Task1_FormURN, and Task2_FormURN).

PREPARE THE FEATURE.XML FILE

This file defines the contents of the WSS feature. This is a pretty simple example, so the XML for the demo looks very similar to the feature.xml snippet provided by the Visual Studio extensions.

There’s not much to add here. Note that this file serves primarily to wrapper the workflow.xml that you created above.

INSTALL THE FEATURE

Now that the configuration is complete, all that’s left is to deploy the feature. For this, Microsoft provides a batch file (that you may need to modify a bit) that does the following:

• Creates the feature directory
• Copies the XML files to the feature directory, along with the InfoPath forms
• Installs the assembly to the GAC
• Installs and activates the feature in a MOSS site collection

USE THE WORKFLOW IN MOSS

Once the feature is installed and activated, you should now be able to use it in your MOSS site.

To do that, you’ll first need to associate it with a list. From the list settings page, select Workflow Settings. Then select Add a Workflow and set the properties as shown.

When you click Next, the Association form that you created will be displayed.

Now, within the list, choose the Workflows option on the context menu for one of the items in the list:

Click on the State Machine Workflow link to start an instance of the associated workflow. You’ll then be presented with your Initiation form:

When you click Submit, the workflow will be started. When you return to the list, you’ll see there is a new column on the default view with a name of State Machine Demo and a value of In Progress.

You can then click on the In Progress link to view the status of the specified instance of the workflow, which will show you all of the tasks and history for the selected instance.

HERE’S THE CODE

So without further ado, here are the links to the full code for this demo:

• Download Visual Studio solution and InfoPath forms

SUMMARY

The State Machine workflow offers a pattern which I think fits many real-world business processes: its ability to transition between states and follow a path through the established rules that is not predetermined offers tremendous flexibility. Combined with the other capabilities of MOSS, the State Machine workflow presents a compelling solution to the challenges of business process automation.