So, I’ve been tempted to throw my machine out the window lately, working with the Windows Workflow Foundation, InfoPath and SharePoint – and as I’ve said before, at least I’m not the only one frustrated. Maybe that’s not fair – it is in beta after all – but if you’re going to release a beta, you could at least release beta documentation. Anyway, here’s what I found…

I suppose I should state my sources too. I started by following the MSDN Webcast ‘Developing Workflows for the 2007 Version of the Microsoft Office

SharePoint System and Windows SharePoint Services 3.0‘. It’s well worth watching – it’s the most complete demonstration I’ve seen – but found that I couldn’t get the InfoPath forms to show for tasks. I figured this one out (see below) based on a blog post ‘My Key Note Demo – SharePoint v3 OM, SharePoint v3 Workflow, InfoPath and Office 2007 Client Add-Ins‘. See the demo code.

Use the Visual Studio SharePoint Workflow Project Templates – Sounds obvious, I know, but you might not know that there is such a thing. Indeed, I believe that this hasn’t been released to the public yet (I’m not entirely sure how we laid our hands on them), and I didn’t know that such a thing existed at the time. I tried using normal workflow projects – a bad idea. Don’t do that.

Modify the install.bat file – It tells you how to do this at the top, but this one caught both myself and other guy out – I thought it would have changed the values in it to the appropriate values, and my colleague didn’t realise that something in there would have to change at all. It’s not hard – just find and replace stuff- and this is described in the batch file itself.

Configure up the Features and Workflow XML files – There are snippets to help do this, although I’m not entirely sure I understood how I added them. It was from the ‘Tools’ > ‘Code Snippets Manager’, but my notes are vague after that. My colleague says his were already configured. Anyway, the snippets themselves are pretty useful, and have reasonable instructions themselves.

Sign the code – You need to sign your code using this keys thing in .NET. (Yes, I’m a .NET rookie, but I recognised this from Java). This allows you to put the assembly in the GAC and also find….

PublicKeyToken – Don’t forget to fill this in on the Workflow.xml file. There are more instructions in the snippet about what goes there.

Do all your GUIDs – Do all the GUIDs in the XML files, and make sure they’re all different.

Specify the InfoPath Forms you want included – These must be installed with the workflow feature, and not installed separately by hand. If you do that, then you’ll get an error “This form cannot be opened. It is not workflow enabled.” I went to the ‘Manage Forms Templates’ page in SharePoint Central Admin – and yes, there’s a column marked ‘Workflow Enabled’, and no, my form was not enabled. That seemed likely to be the problem then, but I couldn’t find anywhere to set the workflow to ‘enabled’ anywhere in SharePoint, or (for that matter) Infopath.

Turns out it isn’t possible – it is defined by how the form was installed. Some silly bugger (me) had forgotten – in the features.xml file we have the XML:

<Property Key="RegisterForms" Value="*.xsn" />

This means that any forms in the root of the Visual Studio Project will be added in to SharePoint when you run the Install.bat file. Install your XSN files this way, and they’ll be workflow enabled.

Accessing the form data – This bit took a bit of figuring out, but I found a good example from 7 Development Projects with the 2007 Microsoft Office System and Windows SharePoint Services.pdf. It’s a little out of date in some of it’s code examples, it appears, but this seemed to work.

SPWeb aSite = new SPSite(workflowProperties.SiteId).OpenWeb(workflowProperties.WebId);
SPListItem anItem = myWeb.Lists[workflowProperties.ListId].GetItemById(workflowProperties.ItemId);

//Log Item Name, and what List the form is in
Log(“Running against: ” + anItem.Name.ToString() + ” in ” + anItem.ParentList.ToString());

//Log some properties.
Log(“PropertyA: ” + anItem.Properties["PropertyA"].toString() );
Log(“PropertyB: ” + anItem.Properties["PropertyB"].toString() );

//Update properties as you would update a normal SharePoint item through code
anItem.Properties["PropertyA"] = “Some Fixed String”;
anItem.Properties["PropertyB"] = TaskProperties1.ExtendedProperties["PropertyB"];

anItem.update();
Deserialize Initiation Data – Initiation form data comes in from an Infopath form as a serialized XML string. It needs deserialised, and used. I used xsd.exe to create a .cs file defining a class (WFTaskForm) of the same format as the xsd for my InfoPath XSN file. See the webcast mentioned at the top for an example. To deserialize:

String initData = workflowProperties.InitiationData;

XmlSerializer serializer = new XmlSerializer(typeof(WFTaskForm));
XmlTextReader reader = new XmlTextReader(new System.IO.StringReader(workflowProperties.InitiationData));

WFTaskForm wfTask = (WFTaskForm)serializer.Deserialize(reader);

_Text1 = wfTask.Text1;
_Text2 = wfTask.Text2;

Creating Workflow Tasks – This seems to involve a little code. You have to Assign a GUID, etc.. In this instance, I’m assigning the task to the workflow originator.

private void createTask1_MethodInvoking(object sender, EventArgs e)
{
Log("Creating Task");

TaskId1 = Guid.NewGuid();
TaskProperties1.AssignedTo = workflowProperties.Originator;

//Note the double escape, or use an @ – otherwise your AssignedTo will be mangled.
//TaskProperties1.AssignedTo = “SOMEDOMAIN\\SOMEUSER”;

//This is important later – see below
TaskProperties1.TaskType = 0;
TaskProperties1.Title = “AutoTask: ” + _Text1 ;
TaskProperties1.DueDate = DateTime.Now.AddDays(4);

TaskProperties1.ExtendedProperties["Text1"] = _Text1;
TaskProperties1.ExtendedProperties["Text2"] = _Text2;
}

