Recently for our own internal SharePoint deployment we had a request for a travel request form to be updated. The current solution was a stand alone form that was emailed the manager one submissions and then the travel team on approval. To be able to choose a manager the form used a drop down for the team and a conditional manager to associate the manager. No automation for user name or manager from user profile web service. This a long with a couple other minor tweaks were among my suggestions for this form.
In our scenario we have a SharePoint 2010 Enterprise installation with multiple site collections and web applications all utilizing claims and SSL. A typical installation for most of our clients.
Everything was going great with hiding sections and removing and replacing with new fields however when I went to use the User Profile Web Service like I have done countless times before I receive the non-descript error of “An error occurred while trying to connect to a Web service. Log ID:5566” along with a Correlation ID and other gibberish.
Looking into the SharePoint Log files did not give me much to go on. On search the webs I was able to track down a couple options for solving this issue. I came across this forum post that detailed at the end how to troubleshoot when you cannot connect in a Claims scenario. This was helpful because in most of my work I have not had to use a data connection with with InfoPath or a Secure Store application. I would either use the Username() function or the User Profile Web Service would just work.
So I rolled up my sleeves and go into doing the following:
- Create a new Secure Store Application and assigned the SPContent account. See Instructions Here.
- Move the InfoPath User Profile Web Service connection to a data connection library within SharePoint. See Instructions Here.
- Downloaded the data connection from the library (.ucdx file extension) and modified the authentication section based on the Claims scenario blog information. See Instruction Here.
- Replaced the connection in the library with the modified connection.
After all of that something was working but not how I figured. When I would set up the Travel Requestor field with the recently configured web service it ended up bringing back the SPContent user name not the current user.
After a little more research on the webs I came across a very obscure Microsoft SharePoint Forum post where Peter Newhook not only talked about the adding the Secure Store application authentication section but also how to use InfoPath to query the web service with a concat (“domain\”,username()) function. Because we were in a Claims environment I had to accommodate the use of SharePoint claims and how it modifies the Username with i:0#.w|domain. This is what I ended up coming with that finally worked.
I hope this post has been helpful with similar scenarios you come across.