Tuesday, May 19, 2015

Call SharePoint 2010 web services within browser based InfoPath 2010 forms?

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:

clip_image001

Subsequently, you will see an error like the following in the ULS logs:
The following query failed: GetUserProfileByName (User: 0e.t|exo-sts|user1@consoto.com, Form Name: otherForm, IP: , Connection Target: , Request:http://wfe1.contoso.com/_layouts/FormServer.aspx?XsnLocation=https://wfe1.contoso.com/sites/siteA/FormServerTemplates/ITWAR.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.
For Example:

clip_image003

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!
After reviewing the blog above, I assume you know how to build a basic data connection to point to a SharePoint web service. Now clicking on Manage Data Connections in my InfoPath form:

clip_image004

Also, field1 is bound to the data connection pictured above:

clip_image005

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.

Work Around

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.
For Example:
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
For Example:

clip_image007

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:

clip_image008

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

clip_image009

3. The data connection must be converted to file of type UDCX
a. After clicking Finish on step 1, select Convert to Connection File

clip_image010

b. Enter the URL + filename of the Data Connection Library you created from step 2 and hit OK

clip_image011

Now the udcx file is converted and stored in your data connection library:

clip_image013

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:

domain\user
password

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

clip_image015

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)

clip_image016

f. Next specify a location on the local drive with a filename.xsn extension

clip_image017

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

clip_image019

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:

clip_image021

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

clip_image022

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

clip_image023

b. Choose edit in browser for the newly published form.

clip_image025

In the screenshot above, my form was published to claims based web application at site collection:
https://smokewfe
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.

Q/A section:
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.


Resources:
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

Thursday, April 9, 2015

Switching views after submit InfoPath Form 2010

How to redirect users to a certain page after they have filled out a browser enabled form with InfoPath  2010 to SharePoint 2010 form library?


Scenario:  You designed a InfoPath 2010 form and published to SharePoint 2010 library.  When user submit the form you don’t want them to see the document library which contain all the submitted form.
How to redirect users to a different page in InfoPath form 2010? 


1. Copy your InfoPath 2010 form URL:


Go where it says Source= and remove everything to &DefaultItemOpen=1


Add your URL which you want your users to go after submitting InfoPath Form 2010.  In this case, after user submit the form, they will be redirected to HR Page.


Friday, February 6, 2015

Quick Fix For “There has been an error while loading the form”

I’m testing a custom SharePoint Designer 2010 activity this fine Sunday afternoon and I was unexpectedly hitting a “Critical Error” when trying to launch the workflow:

There has been an error while loading the form.
Click Start Over to load a new copy of the form.  If this error persists, contact the support team for the Web Site.
Click Close to exit this message.
Show error details


Of course, if you click the “Show error details” button all it does is show you a correlation ID:


* In my case, this turned out to be an Alternate Access Mappings problem.

* I looked at the log file in the 14 hive and saw that InfoPath was complaining about an AAM issue (since I was hitting Localhost instead of the server name).  I changed my URL and that solved it.
Ex :

* Here the problem in this case was with the URL. First I was giving the below URL:
http://win-pfcp2dgt8di/_layouts/15/FormServer.aspx?XsnLocation=http://win-pfcp2dgt8di/MyTestFormLib/Forms/template.xsn&SaveLocation=http%3A%2F%2Fwin-pfcp2dgt8di%2FMyTestFormLib&ClientInstalled=false&DefaultItemOpen=1

Then I gave the below URL and it is working now.

http://win-pfcp2dgt8di/_layouts/15/FormServer.aspx?XsnLocation=http://win-pfcp2dgt8di/MyTestFormLib/Forms/template.xsn&OpenIn=browser&SaveLocation=http://win-pfcp2dgt8di/MyTestFormLib
It does to show that with all the linkings of the various bits now in SP 2010, the thing you naturally this is a problem (SharePoint Designer workflow in my case) is actually totally unrelated to the core problem.

InfoPath 2010 – When creating a filename that breaks your submit

When using a new product a day never goes by when you don’t learn something new and today was no exception.  I’ve been working on 3 new forms and today I was making tweaks to a couple of the forms and after publishing one of them I ran into the below errors when trying to submit a new form to a form library.  The error messages that I was receiving  were really vague to for the actual problem.

InfoPath cannot submit the form.
An error occurred while the form was being submitted.
The form cannot be submitted to the following location: form library url
The site may be offline, read-only, or otherwise unavailable.
The thread is already in background processing mode.



* Then reviewed the changes that were made before it broke and couldn’t find anything wrong.  Started to look at the error messages again and when I scrolled over to the right to view full URL a light bulb turned on because

* I noticed something that a previous client had a problem with.  My filename ended with a . (period) and that’s a big no no with InfoPath forms.  The naming convention for the filename is “event name - company name” and for this instance the company name ended with a period.

* Once I removed the period from the end of company name everything worked like a charm.
* For my client we had to use a rule to search the filename for illegal characters before the form was submitted and replacing them with a _ (underscore) or just removing it all together.

The approach was used because we couldn’t rely on the users to remember not to add illegal characters to the end of the filename.