Creating a SharePoint Solution for an InfoPath Form Template Deployment

Summary: Learn to create a WSS solution package (WSP file) to deploy an InfoPath Form template (XSN file).

Applies to: Microsoft Office SharePoint Server 2007, Microsoft Office InfoPath 2007, Microsoft Office Forms Server 2007

Introduction

InfoPath browser-enabled form template deployments are easy enough to do via the InfoPath client when the template does not require administrator approval. However even when administrator approval is not required, but the SharePoint governance plan requires script-able deployments of all InfoPath forms due to quality assurance and user acceptance testing requirements we need a mechanism to package our forms in a WSS solution package.

In this situation we are left with a few options, the easiest option is to deploy the form template using Central Administration in our development environment and then use Mark Wagner’s SharePoint Solution Exporter tool to extract the WSP file. This option is a bit limited however. The solutions generated by InfoPath Form Services after a form is uploaded using Central Administration contain a single form template and have some really unpleasant naming conventions (GUID are not pretty to look at).

Another option, and the topic of this tutorial, is to create a solution package from scratch. This option requires more work but provides more flexibility. We can include more than one form template (XSN file) per solution. We can comply with form, feature, and solution naming schemes. The following steps are required to create a solution package using this option:

  1. Create and publish an InfoPath browser-enabled from template(s)
  2. Create a solution manifest
  3. Create a feature manifest
  4. Create an element manifest
  5. Create a data description file
  6. Create and deploy the solution package (and activate the feature)

The following sub sections will discuss how to perform the steps above.

Create and Publish the InfoPath Browser-Enabled From Template

There are plenty of resources already available on how to create browser-enabled form templates and what the different types of browser-enabled form templates InfoPath Forms Services can use. So for the sake of simplicity, I will use only one form for this tutorial. The only thing that we need here is to make sure we have a published browser-enabled form template.

Follow the steps below to create a sample InfoPath Form Template:

  1. Open Microsoft Office InfoPath 2007
  2. Using the Getting Started modal dialog, click once on the Sample - Expense Report template under the Customize a Sample heading (center of the modal dialog window) and click the Design this form link under the Form tasks heading (right side of the modal dialog window)
  3. Using the application menu, select File > Publish…
  4. If the an information window appears telling you “the form template must be saved it can be published,” click the OK button and save the form template somewhere (name it something appropriate like Expense Report for example)
  5. Select the To a network location radio button and click the Next button in the Publishing Wizard
  6. Provide the Form template path and file name (I made a directory called c:\wspinfopath and saved the template there, remember the location that ou chose as we will use this location later in the tutorial) in the Publishing Wizard
  7. Provide the Form template name (I used Expense Report) and click the Next button in the Publishing Wizard
  8. Clear the text box (make it empty) and click the Next button in the Publishing Wizard
  9. If prompted about the access path, click the OK button in the alert prompt
  10. Verify the form name, publish path (remember this value), make sure the access path is empty, and the security level is not Restricted (InfoPath Forms Services does not support the Restricted security level)
  11. Click the Publish button in the Publishing Wizard
  12. Click the Close button in the Publishing Wizard
  13. Close Microsoft Office InfoPath 2007

Visit the InfoPath Developer Portal for additional InfoPath development resources. You can also download my sample published InfoPath Form Template here.

Create the Solution Manifest

In order for Windows SharePoint Services 3.0 to know what to do with a solution package (WSP file) we need to add the required meta data in the form of a solution manifest. This file must be named manifest.xml in order for WSS to find it in the package. You can use any XML or text editor to create the file. I used Visual Studio, but it really doesn’t matter.

Follow the steps below to create a solution manifest:

  1. Open your favorite XML or Text editor and create a file named manifest.xml
  2. Save the file to the publish path location of the InfoPath form template (I hope you remembered your path, mine was c:\wspinfopath) and name it manifest.xml
  3. Copy and paste the XML code sample below, save the file, and exit your XML or Text editor
<?xml version="1.0" encoding="utf-8" ?>
<Solution xmlns="http://schemas.microsoft.com/sharepoint/"
          SolutionId="39E1D478-A2BD-4B39-9842-49CA69369BFE"
          DeploymentServerType="WebFrontEnd">
  <FeatureManifests>
    <FeatureManifest Location="myInfoPathFormTemplate\feature.xml"/>
  </FeatureManifests>
</Solution>

When creating your own solution manifest, make sure you generate a new solution id. You can also download my sample solution manifest here.

Create the Feature Manifest

The steps for creating the feature manifest are identical to the steps we used to the the solution manifest with two exceptions. The exceptions are name the file something different (I use feature.xml for this tutorial) and the content that you save in it. So fire up your editor of choice and put the following XML code in the file.

