Warning, spoiler ahead!:
Wait for it……Yes.
- Add a new web part to your page:
- Next, add new content
- You’ll need to edit HTML directly. Click Edit Source.
- Now, just copy in your script and the DIV it refers to (no, the references to Jquery aren’t necessary - I just did a quick copy/paste without really looking at what I was doing) :
- Save your changes to the web part and page, and know that something good is going to happen….
Setting up Tableau Server is easy. Really easy.
And compared to (ahem) some of Tableau’s competitors, setting up a distributed installation is even more straight-forward.
In my opinion, the “trickiest” thing in terms of making everything work is validating that the well documented list of ports we use to communicate back and forth are open. We actually open these ports in the Windows firewall for you automatically, but if you’re running other stuff that does port filtering, it still might get in the way.
So here’s a quick way to make sure that everything that needs to be accessible is indeed accessible:
Next, you need this custom port list that yours truly created to plug into SuperScan. You’re welcome.
- Install SuperScan
- Drop the port list into the same folder where the tool is installed (generally, C:\Program Files (x86)\SuperScan).
- Modify the scanner.ini file to include the new port list in the [PortLists] section
At this point, when you launch the tool, you should be able to click Port list setup, then Load the port list in question. Click OK.
Finally, make sure that the Scan Type is set to Every Port in list.
Here’s me scanning my Primary machine (192.168.203.29) from a different box which is about to become a worker:
…and here’s me scanning the worker from the Primary:
Note that I’ve JUST added the worker as a machine I want to setup, and currently only the “Worker Setup Port” is open.
Once the configuration of the worker is done, it’s listening to more ports:
So, to summarize - port scanning Tableau for dummies (not you, me.)
…and a quick note about setting up SuperScan: since it IS so long in the tooth, your modern OS may handle some things it does a little differently. For example:
- You may not be able to edit the port.lst file or the scanner.ini file directly in the program folder. Instead, you may have to temporarily move them elsewhere for editing, them move ‘em back.
- Windows may also save “old” copies of the files you edit and move in a different location…and use them instead of the newer ones! If this happens, check out the folder C:\Users\ <your user name> \AppData\Local\VirtualStore\Program Files (x86)\SuperScan. It’s likely you’ll find some stuff in there of interest.
Final thing - nah, I’m not going to support you on how to get SuperScan working on your machine: flex those technical muscles of yours and work through it yourself…
Ran into what I think is a documentation gap this morning, thought I’d share it with the interwebs to save folks time / stress / sanity.
- You install and confiure your Primary. All is well.
- You configure any number of other workers with other services (excluding extra gateways). All is well
- You activate one or more gateways on the workers from step 2
The workers on which you activated gateways now show themselves in a degraded state (using tabadmin status -v), and the gateway processes are stopped except on the primary.
Evidently, we don’t actually use those gateways from step 2 until you configure an external load balancer (see the help topic “Add a Load Balancer”. I’m not 100% sure of this, but all the internal notes I’m finding seem to indirectly indicate this.
Since we aren’t spinning those gateways up, they remain stopped. And when a service is stopped on a worker, the worker will return “Degraded”. Nothing is really wrong here, though: the worker just doesn’t seem smart enough to know that the gateway is down for a good reason, and therefore complains about its health.
Nothing to see here, move along. All is well.
EDIT 25-Feb: A couple of other internal folks looked into this with me, and we figured out what was going on (why the non-primary gateways didn’t start up). Actually, they figured it out and then laughed at me and heaped well-deserved abuse upon my person.
I use SSL on my machine, and frankly forgot about that teensy-weensy fact. When you use SSL, you must copy the folder with your certs in it to each and every machine which will be hosting a gateway.
- I didn’t.
- Therefore, gateways don’t start.
- And then the workers hosting the gateways claim “Degraded”.
Another Scooby Doo mystery solved. Damn those kids!
Over the last few months I’ve seen a few folks having problems connecting Tableau and PowerPivot data sources.
Occasionally, the person wasn’t able to connect to a workbook on their local machine. But more often than not, the challenge was connecting to a workbook saved in the PowerPivot Gallery.
Being a masochist, I decided it might be fun to install the Microsoft BI stack on a VM in my domain: It’s been a few years since I’ve felt this particular type of pain, and I was itiching for a good thrashing. In the immortal words of Eric Stratton:
“…In this case, I think we have to go all out. I think that this situation absolutely requires a really futile and stupid gesture be done on somebody’s part”
So, three hours later I have a single node of SharePoint 2013 up and running with Excel Services and the SQL Server PowerPivot System Service chugging along. Hurts so good!
I also went ahead and updated Office (x86) from 2010 to 2013 - I had been running some old add-ins that finally got updated and now work in 2013, so why not go all in.
Off to the Tableau Website where this handy-dandy article told me which version of the add-in to download and install with Tableau 8.1:
Since I’m running 8.1 and like to run x86 Office, here’s what I need:
I dutifully download the correct Add-in from the Tableau site:
And now, I’m ready to test…
First, I find my PowerPivot file:
Next, connect to it:
Volia, one data model ready for consumption:
But that was supposed to be easy. How about connecting to the same workbook saved directly out in SharePoint?
Yay! An error:
"The path you specified is invalid"
"Analysis Services database error 0x80004005: Either a connection cannot be made to the SharePoint server, or Analysis Services is not running on the computer specified"
Aha! Look what those chumps did to us and what I did to myself with the cute file name!
Note the spaces in the name of the default Power Pivot document library that was created for me: “PowerPivot Gallery”.
You can even see that the space is being encoded with %20 in the browser.
Likewise, my trying-too-hard-to-be-funny file name has tons of spaces.
I need to reference this file like so:
…and it worked.
Now, the funny thing here is that I JUST tried the same thing again without encoding my spaces:
http://SharePoint2013/PowerPivot Gallery/I want my morning back.xlsx
And it continued to work. In fact, I can’t get it to fail now.
So, you may need to encode your spaces. Or not, I’m not sure. But I have no problems accessing this stuff from the local filesystem or via SharePoint itself.
Enough pain for one day, time to watch the Jersey Shore marathon.