Compartilhar via

Importing a SharePoint Designer (SPD) workflow with Initiation/Association InfoPath forms to Visual Studio 2010 (Huma Qureshi)

  • Artigo

SharePoint Designer (SPD) workflows are declarative, i-e they have no code and the entire workflow is defined using xml files. When working against SharePoint Server 2010 SharePoint Designer auto-generates InfoPath forms for the workflow with fields defined by the user in the workflow. When you import this workflow to Visual Studio, using ‘Import Reusable Workflow’ template, the InfoPath forms are brought over in Visual Studio but they are not hooked up to run on F5 with the converted Visual Studio workflow. Here are the steps explaining how to get SPD’s initiation/association forms working in Visual Studio.

Notes:

1. If the InfoPath form name contains some special characters, like whitespace, the steps below might run into problems, and some paths might need to be fixed up.

2. It is best to use the actual server URL when testing out the Workflow. Forms won’t load if you browse to localhost.

1. Creating the SPD Workflow with InfoPath forms

1) Create a new reusable workflow on your SharePoint site, using SPD.

2) Export it using the SPD ‘save as template’ option.

3) Download the .WSP from the site’s Site Assets library.

4) Copy the WSP to your dev machine where Visual Studio 2010 is installed.

5) Create a new Visual Studio project of type ‘Import Reusable Workflow’.

2. Set up the form for deployment

1) The imported form is placed under the “other imported files” folder in Visual Studio. First, in the Visual Studio Solution explorer, drag the form (*.xsn) under the workflow SharePoint Project Item (SPI) to which the form belongs.

image

2) Using the property grid, change the ‘Deployment Type’ property of the *.xsn form to be “Element File”. This will automatically deploy the form on server along with the workflow.

3. Set form registration settings

1) Now that the form is set to be copied over on deployment with the workflow, you need to make sure that it is also registered on the forms server when it is deployed. To do this, you need to add a feature receiver to the workflow feature which will take care of forms registration. To do this, select the workflow node in solution explorer, then in the property grid expand the feature receiver property, and set the following two sub-properties:

FeatureReceiverAssembly: Microsoft.Office.Workflow.Feature, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c

FeatureReceiverClass: Microsoft.Office.Workflow.Feature.WorkflowFeatureReceiver

2) In the property grid, in the ‘Feature Properties’ collection add these two property/value pairs. (Also shown in the screenshot below)

GloballyAvailable: true

RegisterForms: [MIGRATED_WORKFLOW_NAME]\*.xsn

image

4. Hookup the form with the workflow

In order to hook up the form with the workflow you need to add its URN to the workflow elements manifest.

1) Browse to the form folder in windows explorer by browsing to the Visual Studio project folder. Right click the *.xsn form and choose ‘design’. This will open the form in InfoPath in design mode. (Do not open the form directly from within Visual Studio)

2) Click File->Info->Form template properties and you will see ID of the form:

image

3) Copy the form ID from InfoPath into the following XML snippet and add the following snippet in workflow elements manifest file in Visual Studio under the MetaData element:

<Instantiation_FormURI>{copy form URN here}</Instantiation_FormURI>

<Association_FormURN>{copy form URN here}</Association_FormURN>

image

Now the forms are all hooked up and will be deployed with the workflow. There is one catch though; SPD’s forms are not generated to run with code-based workflows. We can however do a little fix-up on the form to make sure it runs with our code-based workflow.

5. Fix-up the auto-generated InfoPath form

1) Open the form in design view from windows explorer and set the default view on the form to be ‘Associate’. (As highlighted in the screen shot below)

a. In the ‘Page Design’ tab in the ‘views’ section select ‘Associate’ view from the dropdown and click ‘Properties’.

b. In the ‘general’ tab check ‘set as default view’ and click OK.

image

2) Now you need to add a rule on form load to switch to start view.

a. In the ‘Data’ tab in ‘Rules’ section click ‘Form Load’. Add a condition when ‘isStartWorkflow’ field is true. Add an action to switch the view to ‘Start’. Your form load rule should look like the screen shot below.

image

1) Save and close the form (don’t publish).

2) Now right click the workflow node in solution explorer and select “Workflow Debug Settings”. This will let you set workflow association parameters so that your workflow can be associated at debug time. Complete the wizard to select the settings as you want.

3) Now hit F5! The initiation and association form should now be working with your new migrated workflow!

Comments

  • Anonymous
    March 31, 2011
    Really nice post =) You helped me a lot.

  • Anonymous
    June 15, 2011
    Nice post, but I have no idea about use cases and ALM/CI processes for SPD workflow to VS workflow/wsp package converting. Too hard, complicated and, finally, result not guaranteed - sometimes it works, sometimes - not (diff exceptions in hive14). Are there any real life use cases for that?

  • Anonymous
    July 27, 2011
    Thanks for the great post. I had a question though: I went through your steps, however the project failed to build. Error: The type or namespace 'Office' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?) Any suggestions please? Thanks

  • Anonymous
    March 26, 2012
    The comment has been removed

  • Anonymous
    September 09, 2012
    The comment has been removed