3 Replies Latest reply on May 17, 2016 8:14 PM by Matt Coles

    Can VizAlerts call a script instead of just email


      Will it be possible to call a script or make an http call or invoke  webhook when certain data thresholds are crossed in workbook view?

      I looked at the VizAlerts and it did not look like there was any other alerting option besides email.

        • 1. Re: Can VizAlerts call a script instead of just email
          Matt Coles

          That's correct, there's currently no such functionality--email is the only action supported right now. Check out the Issues page for feature proposals and discussions. This is a cool idea, and I'd love to see your thoughts on how this feature might work--feel free to add an Issue with what you propose and we can talk about how it could be implemented!

          • 2. Re: Can VizAlerts call a script instead of just email

            Thanks Matt. Just started playing with the code today.

            If VizAlerts can make a REST request, developers could write potentially any application and could connect with IoT or call the maker channel on IFTTT.

            One way we could implement this is to create a new function in tabhttp.py let us say, call_webhook


            Then extending on the idea in the sample workbook to look for column header "   if u' Email Action *' in csvreader.fieldnames:"

            we can look for presence of these additional columns owebhook, webhook_url and webhook_token, webhook_param1_value, etc.


            If these are found, we make a rest call and and webhook can be enabled globally with a config key.


            I am just thinking out loud here but feel free to refine or make suggestions. I will add it to issues as well. If I get around to creating this code, I will post it back.

            • 3. Re: Can VizAlerts call a script instead of just email
              Matt Coles

              Totally in line with the original concept behind VizAlerts--email just happened to be the most useful and easy thing to start with. So I'm totally on board with this idea.


              The challenges, to me, seem mainly in these two things:


              1. Finding a way to standardize API calls such that we can do a lot right out of the box without needing to build a bunch of custom, optional installation and configuration steps, and introducing inconsistency in what is and what isn't supported for end-users. So that's one reason to like the idea of trying to build a generic web call that could interface with multiple systems. I'm not terribly experienced in that area though, so I've no idea what a good spec would be for it.
              2. Authentication / permission. For some systems this is probably not a problem, but for some that go beyond simple notification, but actually change systems, it's a non-starter unless there's some way to securely communicate auth to the system being called. Think of a scenario in which we want to build a hook into something that will export a CSV of the data in a view on Tableau Server to a fileshare, then delete any old ones that may exist. We'd need to ensure that whatever system we're instructing to do those things can both match the user that we've already indirectly authenticated by virtue of their ability to create a Subscription on Tableau Server, as well as ensure that the user has the right permissions to modify the fileshare in the way that the viz instructed it to do.

                You could potentially pass username/pass through the viz data to the web call you made, but then you're exposing credentials to random other systems to whoever has access to your viz (e.g., at least all Server and Site admins, probably more). That's not ideal. It'd be better if there was some way for you to configure the third-party systems, provision users and permissions, then tell it that any requests it received from VizAlerts were to be regarded as already authenticated with the user it said wanted to do something. Same as trusted tickets in Tableau Server works, really. I'm not sure how many systems actually would support that kind of scheme though. Limited-permission auth tokens might be an acceptable solution as well...Just spitballin' here.