Attach your Infopath forms – This was a right bugger to figure out. I’ll include the entire workflow.xml file from my test project:

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<Workflow
Name="HelloStateSharePointWorkflow"
Description="This workflow creates a task, which is completed when it is changed."
Id="{8F80610C-DF9F-49e4-8C6F-4B4822610086}"
CodeBesideClass="HelloStateSharePointWorkflow.Workflow1"
CodeBesideAssembly="HelloStateSharePointWorkflow, Version=3.0.0.0, Culture=neutral,
PublicKeyToken=bc5e740d61a52a8d"
TaskListContentTypeId="0x01080100C9C9515DE4E24001905074F980F93160"
ModificationUrl="_layouts/ModWrkflIP.aspx"
InstantiationUrl="_layouts/IniWrkflIP.aspx">

<Categories/>
<!– Tags to specify InfoPath forms for the workflow; delete tags for forms that you do not have –>
<MetaData>
<Instantiation_FormURN>
urn:schemas-microsoft-com:office:infopath:Template1:-myXSD-2006-06-08T14-13-41
</Instantiation_FormURN>
<Task0_FormURN>urn:schemas-microsoft-com:office:infopath:Template1:-myXSD-2006-06-08T14-13-41</Task0_FormURN>

<StatusPageUrl>_layouts/WrkStat.aspx</StatusPageUrl>
</MetaData>
</Workflow>
</Elements>

So, first off, let’s look at the ‘TaskListContentTypeId’. This took me ages to figure out. I tried reading the MSDN documentation on how to do this, but that doesn’t seem to work for me. It also seemed substantially different to the web-cast mentioned above – there was nothing to do with Content types in the webcast, but it seems core to the MSDN documentation about this. Anyway, I reverse engineered mszcool’s post, and found I was missing this attribute from the Workflow tag.

I was a little puzzled as to what content type value to put in the attribute. Looking at the Task list I was using, I discovered that if I went to ‘Advanced Settings ‘ and allowed management of content types that the settings page now exposed the Content Types available to that list.

These were ‘Task’, ‘Workflow Task’, and ‘Workflow Task with InfoPath form’. I copied the content type id for ‘Workflow Task with InfoPath form’ from the url of the ‘List Content Type: Workflow Task with InfoPath form’ page, used that, and reinstalled the workflow. This didn’t work, so I tried the content type id that was the same as in the demo. As the ID I’d just tried had the same first 42 characters as the entire of the id in the demo, this wasn’t as random as it seems. This worked, and my InfoPath form was displayed!

Naturally, I wondered why this was the case. I went back the the ‘List Content Type: Workflow Task with InfoPath form’, and was puzzled by the ‘Parent’ being ‘Workflow Task with InfoPath Form’. Clicking on that took me to ‘Site Content Type: Workflow Task with InfoPath form’, and this has the ID that I’d just used. Note that that is a SITE content type, not a list one, and it appears to be in a ‘_hidden’ group, which might explain why I didn’t find it when looking at Site Content Types.

What I think is happening is that the new TaskListContentTypeId attribute tells the workflow that it’s tasks should display infopath forms, and that this was lacking before. I’m hoping that someone might be able to elaborate – and tell me how I find out what other ‘hidden’ content types there are in SharePoint.

Anyway, this seems to tell SharePoint to use an InfoPath form, but which one. In the exmpale above, we have a tag <Task0_FormURN>. The ’0′ in the tag name matches the TaskType we set in the task properties (see the section above). If we wanted a second form for a different step, it would be <Task1_FormURN> and we would set the TaskProperties2.TaskType = 1;.

That seems to work nicely!

What I still can’t do:

Start a workflow when a new Item is created – I keep getting an error, and I’m not sure what. I’ve looked in the logs, and the error I have is:

06/20/2006 12:00:28.75 OWSTIMER.EXE (0x064C) 0x0D08 Windows SharePoint Services
Workflow 72et Exception

System.ArgumentNullException: Value cannot be null.
at Microsoft.SharePoint.Workflow.SPWorkflow.GetReservedItemId(SPList list, Guid taskId, Boolean createNew)
at Microsoft.SharePoint.Workflow.SPWinOEItemEventReceiver.CreateListItemSubscription(Guid subscriptionId,
SPWorkflow workflow, SPList list, Guid channelTypeId, Guid staticCorrelationId, Guid dynamicCorrelationId,
Guid subEventType, SPEventReceiverType rt, String assemblyName, String className, String eventName,
Int32 itemId, Boolean fReserveId)
at Microsoft.SharePoint.Workflow.SPWinOETaskService.CreateSubscription(MessageEventSubscription sub)
at Microsoft.SharePoint.Workflow.SPWinOESubscriptionService.CreateSubscription(MessageEventSubscription sub)

I’ve searched on Google, and I get nothin’! If I create a workflow without ‘Create Task’ activities, it runs just fine. I’m not sure what the issue here is.

I’ll try and update my site when I discover new stuff – and hopefully not quite as much as in this post…

Info:

I found these links recently – they’re quite handy:

InfoPath forms for Workflows

How to: Design an InfoPath Form for a Workflow in Office SharePoint Server 2007

Upcoming info:

MSDN Webcast: Developing SharePoint Workflows Using Visual Studio 2005

Comments from my old blog: