How do I make my robot process unattended?

(This is not about setting up an unattended robot)
Taking this article in account: Attended vs. Unattended Automation, robot processes often start attended and the later are put into an unattended orchestrator environment.
But during this step the robot process might no longer work. Is there somewhere documented how to make a (former attended) process compliant for a unattended robot? Meaning which activities and activities settings are recommended and which should be avoided or are not supposed to be used.
As for an obvious starter: the Message Box requires user attention and there should not be used in an unattended robot process.
But it get vague, where it concerns settings as e.g. the Click activity, see e.g. Using click, Type into and send hot key as a unattended robot.

Is there a formal document which describes the Do’s and Don’ts for an unattended robot process?
Or even better, is there a automated validation that checks for unattended robot compliance?

2 Likes

There isnt a certain documentation that will go over every little thing about how must be every activity and its settings for the process to be good for unattended, but all documentation, academy content etc will make a developer know those things, i dont think there is also some validation tool to validate this as it could be hard to do and its value would be for most of not that great…

1 Like

I personally have not run into any challenges of Attended vs Unattended, Although I haven’t specifically built an attended process, while developing and running the process it is considered to be attended.

Can you provide examples scenarios that you are aware of?

Something like the Message Box is not recommended to use in an unattended mode, but not because it won’t work or that you can’t acknowledge the alert in the sequence… to me it is more of why would you use it if no one is there to ‘see’ it when there are better ways to handle the flow.

When talking about Clicking and Typing type activities you will generally be thinking about using the Default, SendWindowMessages, or Simulate modes but it is more to do with support of which applications you are interacting with as well as potential interference of a user or another process.

  1. Default Slowest of the three methods, using the hardware driver. It does NOT automatically erase pre-existing text nor does it work in the background, but supports special key strings (e.g. [k(enter)] )
  2. SendWindowMessages It does NOT automatically erase pre-existing text but does work in the background while supporting special key strings (e.g. [k(enter)] )
  3. SimulateType is the fastest of the three methods. It automatically erases pre-existing text and works in the background but does not support special key strings (e.g. [k(enter)] ), in this case, you’ll want to pair it with the Send Hotkey activity.

This is something that you want to think about when you are building an Attended or Unattended process.

I think there might be more of a consideration between Attended Foreground processes or Attended Background processes in which the later shouldn’t have any activities that require user interaction.

2 Likes

Hi @iRon
while im agree with @codemonkee @bcorrea
let me give you some information related this

actually your idea is good , but i hope the uipath docs dosent need to contain like dos and donts
because if its continue they have to endup with large amount of document and as users also the developers and the references have to read all of those in order to take the idea

uipath docs design with the main sprite only i hope , so if you go through the UIPATH academy , basically they talks about lot regarding what will not work / what will be work
and what are recommended things

as the example for your attend unattended recommendation it was clearly define in “Infrastructure Engineer” course in UIPATH ACADEMY

1 Like

Thank you all for the comments,
They confirm what l already knew (I did all UiPath academy levels).

The point here is that I have been assigned a task to rework a process (that I didn’t develop myself) to an unattended Orchestrator robot.
Apart from the Clicking and Typing type activities -were it isn’t always that obvious to change it to something else then Default due to the other constrains and limitations-, I suspect that other activities (like the terminal activity?) to get unstable once started unattended.
Besides, an addition problem in this case is that the environment deals so now and then with a slow network which makes it very hard to trouble shoot and exclude both issues from each other (Activity timeout exceeded)…

Just found some clear prove that “making your robot process unattended” is easier said than done:
In the specific (KBDPro) application, when clicking an item on the menu bar during run time, I get the following message when I check either:

  • SendWindowMessages
  • SimulateClick

Source: Click ‘menu item <menuitem>

Message: Action not supported by this type of element. Please use another type of click.

Exception Type: UiPath.Core.ElementOperationException

Meaning only the default click selection (where both are unchecked, and doesn’t work in the background) can be used.

Hi iRon,

The examples you are alluding to are not because of an running a process with an unattended Robot, they are simply methods in which you can interact with the UI elements that will work for both Attended and Unattended jobs. If the process you have been handed to rework is giving you as much trouble as you suggest, I would probably rewrite it from scratch if possible taking the pieces that could be reused… this may help to identify where improvements could be made.

Where you would use one over the other is if you have a process that needs a lot of human involvement with some steps in-between that can be automated or where you would like the robot to guide or assist the human user.

Changing a Type or Click activity from Default to SendWindowMessages or Simulate can be used with both types of Robots, they are both interacting with the UI and they both cannot interact with the UI if you were to say lock the session unless you used a non-default mode; using an Unattended Robot the session is not locked so you can use either mode.

For your example of KBD Pro, I’m not sure what the underlining framework it was built with, but from their website, the small image they provide it looks Java(?) in nature which has its own security components which could be preventing you from using certain interaction modes such as SendWindowMessages/SimulateClick. These security constraints can be simply client configuration or they could be intentional (or unintentional) configuration of the original developers of the application in question. In any case, I would expect you to have the same trouble if you were to run the process attended or unattended.

Thanks again for your response. I have no clue whether the KBTPro application is written in Java (it could very well be the case) but I don’t think it concerns security constraints as is concerns simple menu items. Saying that, so far I am able to work around my issues with sending shortcuts (e.g. Alt-f for the &File menu).
I guess, I just wanted to mention that it is not always as easy as selecting either SendWindowMessages or SimulateClick to make an attended process unattended knowing that the process did run fine before with the default selection (both unchecked)…

It sometimes be for security reasons, or just the way the developers made the application (assuming Java), and could also be to do with Accessibility which is handled by the Java Access Bridge and disabled by default.

I would confirm if it is a Java application and if so that the Java Extension and Java Bridge is installed correctly.


https://docs.oracle.com/javase/accessbridge/2.0.2/introduction.htm

There are additional documentation on testing Java Bridge via their Java Ferret and Java Monkey example. Based on the Java documentation I’ve read in the past, I believe the Java application must also make use of the javax.accessibility package. You should also be able to find jaccessinspector and jaccesswalker in your JRE/JDK that can be used to test. As an alternate, could test with other assistive applications such as a screen reader.

I have had similar issues to what you describe specifically with a couple Java applications, one of them I was not able to work around beyond using keyboard shortcuts and tabbing, etc. And the other one I was able to use the other Type/Click modes after fixing the Extension/Bridge on the host the Robot was running on (which happened to also be a VM where I was running Studio).

But again, I would expect you to have the same issues locally in Studio or on an Attended Robot. SendWindowMEssages / SimulateClick is not exclusively for an Unattended Robot.