DONE,
and no email received, hammmm, unfortunately i have to leave for today, please keep me informed, i am frustrated now need to know why?
and no email received, hammmm, unfortunately i have to leave for today, please keep me informed, i am frustrated now need to know why?
1 Like
Hi Al, for me, it looks like the table SysRptLst shows the last COMPLETE report that was run. After some testing, the ERROR reports don’t appear in this table in my system. I’m thinking the job traveler report appeared in your table only because that was the first time you ran that report with that server path?
Could the problem be that Epicor is moving the ERROR records to the SysTask table through a SQL database trigger instead of through an Epicor “process”. And a Data Directive doesn’t “see” records that are added to tables unless it’s through an Epicor “process”?
1 Like
may be @sport ,
my guess is the ‘error’ status task comes from another intermediate tables working based on calculated variables for many other rows which has no row mod status at all, thereby our conditions of adding/updating (changed row) at SysTask and SysTaskLog are not triggered at all, i.e. when task error out there is no tt values to validate against,
my other idea to solve this if i were you is to create an updatable dashboard and call all ‘Error’ records from the SysTask DB table, with a data filter, then use its Updatext BPM to create and send emails based on user selection or any completed task as a trigger to do this call.
Do you have Service Connect? I can guarantee that would work as a solution.
You could create a SQL job that runs every minute and sends an email IF any rows EXIST in the ice.systask table where status = ERROR.
Also if you have advanced printing and routing you could follow a solution here:
Dredging this one up again …
I’ve just had reason to revisit this for our system and can confirm that no BPMs fire when TaskStatus is “Error”. I can also confirm that Service Connect can fix the problem, though it’s annoying - we have a workflow that looks for error records in SysTask that match certain criteria, and updates the TaskNotes field (it doesn’t matter what goes in there, but we use “Error” for obvious reasons). Having another field updated DOES trigger any BPM that’s been set up to look for those errors.
are you saying, creating a UD field and cast it to the system field status in SysTask will work ?
No, basically because the directives don’t trigger when the TaskStatus field changes, you have to update any other field. It doesn’t need to be a new one - we used TaskNote. That triggers any BPMs and you can catch them how you like - we structured ours so the same ones worked either way.
Because essentially nothing appears to happen when these error records are created, there aren’t any triggers. Service Connect can work on a schedule so it doesn’t need triggers. If, when it runs, it finds that errors have happened since it last ran, it can update a different field and that DOES trip the triggers.
would you mind sharing your Working BPM here?
It needs two BPMs and a Service Connect workflow/input channel. Would you want all of them?
no, i just want to see how you did structure yours on TaskNote, if what you saying is triggering the update on this table then it is easy to do a stand. Data BPM trigger when TaskNote changed from any to any or not equal Null and taskstatus = error to send the email we want.
I think that’s all you need to know! You don’t need to see my BPMs because that’s pretty much what they do. We also do a check on TaskDescription so we only flag the ones we care about.
Once you are on 10.2.x PowerShell an REST API can do wonders =) Also if you havent seen something Epicor is working on Epicor Health Check API
To be honest, my first choice would be that they fix SysTask errors not triggering BPMs in the first place, but I’ll take whatever works …
2 Likes
That is why I built a report on the sys task table that runs on intervals of 5 minutes or so.
1 Like
ok guys, i have done some tests, to monitor this table status before, while, and after the Error record appears in it, the reason for this issue is that BPM is triggered, run In-Tran and Stad script before the record get to the final status which is Error in our case, the record appears on this table as Active, then when the task finished Epicor stamp the endTime and Status to this new record, with no method trace at all, at this time the BPM has already completed with no founding of any Error record obviously
Yes, you get a trigger for each of PENDING/ACTIVE/COMPLETE separately, but never ERROR.
But if something else changes the record the trigger will fire, and at that point you can take whatever action you like based on the error status.
yes, the only way is to create any scheduled task to run on every predefined interval and check all Error records on the Db.SysTask, but my question is how to avoid alerting about old ones? i am guessing that adding a condition to say within this period, and changing this scanning time period at each run
well this is the problem Daryl, you can not condition any of these PENDING/ACTIVE as you not yet reached the final status, also there is no screen to trigger any other changes within these records unless you force an update
PENDING and ACTIVE both work fine for me …?