With creating a standard data directive on the “SYSTASK” table to send out an auto email upon specific tasks failing. It seems when the directive is active all tasks that go to the system monitor stay in a pending state and never move on. As soon as I turn of the directive everything works fine again. Is there something I am missing? As this seems like a really simple directive.
What do the params on the Email widget look like?
@Chris_Conn Thanks for always helping out with my posts 
(you think the problem is that the action is “Synchronously instead of a-synchronously”
It’s worth a try, that way you dont hold up the process for other records coming across while waiting on emails to complete.
I’d note that @josecgomez mentioned that it can be hit or miss and he has had a few hangups even with async.
Switching to asynchronous let the print jobs pass, ill leave it active and watch to see if it picks anything up or hangs any tasks.
I was trying to deal with this as well. We have scheduled tasks that we need to be alerted about when they fail. At first I was going the route of a method directive, but those tables are extremely important and creating a customization on them can be costly.
What we did to solve the issue was create a report that queries the Ice.SysTask table and returns rows that have a SysTask.TaskStatus = Error in the past 61 minutes. We inner joined the Ice.SysTask table to Ice.SysAgentSched so that the report only had rows where the task was linked to a schedule. We then scheduled the report on a schedule that repeats every 60 minutes. We excluded this schedule number from the Ice.SysAgentSched table so that this report wouldn’t fire off itself when it had No Rows. Please see the screenshots of the BAQ created, the System Agent Schedule, the Report RDL, and the pdf that we occasionally get when it fails.
When you see the BAQ, the sys task log is only included for a calculated field where we are checking to see if the error was due to No records selected. In this case we would not want to report these errors and send out the report because they are harmless. Your sales order acknowledgement process might error out due to no records depending on how you have that set up.
This report has its quirks, but at the very least it alerts of errors with very little impact on the sys task tables like a BPM or Data directive.
That’s awesome and detailed well. I will give this a shot. Thanks a bunch!
The way that we exclude the No Records error is actually through a condition statement in SSRS breaking and routing. See the attached picture. It shows that IF all rows have an error message check of TRUE meaning that all rows error out due to no records selected THEN do nothing, else, send the report.
If you do not have the advanced routing capabilities I suppose you could do this report through a SQL job or something of the sort.
Just keep in mind that’s an additional module that has to be licensed.
That is why I mentioned “if you do not have advanced routing capabilities, you could do this with a SQL job or something.”
Could you just do it as a subscription n the SSRS rdl? I suppose that may work.
This is why I suggested a separate notification engine. It would essentially make all notifications (including email) asynchronous. Why embed all of that email logic all over the application? Keep the same signatures but put the actual transmission logic elsewhere in one place. Now there’s one place for error handling and failure reporting, even retransmission logic, etc. Also, having all that routing logic in one place would make life a lot easier too.
End of old-man rant…
So what I hear you saying… is everybody go vote on this topic? 