<?xml version="1.0" encoding="utf-8" ?>
<Feature xmlns="http://schemas.microsoft.com/sharepoint/"
         Id="41CEE181-9440-4536-A1DA-73F41D2155B7"
         Title="My InfoPath Form Template Feature"
         Description="This feature contains the 1 InfoPath form template, but can contain more than one."
         Version="12.0.0.0"
         Scope="Site"
         DefaultResourceFile="ipfscore"
         ReceiverClass="Microsoft.Office.InfoPath.Server.Administration.XsnFeatureReceiver"
         ReceiverAssembly="Microsoft.Office.InfoPath.Server, Version=12.0.0.0,
                           Culture=neutral, PublicKeyToken=71e9bce111e9429c" >
  <ActivationDependencies>
    <ActivationDependency FeatureId="C88C4FF1-DBF5-4649-AD9F-C6C426EBCBF5"/>
  </ActivationDependencies>
  <ElementManifests>
    <ElementManifest Location="element.xml"/>
    <ElementFile Location="ExpenseReport.xsn"/>
  </ElementManifests>
  <Properties>
    <Property Key="FeatureName"
              Value="My InfoPath Form Template Feature"/>
  </Properties>
</Feature>

When creating your own feature manifest, make sure you:

  • Generate a unique id for the Id attribute of the Feature root element
  • Give your feature a meaningful title in the Title attribute of the Feature root element
  • Give your feature a meaningful description in the Description attribute of the Feature root element

There are a ton of things going on in the feature manifest. I am not going to go into the details of what each node means and what other possible attributes you can use. That topic deserves a post (or many posts) of its own. Instead, let me just point out some key points:

  • The ActivationDependencies node makes sure that InfoPath Forms Services (IPFS) is available and active before our feature is activated. IPFS is an enterprise feature and will require either an Enterprise or Internet CAL.
  • I am not sure why we need the FeatureName in the key-value property pairs in the Propertynode. I am assuming that XsnFeatureReceiver class uses it, but I have not really played with those properties.
  • The ReceiverClass and ReceiverAssemblyattributes are important so that IPFS takes the appropriate actions during the various feature events (such as the install, un-install, activate and deactivate events).
  • If you have more than one XSN file that you want to deploy with this feature, then just add additional ElementFile nodes.
  • The scope of the feature must be a site collection (yes the Site value is correct and intentional in the Scope attribute of the Featureroot element). Remember that when an InfoPath form is uploaded via Central Administration, it must then be activated to a site collection. I am not sure what would happen if a different scope is used as I have not tried it. You are welcome to give it a shot.

Like the solution manifest, you can also download my sample feature manifest here.

Create the Element Manifest

We are more than halfway done… I think. Just kidding we are almost there. The next file we need to create is the element manifest. Basically it is just like the feature manifest, but again the file name and the content of the file are a bit different. Fire up your editor… again. This file will be called element.xml.

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Module Name="XSN" Url="FormServerTemplates" RootWebOnly="TRUE">
    <File Url="ExpenseReport.xsn"
          Name="ExpenseReport.xsn"
          Type="GhostableInLibrary"/>
  </Module>
</Elements>

You can do some interesting things with element manifests and we could spend a ton of time exploring this manifest. But we won’t because that is yet another topic that is deserving of its own post (or more). Just know that this file and its XML code are responsible for telling the WSS run-time to provision the form template to the Form Template Library in the root website of the site collection.

By the way, if you added more than one XSN file to the feature manifest because you have more than one form template to deploy with your solution, then you will want to add additional File elements for those files. There should be a one to one correlation between the form templates listed in the feature manifest and the element manifest.

I know you are expecting by now… so download my sample element manifest here if you like.

Create the Data Description File

When all is said and done, the solution package (WSP file) is just a cabinet file and is created using the MAKECAB utility. But in order for the utility to know how to create the file we have to pass it a data description file (DDF file) as an argument. The DDF file is just a plain text file with its own syntax that is pretty easy to follow. So for the last time (I promise) fire up your favorite text editor and put the following contents in it. (This file will be called wsp.ddf.)

; wsp.ddf (Alonso Robles)
.OPTION EXPLICIT     ; Generate errors
.Set CabinetNameTemplate=myInfoPathFormSolution.wsp    
.Set DiskDirectoryTemplate=CDROM ; All cabinets go in a single directory
.Set CompressionType=MSZIP ;** All files are compressed in cabinet files
.Set UniqueFiles="ON"
.Set Cabinet=on
.Set DiskDirectory1=Package
; Add Solution Manifest
manifest.xml   manifest.xml
; Add Feature Manifests
feature.xml    myInfoPathFormTemplate\feature.xml
; Add Element Manifests
element.xml    myInfoPathFormTemplate\element.xml
; Add Element Files
ExpenseReport.xsn  myInfoPathFormTemplate\ExpenseReport.xsn

You may feel overwhelmed with the contents of the DDF file. It’s okay that’s normal. You may also be wondering why I used a feature folder hierarchy in the file when we created a folder for a feature at all throughout the tutorial. And you are probably guessing that I am not going to go into the details of the DDF file in this post. And you would be right if you think I am going to tell you that the DDF file is another topic deserving its own post. What you may not know, is that I have covered the DDF file in some detail in a previous post: Creating Solution Packages for WSS 3.0 and MOSS 2007 Deployments.

Oh yeah, almost forgot… you can download my sample data description file here.

Create and Deploy the Solution Package (and Activate the Feature)

