The thrill of the new Tableau server honeymoon is over…and now the hard work of Tableau Content Management begins. The first article in this series will answer the question \”why should I care about Tableau Server Content Management\”; and will demystify the various types of content stored in Tableau server.
Why should I care about Tableau Content Management…isn\’t Tableau a self-service platform?
It\’s a valid question. The answer may prove to be a bit shocking at first…SELF-SERVICE isn\’t really self-service. Yes, Tableau server is designed from the ground up to encourage and nurture a thriving self-service culture. However, over time, this self-service freedom comes at a cost. Here are just a few thoughts to get your Tableau Content Management juices flowing.
Multiple copies of the same or very similar data sources published to the Tableau server
Finally, if your Tableau environment experiences any of the scenarios below, some focused attention on Tableau Content Management is a great place to start.
Tableau server users have trouble identifying which data source is the most current.
Tableau server users have trouble finding the dashboard they want (multiple copies of the same content or outdated content).
Database administrators claim Tableau server is negatively impacting the performance of the databases they manage.
Users cannot find the Workbook or Data source that contains the data field or formula they\’re looking for.
Tableau Server Content Types
Let\’s begin by identifying the various types of content found in your Tableau server.
Sites – A Site in Tableau server is an actual content boundary. Cross-site content communication is not possible.
Projects – A Tableau Project is an organizational object in Tableau server, not an actual object.
Workbooks – A Workbook is a package for everything needed to display dashboards.
Views – A View is a dashboard or worksheet published to the Tableau server as part of publishing a workbook.
Worksheet – A Worksheet is a single visualization within a Workbook; whether it\’s published to Tableau server or not.
(Unmanaged) Data Sources – An Unmanaged Data Source is a data source that can only be seen and used within the context of a single workbook.
Published (Managed) Data Sources – A published data source can be used across multiple workbooks.
Metadata – Metadata is data about things like data sources, worksheets, dashboards, Tableau Storys, actions, filters, etc…
Schedules – Schedules are definitions of when tasks are run
Tasks – Tasks are created when a refresh or subscription of a workbook, dashboard or data source has been attached to a specific schedule.
Extract Refreshes – An extract refresh contacts back-end systems to pull new data into a published data source hosted on the Tableau server on a designated schedule.
Subscriptions – A subscription sends the recipient a current version of a View on a designated schedule.
Alerts – Alerts, a content type new to Tableau server 3.X and above creates an automated notification based on user-defined threshold criteria.
Groups – A group is a collection of Tableau server users
Users – A user represents a user account on the Tableau server.
Yeah, there are quite a few content types living on your Tableau server.
Conclusion
Now that we know what type of content that lives on the Tableau server, the next article in the series will introduce some of our favorite Tableau Content Management techniques.
Receiving regular notifications that your automated data extract refresh has failed is a great new feature of Tableau server. There are times when you may want to unsubscribe from receiving the updates. Here’s how…
In the upper-right hand corner of the screen, click the arrow to the right of your name and select My Account Settings from the menu options.
At the very bottom of the page you’ll find the Email Notification section. This is where you can disable extract failure notifications. PLEASE NOTE: This will turn off notifications for all of your scheduled extract failures.
Ever made the type of mistake where if your joints were flexible enough…you’d kick yourself…LOL? If so, we’re probably related somehow.
While executing a routine I’ve successfully done a number of times in this exact environment, I learned something about the Tableau Server TABADMIN command line tool. IT CAN’T SPELL.
Take a look at lines 67 and 68 (sorry for the small image). They’re ALMOST the same; well sort of….er.
The subtle difference in these two lines kept me up all night. Why? because I’m a good IT community member, I run big jobs during off-peak hours and it took 2 hours for this job to fail each time. AAARRRRRGGG!!!
I digress, back too my discovery. After a little digging I found the TABADMIN configuration I needed to address the query limit timeout error (backgrounder.querylimit). An error that created a mild interruption of the GS/TO game. The second two hour window passes and BANG; error again. At this point I’m thinking, those darn DBAs, why won’t they let my query run…LOL. It’s a really good thing no one was available to field my tech support complaint (almost kick yourself).
So this morning I connect with the DBAs, explain my dilemma, and they respond by saying, well, on our side your query ran successfully three times last night. What?
So I do what any rational admin does, I open a ticket with Tableau. While waiting for support to call me, the light came on. Something’s wrong with the configuration property I set. The portion to the left of the period is missing theer.
Moral of this story? Tableau Server admin/architect, check your spelling because TABADMIN won’t correct your spelling and also won’t warn you about a bogus configuration setting. As good admins, we must avoid kicking ourselves at all costs!
You install Tableau Server , and being the good Tableau Administrator you are, as soon as the installation finishes you head over to the server Status page to make sure everything’s running as expected. You anxiously await the page loading only to find the File Store process synchronizing.
At the onset, this doesn’t seem to be something to worry about. Since the File Store is a new process introduced in Tableau Server version 9.X, it’s reasonable to assume that it would need to synchronize the first time out of the box. Reasonable thinking on your part. However, after 30 minutes, then an hour and a full day when the process hasn’t finished synchronizing, you have a reason to be concerned. Aaaarrrrggggg!!!
Reproducing the Behavior
According to the Tableau Server documentation, this new service handles the storage of extracts and in highly available Tableau Server architectures it ensures that extracts are synchronized to other file store nodes so they are available if one file store node stops running. But wait! I don’t have a Tableau Cluster, I have a single node installation of Tableau Server. I know, it threw me for a loop for a while as well.
Choosing NOT to install the sample content while configuring Tableau Server during the installation routine is the condition that creates this scenario? When Tableau Server starts up for the first time, and there’s no content to actually synchronize, you’ll see the File Store process behave in this manner.
The Solution
This may seem laughable, but I’ve done it repeatedly, so I know it works. Simply publish a test Workbook to the newly installed Tableau Server, wait a few minutes and watch the File Store process stop endlessly synchronizing. Then simply delete the Workbook from the Tableau server.
PLEASE NOTE: Adding Worker nodes to the Tableau Server installation will not resolve the issue.