Robot Best Practices

Optimal robot utilization begins with your wizards. Optimize your wizards for faster run-times as follows:

• Avoid static pause times. Instead, use variable waiting mechanisms, such as programmatic loops, the Wait for object to appear action for visual elements, or the Wait for window to appear action for windows.

  

• If you use programmatic loops to find data, be careful to avoid infinite loops, such as the one shown here.

  

  Break the loop as soon as you find what you are looking for. This saves valuable time, which can really add up in the long run.

  

• For large transactional processes, consider using a database instead of Excel. Databases are faster to write to and query, and can be accessed by multiple robots at the same time. This is unlike Excel files that can only be accessed by one robot at a time.

• If you have a wizard that first processes a list of records and then performs similar work for each record, consider, if feasible, splitting your wizard into multiple parts. For example, you could have one record collection wizard that goes through the list of records and collects the relevant process data, before triggering a second wizard (using the Add automation task Advanced Command), once per record, to do the actual work.

  In this way, you can distribute the actual work across multiple robots, improving robot utilization and the speed of the wizard throughput. In addition, if a wizard fails, it only fails for one record, which means that you only have to reprocess that record, rather the running the entire input file again.

  

  See this entry on Nintex Community for additional information.

When you record your wizards, visually optimize them to improve robot performance as follows:

• Optimize the click area settings, so that the object can be found within the smallest click area, rather than falling back to searching the entire screen.

• If the object is a text string, change the detection method to text only as this is much faster than image and text.

• If your application window size is always fixed, consider using Fixed or Relative positioning instead of Detected Object.

• When interacting with applications, use Native API Advanced Commands or keyboard shortcuts whenever possible. Try and use APIs where you can. For example, use a currency converter API if you want to convert currency, rather than manipulating a converter web page with either visual automation or HTML commands. In general, these methods are potentially faster than the visual algorithm, but this can vary depending on the application in question.

  

Ideally, ensure that all possible outcomes of a given wizard are handled, so that the wizard can always end in a timely and clean manner, even if things go awry. Doing so can potentially get a robot back to work quicker, even if a wizard cannot complete successfully.

For example:

• Use adequate Wait for object to appear or Wait for window to appear times when working with object and window detection in Nintex Studio. Remember, these are only potential wait times, not absolute times. As such, you can safely increase this number (in seconds) to compensate for potentially longer wait times in applications.

  

• Use programmatic retries such as repeating a step or using a loop in case a single step fails. For example, this can be useful when you are waiting for a menu to appear, or trying to access a file that might not yet be available. Retrying the step can help you circumvent an isolated issue and save a lot of time, rather than having to fail and start the entire wizard again.

  

• Use the Add automation task Advanced Command to re-trigger a wizard that has failed. For example, you can program a wizard that if a client application on the robot system does not react, the wizard should close all client windows on the system (kill the Windows processes), and then run the wizard again by creating a new automation task.

  

  Assuming that this is a viable option for your use-case, this approach often enables you to react to problems more quickly, rather than waiting for the next scheduled wizard run. This can potentially add up to a lot of saved time, thereby increasing throughput.

  You can create infinite loops this way, so be careful!

Organize your robots into teams according to their capabilities, such as their available applications, or their access to certain subsystems.

Using robot teams enables you to better distribute the workload across all available robots. For example, you can specify that the first available robot in a team should run a wizard, rather than specifying a specific robot, which might be busy or inactive when the wizard needs to be run.

If you have long running wizards and short running wizards, consider using robot teams for each type. You don't want a long running wizard to tie up a robot (or team of robots) when there are many shorter (and possibly more SLA-critical) tasks to be completed.

You can organize your robots into teams using the Nintex Console, as described in the NintexConsole User Guide.

Set the Queue Priority for triggers to ensure that business- or time-critical tasks are handled before other tasks.

When you create or modify a trigger, you can set the Queue Priority as Normal or High. The priority determines where the task activated by the trigger is added to the task queue, to await assignment to a robot for execution.

• Normal priority tasks are added to the bottom of the task queue.

• High priority tasks are added to the top of the task queue, behind any other high priority tasks already in the queue.

You can manage triggers using the Nintex Console, as described in the Nintex Console User Guide.

Choosing the correct trigger type can greatly optimize process performance and increase operational responsiveness. To minimize wait times or time lag, choose the trigger mechanism that most accurately reflects the starting point, frequency, and input of your use case or workflow.

The frequency is particularly important when you are working with time-based triggers.

For example, consider a wizard that, upon running, checks a queue via REST/API to see if records are available for processing. The wizard only performs the rest of the process if records are available.

This type of trigger can be run at a high frequency, as there is almost no risk, as long as the wizard ends successfully if no data needs to be processed, and the Prevent overcrowding the queue option is set for the trigger, so that duplicate tasks are not added to the queue.

You can create and configure triggers using the Nintex Console, as described in the Nintex Console User Guide.

The system can send email notifications when important events occur, such as when a robot is added or stopped, when a task is created, or when a wizard encounters an error. Configure these email notifications according to your business needs and goals.

To optimize robot utilization, ensure the system is configured to send notifications if something goes wrong in a wizard, so that administrators can react accordingly and get the robot back to work quickly. If successful wizard runs have a manual followup process, be sure to notify the corresponding parties or endpoints when wizard complete successfully.

For added flexibility, use the Send email message Advanced Command to program your wizards to send notifications at any step in the workflow.

You can configure notification settings using the Nintex Console, as described in the Nintex Console User Guide.