With Microsoft Office SharePoint Server 2007 it is possible to use InfoPath forms to get feedback from users within a workflow A good starting point is the white paper – Walkthrough : Creating Office SharePoint Server 2007 workflows with Visual Studio but there are still some things you should really now before starting developing your own workflows on top of the SharePoint 2007 platform. This is the first of a series of postings about workflow in SharePoint 2007.
InfoPath 2007 is used in a couple of places in a SharePoint driven workflow:
- In the workflow initiation and association forms which are used to set workflow parameters before a workflow starts
- In a workflow modification form which enables users to alter the workflow while it is running
- In the workflow task forms which is opened when a user clicks the task link which is assigned within the workflow process.
When you want to develop a SharePoint workflow with Visual Studio 2005 you will first need to install the SharePoint workflow project templates. These Visual Studio project templates are installed when you install either the ECM Starter Kit (for Microsoft Office SharePoint Server ) or the Workflow Developer Starter Kit for Windows SharePoint Services 3.0.
When you start a new SharePoint workflow project, you will notice that the solution contains a number of files which are used to define the workflow solution – one of them is the workflow.xml file. In this file, you will need to specify the InfoPath forms you will be using by specifying the URNs. To find the URN of an InfoPath form, open the form in InfoPath in design mode and choose properties from the file menu.
Another location where you can find a reference to the InfoPath forms is in the feature.xml file – here you see the next section – make sure that you uncomment the <Property Key=”RegisterForms” Value=”*.xsn” /> line – this specifies that you will copy the InfoPath forms to the same directory as where you deploy the feature.xml file.
<Property Key="GloballyAvailable" Value="true" />
<Property Key="RegisterForms" Value="*.xsn" />
The last file that you need take a look at is install.bat - this will register your workflow solution, copy the necessary files and register the workflow assembly in the GAC.
Things you should watch out for:
- Design the InfoPath files in a directory separate from your solution and publish them to the same directory (Use publish to network location) in which you have your workflow solution – this way you can simply use the <Property Key=”RegisterForms” Value=”*xsn” /> and use the default line in install.bat - xcopy /s /Y *.xsn "%programfiles%\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\YourCustomFeature\"
- Make sure that the Alternate access path is not filled in when publishing the InfoPath files – when publishing it to a network location, you should have received a warning – see screenshot listed below.
If something goes wrong, one of them the infamous “XSN can not be used on the server” error, you can troubleshoot the problem with the following steps:
- Navigate to a command prompt
- Navigate to this folder: %programfiles%\common files\microsoft shared\web server extensions\12\bin
- Execute this command on each of your XSN files: stsadm.exe -o verifyformtemplate -filename <complete path to your xsn including the name.xsn>
This will give a more detailed description - if you are not sure if the access path is filled in for the InfoPath form you have deployed – you can rename the xsn file in the features directory to a CAB file and extract manifest.xsf from this file in this file – you should see that accessPath=""
P.S. For some more tips, take a look at Blood, sweat and Windows Workflow in SharePoint