InfoPath Dev

Hello,

we have the following scenario: A form with qRules gets filled in and saved on Site A. When it is saved, it also uses SubmitToSharePointList to write data into a list on site B. Both sites are in the same site collection. It works fine when we run it on our in-house network. We have extended the web application and remote users can access it via Unified Access Gateway 2010. The form is served up fine, it saves fine to Site A, but the submit to the list on site B errors out.

Here is the error message:

Failed to submit to SharePoint. URL = 'http://restore.testworld.co.nz/sites/general/dispatch/_vti_bin/lists.asmx'. Exception: Microsoft.Office.InfoPath.Server.SolutionLifetime.DataAdapterException: Unable to connect to the remote server ---> System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 172.20.1.105:443 at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress) at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Int32 timeout, Exception& exception) --- End of inner exception stack trace --- at System.Net.HttpWebRequest.GetRequestStream(TransportContext& context) at System.Net.HttpWebRequest.GetRequestStream() at Microsoft.Office.InfoPath.Server.SolutionLifetime.WebServiceHelper.CreateSoapRequestSyncInternal(XmlDocument soapRequestXml, String soapRequestString, Uri serviceUrl, String soapActionOriginalString, Int64 timeOutMillisec, DataAdapterCredentials credentials) at Microsoft.Office.InfoPath.Server.SolutionLifetime.WebServiceHelper.CreateSoapRequestSync(XmlDocument soapRequest, Uri serviceUrl, Uri soapAction, Int64 timeOutMillisec, DataAdapterCredentials credentials) at Microsoft.Office.InfoPath.Server.SolutionLifetime.WebServiceHelper.ExecWebRequestSync(XPathNavigator inputSubDOM, Boolean[] inputUseDataset, XPathNavigator resultsSubDOM, Boolean resultUseDataset, XPathNavigator errorsSubDOM, Uri serviceUrl, Uri soapAction, Int64 timeOutMillisec, DataAdapter adapter, Document document, DataAdapterCredentials credentials, Boolean useDcl, Boolean useProxy, Boolean useSelf) --- End of inner exception stack trace --- at Microsoft.Office.InfoPath.Server.SolutionLifetime.WebServiceHelper.HandleExecWebRequestException(Document document, Exception exception, ExecWebRequestExceptionState state, Byte[] exceptionResponse, Ids errorId) at Microsoft.Office.InfoPath.Server.SolutionLifetime.WebServiceHelper.ExecWebRequestSync(XPathNavigator inputSubDOM, Boolean[] inputUseDataset, XPathNavigator resultsSubDOM, Boolean resultUseDataset, XPathNavigator errorsSubDOM, Uri serviceUrl, Uri soapAction, Int64 timeOutMillisec, DataAdapter adapter, Document document, DataAdapterCredentials credentials, Boolean useDcl, Boolean useProxy, Boolean useSelf) at Microsoft.Office.InfoPath.Server.SolutionLifetime.DataAdapterWebServiceSubmit.Execute(Document document, Uri soapAction, Uri serviceUrl, XPathNavigator querySubDOM, XPathNavigator resultsSubDOM, XPathNavigator errorsSubDOM, Int64 timeout, DataAdapterCredentials credentials, Boolean useDcl, Boolean useProxy, Boolean useSelf) at Microsoft.Office.InfoPath.Server.DocumentLifetime.DataAdapterWebServiceSubmit.ExecuteInternal(XPathNavigator queryFields, XPathNavigator resultFields, XPathNavigator errors) at Microsoft.Office.InfoPath.Server.DocumentLifetime.WebServiceConnectionHost.<>c__DisplayClass17.b__16() at Microsoft.Office.InfoPath.Server.DocumentLifetime.OMExceptionManager.ExecuteOMCallWithExceptions(OMCall d, ExceptionFilter exceptionFilter) LogId: 5567 Details: System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 172.20.1.105:443 at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress) at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Int32 timeout, Exception& exception) --- End of inner exception stack trace --- at System.Net.HttpWebRequest.GetRequestStream(TransportContext& context) at System.Net.HttpWebRequest.GetRequestStream() at Microsoft.Office.InfoPath.Server.SolutionLifetime.WebServiceHelper.CreateSoapRequestSyncInternal(XmlDocument soapRequestXml, String soapRequestString, Uri serviceUrl, String soapActionOriginalString, Int64 timeOutMillisec, DataAdapterCredentials credentials) at Microsoft.Office.InfoPath.Server.SolutionLifetime.WebServiceHelper.CreateSoapRequestSync(XmlDocument soapRequest, Uri serviceUrl, Uri soapAction, Int64 timeOutMillisec, DataAdapterCredentials credentials) at Microsoft.Office.InfoPath.Server.SolutionLifetime.WebServiceHelper.ExecWebRequestSync(XPathNavigator inputSubDOM, Boolean[] inputUseDataset, XPathNavigator resultsSubDOM, Boolean resultUseDataset, XPathNavigator errorsSubDOM, Uri serviceUrl, Uri soapAction, Int64 timeOutMillisec, DataAdapter adapter, Document document, DataAdapterCredentials credentials, Boolean useDcl, Boolean useProxy, Boolean useSelf). Full error node text: No error node text available.

