Hi Everyone,
I am currently looking for a good way how i would notify an admin that a Workitem exceeded its retries and therefore failed. Is there any good way to do this? I know there is push to queue on failed, but as far as i understood that sends it to the new queue even if it fails once not only if the retries exceed?
1 Like
Hey
That is incorrect. It pushes the item to the failure queue once it hits the retry limit.
So you could use a failure queue and then use an agent with some code or a Node-RED workflow to process those items and send an email.
If you have a licensed OpenCore, you can also use Grafana Alarm Manager to raise an alarm when a queue has a failed item (then it can do one of many different things, including calling a REST endpoint or sending an email).
Thanks the failure Queue is perfect then 
Sadly this seems not to work correctly
You can have a work around like this:
When WorkItem failed the last time you can set in the logic of retry/update WorkItem to push the details of that WorkItem to the another Queue. Same as above, but here only your package will manage it.
We have quite few, very big installations that uses this without issues.
Just to be 100% sure, you are ALWAYS setting workitems to state “renew” in openrpa/nodered/code when an items fails, right ? if you manually set it to failed, this will not work,
This might be the issue i am gonna double check thanks.
Yea sadly that is not the problem, i set the status from OpenRPA and set it to retry always.
Just to be safe, i did a test. I created openrpa1, use the workitem example but force it to fail every time in Process Workitem
Settings on openrpa1 queue
In my try catch in OpenRPA
Result:
Just for information, i don’t know if that is relevant or not, but looking at the workitems in the database they have:
“failed_wiq”: null,
“failed_wiqid”: null,
the queue itself looks good so:
“failed_wiqid”: “688223d36e761c9f76bc5e5d”,
“success_wiq”: “”,
“failed_wiq”: “Carlo Auftragsbestätigung_Failure”,
Yes, the idea is to set the DEFAULT on the queue. However, you can create custom logic while processing an item that sends the individual item to a different queue on success/failure and overrides the setting on the queue. This is so you can handle more complex processes.
Hmm then i don’t understand why it wont work, anything i can look at to figure it out?
Ok i found what makes it not work, but not why:
If i enable automatic queue triggers it does not work the moment i turn off the automatic queue trigger it starts working. I Hope this is not intended?
Sorry for the late reply, I’ve been in a ton of meetings.
I’m not sure what you mean by “automatic queue triggers”… Can you send a screenshot of where you enable/disable that?
Sorry probably wrong wording, what i mean is when a bot is triggert by a new item in the queue, like this:
If i remove this and just pull the items normally the failed queue works if its triggert by this it does not.
I don’t know what you mean by “pull the items normally,” but if you mean using some external tools to schedule the robot to call “pop workitem,” then no, that makes no sense to me. It should not matter HOW a workflow was called, as long as it calls Pop Workitem and calls Update Workitem with either state “successful” or “renew” at the end.
I’m super curious now. If you can do a basic setup that shows it working and not working, I would love to see that?
Yea what i mean:
-
If the Bots are triggered via the Queue setup as shown above the failure queue does not work.
-
If i start the workflow manually via OpenRPA clicking on Play and have the above setting disabled it works.
I am going on vacation next week, after i return i can try to reproduce it with a super simple setup and we can see if its just a problem on the complex setup.