- Not easy to do. The problem is that Tableau doesn't quite exactly subscribe to this old paradigm. That's the nice thing about self-service. I will say it can't be done simply. Others can chime in on their success, however, I have yet to read thorough instruction by someone who has done this successfully.
- First, what do you mean by "Tableau Code"? Extracts, published data sources, workbooks, ???
- Go here: Tableau Help | Tableau Softwareand near the bottom are the various programmatical ways to work with Tableau:
I have the same question and many more on this topic. At this point it is my understanding that Tableau simply does not do a good job at supporting the migration of packaged content. They have released something they call the Document API and they have some existing REST API web services that cover some of the migration needs but not all.
Specific to your question parameterizing database connections when migrating, we have very similar need and have been unable to find a solution. For us, we need to develop a standard data source + dashboard for delivery to our clients running our integrated software (ours integrated with Tableau). The integrated s/w runs on Oracle or MSSQL and clients have the ability to use any schema and service names they wish.
Therefore, since we build the content in our labs and ship to a client site that data connection info will be different. So if we call our database dbname BLAH and connect with dbo/pwd this data source + workbook will fail to deploy on the client environment. Why? Because it will fail to connect upon Publish. Apparently, when Publishing Tableau insists on creating a thumbnail image of the dashboard. Since it fails to connect, it will fail to Publish. The only way to Publish this workbook is to open it in a local Tableau Desktop and supply valid connection info then Publish. We would clearly prefer to not have to deliver Desktop just to change connection properties. This same problem exists during migration like your need and we have been unable to find a solution while working with Tableau.
There was a good session on the use of the Document API versus XML and Rest API etc at the Tableau conference. You may watch it here - http://tclive.tableau.com/Library/Video?vCode=BRK51208
They discussed the very problem you're trying to solve. While I don't have the same use case, I couldn't help but think "yeah I could totally write a script to automate the migration from DEV > UAT > PROD like we used to have with Business Objects".
So if we call our database dbname BLAH and connect with dbo/pwd this data source + workbook will fail to deploy on the client environment.
A potential shortcut - could you not give all client database names the same name and potentially get their network admins to set you up an internal dns record like 'seansawesomedatabase.com' to point to the target database? That way you would only be handling a change in the credentials on a client by client basis.
Finally, I see you've posted a couple of things in the OEM forum (which is what led me here). I'm not a member, I think most of us are not. So you might actually benefit from posting those questions in the regular forum, I know I have a couple of ideas to contribute
Tom - Thanks.
I will take your advice and post these questions in the wider world and not hidden under OEM banner. I know it impacts others too but these seem like they must be significant challenges for OEMs that many must have solved. We are having trouble understanding how a great product like Tableau is missing such features that seem basic to us from a s/w delivery standpoint....
I somehow missed the TC session you posted in my past reviews. I will take a look and pass it along to my team. We are generally against hacking XML in OEM products as it is unsupported and we fear causing future support and upgrade problems. That said, for our purposes, it is indeed our current fallback to automate some delivery tasks via command line.
The session I linked to was actually all about avoiding the XML hacks and giving options through the REST API / Document API.
I think there's plenty of good options to achieve what you're trying to achieve, you're just going to have to do some of the legwork yourself in order to create the tools and scripts to do so.
Hi Tom - Maybe I wasn't clear above as I was posting similar discussion in the OEM thread. (Apologies on dual posting)
The Document API and REST API suffer from gaps in which properties can be manipulated programmatically.
- For MSSQL database type we are missing dbname and schema.
- For Oracle database type we are missing schema and service
- For "Query Workbook Connections" & "Query Datasource Connections" APIs the response is missing the connection names. The REST API only returns the connection id. Which is not useful when multiple connections exist as this id is internal and not known to the client.
These gaps cause us to fall-back to XML hacks currently.