Explore RPA Unit execution lifecycle

There are two generic approaches for the RPA Unit execution:

• One record per transaction
• Multiple records per batch processing in one transaction

Both approaches have their pros and cons. Refer to the image for more details on RPA Unit performance in terms of time:

It is recommended to create one record per transaction execution logic and only then to investigate whether it is required to use multiple records per batch or not.

Multiple records per batch

Let's see the example when three records are executed in one transaction. The login operation is not time-consuming, taking from 10 up to 30 seconds to perform. Major business logic is encapsulated inside the red square block, and executing a separate record takes 1 to 40-50 minutes to execute a separate record. That block can have stability problems and fail with any RPA processing or business logic issue.

In case of a failure, the whole batch with three records fails, and the RPA Unit is relaunched from scratch.

The SLA for a single record is equal to that for the whole batch.

The only generic benefit is that this approach is less time-consuming when the logic is simple and the execution is straight enough to finish processing. However, it is more unstable when the execution of a single RPA Unit is associated with complex business logic or long execution time.

One record per batch

The one-record-per-transaction approach is preferred in terms of SLA as one record is processed in one go and reaches the export plugin as soon as possible. That record is immediately ready for the next RPA Unit. In case of a failure, it is relaunched independently without interrupting the remaining records.

The SLA for a single record is equal to that for one transaction.

An increase in the execution time of business logic significantly reduces the effect of login and logout operations in terms of the total execution time. It also leads to a decrease in the share of these components in the total execution time.