Robot Execution Mode

In Smart Re-execution mode, the way that the robot is executed in Design mode is similar to the way it is executed at runtime or in Debug mode. This is the default mode for Basic Engine Robots .

As an example, when you click step C in the following robot, it automatically executes through the bottom branch of the Try construct when the test fails in the Test Value step:

The blue exclamation mark icon on the Test Value step indicates that the error handling to Try Next Alternative was triggered.

With loop steps, all iterations up to and including the selected iteration are executed when clicking a step inside the loop.

In the following example, clicking step C causes execution of three iterations of the loop.

Further, if clicking a step in a branch below a loop, all iterations of the loop are executed. As an example, see the following robot.

Clicking step D causes execution of step A and repeated execution of steps B and C (as many times as there are iterations in loop B) before finally stopping at step D.

The Smart Re-execution mode is particularly useful when working with global variables, and when you have subsequent steps in the robot that depend on accurate variables. This mode may be useful for building a payload for a web service (REST or SOAP) call, or constructing an Excel document. The XML or Excel document that is being populated resides in a global variable, while its content is added during the execution of a loop. In a branch below the loop that populates the document, the robot takes the entire document and posts it to a web service or similar. In this case, the Smart Re-execution mode makes it easier to build the robot, as it ensures that the document is populated when testing the web service call in Design mode.

In Smart Re-execution, the interaction with the external world in the form of websites, databases, or web services is cached. Caching avoids re-execution of steps unless the prerequisite for storing the execution result has changed (such as a variable that determines which URL to load). Smart Re-execution has a higher memory footprint than the Minimal Execution mode.

We do not recommend Smart Re-execution mode for large robots with significant interaction with the external world, or for long-running robots. The execution time as well as memory usage are too high in these cases.

To cut down on the execution time while designing the robot, you can right-click a branch and disable it in Design Studio. A similar setting can be applied in Debug mode. Additionally, you can disable the branch based on a specified condition in select iterations.

Connection configuration

The Design mode tab of the robot configuration also features an option "Avoid External Re-execution". When checked, it is ensured that steps are never re-executed, even when the cached result of the previous execution cannot be used. In this case, you can still edit the robot, but without a current input state to work on. Use this option only to meet requirements for interaction with the external world to avoid re-execution (for example, if re-execution would result in incorrect or duplicate data in a partner's system).

The Minimal Execution (Direct) mode is the traditional Design Studio execution mode. All robots written in versions prior to 9.5 will use this execution mode.

When you click a step in Minimal Execution mode in the robot graph, Design Studio takes the shortest direct path to that step, skipping any previous branches and iterations that are not on the direct path.

Consider the example below:

During runtime execution, the robot would normally execute steps A, B, C and D before reaching step E. But in Design mode, clicking step E result only in the execution of steps A and D.

Similarly, if the step resides inside a loop, only the selected iteration is executed.

As the iteration counter is set to 3, clicking step C cause only step A, B and C to be executed once, where step B selects the third iteration.

The Minimal Execution mode is optimized towards executing as few steps as possible. This mode is useful when you have large robots and steps that take considerable time to execute, such as steps that interact with complex websites. Generally, we recommend Minimal Execution for most data collection use cases and for robots that perform significant interaction with external sites.

The drawback of Minimal Execution mode is that it requires user assistance to select the path to a given step whenever it cannot execute directly to the step using the default path; for example, try steps in a path may prevent a robot from following the topmost branch.

See the following example.

When clicking step C, Minimal Execution mode is not able to proceed if the test fails in the Test Value step. In this case, the user must explicitly click the bottom branch of the try step first, to guide the execution path towards step C.