More workflow fun – this time caused by my using the latest Visual Studio project for building SharePoint workflows – at this time it’s the one packaged in the VSeWSS3 version 1.2.
Back in the days of RTM, Workflows had a rubbish Visual Studio Project – I mean, awful. “Some assembly required” is really understating it. However, an improved version came along, and it was alright. Sure, there was some fiddling with batch files, but it worked. You could build it, deploy it, and test it easily, and it was pretty easy to get a simple workflow and some InfoPath forms working.
This is my first time using the 1.2 installer, which looks much more sexy – it’s got a wizard and does the ‘deploy’ bit for you, so no fiddling with .bat files. However, I couldn’t get InfoPath forms to appear for my workflow. The were getting deployed into the FEATURES folder, but when I ran the workflows – just ordinary task views appeared.
Bugger.
I tried various things (maybe I was referring to them wrongly – wrong URN – or maybe I needed to do something new to deploy them, etc.). In the end went back to the workflows I’d built with the previous project templates, and began to try and compare them. My current Workflow.xml file looked like:
Looks okay to me. This is the working Workflow.xml file that I’d used in a demo:
Actually, there are a number of things a bit different there – the Status page URL is now in it’s own XML node, rather than an attribute in the Workflow node – but the thing that caught my eye was that the older project had an attribute TaskListContentTypeId . A bit of checking showed that it’s value matched the content type for “Workflow Task with InfoPath form“. Hmm. Suspicious. I tried putting this into my new Workflow.xml:
I saved the project, built and deployed it – and suddenly my InfoPath forms were working.
So what is the TaskListContentTypeId? Well, here’s what MSDN says – and it’s well worth a read. Seriously.
Okay, so the TaskListContentTypeId defines the type of task that we’ll create in our workflow – this appear to be Workflow Task by default, which is hardly surprising. We can define our own Task Content type for our workflow – though for InfoPath forms we’ll just want the ‘Workflow Task with InfoPath form‘ content type (it appears that Microsoft call this type ‘Office SharePoint Server Workflow Task‘, but that’s not a very descriptive name).
We could, in our workflow, create tasks with different content types throughout the workflow by using the CreateTaskWithContentType workflow activity. As a side note, you can see the content types at the bottom of the standard Task forms:
I suppose, though, that I don’t really need another content type for my InfoPath forms; the main advantage of using my own Workflow Task Content type would be for defining my own forms, but we’re doing that already! I guess that there might be some advantages with extra columns to display on the list – but I think I’ll try and do without them…
Anyway, for my own memory…
| Content Type | Content Type ID | Group | Description |
|---|---|---|---|
| Task | 0×0108 | List Content Types | A standard, non-workflow task |
| Workflow Task | 0×010801 | _Hidden | A standard, workflow task. Looks a lot like a normal task, but isn’t |
| Office SharePoint Server Workflow Task | 0×01080100C9C9515DE4E24001905074F980F93160 | _Hidden | Workflow task with InfoPath forms. |
How did I find the _Hidden group content types? I used SharePoint Manager to dig into the Content Types List:
