(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?
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âŚ
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.
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)] )
SendWindowMessages It does NOT automatically erase pre-existing text but does work in the background while supporting special key strings (e.g. [k(enter)] )
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.
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
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.
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.
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.
Yes, that is indeed the case but I just need to select either SendWindowMEssages/SimulateClick to make it unattended. Meanwhile, I have been able (most) of the Robot process to an unattended version. I will need to dive into Java Bridge information to confirm your suggestion.
ashokkarale
MD_Farhan1
Ajay_Mishra
postwick
Dheerendra_vishwakarma
Anil_G
chandreshsinh.jadeja
Gautham_Pattabiraman
vrdabberu
aravindbalineni123