InfoPath Dev

Eventually got my infopath form to submit data to a SharePoint list. I found that unless I removed the form's code, re-injected then reset the send data connections it wouldn't work. Anyway, my question is now that I have it working using the InfoPath client is there any reason it shouldn't work as a published browser form? The form is published using Central Admin, the form renders with no problems but on submission it does not create the remote SharePoint list items (or provide any error). Is this a supported use case for the SubmitToSharePointList function? The same form is working fine in the client tool. Lastly, great solution, little tricky to use the first time with so many steps, looking forward to the next version (with delete hopefully!). Using the trial right now but expect to purchase in the next day or two. Thanks.

Subsequent to my last message I am now getting the following error returned: An unexpected error occurred executing the rule. Action: SubmitToSharePointList Arguments: System.Collections.Generic.Dictionary`2[System.String,System.String] Details: The remote server returned an error: (401) Unauthorized. Stack: at Microsoft.Office.InfoPath.Server.DocumentLifetime.OMExceptionManager.ExecuteOMCallWithExceptions(OMCall d, ExceptionFilter exceptionFilter) at Microsoft.Office.InfoPath.Server.DocumentLifetime.OMSecurityContext.ExecuteOMCall(Solution solution, SecurityLevel methodSecurityLevel, ExceptionFilter exceptionFilter, OMCall d) at Microsoft.Office.InfoPath.Server.DocumentLifetime.WebServiceConnectionHost.Execute(XPathNavigator input, XPathNavigator output, XPathNavigator errors) at Qdabra.Tools.RulesLibrary.Commands.UploadData(String siteUrl, DataConnection dc) at Qdabra.Tools.RulesLibrary.Commands.SubmitToSharePointList(String submitDs, String mappingDs, String id) at Qdabra.Tools.RulesLibrary.Commands.ExecuteCommand(Application application, XmlFormHostItem formHost, XPathNavigator commandsNavigator)

Hi -- is the list you are submitting to on the same SharePoint server as the one your form is published to? Actually, since it works in client, I'd expect it to work in browser -- as I recall, we tested that scenario. Let me check with our test team to find out if they know anything about potential pitfalls using this in the browser, okay?

Thanks. The list is on the same site collection and same sub site as the form library itself. It works reliably in the client but fails using forms server. I wondered if it might be a LoopBackCheck issue but it is already disabled in the registry, it's running on Server 2008.

Hi, Alistair – we did test this command successfully in IPFS. I’m not certain why you’d be seeing a difference in behavior between client and browser…. We didn't need to use UDCX either, as the form's published in the same server as the list it was submitting items to.

We've tested on Server 2003 and MOSS 2007 though. We can double check on Server 2008, but if you have any other details about your environment that might help up investigate, please let us know.

Cheers!

Environment wise it's a server farm which does use ISA for external users and the Service Accounts are setup using a least privilege model. I've tried setting up host files to ensure the web service traffic from IPFS is not going through ISA. Disabled any loopback check. At this point I've fallen short of sniffing any net traffic to see exactly what requests are going where. The least privilege model might be an issue, I haven't looked exactly what accounts are setup for IPFS yet. Thanks.

For the server side submit, you will want the data connection to use the internal url and not the public url.  Are you using an Alternate Access Mapping for the external users?

The web app uses the same public URL for both internal and external users. There is some complexity around external users AAM, but I've isolated testing on the server with a hosts file to remove ISA from the equation and still have the same 401 failures.