DEV Community

Pravinraj Vincent
Pravinraj Vincent

Posted on Originally published at forum.uipath.com

UiPath Pitfall #3: Expecting Orchestrator to Retry a Business Exception

#uipath #rpa #orchestrator #automation

Your failed queue item never got retried. Or the opposite: the robot hit the same broken item three times in a row. Almost every time, it comes down to which exception type the item failed with.

This question shows up on the UiPath Forum every few weeks in one form or another, so it got its own Pitfall of the Week.

The mistake

Treating Business and Application exceptions as two labels for the same thing, "failed". Orchestrator treats them very differently.

  • Application exception + Auto Retry turned on for the queue: Orchestrator retries the item, up to the queue's max number of retries.
  • Business exception: Orchestrator doesn't retry it by default.

That's straight from the Set Transaction Status docs. With ErrorType set to Application, the transaction is retried according to the settings in Orchestrator. With Business, it isn't.

It bites in two directions

  1. A technical problem thrown as a BusinessRuleException. Say a page timeout or a frozen app ends up in the wrong catch. The item goes straight to Failed and never gets a second chance, even though a retry would probably have worked.
  2. A data problem thrown as a plain System.Exception. Missing invoice number, invalid customer ID. The item gets retried, fails the exact same way, and burns runtime. If the failing step is a login with bad credentials, repeated retries can also get the account locked.

In REFramework, what you throw is the decision

REFramework makes the split for you. In SetTransactionStatus.xaml, anything thrown as BusinessRuleException is marked Business, and everything else is marked Application. So the exception type you throw in Process.xaml decides whether the item gets another shot.

A data check in Process.xaml can be as simple as this (VB):

If String.IsNullOrWhiteSpace(in_TransactionItem.SpecificContent("InvoiceNumber").ToString) Then
    Throw New BusinessRuleException("Invoice number is missing")
End If
Enter fullscreen mode Exit fullscreen mode

In Studio you'd normally do this with an If activity and a Throw activity, but the idea is the same.

What I do now

  • Ask one question before throwing: would running this exact item again, unchanged, have a real chance of working? Yes means Application. No (bad or missing data, a business rule the item fails) means BusinessRuleException.
  • Validate input data early in Process.xaml and throw BusinessRuleException with a clear message. That way the reason shows up in the transaction details instead of a stack trace.
  • Handle a shared login failure in the Init state and stop the job, instead of failing every queue item one by one.
  • Let one layer own retries. The note on MaxRetryNumber in the REFramework Config.xlsx says it must be 0 when you're working with Orchestrator queues. So leave it at 0 and set retries on the queue itself (Edit queue, Auto Retry section).
  • Retry a single flaky step in place. If one step just needs another try right away, wrap only that step in a Retry Scope (Number Of Retries, Retry Interval) instead of failing the whole item.

Docs

Where do you draw the line on the gray areas, like a CAPTCHA, an expired password, or a target system down for maintenance? Join the discussion in the original forum thread: https://forum.uipath.com/t/uipath-pitfall-of-the-week-3-expecting-orchestrator-to-retry-a-business-exception/5785256

Originally posted on the UiPath Forum: https://forum.uipath.com/t/uipath-pitfall-of-the-week-3-expecting-orchestrator-to-retry-a-business-exception/5785256

I post short UiPath fix videos from real forum questions on my YouTube channel, RPA Simplified.

Top comments (0)