i know, this is what i’m saying, these status are not the one we need to target, it is the final status [ERROR], and until this status appears the table BPM will be finished.
You may have some overlap of a minute and see the same failed task twice, but throw the unique task identifier in there and you will know that it is a duplicate. It isn’t a perfect solution, but it will alert you. Also, using a report instead of a BPM saves you from any complications the BPM may cause in processing.
Yes, that’s my point. As @utaylor says, nothing will trigger when it errors, but those error records do then sit in the system to be read. His method periodically checks for those errors and reports them directly when new ones are found, and the “periodically” part is key because of the lack of trigger. If it looks for errors every five minutes and those errors have occurred in that time, you’ll get a report.
In our case we want specific actions taken in the system, so our periodic check updates another field, which DOES trigger the BPM and the error status can be seen and acted on then.
1 Like
good morning Daryl,
as @utaylor is doing which is scanning the endtime of each records in the DB and compare it to the run time of the task, as there is no tt table record or U RowMod what so ever at this stage.
how do you update fields in this table? are you forcing an update by code ?
Yes. Our way uses Service Connect because it’s easy to create a check on a schedule that way, but anything else that isn’t dependent on triggers from the SysTask records could do the same job, such as the report discussed here.
The method is SysTask.UpdateExt in our case, passing in the SysTaskNum found from the database query and a new value for the TaskNote field.
1 Like
Yep, we have email configured and working in E10.
it will only work for COMPLETED, not the other status ERROR, PENDING or ACTIVE.
The records are there for non-COMPLETED tasks, it’s just that the triggers don’t fire. So any other process which checks the database periodically will find those records and can take action for you as long as you aren’t requiring instant notification.
Hmmm … I just tested something last night and I got an email for Status = “PENDING”
Here’s the email. The highlighted fields are inserted Field Queries
what is your trigger ? i.e. SysAgentSched NextRun or systask TaskStatus ? i think you are using both
I’m using a Data Directive. SysTask (Standard)
the ERROR one did not work for me for sure, and the reason i explained before is the timing between the BPM trigger and the Record field creation time
If they’ve fixed it, great. Which version did you test on?
There were definitely no triggers firing in 10.1.400 and I haven’t had reason to test since we upgraded.
I’m on version 10.1.400.23.
And it looks like I only get emails for the TaskStatus equal to PENDING, ACTIVE, and COMPLETE
Granted I might have an error in my DD.
I’d think the the TaskStatus of ERROR should work, as I see it in the SysTask table when viewed as a BAQ. So it’s not like a SysTask record never exists with the status ERROR
EDIT
The bottom email was for a report that resulted in an error (no records selected). I got the PENDING, but no ACTIVE or ERROR
That sounds right. It was always the ERROR that was the problem, because it’s those that people commonly want notifications for. Hence our workarounds.
I really should go back and try it again to check it’s no different in 10.2.
it will be exists as record but no -final- value within the taskstatus field at the BPM firing moment