11 Replies Latest reply on Sep 8, 2015 1:48 PM by Toby Erkson

    Better way to test alerts?

    Toby Erkson

      I noticed that the VizAlerts have a strict adherence to its Schedule.  So while we can manually trigger a Schedule to Run Now, we still have to wait for the VizAlert to execute on the actual schedule.  Thus, if we have a Schedule that triggers once an hour, we actually have to wait for that hour.  Even if we do it for every 15 minutes, that means only 4 possible tests per hour!

       

      Is there a way to force a VizAlert to run immediately like how Tableau Server allows its Schedules to Run Now?  Or have them run at the next Windows Task Scheduler time? (I have mine set for every minute).

       

      Matt, please add some verbiage about this in the documentation.  This was a point of confusion for me because I would Run Now and while I would get the immediate email of my subscription, I wouldn't get the VizAlert email until the actual Schedule time; thus I though it was broken

        • 1. Re: Better way to test alerts?
          Matt Coles

          There is a way to force VizAlerts to "run now" for a given Alert, but it's not very user-friendly at the moment:

           

          1. If you're running VizAlerts from a Scheduled Task, disable the task.
          2. Open .\ops\vizalerts.state.
          3. The two timestamps in the file represent the time the alert was last checked, and the next time it will run, respectively. You can edit just the latter, "run_next_at" by setting it to a time that is in the past, and this will trigger the check next time VizAlerts runs.
          4. If you need the right timeout length applied to the alert when it is checked, you'll want to update the "ran_last_at" date as well, setting it back to whenever the alert would have been last run in real life.
          5. Re-enable the VizAlerts Scheduled Task (or trigger it manually) - when it runs, the Alert will be checked then and there, one time only. The state file will then be overwritten with the new dates and VizAlerts will resume normal operations.

           

          Another alternative is to create a new Alerts schedule, name it something like "VizAlerts TEST, DON'T USE" or something, then manually update the PostgreSQL Repository using the tblwgadmin user and set it to run every 1 minute (not officially supported, of course). Then you can test things more quickly, though you'll need to unsubscribe quickly too, otherwise you get barraged with one or more emails every minute.

          • 2. Re: Better way to test alerts?
            Toby Erkson

            Matt, this works great!

             

            Matt Coles , can you please change this to a Question and then mark your answer as Answered?  I don't have moderation rights in this group.

            • 3. Re: Better way to test alerts?
              Matt Coles

              haha, thanks for helping me admin my own Group, Toby! Done.

              • 4. Re: Better way to test alerts?
                Toby Erkson

                Just a FYI

                Background:  I have the Windows Task Scheduler on our test server running every minute.  The folder that contains the vizalerts.state file is Shared so he can use it for his testing:

                 

                Instructions to one of my end users for testing their VizAlert...

                Vizalerts.state

                Oy! Yeah, this isn’t as simple as it could be.  So, look at the file.  Make your subscription.  After a minute go back to the vizalerts.state file and there will be a new entry at the bottom which will be your [new] subscription.  The subscription_id is the value you want to remember as it is the one in which you’ll change the run_next_at:

                The reason to remember the subscription_id  is in case other entries are added.



                This allows the end user to test their VizAlert without requiring me to disable the Scheduled Task on the Windows Task Scheduler.  This is how I do it as well.  So at most the delay to test will be 59 seconds

                • 5. Re: Better way to test alerts?
                  Matt Coles

                  So, here's a proposed interim method for testing alerts--let me know what you think, guys:

                   

                  If the owner of the View adds a comment with content "test_alert", the alert will be triggered once. Thereafter, even if the comment remains, it won't be triggered unless it's via an Alert Schedule. If a new comment with the same content is added, it will fire off the test again. If the existing comment is edited and contains the same content, that will also trigger the test. Removing old comments won't re-trigger the alert.

                   

                  Do you think that will work in the absence of the Schedule-based version of this feature, since I can't yet programmatically unsubscribe a user from it?

                  • 6. Re: Better way to test alerts?
                    Toby Erkson

                    What I do like about the current method is that when the VA (VizAlert) fires the "run_next_at" will reset.  So if I change an entry to "2014-09-08..." and then a minute later it goes to "2015-09-08..." then I know at least the Task Scheduler is working properly and the task, and thus the VA, was properly executed (it's working).

                     

                    Okay, so:

                    Matt Coles wrote:

                     

                    ...

                    If the owner of the View adds a comment with content "test_alert", the alert will be triggered once. Thereafter, even if the comment remains, it won't be triggered unless it's via an Alert Schedule.

                    1.  So there will be no need to open the viz and subscribe to it with an Alert Schedule since the "test_alert" will essentially replace that, correct?

                    2.  Should there be an Alert Scheduled it will fire regardless of the comment, correct?

                    Matt Coles wrote:

                    If a new comment with the same content is added, it will fire off the test again. If the existing comment is edited and contains the same content, that will also trigger the test. Removing old comments won't re-trigger the alert.

                     

                    3.  So you can read when a field was modified and that is what you're checking?  Not sure I fully understand...could get confusing.

                    Matt Coles wrote:

                    Do you think that will work in the absence of the Schedule-based version of this feature, since I can't yet programmatically unsubscribe a user from it?

                    4.  Well, what about an " Email Test ~" field?  If present and it contains FALSE then don't fire off the VA for it.  If it contains TRUE then do fire off the VA for it.  What would be nice is that a TRUE entry is set to FALSE after the VA fires off.  At least that would be a positive indicator that a VA action was enacted against the viz, successful or not.

                     

                    However, I'm not sure if I like this field method of triggering.  Using my testing environment for example, I have the Task Scheduler firing off every minute.  The author would have to include the particular test field and then publish, wait for the Task Scheduler to fire, and:

                    - if using method #4 the author would need to quickly re-publish the report with FALSE to turn off the triggering.  Make adjustments, then re-publish with TRUE and repeat the process.  Too tedious.  I don't recommend.

                    - if using #1 it could conflict with the need to test the viz with a specific Alert Schedule (I can't think of a test case but we know it could happen).

                     

                    I don't mind the current method, would just like an easier way to identify the particular VA so it can be readily changed.  However, I can understand how an alternate method of firing off a VA would be necessary in an environment where an admin cannot or will not give users access to the .state file.

                    • 7. Re: Better way to test alerts?
                      Matt Coles

                      1. The "test_alert" comment means "run this alert right now, one time only". That's it. So it would allow non-Admins to test their alerts without waiting for a Schedule to kick off.

                       

                      2. Yes, correct. If the alert is set up for a Schedule, it'll be tested when the Schedule runs, regardless of the comment.

                       

                      3. Actually, I was wrong on that--it'll be driven off when the comment was created only--updating an existing comment won't have any effect. To re-test it, you could add a new comment or delete and re-add the same comment. But yes, I'm pulling that date from the postgreSQL repository.

                       

                      4. Interesting idea, but exactly--I don't want to pit the alert author in a race against VizAlerts executing again!

                       

                      I'll post a video showing the proposed functionality. I've got a POC going on my workstation.

                      • 8. Re: Better way to test alerts?
                        Matt Coles

                        Here's the example video of how this would work...

                        • 9. Re: Better way to test alerts?
                          Toby Erkson

                          Oooooooooh, that Comment field!  For some reason I was thinking of a column field being added to the viz itself.

                           

                          Okay, I like this better now.  Yeah, I could deal with that and it's a great deal easier for end users, too!  The negative value is a good indicator in the .state file, I like that also.

                          • 10. Re: Better way to test alerts?
                            Matt Coles

                            Okay, cool. You can also still use the state file if you like. Personally I kind of hate that hack, because it's too easy to fat finger something and kick off someone else's alert when it's not supposed to be...and you can accidentally introduce a formatting issue into the dates and cripple VizAlerts (I've done it several times now).

                            • 11. Re: Better way to test alerts?
                              Toby Erkson

                              Matt Coles wrote:

                               

                              ...and you can accidentally introduce a formatting issue into the dates and cripple VizAlerts (I've done it several times now).

                              Put that possibility in the instructions just in case trouble-shooting is needed.