Microsoft InfoPath 2010
The official blog of the Microsoft InfoPath team

October, 2006

  • Microsoft InfoPath 2010

    Cascading Dropdowns in Browser Forms

    If you are building an InfoPath client-only solution and you need to filter drop-down list boxes, you can simply use the “Filter Data” feature when you set the Entries property for the control. However, since filters are not supported in browser-compatible form templates, how can you accomplish the same functionality?
    This is where .NET web services can “save the day!” By creating web methods that accept parameters, you can add those web methods as data connections and then pass the selected value from one drop-down list box to the appropriate data connection “queryField”. Once the queryField has been set, simply execute that data connection to retrieve the associated values.
    To setup this sample, you will need to have access to the SQL Server Northwind sample database and Visual Studio installed on your server.
    First, let’s create the web service and the two web methods we will use in this sample:
    Step 1: Open the appropriate web site
    1. Launch Visual Studio
    2. From the File menu, select Open and choose Web Site
    3. Select File System and then navigate to: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS
    NOTE: By choosing to open the LAYOUTS folder, your web service will be available from all provisioned sites. If you want the web service only to be available from a specific site (i.e. the default site) you would want to open: C:\Inetpub\wwwroot\wss\VirtualDirectories\80
    1. Click Open
    2. In the Solution Explorer, right-click on the web site and choose New Folder
    1. Rename this folder to: WebServices
    2. Because you may have multiple web services, let’s add a sub folder here that is specific to our web service:
      1. Right-click on WebServices and choose New Folder
      2. Rename this folder to: NorthwindTables
    Step 2: Create the web service
    1. Right-click on NorthwindTables and choose Add New Item
    2. From the Visual Studio installed templates list choose Web Service
    3. In the Name box, rename this to: NorthwindTable.asmx
    1. Uncheck the option “Place code in a separate file” and click Add
    Step 3: Add the web methods
    NOTE: For this sample, it is assumed the SQL Server database is installed on the same Microsoft Office SharePoint Server. 
    1. Add the following “using” declarations at the top of your code page: 

    using System.Data.SqlClient;
    1. Add the following web method to retrieve the CustomerID values from the Customers table in the Northwind database:
    public DataSet GetCustomers() {
                // Create a SQL connection to the Northwind sample database
                SqlConnection cn = new SqlConnection("Data Source=(local);Integrated Security=SSPI;Initial Catalog=Northwind");
                // Create data adapter object passing it the SELECT
                // statement to retrieve the customer ID values
                SqlDataAdapter da = new SqlDataAdapter("SELECT Customers.CustomerID FROM Customers Order By CustomerID", cn);
                // Create a dataset object to store the data
                DataSet ds = new DataSet();
                // Open the connection
                // Fill the dataset
                da.Fill(ds, "Customers");
                // Clean up
                cn = null;
                da = null;
                return ds;
    1. Add the following web method to retrieve the associated orders for the selected customer:

    public DataSet GetOrdersForSelectedCustomer(string strCustID) {
                // Create a SQL connection to the Northwind sample database
                SqlConnection cn = new SqlConnection("Data Source=(local);Integrated Security=SSPI;Initial Catalog=Northwind");
                // Create a string variable for the modified SQL statement
                string strOrdersSQL = "";
                // Create a string variable for the default SQL statement
                string strOrdersOrigSQL = "SELECT * FROM Orders";
                // Some of the customer ID values contain apostrophe's - we need
                // to replace them with two single quotation marks so that all
                // single quotation marks in the CustomerID are parsed correctly.
                strCustID = strCustID.Replace("'", "''");
                // Concatenate the default SQL statement with the "Where" clause
                // and add an OrderBy clause
                strOrdersSQL = strOrdersOrigSQL + " Where CustomerID Like '%" + strCustID + "%' Order By OrderID";
                // Create data adapter object passing it the SELECT statement
                // to retrieve the OrderID values
                SqlDataAdapter daOrders = new SqlDataAdapter(strOrdersSQL, cn);
                // Create a dataset object to store the data
                DataSet Ds = new DataSet();
                // Open the connection
                // Fill the DataSet
                daOrders.Fill(Ds, "Orders");
                // Clean up
                cn = null;
                daOrders = null;
                return Ds;
    1. Build and save the project
    Step 4: Test the web methods
    NOTE: The Identity account of the Application Pool for the web site where this web service is published will need to have access to the SQL Server database.
    1. Open a browser and navigate to: http://<server>/_layouts/WebServices/NorthwindTables/NorthwindTables.asmx (replace <server> with the name of your server)
    2. You should see the two web methods created above along with the default HelloWorld web method:
    1. Click the GetCustomers link and then click Invoke – this should return a list of the CustomerID values
    2. Click the GetOrdersForSelectedCustomer link, in the strCustID box enter: BERGS and then click Invoke – this should return a list of only those OrderID values for BERGS
    Step 5: Create the InfoPath form
    1. Design a new, blank, browser-compatible InfoPath Form Template
    2. Add a drop-down list box to the view and modify the name to: SelectCustomer
    3. Add another drop-down list box to the view and modify the name to: SelectOrder
    1. Add a new “receive data” data connection to the NorthwindTables web service for each of the web methods created above as follows:
      1. GetCustomers:
        • Enable the option “Automatically retrieve data when the form is opened”
      2. GetOrdersForSelectedCustomer:
        • Use ALFKI as the sample value for the strCustID parameter when prompted in the Data Connection Wizard
        • Uncheck the option “Automatically retrieve data when the form is opened”
    2. Set the Data source for SelectCustomer to the GetCustomers data connection and use the CustomerID field for both the Value and Display name properties
    3. Set the Data source for SelectOrder to the GetOrdersForSelectedCustomer data connection and use the OrderID field for both the Value and Display name properties
    4. Create a Rule on SelectCustomer with the following actions:
      1. Set a field’s value: Set the SelectOrder field to nothing (e.g. leave the Value blank)
      2. Set a field’s value: Set the parameter value (strCustID) for the GetOrdersForSelectedCustomer data connection to the SelectCustomer field
      3. Query the GetOrdersForSelectedCustomer data connection
    1. Save the form locally as FilteredDrop-downs_IPFS.XSN
    Step 6: Publish the form
    1. Publish the form to a server running InfoPath Form Services
    2. Navigate to the form library where the form was published and click the New button
    3. From SelectCustomer choose BERGS
    4. Click SelectOrder – only those orders for BERGS are displayed
    5. Select a different customer – notice the orders have also changed
    Scott Heim
    Support Engineer
  • Microsoft InfoPath 2010

    Data Connections in Browser Forms

    A while back, I wrote a series of 3 blog posts about authentication that was targeted at advanced enterprise-level scenarios involving multi-tier delegation of credentials for data connections on the server. However, I never took the time to cover the basic scenarios around getting basic data connections to work on the server. This post will answer the question "how do I get my data connection to work on the server". Cart, meet horse.
    When we started defining the server experience for InfoPath forms, one of the guiding principles we espoused was "design-once." Meaning, provided you stick within the subset of functionality supported on the server, you could design a form once and it would run in InfoPath and in Forms Services. That is basically true for data connections, but there are two special considerations that differ significantly when moving to the server, namely
    • Authorization to perform cross-domain connections
    • Multi-tier authentication
    The cross-domain issue, server edition
    Short version:
    You can’t make a cross-domain connection from a domain security browser form unless your data connection uses a UDC file.  Period.
    Long version:
    InfoPath has three security modes, which we refer to as restricted (AKA "super-sandbox"), domain, and full-trust.  Restricted form templates don’t run on the server.  Full-trust form templates are allowed to do whatever and consequently need to be administrator-approved in order to run server-side.  Domain trust form templates constitute the vast majority of form templates in the enterprise, and roughly follow the Internet Explorer security model which dictates that by default, the user must approve any attempt to access resources that come from a different domain or Zone.  So, if you have a form template running on http://myserver/, and it tries to connect to a web service on http://yourserver/, InfoPath will prompt you before trying the connection.
    Works great in InfoPath, but when you run a form in the browser, you may be running server-side business logic.  That business logic may want to execute a data query.  Because HTTP is a stateless protocol, Forms Services can’t halt execution of a server-side process and return to the browser in order to ask you for permission to continue.  Additionally, the user in this case may not be the right person to own the decision about whether the cross-domain connection can take place.  So, this decision is placed instead in the hands of the server administrator who owns security around the form template.  Depending on whether the form is administrator-approved or just published to a document library by Joe User, this ownership falls on the farm administrator (I call her Julie) or the site collection administrator (henceforth known as Bob).
    The technology which allows Julie and Bob to determine whether forms can make cross-domain connections involves a system of checks and balances.  Central to this system is a data connection settings file in the Universal Data Connection V2 format, called a UDC file.  Bob’s UDC files live in a special type of document library called a Data Connection Library, or DCL.  Julie’s UDC files live in the Microsoft Office SharePoint Server configuration database, and are managed via the "Manage Data Connection Files" page in the Application Management section of SharePoint Central Administration (I tend to refer to this as "the store").
    The basic premise behind UDC files is that in InfoPath 2007 your data connection settings can live outside of the form template in one of these files, and both InfoPath and Forms Services will retrieve the current connection settings from this file at runtime before making the connection.  The UDC file itself is retrieved from a URL relative to the root of the site collection where the form was opened.  This enables lots of cool functionality - for example, you can now share settings across multiple forms and change them once when you move your data source. 
    You can also pre-deploy test and production versions of your data connection settings to your staging and production environments so that you don’t need to update the form template with new data connection settings when you go live. 
    For the purposes of this discussion the key takeaway is that a domain security form running in the browser will never make a cross-domain data connection unless those connection settings come from a UDC file.
    In other words, you can’t make a cross-domain connection from a domain security browser form unless your data connection uses a UDC file.  Period.
    Why is this more secure?  Well, if Bob is a good administrator, he controls access to Data Connection Libraries on his site collection.  A DCL requires content approval by default, and while members of the site with Contributor access can write files to the library, nobody but the owner of the file can use the file from InfoPath unless a content approver has approved the file.  By default, all members with Designer permissions have the Content Approval right.  In short, Bob can set up the site collection such that only people that he designates can approve UDC files.  Therefore, forms on Bob’s site collection can only make connections outside the farm unless he approves the connection first.
    Julie’s central store is more secure - only users with access to SharePoint Central Administration can modify those files.  Furthermore, by default only the server object model can access files in the store.  In order to make these files accessible to web clients such as InfoPath, the "web accessible" flag must be set.  Otherwise, the files can be used from browser forms only.
    Finally, if Julie wants to have complete control over cross-domain connections for the farm, she can turn off the ability for user form templates to make cross-domain connections at all (in fact, these are disabled in a default install).  When cross-domain connections are disabled for the farm, even connections that use settings from a UDC file can’t make cross-domain connections.
    Solving multi-tier authentication issues
    Once your form is allowed to make cross-domain connections, you’ll need to deal with getting access to the data.  If your data lives on a different computer than your Forms Services site, this means figuring out an alternative set of credentials for data access.  I’ve covered why this is true, and the various options for accomplishing this task, in a series of posts called "Advanced server-side authentication for data connections," but I left out one useful prototyping trick.  Consider the following UDC authentication block:
           <udc:UseExplicit CredentialType="NTLM">
    The UseExplicit element allows you to specify a username and password in plaintext.  When this is present, Forms Services will impersonate the specified user using the supplied credentials.  This is a great tool for prototyping - you can see immediately whether your connection can be made given valid credentials before you go to the trouble of setting up Office Single Sign-on.  However, I cannot stress enough that this is for prototyping only.  Because  the UDC file is in clear text and is accessible to anyone with read permission on the library, this puts a windows username and password in clear text on the network, which is bad-bad-bad.  You’ve been warned.
    Whatever Julie wants, Julie gets
    The "Manage data connection files" page (AKA "the store") gives Julie a great deal of power over the use of data connections in administrator-approved form templates.  Furthermore, Julie also has a great deal of control over what Bob’s users can  do.  The following defaults can only be modified on the Configure forms services page:
    • User form templates cannot make cross-domain connections (not even with a UDC files)
    • User form templates cannot use authentication embedded in a database connection string. 
    • User form templates cannot use the authentication section of the UDC file 
    • User form templates can use credentialType BASIC or DIGEST only if the connection is made using SSL.
    • User form templates cannot make cross-domain connections (not even with a UDC files)
    • User form templates cannot use authentication embedded in a database connection string.
    • User form templates cannot use the authentication section of the UDC file
    • User form templates can use credentialType BASIC or DIGEST only if the connection is made using SSL.
    The following default setting can only be modified on the Configure Web Service Proxy page:
    • User form templates cannot use the Web service proxy
    What’s next?
    Now that you’re motivated to use UDC files to enable data connections on the server, you’ll need to know how to create them and how to re-use them.  I’ll tackle that topic in a future post.
    - Nick Dallett
    Program Manager
  • Microsoft InfoPath 2010

    The anatomy of a UDC file


    OK, we’ve talked about super-fantastic high end authentication scenarios. We’ve talked about cross-domain security and administrative control. We’ve talked about generating UDC files using InfoPath and consuming them again in the designer. Now let’s drill into the structure of the file itself.

    UDC V2 is an XML format, and like any good XML format, there is a schema and a namespace associated with it. I’ll give you the full schema at the end of this post.

    A handy tip: copy the schema into notepad and save it with an xsd extension, then follow the steps outlined in Aaron Stebner’s blog here: to add the xsd file to Visual Studio’s intellisense cache. Once that’s in place, Visual Studio will help you generate your UDC files!

    Basic Structure of the File

    Every UDC file you create will have the structure below, so copy it to notepad and use it as the basis for all your files. This is the infrastructure – the metadata that describes the connection and allows external components such as SharePoint and InfoPath to understand what’s inside.

    <?MicrosoftWindowsSharePointServices ContentTypeID=”0x010100B4CBD48E029A4ad8B62CB0E41868F2B0”?>
    <udc:DataSource MajorVersion="2" MinorVersion="0" xmlns:udc="">
      <udc:Type MajorVersion="2" MinorVersion="0" Type=""/>
      <udc:ConnectionInfo Purpose="" AltDataSource=””/>

    The file begins with a processing instruction specifying a Content Type Id. This is necessary to associate the file with the UDC content type on a Microsoft Office SharePoint 2007 server. Having the content type identified allows the Name, Title, Description, Type, and Purpose fields to be promoted into columns in the data connection library so that the InfoPath designer can see the file.

    By the way: there’s a known issue on Windows Vista where the title property doesn’t get promoted when using the Convert function in the InfoPath designer. To work around this issue, save the file to your local disk, and then re-upload the file to the library using the SharePoint library upload function.

    The root node is called DataSource, and it specifies the UDC version of 2.0, as well as the udc V2 namespace. The Name and Description fields are promoted into SharePoint columns, and they show up in the InfoPath designer when browsing to the file in the data connection wizard. So, while these fields are not strictly required, you should use them to provide useful information about what the data connection is about, and maybe even contact information for the owner of the data source.

    Type (specifically, the Type attribute on the Type element) and Purpose are both required, and very easy to fill once you know the possible values:



    Use for


    SharePoint list query connection


    SharePoint Library submit connection


    Database query connection


    Xml file query connection


    HTTP Post submit connection


    Web service submit or query connection



    Use for


    All query connections


    All submit connections


    Web service only, when both query and submit methods are specified and they reference the same WSDL

    The AltDataSource attribute specifies a second UDC file in the same library. When specified, InfoPath will use the original file, and Forms Services will use the file specified in the attribute. The attribute's value should be the filename of the alternate UDC file. Naturally, the two files should specify equivalent connections - specifically, the connections have to have the same Type and Purpose, and they have to return the same data, or data in the same format.

    The ConnectionInfo Element

    The meat of the connection information is here, and each type of data connection requires specific elements. So, the contents of this element will change depending on the Type and Purpose attributes.

    Let’s run ‘em down, shall we? I’m confident that you can learn by example, so I’m not going to do a lot of explaining here. As I noted in a previous post, we’re working on a schema reference that will fill in the details.

    1. Web Service
    This example is for a query connection. For a submit connection, the Purpose would be WriteOnly, and the ServiceUrl and SoapAction would be contained within an UpdateCommand element rather than SelectCommand.

    Web service is the only connection type that can have both a SelectCommand and an UpdateCommand in the same file. The two operations need to share the same WSDL, and the Purpose in that case is ReadWrite.

    <udc:ConnectionInfo Purpose=”ReadOnly”>

    2. Database
    A database connection is always marked as ReadOnly. InfoPath determines at design time whether submit can be enabled for the connection.

    <udc:ConnectionInfo Purpose=”ReadOnly”>
    Provider=Microsoft.ACE.OLEDB.12.0;User ID=Admin;Data Source=C:\temp\Database1.accdb;Mode=Share Deny None;Jet OLEDB:System database=&quot;&quot;;Jet OLEDB:Registry Path=&quot;&quot;;Jet OLEDB:Database Password=&quot;&quot;;Jet OLEDB:Engine Type=6;Jet OLEDB:Database Locking Mode=1;Jet OLEDB:Global Partial Bulk Ops=2;Jet OLEDB:Global Bulk Transactions=1;Jet OLEDB:New Database Password=&quot;&quot;;Jet OLEDB:Create System Database=False;Jet OLEDB:Encrypt Database=False;Jet OLEDB:Don't Copy Locale on Compact=False;Jet OLEDB:Compact Without Replica Repair=False;Jet OLEDB:SFP=False;Jet OLEDB:Support Complex Data=False;
      <udc:Query>SELECT * FROM Table1</udc:Query>

    3. SharePoint list query
    <udc:ConnectionInfo Purpose=”ReadOnly”>

    4. SharePoint library submit
    The FolderName element specifies the default folder name that is used to prepopulate the data connection wizard.  Form designers will still need to specify the file name, as it is stored in the form template.

    <udc:ConnectionInfo Purpose=”WriteOnly”>
      <udc:FolderName AllowOverwrite=”true”>

    5. XML file query
    <udc:ConnectionInfo Purpose=”ReadOnly”>

    6. HTTP Post
    <udc:ConnectionInfo Purpose=”WriteOnly”>


    I’ve described the contents of the Authentication element in previous blog posts, so I won’t go into a detailed explanation. Two things are important here:
    1. The Authentication element must be the last child of ConnectionInfo
    2. If both SSO and UseExplicit are specified, Forms Services will use the credentials specified in the SSO element and will ignore the UseExplicit element.
    This section is used only for forms running in the browser – InfoPath always ignores the authentication element.

     <udc:UseExplicit CredentialType="">
     <udc:SSO AppId="" CredentialType=""/>

    The Universal Data Connection 2.0 schema

    Download the XSD from here.

    - Nick Dallett
    Program Manager

  • Microsoft InfoPath 2010

    Where do UDC files come from?

    Where do UDC files come from? - I knew you’d ask. (For those of you who are wondering what a UDC file is, you should go read my post entitled "Making data connections work in browser forms.")
    There are a couple of ways to go about it. UDC files are just xml files with a specific namespace and schema, so once you have a few examples you can probably get around handily with notepad and cut and paste. However, we’ve made it easier than that with the new Convert functionality on the Manage Data Connections dialog. (For those intrepid souls who prefer the notepad route, a schema reference is being prepared for publication.)
    If you start out by designing your data connection the way you normally would, you can then use the Convert button to change the connection from settings in the form template to settings in a data connection file. (In fact, you can open any existing form template in InfoPath 2007 and convert existing data connections the same way.)
    To start with, make sure you have write permissions to a data connection library (henceforth "DCL") on the Microsoft Office SharePoint 2007 server you’re going to publish your form to. Then, using InfoPath 2007 Beta 2 or later, create your data connection or open a form template with an existing data connection. Make sure the connection is to a source supported by UDC. (E-mail connections, connections to a Microsoft Access database, or connections to an XML file in the form template cannot be converted to UDC connections.)
    Here’s the data connections dialog showing a few connections I threw together (you can get to this dialog off of the "tools" menu in InfoPath design mode):
    Click the Convert button and specify the path to your data connection library. If you click "Browse...", InfoPath will suggest a filename based on the name you gave the data connection when it was created.
    If you choose a data connection file that already exists, InfoPath will use the settings in the file you chose - don’t expect it to overwrite the original file with new settings. This could have unexpected results if the file that’s already in the library is a different connection type or returns data that does not conform to the schema your form template expects.
    For most cases, you want to leave the default connection link option. Choosing "centrally managed connection library" will cause InfoPath and Forms Services to look for the UDC file in the "Manage data connection files" library in SharePoint central admin. This is fine, but it means that you need to copy the file from the DCL where you created it to that location before you can use it. This presumes you have access to SharePoint Central Admin. See my last blog post entitled "Making data connections work in browser forms" for more information on this option.
    Once you click "OK" on this dialog, your UDC file will be created and saved to the location you specified, and the connection in the form template will be modified to retrieve settings from the UDC file rather than from the form template.
    NOTE: There’s a known issue in the Beta 2 release where you will see an "invalid URL" dialog at this point. This is benign and is no longer seen in the technical refresh.
    You now have a UDC file in your DCL, but you’re not quite done. By default, a DCL will require content approval before anyone other than the file’s owner can use the UDC file you uploaded. Unless the content approval requirement has been removed, a site administrator or someone else with the content approval right will need to set the file’s status to "approved."
    Adding Authentication
    InfoPath does not automatically configure server-only authentication options for you. However, when creating a UDC file, InfoPath automatically creates an authentication block within the UDC file that is preconfigured to use Office Single Sign-on. In order to use this authentication option, you’ll need to uncomment the authentication block within the file and add both the SSO application ID and the CredentialType. Most of the time, you’ll want to use the SSO credential to log onto Windows, for which you’ll need to specify "NTLM" as the CredentialType. The full list of possible credential types is as follows:
    Credentials will be embedded in a database connection string for authentication against a SQL server.
    Credentials will be used to impersonate a Windows user
    Credentials will be used to impersonate a Windows user using Kerberos
    The username will be used to impersonate a Windows user using Constrained delegation
    Credentials will be used to perform HTTP Basic authentication
    Credentials will be used to perform HTTP Digest authentication
    Reusing existing UDC files
    Once you’ve created your UDC file, you may want to use the same connection for other form templates. Among other things, this has the benefit of sharing settings for multiple forms in a common location. Changing the settings in the UDC file will cause all of the related forms to pick up the changes the next time they are used.
    There are several places in InfoPath where we expose the ability to re-use data connection settings exposed as UDC files in a data connection library. Here are a few examples:
    All of these entry points lead to this dialog:
    When you specify one or more SharePoint sites to search, this dialog allows you to browse available UDC files containing in DCLs on those sites. Based on the context, this dialog is filtered to show only applicable connections (for example, if you start from the "Design a form" dialog, this dialog will only show Web service and database connections).
    Once you’ve specified the UDC file to use, you may need to specify some properties for the connection that are not contained in the file (for example, for a SharePoint list connection, you’ll be asked to specify which columns to include in the data source), but otherwise, you’re done.
    - Nick Dallett
    Program Manager
  • Microsoft InfoPath 2010

    Behind the Scenes of Administrator-Approved Form Templates


    If you’re a server administrator for Microsoft Office InfoPath Forms Services 2007, there may be a time when you’re tried to perform some action on a form template and received an error message that looks like the following:

    “Form template was deployed as part of the 9b518781-2fcd-40fe-a1f4-964b2cd4c0b8 feature”

    This feature name probably doesn’t mean a whole lot to you, and the error message could be a bit more actionable, right?  What the heck is this feature thing that the message refers to?  You might also have come across other IDs or other weird timing issues on a multiple server farm.

    Starting the Tour

    So, to shed some light on this, let’s go back-stage to see a little of what’s going on behind the scenes.  The stage is Windows SharePoint Servers Central Administration, where you will find 5 options in the Microsoft Office InfoPath Forms Services group on the Application Management landing page. This tour will mainly be concerned with the Upload Form Template page and a little bit with the Manage Form Templates page. 

    Let’s start at the Upload Form Template page, which is how a form template gets approved by the administrator.  Each new form template uploaded to the farm also adds a new FormTemplate object to the FormsService.FormTemplates which is the singleton FormTemplateCollection object for the farm’s administration object model.  This FormTemplate object allows the same manipulation that is available through the UI.  It also contains a lot of information used only internally to InfoPath Forms Services.  The most important internal property is the converted file, which is essentially a compiled version of the form template that can quickly render as a form template in the browser.

    When InfoPath form templates are uploaded to a server, the Windows SharePoint Services solution deployment and featurization infrastructures are being used to turn the form template into an administrator-approved form template..  Behind the simple click of the Upload button, InfoPath Forms Services creates a feature to deliver the form template (.xsn file).  The feature is then wrapped in a Windows SharePoint Services solutions package which is a .wsp file (just a renamed .cab file) that contains the feature and some other packaging information.

    The Solution Package

    This solution package is the means of deployment to all of the servers in a farm.  All Web front-end servers will have the form template propagated to their file systems, via the solution’s package.  So, there may be a delay in showing up on a multiple-server farm, hence the ellipsis in the “Installing…” status which remains until the form template is deployed to all machines in the farm.  These are propagated via the SPTimerv3 service which runs on each box and is scheduled to pick up jobs from servers running the central administration Web Application (where the Upload took place) and it uses the SPAdmin service to install the solution on the machine, via the administrator account.  So, InfoPath Forms Services deployment needs these services running on each machine, just like WSS solution deployment, because it’s actually the same thing.  Once deployment is completed, the form template is marked with “Ready” status.

    [Side Note: An implementation just like what we use for solution deployment is also available to you.  Our shipping documentation covers how to create features and solutions from scratch.  You might want to do this to bulk deploy many form templates at the same time, to indicated InfoPath form templates in other features or solutions, or to create a custom workflow that contains custom InfoPath form templates.  These custom-created solutions are still registered into the InfoPath Forms Services OM, but will be treated a little differently in IPFS, for instance, you cannot activate/deactivate/remove/upgrade these form templates through IPFS management, because that might invalidate the overall solutions that were constructed.  The whole features must be activated the same way that other custom features are activated (see Ready for Activation, below).]

    Ready For Activation

    The Ready status indicates that the form template can be used and is in normal operation.  The feature created, is a site collection-scoped feature (that’s SPSite-scoped in WSS OM-speak), which can be activated on an site collection like most other site collection-scoped features.  If you are a site collection owner, navigate to Site Settings, and see Site Collection Features under the Site Collection group heading.  Every form template that was administrator-approved through the upload page is available here along with the other site collection scoped features.

    You can also activate and deactivate features from the Manage Form Templates page in Central Administration.  This is exactly the same thing, and is provided as a courtesy for farm administrators who are also site collection owners.

    Behind the Scenes of Activation and Invocation

    An activated form template is added as an item in the Form Templates library at the root site of the site collection (SPSite.rootWeb) in the /formservertemplates path.  The form template is not actually present in the content database for the library, it is stored as a ghosted entry.  A user invoking the form template with the Microsoft Office InfoPath 2007 rich client is actually pulling the form template from the file system of the Web front-end server where it was placed by solution deployment.  Invoking the form template via the browser will pull the converted file from the FormTemplate object in the administration object model.

    The Form Templates library is special in a few ways.  The most important special aspect is that activated form templates cannot be unghosted.  This is to ensure that the converted file version and the on-disk version cannot be different, so that no matter what client you fill the form in, it’s the same form. 

    Be a Better IPFS Admin with this Knowledge

    Our hope is that this article will make our behavior more clear and expose a few tricks to help you be better Administrators.  Here are a few tricks in how to use that information to your advantage.

    Handle the error:  “Form template was deployed as part of the 9b518781-2fcd-40fe-a1f4-964b2cd4c0b8 feature”

    If you receive this, you most likely want to remove the form template and start over.  Here’s the action to take, and it’s only available from the command line:
    "%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\12\BIN\STSADM.EXE" -o uninstallfeature -filename 9b518781-2fcd-40fe-a1f4-964b2cd4c0b8\feature.xml

    Form template’s status never leaves “Upgrading…” or “Removing…” states

    These states seem to indicate that you're running a multiple-machine server farm, and on your server farm, you're running into some issues in propagating changes to all of the machines.  If you have not done so already, I highly recommend turning on the following services on each machine: SPAdmin, and SPTimerV3 You can do this by running:
                    net start SPTimerV3
                    net start SPAdmin
    On each machine.  Net start is a ensure semantic, so this will not inadvertently toggle or cause any damage if run on a machine where the service is already started.  Now that that's done, you can go on to correcting the problems that you have.

    From Central Administration, go to the Operations page, under the Global configuration group, click on Timer Job Status.  On that page, look for timer jobs that have the name in the following formatting.  If you filename is FOO.xsn, it will look like:
    Windows SharePoint Services Solution Deployment for "form-FOO.wsp"

    See if there was a failure.  If so, go back a page, and go to Timer Job Definitions.  Drill down in the timer job definition that you care about and you can perform the following:

    >> For the case of status stuck on “Uploading”:
    1.       Try to restart the job if that is available.
    2.       If restart is not available, delete the job, then attempt to upgrade again.

    >> For the case of status stuck on "Upgrading":
    1.       Try to restart the job if that is available.
    2.       If restart is not available, delete the job, then attempt to upgrade again.

    >> For the case of status stuck on "Removing":
    1.       Try to restart the job if that is available.
    2.       Else, Remove the job. (continue to step 3)
    3.       Then, go back to the Manage Form Templates and try again to Remove the form template.

    Ed Essey
    Program Manager
    Alexei Levenkov
    Software Design Engineer
  • Microsoft InfoPath 2010

    Do it anyway: Submitting with Data Validation errors

    When building a workflow solution using InfoPath, it is often necessary to enforce data validation for some, but not all users. For example, in a simple expense report workflow, Employee->Manager->Accounting, the manager may be required to specify the cost category. The employee, however, can't provide this data. This means that setting the "cannot be blank" property for the costCategory field in the InfoPath form will not be enough to make this work. In this article, we will explore a technique that will let you use powerful InfoPath data validation capabilities to enforce this business logic correctly.
    You may have seen a different incarnation of the same problem - "if only I could submit the form with data validation errors...". If so, read on.
    1. Create a node in your data source that remembers the role of the current user; let’s call that node userRole. Create rules or code to get that node populated on load of the form.

      Trick 1 - acquiring user role. To set the value of a node to the current user role in rules, use the XPath expression xdXDocument:get-Role().

      Trick 2 - acquiring Active Directory username.  If you are using InfoPath 2007, you can get to the username of the current user through the built-in userName function. In InfoPath 2003, the easiest way to accomplish this is to write a simple whoAmI web service (here is a sample implementation), and plug it in to your form template through a secondary data connection.

    2. Setup data validation logic on the costCategory field by using the Data Validation dialog (not through the “cannot be blank” shortcut in the properties dialog).

    3. Add a new "logical and” clause to the data validation condition. This clause will check if the userRole actually requires the field to be filled out. The entire data validation condition will evaluate to false if the userRole doesn't have this requirement, and the error message will not be shown:
    This technique will work in both InfoPath 2003 and InfoPath 2007, and it is supported in browser-enabled form templates.
    Alex Weinstein
    Program Manager
  • Microsoft InfoPath 2010

    Browser Forms with Spell Check

    With InfoPath Forms Services, you can take powerful InfoPath forms, and allow users to fill them out by using a browser. This enables your forms to reach more customers than ever before. Many Office users have been enjoying the convenience of spell check in Word and InfoPath. To enable this valuable feature for browser forms, we recommend pointing your customers to an Internet Explorer extension called ieSpell. It will check the spelling in your document, just like you would expect it to; you even get to store your personal word list or (clever!) point ieSpell to a Microsoft Office dictionary.
    After filling out a form, hit the ieSpell button and it pops up a dialog, similar to the Microsoft Office spell check. If you want to know the meaning of the word, the thesaurus is just a click away.
    Installing the program is quick and easy. Download from here (free for non-commercial use). When you're done, you will see a new button in the IE toolbar, as well as a new Tools menu item.
    If you are interested to learn more about ieSpell and other browser extensions, take a look at this article from the Internet Explorer team blog.
    Pradeep Rasam
    Program Manager
  • Microsoft InfoPath 2010

    Complex Data Validation

    How do you test more than 5 parameters? How do you group parameters? One answer to both questions, is to have multiple validations in one statement. We'll look into these problems in detail in the case studies below.

    Case Study #1

    Problem: a form designer wants to use this logic:

    IF (State="Ohio" or State="Alabama" or State="Arizona" or State="Georgia" or State="Utah" or State="Idaho" or State="Iowa") THEN (fail...)

    Since the Validation UI only supports 5 statements, you run out of room before entering all of the tests.

    Solution: Put more than one test in a statement. If you aren't sure of the syntax, follow along.

    Enter the first three tests.

    Click [OK] to close the dialog. Notice that the syntax is displayed in this dialog:

    Click [Modify] and use this syntax.

    When you change the first column to "The expression", you will see how to refer to the field you are checking. This differs depending on if you are checking the current field or a different field. In this case, State is the selected field, so we can enter the validation like this:

    If you OK this and then come back to it, InfoPath will automatically break out the last 4 tests into separate statements. This makes it easier to see more of the conditions that are being evaluated.


    Case Study #2

    Problem: a form designer wants to use this logic:

    IF (State="Ohio" or State="Alabama") and TaxRate is blank THEN (fail...)

    Using just the default Validation UI, you can't group tests like this.

    Solution:  Put more than one test in a statement. Again, if you aren't certain of the syntax, enter the tests in the Validation dialog:

    Click [OK] to close. Note the syntax in this dialog:

    Click [Modify], and use the syntax shown in the Validation statements.


    Alternative Approach

    Another way to handle both of these scenarios is to use multiple validations:

    This will work and in some cases would be easier to follow (the 50 states could be listed and you could scroll the Validations).

    Performance may be better in one or the other, but that would depend on the logic you are validating.

    All of these statements are evaluated. There is not an implied "and" or "or" combining them. In this last example, if you were checking the "State = ...  OR TaxRate is blank", both would fail. You could check the number of errors and would get 2, even though only 1 error message would be shown (the first one).

    Jerry Thomas
    Software Design Engineer in Test

  • Microsoft InfoPath 2010

    IE7 is here


    Our friends from the Internet Explorer team are celebrating a major milestone - the release of Internet Explorer 7. You all know about the great features it brings to browser users (security, performance, ease of use); you may have seen them first-hand by trying out their Release Candidates.

    You may be wondering - how does this affect InfoPath? From the first look, there shouldn't be much connection, but there is.

    InfoPath ‘s editing surface is built on top of Internet Explorer. This means that most things that you see when you fill out an InfoPath form are, really, just clever HTML elements. Internet Explorer 7 brings improved implementations - thus, InfoPath users will benefit from the IE7 install, too.

    Some specifics:

    • IE7 provides a windowless SELECT control, which brings better performance for InfoPath forms that use the Drop Down List Box, List Box, or Combo Box controls .
    • IE7 offers full type-ahead support for dropdowns: for example, if a dropdown contains {"apple", "banana", "orange"}, then typing "ba" with the focus on the control will take you to "banana". InfoPath inherits this perk.
    • Overall rendering performance is improved
    • Many InfoPath crashes are fixed

    This list is relevant for InfoPath 2007. InfoPath Forms Services will benefit just like any other web app.

    Bottom line: if your organization uses InfoPath, the returns on deployment of Internet Explorer 7 will be even greater! IE7 will be distributed as a public update; if you can't wait (and I personally couldn't - I downloaded the final release of IE7 the minute I found out it was available), get it here.

    Alex Weinstein
    Program Manager

  • Microsoft InfoPath 2010

    Hosting InfoPath forms in a custom ASPX page


    Many of you saw a detailed MSDN article on embedding an InfoPath XmlFormView control into a custom ASP.NET page. But - there's more to it. I came across an interesting blog post that talks about embedding a browser-based InfoPath form into a webpart. Here's another post of someone who got it to work, with nice screenshots.

    Alex Weinstein
    Program Manager

  • Microsoft InfoPath 2010

    Awesome blog on InfoPath


    I've been on a hunt for cool InfoPath-related blogs; well, I just found a gem. Shoutout to Liam Cleary whose blog talks about SharePoint, VSTO, Groove, and, of course, lots and lots of InfoPath. I loved all the screenshots and detailed walkthroughs. Some highlights:

    1) Article on Word import - a walkthrough of a new feature in InfoPath 2007 that allows converting Word documents into InfoPath form templates.

    2) Very interesting article on picking the right technology for your project: Word + VSTO or InfoPath.

    Alex Weinstein
    Program Manager

  • Microsoft InfoPath 2010

    Aggregation: and many became one...


    In InfoPath 2003, forms were equipped to merge in a simple manner: repeating sections and tables would merge to form one, as would the contents of lists or rich text controls. The remainder of the form was not merged. This functionality proved useful for many scenarios, but there was much more that could be done. Unfortunately, the only way to do it was to write your own merge XSL. So, in InfoPath 2007, we’ve enabled options that allow you to customize a form’s merging behavior.

    Merge settings are now available in most fields’ and controls’ Properties dialogs. For fields, you’ll find Merge Settings under the Rules and Merge tab. For controls, under the Advanced tab. The available options will differ based on the settings that are available for each type of field. Here’s an example of options available for repeating fields and groups:

    Notice that you can select the order of the merged items as well as whether to combine entries based on a matching value.

    Merge settings for rich text fields vary somewhat from the repeating group ones shown above:

    One of the most useful options is being able to prefix each merged item with some value. For example, if you’re merging status reports from different members of your team, you may want to prefix each entry with the name of the person submitting the report. This’ll ensure that you can keep track of who said what. You can even add fancy formatting for your visual pleasure.

    Changes to the OM

    In the new InfoPath OM, you will see some changes with regards to merging: there is now only one merge event, called – surprise, surprise – Merge. In InfoPath 2003, there were two events: OnMergeRequest and OnAfterImport. The new Merge event has taken the place of the old OnMergeRequest event. We have chosen to deprecate OnAfterImport because there’s no real need for it: InfoPath code executes sequentially, so any code that would have been included in the OnAfterImport event can be placed directly after the XmlForm.Merge() call that actually performs the merge.

    Using InfoPath 2007 to set merging on your InfoPath 2003 forms

    Because InfoPath strives to achieve backwards compatibility, any form template you design in the InfoPath 2007 designer can be saved as an InfoPath 2003 form template. This will allow users that don’t have the newer version of InfoPath to fill out your form.

    Even though the ability to specify how your form will merge is a new feature in InfoPath 2007, InfoPath 2003 already had the infrastructure in place to make it work. In fact, if you knew how to write the appropriate XSL stylesheet, you could have created all the specific merge functionality that is now permitted through the UI.

    So, bottom line, all the fancy merging work that you do while designing your form in InfoPath 2007 will be respected when you save your form template as InfoPath 2003 and have users with InfoPath 2003 fill it out.

    - Bojana
    Program Manager

  • Microsoft InfoPath 2010

    Two excellent InfoPath resources


    I just came across two great InfoPath resources:

    1. A series of articles by Christopher Domino (12 detailed articles so far!). Christopher's articles look deeply into many InfoPath aspects, from "declarative logic vs code", deployment approaches, and backend integration discussions to detailed code dive-ins. Highly recommended.
    2. has a few interesting InfoPath articles; I particularly liked their review of the Logic Inspector (new InfoPath 2007 feature that offers an easy way to debug form logic) and the walkthrough on how to invoke BizTalk orchestrations using InfoPath.

    Alex Weinstein
    Program Manager

Page 1 of 1 (13 items)