If we enter the url 'http://restore.testworld.co.nz/sites/general/dispatch/_vti_bin/lists.asmx' into the browser, it returns the list of lists and libraries correctly, so the connection can be made through the browser, but apparently the SubmitToSharePoint command can't.

Any ideas?

cheers, Ingeborg

Hi - I've asked Jim to take a look at this post and see if has any ideas of what may be going wrong - is the form being filled out in InfoPath Filler or in the browser?

Hi,

thanks for the quick reply. It's a browser form. Injected with qRules 4.2 and admin approved. The form itself behaves fine. Just writing to the SharePoint list on the sibling site is the problem.

Are the same urls used to access the site both internally and externally?

Based on the IP:port shown in the logs, it is using SSL, but the url shows http.  This may be just part of the way UAG works.  If the UAG works like ISA, then some translation rules may be affecting the urls.

If you access the url in the browser, does it redirect to https ?

Hello Jim,

yes, the same urls work internally and externally.

I have tried to change the url to use https before I posted here, but the error returns exactly the same message, just shows https in the url.

Yes, if I enter 'http://restore.testworld.co.nz/sites/general/dispatch/_vti_bin/lists.asmx' as the url, it redirects to https when it lists the web service operations.

cheers, Ingeborg

Hi Jim,

Thanks for your assistance, to add some info from the other side of the fence, I'm the chap who looks after the load balancer (it's a Netscaler, the post I sent Inge was about UAG but the principals are the same)

We've published SharePoint externally using the standard approach (creating alternate access mappings), this excellent article explains it all nicely:
What every SharePoint administrator needs to know about Alternate Access Mappings (Part 1 of 3)

To summarise, we have created the following in AAM:

Internal URL: https://restore.testworld.co.nz
Zone: Internet
Public URL for zone: https://restore.testworld.co.nz

Internal URL: http://restore.testworld.co.nz
Zone: Internet
Public URL for zone: https://restore.testworld.co.nz

For internal clients, we have the following:

Internal URL: http://intranettest
Zone: Default
Public URL for zone: http://intranettest

Requests from external clients come in via SSL, the load balancer sends them downstream as HTTP. This generally works 'as advertised', except in this scenario when posting this form to another site. As an aside, there's absolutely no URL translation required at the gateway - we did it this way initially whilst fumbling along trying to understand SharePoint, it worked all right, but required lots of band aids. SharePoint does it all for us now, care of those AAM settings above.

I'm slightly bemused where the IP has come from (it's the right one), but it plain as day won't work, because our SharePoint web apps all use host headers exclusively. When I connect using that IP the only thing that is going to respond is IIS, not one of the SharePoint web applications on that server.

There's no cert bound to IIS, which is why you get the 'connection actively refused' error when connecting to port 443, the question I'm curious about is where it's getting this IP from. Would some data connection in InfoPath potentially have this?

My understanding of SharePoint is a bit lacking I'm afraid (and I'm clueless about InfoPath), but I hope that through me hijacking Inge's thread we can find some middle ground where we can get an understanding of this problem.

Rgds,
Stu

Bump. Any ideas, Jim?

I would think that AAM with the Internal URL: https://restore.testworld.co.nz would be problematic since you aren't actually listening on that port.

Hi - I'm wondering - when we use this command in a browser form, by default it will use the SharePoint object model. There is a qRules data source field you can use to override this behavior - it is in the Form group - /QdabraRules/Form/@useWebServices

Could you try setting that node to true and then see what happens when the command is executed? You can either set a form rule to set the node to true, or just temporarily put it on your form and check the box. If @useWebServices is true, the form should use the web service data connection to actually perform the submit, rather than using the SharePoint object model. I think it would be worth a try in this scenario.

Do you have restore.testworld.co.nz in the hosts file mapping to the local server?  If it gets directed to the load balancer, it may be causing problems.  When the request is processed from the form code, the urls should be connecting to the local server handling the request.

Thanks, Hilary. While trying to give that a go, I see the following:

- When I drag the @useWebServices field onto the form and preview the form, the check box is ticked. But when I inspect the field, its default value is FALSE. How can that be?

- I can use the FormLoad rule to change the value, but I cannot tick the box on the form.

That also applies to the ExtendErrorMessage field. I can drag it to the canvas, but I cannot tick the box, since the control is grayed out. According to the properties the field value should be FALSE, but the box is ticked.

 What am I missing?

 Edit: Found the reason for the TRUE setting: The FinishedLoading field has an action to set the @useWebServices field to TRUE

Can you send me your form? You have my email address, I believe?

Explanation for the grayed out check boxes: The view that I added the qRules fields to was set to read only. Duhh.

I'll try to set the @useWebServices to FALSE, since so far it was always set to TRUE by the action on the finishedLoading field.

Oh, that explains it. So you have been using web services - well, it seems like trying not to may be worth a shot.....

Success. Setting @useWebServices to FALSE did the trick.

Problem solved.

Thanks Hilary and Jim!!