EDIT: 20-April-2016: About 2.5 years ago I warned you that that they could go away….Well, in 9.3, they went away in a default configuration of the Server. Sorry. More info here, but you probably don’t want to use these techniques any more: http://kb.tableau.com/articles/knowledgebase/xml-endpoints-no-longer-available
As of late, I’ve seen a lot of activity on the #Tableau Community Forums concerning the “informational” XML files that Tableau Server can generate for you, I thought it might be fun to write several long, rambling posts that speak to just about everything you can do with these suckers. Doing so helps me drown out the holiday noise that is Black Friday, Small Business Saturday, and Cyber Monday. Feh! Maybe I’ll just keep going until Jan 2.
As I’m sure you know, generating and using these files is not supported by Tableau. This is an internal mechanism which is undocumented and will stay that way as far as Tableau is concerned. This stuff could change at any time, like tomorrow. It could give you food poisoning and very bad breath. Your girlfriend or boyfriend might leave you. Seriously.
You’re an adult can choose to lean on this functionality if you wish, but there is risk involved. Eyes wide open, please.
What do these files do for me?
If you’re a Tableau Server administrator, the XML files offer an easy way to pull information about your users, workbooks, and other objects out of the server.
Generally, the same information is available via our (supported) database views. So, more often than not you don’t need and probably shouldn’t use the “XML File” approach. Got it?
There are some edge case scenarios where these can be quite useful, however:
- I need a list of data connections on the server
- I want a list of users in a specific group
- I want to know what workbooks or views a user or group has access to
- I want a list of workbooks owned by a specific user
- I’m bored and just feel like showing off
Here are “Big 12” files that are (easily) available. We’ll define what each does later:
- data_connections.xml
- datasources.xml
- groups.xml
- projects.xml
- schedules.xml
- sites.xml
- subscriptions.xml
- tasks.xml
- users.xml
- <username>.xml
- views.xml
- workbooks.xml
Under the Covers Overview
Tableau Server is built on top of Ruby on Rails. RoR allows you to hit paths, like http://myServer/views. Ruby on Rails uses routes to forward various combinations of paths and HTTP Verbs (GET, POST, PUT, etc) to a controller which executes actions
We’ll be focusing on a subset of the most important controllers and actions, but there are tons of ‘em. All you have to do is watch the _http_requests view inside our PostgreSQL database, and you’ll see lots of fun stuff you can query.
For example, Tableau Server 8.1 will now “alert” you if one of your extracts didn’t refresh properly:
How is Tableau getting the information which is displayed in this dialog? It is hitting a controller. I can see this happening inside PostgreSQL:
If I know the URI of that path/action and I’m authenticated against Tableau Server I can often just hit the URI myself.
Look familiar?
Most of these controllers have template handlers which allow someone to render as either HTML or XML I don’t know tons about RoR, but the templates which handle HTML generation have an .erb file extension, and the ones which “do” XML have a .builder extension. Here’s the template to build out the views.xml file and the output of the xml file itself:
Note the references to fields in the builder file which show up in the XML that Tableau Server generated for me
Approach
There are three steps you’ll take when leveraging these files:
- Authenticate: You must be logged into Tableau Server to request the files
- Request: Make a request for a file, sometimes providing additional filter parameters
- Consume/Parse: Reading raw XML isn’t the greatest experience, so while viewing this stuff directly in the browser is fine, you might want to parse it.
In the next post (part two) , we’ll talk about the start of this process – how you can authenticate against Tableau Server.
Part three will drill down into each XML file and what it does. We’ll discuss how to get the file you want, and how you can dynamically filter some of them.
The final post (part four) will be boring, but important. I’ll point out a couple ways you can parse the XML you get back so it is more human readable.
Happy holidays (whatever.)
