Hmm, I haven't seen this specific error before and it seems like you have configured the environment correctly - thanks for confirming the whitelists are in place and working. Let me see if I am able to reproduce this issue on my end.
One thing you could try in the meantime is running one of the developer samples on your server. This could help narrow down if it's a product issue or an issue with the specific connector you are using.
Thanks for the quick reply. I will take a look at running one of the sample connectors and report back, but it will take a bit as our server sits on a box with very restricted network, and allowing new domains takes a back and forth with our network security team, so I will need to either modify them to not call external domains or get those external domains whitelisted.
Hi again Brendan,
I've been able to test the IncrementalRefreshConnector from the WDC sample kit and gotten it to work fine when I run an incremental refresh from server. This was hosted on a separate server on our internal network (similar to the problematic Presto WDC from the original post).
In the process, discovered a faulty egress proxy setting on our Dev server where this testing is being done that prevented the server from contacting the WDC correctly. However, even with this fixed, while I no longer see the "unable to load URL" error I am seeing strange behavior, as outlined below.
- Connect to the internally hosted Presto WDC from Tableau Desktop (installed on same machine as Dev version of Tableau Server to verify network connectivity).
- Use a small query to create a sample workbook and publish to Dev Tableau Server.
- Run an extract refresh on Tableau Server. It times out after 2 hours, and on the Presto side we see no attempted connections from Tableau (the Presto coordinator shows all attempted queries)
- Open the published workbook again in Tableau Desktop sitting on the server box, run a manual refresh. It works (verifying that connection details for WDC were correctly embedded after publishing).
Can't quite wrap my head around what's going on here. The same machine is able to execute a refresh from Tableau Desktop but not from Tableau Server against the same WDC.
Any thoughts on best ways to try to debug?
Lasse Thorenfeldt We are facing the same issue as you described. We too are using an internally hosted Web Connector.
we have already tested the web connector path on the browser of the server hosting machine, and it works.
The data refreshes just fine when refreshed using the Tableau Desktop(10.2.1) installed on the Tableau Server(10.2.1) hosting Machine. Which leads to me believe that connectivity is not an issue. However, a manual/scheduled refresh on the server itself throws up an error : "com.tableausoftware.nativeapi.dll.DataSourceException: WebDataRequestor::InitAPIObj Unable to load URL: <WDC Path>"
Have you been able to figure this out and solve the issue?
Any pointers would be of great help.
Unfortunately we were never able to get this fixed. In our case, we were able to get the native Presto connector to work with the open-source version of Presto, so that eliminated our need for the problematic WDC. After that, we didn't pursue it further.
Sorry I can't be of more help.
Thanks for your input. :-) However, we were able to figure it out and the WDC refresh on the server now seems to be working fine.
Since our WDC was an internal one, We just needed to add the WDC domain address (without https) to the Exception list under LAN Connections on the Tableau Server machine and it worked perfectly.
We had some help from the tableau support team and in the end, It turned out to be a pretty simple solution.
Hope this helps!
We are also having issues with a WDC extract refresh. When you say "add the WDC domain address (without https) to the Exception list under LAN Connections on the Tableau Server machine" do you mean to add the WDC URL to the whitelist with just http?
Hi Rainer Dittert,
The steps I indicated above are in addition to whitelisting, in case it still doesn't work.
To add the WDC to whitelist, you need to use the complete URL and also add secondary whitelists if any. This can be quite troublesome really; as even if one URL is missed out, your WDC may not work.
If you have successfully completed the whitelisting, but for some reason it still doesn't work, then you may need to add the WDC to the exception list on your proxy settings ( as communicated to us by Tableau ).
For example, if your WDC is "https://myfirstwdc.com" , then you need to add "myfirstwdc.com" to the exception list. This step has to be done on the "Run as User" account. The steps are described in the below article I found on the Internet.
If it still doesn't work, make sure to check that the "webdataconnector.refresh.enabled" configuration setting has been set to true. You can do this by using the tabadmin command.
Hope this helps?
Thanks, Crystal, for your response. We actually have this configured on our development instance and our production instance with the same configuration, and it works fine in development but fails with this error on production. We have checked and deleted/recreated the configuration items several times with the same result. I looked at the proxy settings, but we don't use a proxy server on either dev or prod, so that doesn't seem like it would be the issue; both dev and prod are on the same network subnet. I do have an issue opened with Tableau Support and am hoping they can shed light on this issue.
A few additional things and checks we did when we raised a case with Tableau. Listing it out here as it took us a lot of time waiting for them to analyse logs and then share more logs again.
1. Does the WDC url work from the Tableau Desktop using the "Run as User" Account on the server host machine? or any other admin credentials?
2. If the above works, does the WDC open up its home page from IE/Chrome using "Run as User Account" and also admin credentials on the server host machine?
3. If the above two are true, please do check the LAN Connections exception list as I described earlier. This resolved our issue when the above two were working.
4. Check the logs to see if there are any secondary URLs not yet whitelisted.
If the first 3 points are all working and you are sure there are no additonal secondary URLs, just mention this to the server support engineer for your case and it could help speed up a resolution to your case if they already know what you have tried.
What we were told is that, if the WDC works on a Tableau Desktop and Browser using the "Run as User" credentials, then it must work on the Tableau Server as well.
Honestly speaking, this bug was a pain for us for almost 2 months to identify this issue and get it working. Hopefully this additional piece of information helps you in your investigation.