I recently ran across an interesting issue where InfoPath forms were calling OOB SharePoint 2010 web services. In particular, these forms contained one or more fields which called SharePoint OOB web service. These forms were published to web applications configured with Claims Authentication. Opening this form works fine as long as you open the form using InfoPath on the client. When attempting to view the form in the browser the following error occurs:
Subsequently, you will see an error like the following in the ULS logs:
The following query failed: GetUserProfileByName (User: email@example.com, Form Name: otherForm, IP: , Connection Target: , Request: http://wfe1.contoso.com/_layouts/FormServer.aspx?XsnLocation=https://wfe1.contoso.com/sites/siteA/FormServerTemplates/IT WAR.xsn&SaveLocation=https://wfe1.contoso.com/sites/siteA/ITWARdir&ClientInstalled=t=1, Form ID: urn:schemas-microsoft-com:office:infopath:FormLib:-myXSD-2012-07-12T16-05-43 Type: DataAdapterException, Exception Message: The remote server returned an error: (500) Internal Server Error. Server was unable to process request. ---> Attempted to perform an unauthorized operation. The remote server returned an error: (500) Internal Server Error.)
The quick answer is this is a limitation of InfoPath Form Services not being claims aware.
Basics of Building InfoPath Forms that call Web Services
Before discussing any workarounds, I’d like to provide a brief overview of calling SharePoint web services within an InfoPath form. First, you always start off with an InfoPath form template which is an .xsn extension and you add labels and controls.
On the left we have labels to provide a description of each field. On the right we can insert controls like a text box for example.
Note: The far right fields represent the controls I’ve inserted on the left which is why I have 3.
Assuming you want to call the UserProfile web service to automatically retrieve and populate the control next to User Name, define a Data Connection within InfoPath to this web service.
Question: So how do you setup a Data Connection to call an OOB SharePoint web service? Answer: An excellent blog walks you through this process. Click Here!
Also, field1 is bound to the data connection pictured above:
Publish the form template to a SharePoint Form Library
The final step is saving the template and publishing it to a Form Library on the desired Site Collection.
1. Select File, Publish, Publish Form to a SharePoint Library 2. Follow the publishing wizard and enter URL of the Site Collection and click next 3. Check “Enable this form to be filled out by using a browser” and select Form Library, click next 4. Create a Form Library or choose from existing and click next 5. Click next and then Publish
This basic method of publishing InfoPath forms works fine with Data Connections but it doesn’t work well when publishing the form to Claims based Web Applications if the data connections are used to call SharePoint web services.
Update the web service URL in the data connection to call a Web Application configured to use Classic Authentication.
The form must make calls to a different web application configured with Classic Windows Authentication.
Both Web Applications reside in the same farm. Web Application A (Claims Based Authentication) Web Application B (Classic Windows Authentication) InfoPath Form is published to Web Application A The published form calls OOB SharePoint web services on Web Application B
If the form must make web service calls across Web Applications, the following must occur:
(This step is necessary but not listed below) Provision a new web application with Windows Classic Authentication
1. Update the data connection web service URL to call the Web App URL’s configured with Classic Auth 2. Create a data connection library in a given site collection 3. The data connection must be converted to file of type UDCX and published to a Data Connection Library 4. Download the UDCX from the data connection library and edit it 5. The form must be full trusted and published locally 6. The form template and data connection file are uploaded to SharePoint Central Administrator 7. Adjust configuration settings within Central Admin InfoPath Forms Services 8. The form template is then activated to a Claims Web App\Site Collection 9. Test to ensure it works without error
Detailed Steps are below
Note: I assume you know how to provision a new web application with classic authentication so skipping this step but make sure you have one provisioned.
1. Update the data connection web service URL to call the new Web App URL configured with Classic Authentication
a. Open the form template (.xsn) with InfoPath Designer 2010
b. Select Manage Data Connections on bottom right under actions and select Modify on the data connection and update the web service endpoint to the Classic Web App URL
c. After clicking next, select the web service method which in this case I chose GetUserProfileByName and click Next. d. Click Next through the next couple of prompts until you get to here:
e. Ensure you leave Automatically retrieve data when form is opened checked and click Finish
2. Create a data connection library in a given site collection
a. This is for temporary usage and can be deleted at the end of these steps b. For a site collection select Site Actions\More Options Filter by Library and Choose Data Connection Library c. Name it and click Create
3. The data connection must be converted to file of type UDCX
a. After clicking Finish on step 1, select Convert to Connection File
b. Enter the URL + filename of the Data Connection Library you created from step 2 and hit OK
Now the udcx file is converted and stored in your data connection library:
4. Download the UDCX from the data connection library and edit with notepad
a. Download the UDCX file from the Data Connection Library you uploaded b. I put mine in c:\IPStuff c. Edit the UDCX File locally and add\save the following:
<udc:Authentication> <udc:UseExplicit CredentialType="NTLM"> <udc:UserId>domain\user</udc:UserId> <udc:Password>password</udc:Password> </udc:UseExplicit> </udc:Authentication>
Note: Ensure you use an account name and password with appropriate permissions to the remote web app
5. The form must be full trusted and published locally
a. Within the Form, select File, Info and Choose Form options b. Ensure you uncheck “Automatically determine security level and choose Full trust and Click OK
c. Select File, Publish, and choose SharePoint Server d. Type a URL for a form library (we won’t actually publish it to the library), click next e. Ensure you leave “Enable this form to be filled out by using a browser” checked and click next
(See the following screenshot)
f. Next specify a location on the local drive with a filename.xsn extension
g. Hit next through the next few prompts and then click finish.
6. The form template and data connection file are uploaded to SharePoint Central Administrator
a. Upload the form template saved from step 4 to Central Administrator\General Application Settings\Upload Form Template. b. Browse to form and click Upload c. Upload the data connection (UDCX file) to Central Administrator\General Application Settings\Manage Data Connection Files d. Select the file and ensure Allow HTTP Access to this file is checked and click upload
7. Adjust configuration settings within Central Admin InfoPath Forms Services
a. Access Central Administrator\General Application Settings\Configure InfoPath Forms Services b. Check the following options:
Check: Allow users to browser-enable form templates Check: Render form templates that are browser-enabled by users Check: Require SSL for http authentication to data sources Check: Allow User form templates to use authentication information contained in data connection files Check: Allow cross-domain data access for user form templates that use connection settings in a data connection file
It should look like:
c. Finally hit OK
8. Activate the form to a Site Collection hosted by a Claims Based Web Application
a. Access Central Administrator\General Application Settings\Manage Form Templates b. Select the new form template and Activate to a Site Collection
c. Choose the appropriate site collection and hit OK
9. Test to ensure the form works without error
a. Test by going to the targeted site collection’s formservertemplates:
For Example: https://siteA/formservertemplates
b. Choose edit in browser for the newly published form.
In the screenshot above, my form was published to claims based web application at site collection:
The form opened in the browser and the User Name field was correctly populated the FirstName attribute after calling the UserProfile web service that is hosted by the Web Application configured with Classic Authentication
Note: It might fail the first couple of times but after 2 minutes or so it works fine which I assume is a result of the application pool spinning up.
Question: Why can’t I just update the Form’s Data Connection to point the web service URL endpoint to the Classic Windows Auth Web Application and republish it back to the original location which is a Site Collection\Form library on the Claims Based Web Application?
Answer: In order to call a web service on a remote Web Application the InfoPath form must be fully trusted. Forms that are fully trusted require administrator approval and thus must be published to Central Administrator.
Question: Why do I need to convert the data connection to file? Answer: Because in order to make “cross-domain” connections you must use a data connection file.
Question: Do I still need the Data Connection Library created from Step 2 above? Answer: No, it was a temporary holding place so now that the data connection file is stored on Central Admin, you can remove it from the site collection if it’s no longer needed.
http://blogs.msdn.com/b/infopath/archive/2006/10/02/data-connections-in-browser-forms.aspx http://blogs.msdn.com/b/bowerm/archive/2006/12/06/calling-web-services-from-infopath-web-forms.aspx http://blogs.microsoft.co.il/blogs/itaysk/archive/2007/04/05/InfoPath-_2D00_-Get-the-current-user-without-writing-code.aspx http://technet.microsoft.com/en-us/library/cc262921.aspx
Russ Maxwell, MSFT