Calling Web Services From InfoPath Web Forms

  • Article

Today I needed to get an InfoPath Forms Services web-form to make a call out to a web service. I was non-too pleased to get a cryptic error message from SharePoint when I tried to do this first-off. SharePoint claimed it had written details of the error to the Windows Event Log, but there was nothing to be found there L

Instead I trawled the SharePoint log files and found details of an exception caused by cross-domain data-access not been permitted. Then it was fellow bloggers to the rescue as Joris has a very helpful post explaining that there are in fact two steps required to enable Web Services to work in InfoPath web forms:

  • First make sure that cross domain access is enabled for InfoPath Forms Services - Go to SharePoint Central Admin > Switch to the Application Management tab. Underneath InfoPath Forms Services - Choose Configure InfoPath Forms Services. Check "Allow cross domain access for user templates"
  • Use the Data Connection Library to store the connection setttings to the web service. A Data Connection Library (DCL) is a new type of SharePoint document library which provides a place to store, manage and share connection files. For more info about DCLs - check out Excel Services part 10: Data Connection Libraries, or connecting to databases made easy, manageable, and secure . Open your your locally saved InfoPath 2007 form in Design View. Select Tools - Data Connections. Select your web service connection and click the Convert button. For the name enter something like https://servername/DataConnectionLibName/WebService.udcx (Ignore the warning that you get ... this will be fixed in post beta2 builds) Once the connection has been converted to a data connection file, save the form locally again and publish it to the SharePoint forms library.

The first step makes sense, but why do I need to store a UDC in a Data Connection Library? A couple more searches turned up two great posts from Nick Dallet on the InfoPath Team blog. The first post explains exactly why. The short answer is that it is because HTTP is stateless InfoPath can't interrupt server-side code execution to go back and prompt the user to authorise the cross-domain call. Using a UDC enables this decision to be placed in the hands of the SharePoint administrator at deployment time.

Nick's next article goes on to explain details of UDC files and this bit stood out for me: How you can use the SharePoint SSO (Single-Sign-On) service to pass credentials to the web service you are calling.

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:

Value

Description

Sql

Credentials will be embedded in a database connection string for authentication against a SQL server.

NTLM

Credentials will be used to impersonate a Windows user

Kerberos

Credentials will be used to impersonate a Windows user using Kerberos

CD

The username will be used to impersonate a Windows user using Constrained delegation

Basic

Credentials will be used to perform HTTP Basic authentication

Digest

Credentials will be used to perform HTTP Digest authentication