Once thing that is missing in my opinion (also in the REF itself) is the option to retry a failed init.
Say your init opens up your main application. But unfortunately your IT department sucks and the application is unstable. Sometimes it takes 2-3 attempts to log on. NOw of course you should adress that issue on its own with your IT department, but we all know how this works. It will at least take a while…
Being able to loop through the init with an x number of retries greatly increases the overall stability of your RPA on an unstable IT landscape.
We have a few of those cloud based tools where we increased effectiveness of the bots by 50% just by implementing that in our (unattended) REF.
Attended I’d throw the choice to the user. It will create awareness that the non-functioning part of the automation is not RPA related, but IT stability. So RPA won’t get blamed for other’s failures. And it gives the user a sense of control on how they spend their time and patience.
I’m watching the second video of this framework. The Business Exception messages are stored in the Config file, which adds to the flexibility. But if the Config file is part of the deployed package, and if the user comes back requesting that the BEX message be updated , do we have to update the Config file with a new message and then roll out a new version?
I’m asking because, we externalized the Config file as one of the first major changes to the RE Framework. The Config file is published separately and our Attended Automation users download the file, and then pass it as an Input parameter to their automations.
In addition, we have added a tab named User Managed to the Config file and trained our end users to update existing settings on the file to suit their requirements. Obviously, due-diligence is involved during the requirements gathering phase to determine what is a user managed setting and what isn’t!
We did this for three reasons. First, we wanted to avoid needless redeployments for the sake of minor changes. Second, our Attended Automation team is split between several geographic zones. The statuses, business attributes, communications, etc. were different based on their location and their clients. And third, each team followed a slight but significantly different method of the business process. Therefore, they would adjust the bells and whistles in the Config to influence the change in behavior of the automation.
I think our frameworks must take these aspects into consideration, at least as an option.
Thanks for the feedback @AndyMenon. I was just thinking about this earlier today and the design you mentioned isn’t uncommon amongst attended automations. You’re correct to assume that currently you would need to republish a new version to update the BEX message. We’re updating the framework for 22.10 and we would like to provide several methods to store the Config file.
Locally (how the current implementation works)
Retrieved as an Orchestrator Asset
Retrieved from developer-designated location
I am assuming you are using Excel (rather than Forms/Apps) to allow users to configure their automation). Are you still using a UI (e.g. Apps or Forms) to prompt the user for the Config file path?
Correct. Excel works well for Finance teams. Unfortunately, our SOC does not allow us to work with Apps as it will mean going out to the Automation Cloud. We have resident Orchestrators. The Config Path is an input argument to the Main.xaml file which users can then populate via the UiPath Assistant and save it as a one-time setting.
I like the status updates, but tried wrapping each status update in a separate workflow, and then use the Invoke Workflow File activity to have the status shown in the Main session (when running PiP). This didn’t work, maybe due to some WPF stuff…?
Hi Jeppe, thanks for the feedback. I tried playing around with it and may have found a workaround.
In the Main.xaml, put a “Progress Window Show” as the first activity
Expand the Advanced Options and provide an “Inter Process Pipe Name” string
Next, put your automation logic in a workflow and invoke it
Set the invoke to isolated and Target Session PiP
Inside this workflow, you can use “Progress Window Change Message” and make sure to include the “Inter Process Pipe Name” string in each activity
End your Main.xaml with a “Progress Window Close”
Include the “Inter Process Pipe Name” string
This will display the status window in the main session, switch to PiP for your automation logic and send messages back to the window in the main session.
I found the attended framework very helpful. I really like the form that is included and the ability to update it as the process executes to give the user insights on what the bot was doing.
I had a use case where the attended framework was using queue items. The bot gathers data from SAP (dispatcher) and enters it into a website where the login required a mobile app code for MFA. I did not see an option to use a queue with the attended framework so I had to add those pieces myself. If this could be include in the framework that would be helpful
This is a great idea, currently I having being modifying the current framework for my attended automations but having an actual stable framework would be much easier! Am looking forward to the official UiPath realease
Hi everyone, we’re nearing the completion of version 2.0 of the attended framework. I’d like to share it with this group first to get initial thoughts and feedback.
It might depend on the definition of “official UiPath version” but you can find in the Marketplace the Attended Framework shipping as a UiPath made component:
I was referencing Tuan’s statement (see quote below).
Based upon context, I am assuming Tuan is referencing an official version of the “UiPath WPFInteractive Activities” activity package, since that package is currently published by Internal Labs, and therefore only comes “with Community Support (as opposed to Official UiPath Support)”.
I would love to know whether activity packages we are considering have official support, or would only be subject to support “on a reasonable effort basis by the developer that created them”, as “reasonable effort” support carries concerns (e.g. the developer is inundated, leaves UiPath’s employment, etc.).
vrdabberu
lrtetala
Yoichi
Anil_G
postwick
Parvathy
pravallikapaluri
Stef_99
phuc_trinh
DimitriLYR