Mark a transaction as failed, increase retry counter and postpone its reprocessing


Is there a way to mark as transaction as failed and get orchestrator to increase the retry counter but at the same time, postpone the transaction from being processed by, let’s say 2h?

  1. In my scenario, I’m looking for some data in a database and if not found, I want to mark the transaction as failed and increase the retry to 1 in orchestrator and I want this failed transaction to be postpone for a couple of hours.

  2. Assuming the database eventually gets updated with the relevant data an hour later, when the orchestrator triggers the relevant bot and attempts to reprocess the transaction 2 hours later, it will be successful.

  3. If on the other hand, the database still doesn’t contain the data and 2 hours have elapsed, the transaction will fail again and I need orchestrator to increment the retry to 2 and it will postpone it for another 2 hours.

  4. Finally, if the data is still not there 2 hours later (i.e. 6 hours has elapsed), I want the transaction to fail again, increase the retry to 3 and stop attempting to process it assuming it has reach its max number of retries as set on the queue in orchestrator. It probably will send an email to notify an admin.

A few things I don’t understand:

  • Why is a business exception not retried. To me, the above scenario, is a business rule that failed (i.e. data not found in database) but if I understood what the “Set Transaction Status” workflow states, it will not retry to re-process a business rule exception. Makes no sense to me, well, at least based on my scenario.

  • Does that mean that the only way to increase the retry counter in orchestrator, is to generate a system exception? This just doesn’t feel right, nor do I want to take a snapshot as per SetTransactionStatus when dealing with this kind of exception. Am I missing something??

  • Also when calling the postpone activity, I can see that it’s changing the transaction status from ‘failed’ to ‘new’ which isn’t ideal either but could live with it if necessary. What’s important to me here is that the retry counter does not get reset in orchestrator when this is called but since the status is changed from failed to new when calling the postpone activity, I’m concerned that it will reset the counter which would be a problem.

I haven’t checked yet if the number of retries remains when calling the Postpone activity as I haven’t gone through an entire process just yet.

What is the correct way to achieve this? Can this be achieved?


PS: Apologies for the lengthy post but I thought I’d provided as much detail as possible.

1 Like