I am currently building an bot on the REFramework template. On a very high level, it takes in data and inputs it into a variety of 7 different websites (using a switch statement to know which one). The ultimate goal of the bot is to be unattended, which I have never done before. Are there any tips or best practices I should know of before continuing out development since it will be unattended? It will go through some relatively rigorous testing and efficiency metrics before being implemented
Using REFramework is the best starting point for unattended automation.
As mandatory thing, ensure you haven’t included any Dialogs (message or input boxes)
Other recommendations are:
- Ensure you are using same versions for Studio and Robot (Unattended)
- Check the environment to ensure there are no undesired popups when logging in or when opening the browser for the first time
- Ensure UiPath extension is installed and enabled in Robot machine
These are common tips, not specific to the design of your solution in particular
Hope it helps
1 Like
Few that I can recall right away:
-
use as many assets as possible to keep the stuff like website URLs, username passwords for login, email ids to send execution reporting to etc separately for dev and prod environment.
-
Take a note of the screen resolution you will be developing your process in. This is very important as when robot logins in to run a process, it needs to be a same resolution for successful interaction with hi elements on websites.
-
for automation, try to keep the orchestrator folder property empty for activities wherever it is needed. This ensures which ever process your automation runs from as unattended, assets are read successfully. Specifically providing folder name can sometimes cause issue’s especially when folder names are different in dev and prod environments.
-
for selectors, identify the difference and common pattern between main dev and prod urls. Keep the common part in the title(and few other where required) property of the selector and use wildcard for the rest part as title name can be different for dev and prod version of the website.
-
use more and more of check app state property especially on different landing pages to ensure a particular page is loaded properly before interaction with its ui elements.
That’s all I can think as of now 
Rest some of the points have already been specified by @dokumentor
Hope this helps.
Regards
Sonali
1 Like
Use Orchestrator queues for input if possible. Avoid UI prompts like Message Box. Handle all exceptions with proper Try-Catch. Use Retry mechanism in SetTransactionStatus. Log clear business or technical info with Log Message. Ensure assets and credentials come from Orchestrator. Use Kill Process to close browsers at Init state. Design to run headless with no human intervention. Use Config file wisely for all dynamic values. Test all paths including success, failure, and business rule exceptions.
Happy Automation
1 Like
How often should I be adding in Business Exceptions in my Process.xaml? I will likely add it + throw in to check basic rules for my data, but what should I be doing to handle website entry errors/exceptions? What if a data point doesnt enter or enters incorrectly? Thanks for all your help, the whole Try Catch is a bit new to me as I decipher which part of the workflows need editing and which don’t.
If you use REF properly you can levarage its retry mechanism, if you set InitAllApplications and CloseAllApplications correctly.
Regarding exception handling if you want to apply some kind of validation to control one of the steps performed by the robot, do it and then throw a System Exception if you condsider the transaction has to be retried or a Business Exception if not
Depending on th case some other specific Business Exceptions may apply
Regarding this, please go through below doc to understand more about business exception and system exception. In brief, I would say business exception is more related to data entry/validation/missing errors. But system exception is related to application not responding, element not found errors. You can throw as many as required exceptions per your process flow. 1 key point to note is txns throwing business exception are not retried but system exception ones are retried if retry mechanism is enabled.
I’m abit late to this Ryan,
But whats the reason you have to put all 7 websites into the same bot?
Often doing that makes the code much harder to understand and test and more difficult to maintain.
For example, lets say one website changes, well to do proper testing practices on that, before you push the changes for that one website to prod, you have to test the existing code for all 7 websites to make sure you didnt accidentally change something.
This is just one example, but just understanding the code can become much much harder.
I also imagine it creates quite some mess in Application Start and Stop, since you dont know which site you need to input into before you get a transaction (I am assuming the target portal is in the queue item) then you need to open all 7, which is slow and messy.
What if one portal fails to log in, even if you dont need that portal the error will stop the Framework from continuing and you cannot process any queue items.
Either that or you have some messy logic to fully log in and log out as part of each transaction. This is also ugly because if, for example, a password expires, then dozens of queue items can incorrectly be marked as failed when infact they could have likely been processed perfectly fine and avoided failing if the login was done in the normal way in application start.
I would recommend you consider splitting this into 7 distinct robots, each with their own queue, and manage which one is picked up that way in your dispatcher or whatever is making the queue items.
1 Like
Hi Jon this is very helpful in tackling really what I wanted to. It is a bot that files taxes in their respective state websites when iterating through the populated queues with that tax filing data (about 40 rows per month). Each state has its own navigation steps through their website. Within REF, I was actually not opening each website in Start and Stop Applications… I was just opening the necessary state link when that state’s workflow was invoked (Main–> process transaction → process → switch statement to invoke state workflow).
For why I chose one file, I guess it just feels easier to me to build out one file with some forks instead of managing 7-8 different files as well as being more scalable (which will be built out to 10-12 states in the future). The worry of one state’s website breaking did actually come up with the devs. They warned of this when i was NOT using REF, and it made sense as to why the bot would break. However, I may be wrong, but I though the utility of REF was that if one state’s website breaks down, those transactions will fail but the rest will not? Thanks for all your help