Following...I am experiencing a similar issue with a data source extracted from MS SQL Server to Tableau Server 2018.1.2. Tableau Desktop extract refresh and publish to Tableau Server takes <10 min where Tableau Desktop is running on Tableau Server Host. Extract refresh times out when launched from browser. Other data sources complete in a reasonable amount of time.
Are you sure that in Scenario 2 & 3 the extracts refreshed completely in 5-10 secs? Assuming that you validated by checking the numbers.
Usually "Refresh Extract from Source" option just initiates the extract process. In your Tableau Server there will be a Status page. In that there will be an embedded Tableau workbook with various administrative views. If you check the "Background Tasks for Extracts" tab and select the relevant dashboard in the filter you will be able to see this.
In Scenario 1, there is a backgrounder.querylimit parameter which is set by default to 7200sec. So any query which takes more time than that gets cancelled automatically. You can increase this limit as detailed in this article. I would suggest re-look at the data you are trying to bring into Tableau. Create extract of only required fields/columns (the more columns you have the more time it takes since Tableau extracts are columnar data stores) and use extract filters to restrict your data to the extend possible and what is required for your dashboard. Also consider having a data pipeline (or ETL) before you bring your data into Tableau, to aggregate to required levels rather than bringing in the most granular data.
I've checked the numbers. We only had 250 records in the source during our testing phase.
Additionally, just wanted to point out that "Refresh Extract from Source" option never triggered a job in the backgrounder.
The issue is definitely not with the backgrounder.querylimit. I'm aware of this limitation and its good to keep it at default. As i said, we only had 250 records.
I realised after posting this question, that I've encountered something similar already earlier in one of the other discussions. However, im trying to get an understanding between the two refresh options here.
Here's a link to the other discussion Getting "InitAPIObj Unable to load URL" error when refreshing whitelisted WDC
After a bit of thought, i believe that both the issues are interlinked. It would be great if we had someone from Tableau to give us some picture here!
While I have already resolved this issue and understood why the Scenario 1 failed, I've raised a case on this matter with Tableau to get an understanding from them before i post my response here in the community!
When you mentioned that the extract is running from Tableau Server Host machine - did you mean with the Run as User Account or with your admin credentials?
From my experience, there could be due to different proxy used in the Run as User account. The Tableau Server (when you trigger from the browser) uses this Run as User Account.
You could also check the logs to see what are the errors thrown. It usually helps to get a better picture of the error.
Ok, so I waited a while to post the solution as I wanted to hear from the Tableau Case support first.
The reason why the scenario 1 failed was that there were a few WDC Secondary URLs which were not whitelisted. This was identified by checking the tabprotosrv and backgrounder logs to see which URLs were getting rejected during the connection phase.
After this, I still wanted to get an answer on the reasons for the scenario 2 & 3 succeeding in refreshing the datasource since the URLs were not whitelisted. For this, I raised a case and this is what the good guys at the Tableau Case Support had to tell. It makes a lot of sense now.
-When we try to connect to a WDC using Tableau Desktop, the connection is established between the TD client and the WDC. The server is nowhere in picture. The Tableau Desktop then takes up the responsibility to refresh the WDC. Since the Tableau Desktop doesn't need things like whitelisting, it is able to successfully refresh on both the Server Host Machine as well as a local client machine.
To answer a question of why the Tableau Desktop is able to refresh a source which fails on the server (maybe blocked on purpose by the server admin), this is possible because of the Editor permissions on the Tableau Server for the specific Datasource.
I did a test on this and realised that this is not restricted to a WDC but any Datasource having similar issues (as detailed in the three scenarios).
If a server admin wants to restrict who can refresh the datasource from the server, they have to keep an eye on the Editor permissions for the datasource. A connector permission would not allow the user to refresh the Datasource. (I am trusting Tableau on this).
I hope this helps.