Hello fellow cloud peeps, are y’all able to send a simple email using the email widget on a standard data directive on the Ice.Systask table whan a row is updated or added? The email does not send for me, but when I copy the directive to another table, like UD02 or POdtl the email sends.
Unfortunately this is now “as designed” according to Epicor, Data Directives will no longer trigger from SysTask starting in 2024.1 (worked back in 2023.2). If you want put in a ticket, maybe when they get enough they will consider adding it back. Response from support is below (I asked yesterday about this no longer working). Why they would take away this functionality is beyond me, maybe @Rich or @timshuwy can find out and/or let us know
6 Likes
Well that doesn’t make any sense.
3 Likes
You can still setup a data directive on SysTask though if you want to look at it for old times sake
3 Likes
Welp there goes real time alerting on critical task failures (SOX) where we said we could get an email. Why Epicor why!? We will see if our auditors like this 
2 Likes
I assume the method directives still work. We have some options.
1 Like
This one does work, only for completed tasks though. If the task errors out the post processing is not reached
2 Likes
The problem is with line 199, throws the error so no post proc to use the SysTaskNum to check what the status ended up being. I guess you could log each SysTaskNum that you would want to monitor into a UD table (pre proc) then have a scheduled function checking the status and clearing the UD table records every min that dont have a status of pending or active, but question still is why do we have to jump through hoops now to do this when it worked fine until now using DD’s. Also might be other method directives to monitor, haven’t dug into it that much yet
3 Likes
If I wasn’t knee deep in something else, I’d poke around with you.
1 Like
I don’t care that much I guess, I already made workarounds where things broke. Just would like to know why this was taken away
4 Likes
Waiting for @Rich to also respond, but I will state that there has been discussion over the years to eliminate this type of trigger because it is soooo easy to do something really bad with a BPM monitoring systask. IF it is done incorrectly, but BPM becomes a system hog, and you don’t even know it. This is especially bad in the cloud. I am sure that Rich has more info.
3 Likes
And a few other tables.
I’d argue that’s not your problem, it’s the clients.
I would hope Epicor has systems in place to identify and mitigate “noisy neighbors” ?
1 Like
2 Likes
for what it’s worth… maybe you can make a BAQ report or RDD based on BAQ to help your woes?
It’s not going to be triggered on the actual even happening, but…
1 Like
1 Like
A while ago, there was mention of adding Web Hooks to Kinetic. These kinds of tasks seem like a natural place to have clients subscribe to. It would be less work on the server, eliminate polling, and give quicker responses to the clients. Would having CDC set up on the SysTask table improve performance? 
4 Likes
Hey all - sorry to be late to the party.
I believe that the DD not running on the SysTask table was introduced by prep work being done in order to change the way Reports and Tasks run. We need to investigate further but likely the capability will be restored.
I have to admit that I intensely dislike DDs on SysTask. Prior to the ability to schedule Functions, DDs on SysTask were (and still are) often used to “do stuff” on the regular heartbeat of the Task Agent. A fair amount of the SysTask DD BPMs do not consider how frequently execution occurs and performance complaints, SQL Locking errors, and AppServer Memory issues often result.
6 Likes
Thanks for looking @Rich.
Look forward to an update.
I don’t know if I’d go that far with my disdain, but you’re not alone.
My approach would be caution and probably as a last resort.
2 Likes
It would be great if we didn’t need bpms on systask . . .
https://epicor.ideas.aha.io/ideas/KIN-I-3280
https://epicor.ideas.aha.io/ideas/KIN-I-4013