Qdabra Database Accelerator

Re: Problems with calling QdabraWebService

Jim Cantwell — Thu, 02 May 2013 17:22:39 GMT

There are multiple ways the SSL site may have been configured.

1) An extension site, which will have its own site in IIS.

2) Port 443 could be added to the SharePoint site, and you add an alternate access mapping with the host name (forms.corp.integris-health.com)

3) An ISA server or similar forwards external traffic to the server on the 33333 port.

If the site url dropdown, you may find NSBMDSP12:443. This is what you would want to select. If it has a host name defined, that will be automatically used. If the host name is not specified, you can enter forms.corp.integris-health.com for the host name.

An issue that may arise is that forms.corp.integris-health.com is not resolving to the local server IP address. You can check this by logging onto the server and pinging the hostname. If it resolves to the local server IP, no change is needed. If it resolves to a load balancer, you will need to add an entry in the hosts file to point it to 127.0.0.1. Without this, web service calls from the InfoPath forms going to forms.corp.integris-health.com will be treated as a machine-hop and user credentials will not be passed for the connection.

Re: Problems with calling QdabraWebService

TomRenfro — Thu, 02 May 2013 14:59:02 GMT

I'm trying to reinstall DBXL to the secured site, but it's throwing an error and I can't pick SSL. I'm attaching a screenshot. The error is "Hostname must resolve to a local address." I'm not sure how to get around this, and now DBXL is uninstalled.

The site I need to apply to is an alias that's secured by discrete certificate, and needs to be https://forms.corp.integris-health.com.

Re: Problems with calling QdabraWebService

Jim Cantwell — Thu, 02 May 2013 05:25:25 GMT

If all users can access the secured site, it is best to uninstall DBXL and then reinstall to the secured site using the existing DBXL databases. Then resave all your doctypes in the DBXL DAT tool so that the XSNs DBXL data connections point to the extranet.

SharePoint also does some auto transformation of urls when you have alternate access mappings. So if a form is accessed from the extranet on the secure site, data connections pointing to the local site will get transformed to the extranet site url. If a data connection points to a url not listed in the alternate access mappings, that url will remain unchanged. One trick is to add another port to the site in IIS, say 44444, you can prevent the data connection from getting swapped. But doing this has management issues, especially if using multiple WFEs.

As you noted, running in the sandbox has slightly different behavior. The SharePoint and IIS logs should allow you to see what url and identity is being used when the connection fails.

Re: Problems with calling QdabraWebService

TomRenfro — Wed, 01 May 2013 13:58:15 GMT

Thanks for the reply Ernesto. My guess about injection, and this is purely speculation, is InfoPath Forms Services sandboxes the injected forms. This might be why the perceived double hop is mitigated on the first iteration. Just a theory.

I'll send a response via support so we can get this configured correctly. I didn't set the site up, and it's what I have to work with.

Thanks again, and look forward to hearing from you. I'll reference this URL in the request.

Re: Problems with calling QdabraWebService

ErnestoM — Wed, 01 May 2013 13:48:23 GMT

It would seem to me that if the users are accessing forms via https://mysite.corp.org.com/ and the forms are configured with web service connections to http://mysite:33333/QdabraWebService, issues are bound to arise. During installation, in the Site tab it is possible to change the URL users will use to access the web service (even if you can't change the site from the dropdown options), so perhaps a closer look at the server set up and DBXL installation is necessary.

I also don't see a reason why the qRules injection would make a difference.

If you'd like, please contact us via support at qdabra dot com and we can help you look at the installation/configuration and address these issues. Thank you.

Problems with calling QdabraWebService

TomRenfro — Tue, 30 Apr 2013 19:46:19 GMT

Hi all.

Again, I'm revisiting the dreaded "5566" web service error when trying to call QdabraWebService, mostly making calls to GetUserInfo. A little background is in order:

The way our SP farm is configured currently, the direct address to SharePoint 2010 is unsecured and installed as a separate site, i.e. http://mysite:33333/Publishing. We have a secured reference to the site, with a corresponding certificate, which is https://mysite.corp.org.com/Publishing. This secured connection references the aforementioned site application.

When installing DBXL, which includes the Active Directory Web Service QdabraWebService, my only installation choice was to the direct site application. I couldn't install to the secured site. So, in order for my web service calls in InfoPath to work, I referenced them via the unsecured URL. At first, none of my web service calls worked. They all threw the "5566" error with very little to find in the server logs. I noticed, however, that forms injected with qRules didn't have that issue. So, for baseline web service calls, whether I use qRules or not, I inject all forms. This seemed to alleviate the issue on initial form rendering and submission.

Here's where it gets interesting. If I have secondary web service calls, such as workflow approvals, after the form is initially submitted to the form library, when logged in the library under the secure URL, the call fails with the "5566" error. If I'm accessing the same site and the same form, only via the unsecured, direct URL, the call works without issue.

I just can't figure out how to get around this issue. I don't know if DBXL is installed incorrectly, I'm fairly sure the certificate URL and actual farm configuration don't exactly match up. Any viable workarounds or solutions would be greatly appreciated. Thanks in advance.