A Tableau workbook is an XML file. You can manipulate it using low level code or through various libraries like the Document API .
We don't have to worry about on-site deployment, but we do have to manipulate the data source connections across 70+ sites. Our code changes the schema, database user, etc. in the workbooks and then publishes using the REST API.
We also have some custom tables for specific clients. To support those, we built a web UI that allows the clients to link the custom tables with our standard tables. Those linked models are used to create custom Tableau data source files which are published to the server again using the REST API.
Jeff, Thanks for the reply.
The document API is missing some properties we need.
Manipulating the XML directly is my R&D teams fall-back plan. We are generally against this as it is not a published API from Tableau so there is risk that they may change something internally and break our solution later on. We try really hard to ensure we aren't hacking things when trying to build a repeatable and supportable solution.
Given your extensive use of direct XML manipulation, have you had any upgrade issues in the past?
We've mostly been manipulating the data source connection information. Occasionally, we need to change tables, and rarely columns. So far, we haven't had any version problems (8.2, 9.0, and now 10.1).
What properties are you missing?
cc: Michael Kovner
Can you elaborate on "Right now, given limitations in Tableau Server APIs the only way we can deliver our packaged dashboard is to require they also license and install the Tableau Desktop."?
What would needed to be added to the REST API or Document API to enable the programmatic provisioning of content that you're looking for?
Hi Michael - You were on the call with my team the other day on this topic. (I am with Actimize.) I thought some people on the forums might have come up with different ideas than we have already. Still holding out hope too.
To answer your question:
- 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.
Ideally we would like to simply programmatically (via command line or otherwise) publish a workbook into the client environment. Our clients configure these property names in our software so we are able to programmtically query them to automatically configure the data source connections. But without a complete API, I think we are left with either hacking the XML or requiring clients install Desktop for the sole purpose of setting the connections. This, of course, is really hard to explain. In fact, we would prefer not to have to license them the Desktop tool unless they actually plan to develop with. So it is hard to require them to license, what amounts to, a configuration tool. The option of direct XML manipulation may be our best option (and a little research shows it is fairly widely done which decreases our risk a bit.)