This next part is accomplished using the command line. I am going to assume that you have the MAKECAB utility installed and that you have both MAKECAB and the STSADM utility accessible via the your environment variables. If you don’t you may need to update your environment variables to make the utilities accessible (or use absolute paths) when using them. Fire up a command line window and let’s get started. Below you will find the commands that I used to build and deploy the solution package (with a few modifications to generalize the commands) followed by a brief explanation:

cd c:\wspinfopath
makecab -F wsp.ddf
stsadm -o addsolution -filename myInfoPathFormSolution.wsp
stsadm -o execadmsvcjobs
stsadm -o deploysolution -name myInfoPathFormSolution.wsp -immediate
stsadm -o execadmsvcjobs
stsadm -o activatefeature -name myInfoPathFormTemplate -url http://mymoss

Quickly reviewing the commands above, we can see that we changed our working directory to the location of the publish path of the InfoPath form template (and the solution files). Then we generate the WSP file with the MAKECAP utility. Finally, using the STSADM utility we added the solution, deployed it, and activated the feature (for more information STSADM operations see my post on the 189 STSADM Operations). 

Conclusion

This post covered how to create a WSS solution package to deploy InfoPath browser-enabled form templates. While this method may not be required for all Microsoft Office SharePoint Server 2007 or Microsoft Office Forms Server 2007 implementation, it does offer some flexibility in order to allow us to comply with solution, feature, and form template naming conventions. In addition, it provides the ability to create script-able deployments that can be uniformly applied to multiple environments.

Additional Resources

This entry was posted in InfoPath, Sharepoint Server and tagged , , , , , . Bookmark the permalink.

12 Responses to Creating a SharePoint Solution for an InfoPath Form Template Deployment

  1. Jerry says:

    Cool!
    I still have one more question, could the infopath form template solution be packaged with a workflow solution into one wsp file? Because these two kind of features have different ReceiverAssebly and ReceiverClass.

  2. Jerry,

    Yes, I think its possible. And you are right about needing two features (you can add many features to a single solution package).

    One thing to keep in mind is the deployment target of the workflow assembly. I am assuming Visual Studio created workflow with Windows Workflow Foundation. Workflow assemblies need to be deployed the GAC including the GAC of the application servers. So the solution deployment server type would need to be changed from a web front end to an application server. The application server option will push the assemblies to all of the servers.

  3. Sri says:

    Hi,
    I have two infopath forms and I deployed it through wsp.
    After that I have added some controls to the Infopath forms, published the infopath and build the wsp. After building i deployed the wsp using upgrade command. All Infopath forms are replaced with newer versions, but still it is not displaying the new infopath forms. After uninstalling and installing the feature it is referencing to the newer version of the infopath forms.
    But is there any way to get the latest reference of these infopath forms without uninstalling and installing the feature.

    Please suggest me solution regarding this.
    Regards
    Sri

  4. Sri,

    The short answer to your question is no. You have to uninstall and install the feature. I am pretty certain that this is how the upgrade form functions in Central Administration work.

    The long answer is you have to understand that the upgrade solution operation in STSADM does not do any uninstalling/installing of the features. It only updates the solution store in the configuration database with the new WSP content and pushes the content out to the servers. If I have a correct understanding of this operation, then you would only see changes to the files on the file system and the global assembly cache (GAC). This would include the XSN file and feature definition for your updated InfoPath form. When you uninstall and install the feature, the feature definition in the site collection is then updated. So you have to re-install the feature anyway.

  5. Pranav says:

    I want to change Modification data of an Infopath Workflow after some tasks get completed. Is it possible? Currently I am trying to assign new data (xml document) to ContextData property of OnWorkflowModified activity, but changes in data are not getting reflected in the modification form. If it is possible, please let me know the procedure.

  6. Pranav,

    Sorry, I won’t be of much help here. I would think that what you are trying to do is possible. However, it has been a while since I’ve worked with InfoPath based modification forms.

  7. Giri says:

    Hi,
    I have a requirement where i need to upload a document in workflow initiation form and the same document needs to be uploaded in the another site collection document library of different machine/box. Is it possible to achieve this?

  8. Sri says:

    Hi
    In the workflow after content/page is a approved we are publishing the page using
    SPFile.Publish() and it is publishing with system account. Is there any way to publish a page with user/who approves the page?
    Regards
    sri

  9. Pingback: MOSS: Como automatizar la publicación de formularios Infopath (III)! « Pasión por la tecnología…

  10. Pingback: MOSS: Como automatizar la publicación de formularios Infopath (III)! - Blog del CIIN

  11. Raj says:

    Hi Alonso

    I am using InfoPath 2010 and publishing the form using central admin –> manage form templates –> upload template.

    the problem i have is, i am not able to give desired name for the solution that gets deployed once after uploading the published form to central admin. It gives its own name like “form-fornamexyz.wsp” However, i would like to give my desired name.

    could you please help me out.

    regards
    raj

  12. Raj,

    The only way I got around this was by creating my own solution and WSP package as described in the article. That was on MOSS 2007 and I’m sure things have changed in SP2010. Unfortunately, I have not worked with InfoPath 2010 and SP2010 at all so I won’t be of much help. However, I can’t imagine that it would be much different.

Leave a Reply