InfoPath Dev

I've always used the InfoPath function userName() to return the ID of the logged on user in my forms. This works fine in InfoPath forms and in SharePoint rendered forms.

Recently, I decided to investigate the use of SOAP Web Services (specifically GetUserProfileByName) so that I could return more information about the logged on user. I was surprised to discover that this was pretty straightforward to setup and within a few minutes I was able to return other data about the user like first name, surname, manager etc. So far so good. This test was done within InfoPath and (if previous experience is anything to go by) I knew I need to re-test my form again once published to SharePoint. Did it work? Of course not! I got the dreaded 5566 error:

"An error occurred while trying to connect to a Web Service"

A search of this board (and the internet in general) tells me that over the years many people have seen this error and various strategies have been suggested.

The security setting of my form is "full trust" and was published using the "admin approved" functionality. This form was then uploaded via Central Admin and activated  to my site collection (let's call it http://servername/sites/site1.

I have a child site under site1 (let's call it site2). In site2 I have created a form library (which allows management of content types) and told it to use my InfoPath form. When I select File, New in this library my form appears along with the previously stated error message and a suggestion to look at the Windows Event Log for more details. The event log has the following information:

The following query failed: GetUserProfileByName (User: 0#.w|<domain\<username>, Form Name: KPI-Registration-Form, IP: , Connection Target: , Request: /_layouts/15/FormServer.aspx?XsnLocation=http:///sites//FormServerTemplates/KPI-Registration-Form.xsn&SaveLocation=http:///sites///KPIActivity&ClientInstalled=true&DefaultItemOpen=1&Source=http:///sites///KPIActivity/Forms/AllItems.aspx&AjaxDelta=1">http://<servername>/_layouts/15/FormServer.aspx?XsnLocation=http://<servername>/sites/<site1>/FormServerTemplates/KPI-Registration-Form.xsn&SaveLocation=http://<servername>/sites/<site1>/<site2>/KPIActivity&ClientInstalled=true&DefaultItemOpen=1&Source=http://<servername>/sites/<site1>/<site2>/KPIActivity/Forms/AllItems.aspx&AjaxDelta=1, Form ID: urn:schemas-microsoft-com:office:infopath:KPI-Registration-Form:-myXSD-2016-10-04T14-24-55 Type: DataAdapterException, Exception Message: The custom code in the form cannot be run. This functionality may be deactivated on the server. For more information, contact the server farm administrator.

The custom code in the form cannot be run. This functionality may be deactivated on the server. For more information, contact the server farm administrator.)

This message makes no sense. There is no custom code in my form and "sandbox" is definitely not deactivated as I have other forms with code that work fine. SharePoint gives me a correlation ID and I'm sure if I could find the correct log this might give me a bit more of a clue - but which log and where would I find it?

Is it something to do with my form library being in a subsite? When I designed my site collection this seemed like a good idea but over time I wish I'd never bothered and kept everything in one site as SharePoint does not make life easy when you have a subsite and I've already fallen down lots of potholes because of it.

One other point to mention. When I created my receive data connection in InfoPath I used the following URL: "/sites///_vti_bin/UserProfileService.asmx?WSDL">http://<servername>/sites/<site1>/<site2>/_vti_bin/UserProfileService.asmx?WSDL" . I assume this is correct given my form library is in site2?

So, what more does SharePoint need? Why is life so unnecessary complicated? I almost feel like I need to set aside a day for each simple step forward. Remember those old DOS-based adventure games? Working with SharePoint is exactly like that (go North, there is a door, door is locked, you need a key, find key, try opening door, your key is red - find another key. oh, this ones yellow - will that work, damn! no! etc etc) This was fun back in the day but SharePoint should have progressed beyond this by now. :-)

I'm using InfoPath 2013 with SharePoint 2016 by the way. Does anyone know what the problem is? Thanks in advance.

 

 

 Are you 100% sure there is no code in your form? We've been discussing a form of yours in another thread - and qRules is a code DLL, so if this is the same form, it definitely has code.

 Yes, really sure. It's a brand new form. Very simple, in fact it's so basic it doesn't really do anything at the moment. No qRules injected - nothing. All it does is give me the first name, surname and email address of the logged on user using a SOAP web service request. See screen dump below. In InfoPath the form is successfully populated but not in SharePoint (the fields are blank but the form is correctly rendered). It's probably the simplest form I've ever created. :-)

 

 

Oooh, I think you have to get rid of the claims stuff before the user name when you set the user name field in the query params. https://social.technet.microsoft.com/Forums/en-US/1c21d671-8ca2-4d1a-82ab-48bf2b69a7d3/infopath-query-userprofil-webservice-in-sharepoint-2016?forum=SP2016

Hilary you're saving me so much time! That is exactly the problem. :-) Funnily enough, earlier on I was explaining to my boss about the userName() function and explaining the difference between what got returned in InfoPath and what got returned in the browser. It never crossed my mind that the same scenario would apply to using GetUserProfileByName as well. Fortunately I'm well-versed in the technique and my form is now working in the browser. Thank you so much. Without your intervention I could have been looking at this for days (even though I should have realised earlier as the error log did hint at the problem when it referenced the userid query using the prefix 0#| mumbo-jumbo ("claims stuff"). You're my go-to when it comes to InfoPath (but you may live to regret that - just ignore me if I ask too many question). :-)

I'm just glad that was the problem - here's what I searched on from your error text to get back that post that I linked: "DataAdapterException, Exception Message: The custom code in the form cannot be run. This functionality may be deactivated on the server. For more information, contact the server farm administrator." No such thing as too many questions - I saw another post on this forum with the same question, unanswered - I'm going to add a link to this post.