- Getting started
- Best practices
- Tenant
- About the Tenant Context
- Searching for Resources in a Tenant
- Managing Robots
- Connecting Robots to Orchestrator
- Storing Robot Credentials in CyberArk
- Storing Unattended Robot Passwords in Azure Key Vault (read-only)
- Storing Unattended Robot Credentials in HashiCorp Vault (read-only)
- Storing Unattended Robot Credentials in AWS Secrets Manager (read Only)
- Deleting Disconnected and Unresponsive Unattended Sessions
- Robot Authentication
- Robot Authentication With Client Credentials
- Audit
- Resource Catalog Service
- Folders Context
- Automations
- Processes
- Jobs
- Triggers
- Logs
- Monitoring
- Queues
- Assets
- Storage Buckets
- Test Suite - Orchestrator
- Host administration
- Identity Server
- Authentication
- Organization administration
- Other Configurations
- Integrations
- Troubleshooting
Business Exception Vs Application Exception
It is important to choose the correct type of exception with which a transaction is failed, because this choice influences whether Orchestrator chooses to retry the transaction of the queue item or not, as follows:
-
An Application Exception describes an error rooted in a technical issue, such as an application that is not responding.
Such a situation is, for example, a project which extracts phone numbers from an employee database, creating queue items for each of them. These items are then to be processed and inserted into a financial application. If, when the transaction is attempted, the financial application freezes, the Robot cannot find the field where it should insert the phone number, and eventually throws an error.
These kinds of issues have a chance of being solved simply by retrying the transaction, as the application can unfreeze.
-
A Business Exception describes an error rooted in the fact that certain data which the automation project depends on is incomplete or missing.
Such a situation is, for example, a project which extracts phone numbers from an employee database, creating queue items for each of them. These items are then to be processed and inserted into a financial application. If a certain phone number is missing a digit due to human error, the queue item containing it becomes invalid. This causes the automation to throw an exception, as the Phone Number field in the financial application does not accept a queue item that contains an incomplete number.
Retrying the transaction does not yield any chance of solving the issue, and there are other better courses of action, such as notifying the human user of this error.
The Set Transaction Status activity can be used to shape the logic of your project in a way that encapsulates this distinction in several ways:
- If the Set Transaction Status activity fails the transaction with an Application Exception and the Auto Retry option in the Create Queue page is set to Yes when the queue is created, the queue item is retried.
- By default, Orchestrator does not retry transactions which are failed due to Business Exceptions. This happens because an inconsistency between the transaction value and the business requirement means that there might be errors in the initial data which the queue items were created from. Additional actions might be required to fix this type of issue, and logging this type of exception can be useful.
- An If or Flow Decision activity can be used to take different courses of action if a transaction is failed with a certain type of exception, such as using the Log Message activity to log a custom message or the Message Box activity to display a window containing information about the event.
Below you can see an example of such a project:
The screenshot below shows the mapping of the properties in the Set Transaction Status activity (on the left) and their corresponding fields in the Transaction Details window in Orchestrator.
The True branch of the Flow Decision activity sets the transaction status to Failed with a Business Exception, while the False branch sets it to Failed with an Application Exception.
