help desk software
+(800) 286-4232 info@ratchetsoft.com

When I meet with customers to discuss RPA, the conversation almost always includes a primer on the differences between: attended, unattended and hybrid bots. However, recently, this conversation has gotten a bit more confusing for customers because they now have worked the acronym “RDA”, Robotic Desktop Automation, into their vocabulary. Though the term is not new, it seems to creep up every now and then, and unfortunately, I don’t think it’s helping to clarify things.

For me, RPA is the global moniker used to describe the technologies and techniques employed to automate manual processes and integrate applications and data sources through a user interface. Yes, I know, automations don’t necessarily have to use UIs and should leverage APIs where available, but if there is a programmatic option available to integrate a process, why use a robot in the first place? But I digress.

Conceptually, whether these automations run on the user’s desktop or on a dedicated computer is not an important distinction because both deployment models should, if you’ve selected the right RPA provider, involve the same technologies and techniques. Sure, each RPA vendor’s platform needs to provide specific bot management and monitoring tooling to accommodate each bot style, but that should be a platform level concern and not the concern for the Automation Architect. Or should it?

As I wrote back in February, 2017 in an article entitled; “Attended Versus Unattended Bots…Aren’t They All Just Bots?”, I still maintain that “yes”, attended bots, unattended bots and now hybrid bots, are all just bots. The distinctions I drew in the article between these bot types revolve around use cases and invocation methods. If those distinctions are of interest to you, I recommend you give that article a read. However, while it is true that roughly 90% of the design and development processes are the same for all bot types, there are some technical considerations that should be made when designing and employing attended bots. These considerations mostly relate to the variability an attended bot will encounter on the user’s desktop.

Desktop Variability Issues

Unattended bots usually run on a locked down, virtual machine where state and configuration is either guaranteed, or can be reset to default without issue. However, attended bots do not have this luxury. Since attended bots run on, and interact with the user desktop, variability from user-to-user, or even from day-to-day for a given desktop, is a given and must be planned for. When I say “planned for”, I mean accounting for variability during the design phase, and allocating approximately 30% of your implementation budget towards performing variance testing.

So, what are the variability issues (other than invocation methods), you should consider when building an attended bot? Let’s take a look.

Desktop Scaling and Resolution

If an automation relies on screen paint and write APIs or OCR to interact with an application, anticipating the physical location of objects on a screen is critical. While offsets from guaranteed anchor points help alleviate this problem, varying resolutions and custom scaling options can wreak havoc on your automation. Hence, your attended bot automation should always perform a check on these operating system parameters in order to perform the appropriate calculations to find screen objects. While you’re at it, you should probably detect if the user has font smoothing turned on as well because that will impact your results if you’re using screen OCR.

Access To Accessibility

Accessibility is one of the most powerful tools available to RPA practitioners. When an underlying application is a well-behaved, accessible client, life gets more predictable and easier. However, not all applications implement or inherit accessibility in the same way. For example, by default, Google Chrome does not have accessibility enabled. Java applications are accessible but only if the Java Access Bridge is enabled. The take away here is, if your automation is leveraging accessibility, the automation should ensure accessibility is enabled for all applications involved in your automation.

Application Access Controls, User Types and Preferences

One common mistake made when building an attended bot is to develop an automation using the access controls, user types and preferences of the users who assisted in building the specification. This is a problem because applications may behave quite differently depending upon these factors, so you need to develop and test your automation across all applicable access controls, user types and likely user preferences. Also, be aware that during development, you are usually working on a computer that has OS-level administrative rights, rights that are unlikely to be present in production. So, if you need administrative rights to execute your automation (something you should avoid if possible), make sure you have them available in production.

Workstation Differentials

Applications may behave differently depending upon a number of workstation differentials. Make sure your variance testing plan contains the universe of options available in the production environment. The most common differentials include:

  • Operating system version
  • Browser version
  • Application bitness (32 or 64 bit)
  • Processor speed
  • Memory

Applications and Utilities Conflicts

If the desktop is not locked down, there is no guarantee the software your automation needs is installed as expected. Worse yet, something may get installed that conflicts with, or breaks your automation. A best practice is to perform a software scan on the variance test machine population to determine where potential conflicts may arise. Macro utilities often grab the same hooks your automation need to grab so pay close attention to those.  

Preventing The User From Interfering With The Automation

If an automation is executing on the user’s active desktop (i.e. not in the background), and needs access to the mouse and keyboard, it is important the user not interfere with the executing automation and create an unexpected state. Best practices to ensure desktop state predictability include the following:

  • Displaying a semi-transparent screen curtain informing the user that an automation is in progress.
  • Park the mouse and keyboard so the user cannot click or type while the automation is in progress.

 

Minimizing Bogeys

Popup screens that intermittently display in an application without any obvious reason are called “bogeys”. Though by definition it is impossible to plan for bogeys, there are ways to minimize their intrusion in production. The first is to review the automated applications and look for settings and preferences that generate intermittent messages such as; backup reminders, advertisements for associated products, reorder triggers, etc. These preferences should be turned off wherever possible. The second method is through testing, testing, testing. The bottom line is the more you variance test, both in terms of number of desktops and transaction volume, the more likely you will flush these bogeys out and either turn the preferences that trigger them off, or account for them in your automation.   

Reliance On Screen Detection Versus Timing

Inexperienced Automation Architects tend to rely heavily upon screen timing and pauses to control automation flow. Problems associated with such a reliance are less likely to rear their heads when running in a locked down environment. However, when developing an automation that’s intended to run on the user free-for-all that is the user desktop, it is a best practice to explicitly look for, and confirm the appearance of an anticipate screen versus assuming a pause will do the trick.

Consider Using A Hybrid Bot

A hybrid bot is a combination of an attended bot and an unattended bot where the automation is initiated by the user on his/her desktop, but then passes control of the automation to a remote unattended bot to complete the automation. Hybrid bots are mostly used to handle long running transactions thus freeing up the user desktop, or, where the user is needed merely to provide context for an automation (e.g. which record should the bot process now).

So, while most of the differences with regard to developing for attended versus unattended bots should reside at the tooling and platform level, there are some differences the Automation Architect should consider to help ensure the attended bot automation rollout goes smoothly.