Re Framework UiPath
Re Framework UiPath
Re Framework UiPath
Analysis
RPA lifecycle begins with Analysis as its first phase. Business team and RPA strategic/Architect
work together to understand a business process for RPA development. This analysis is done
mainly to identify the feasible processes for automation, save the manual effort, and bring Rol.
Bot Development
The developers of RPA team focus on requirements in their environment possibly a diverse dev
environment.
Testing
Testing carries out by following the two approaches as below:
A script/bot can be updated if any change comes in a process and in case any issue occurs in a
bot then the same bot can be re-deployed by repeating the dev-test process.
Low code structure : Code is written very clear ,proper commented and reusable
functions for understanding to any developer.also Main.xaml bringing structure to
the process design architecture
Re usability : Used code can be reused in any place because mostly used
functions.It work for any type of process and independent of data
sources(QueueItems, local excel files, Database data, API retrieved data).
Best Exception recovery and retry mechanism : Step by step exceptions is
managed by the framework layer also we can easily configure retry rules.
Audit and logging mechanism : Step by step tracking the bot’s work,with as much
detail and privacy as you choose with the new workblock concept. we can configure
log and generate the log for easily tracking activities of bot.
Maintain, extend and upgrade easily: we can easily maintain the coding structure
. Extend to achieve process behavior by editing 6 empty workflows that connect to
the Main.xaml in a standard way. Upgrade or extend framework independently of
business code, by editing only one file, the Main.xaml in re framework.
Separation of concerns: Very good idea to separate from business logic code,
allowing developers and SMEs alike to focus on building processes.
3). Why learn Re Framework ?
Ans : – To Automate a complex process which has defined states.
To clear RPA developer examination.
4). What are the Key Features of Re Framework ?
Ans:-
Extensive logging
Uses State Machine and comprises of Sequences and Flowcharts within
Error handling and retry mechanism
5). What are components of Re Framework ?
Ans:- Following are the four components of Re Framework.
1). Init :- firstly all the data which is written in config file is read and convert it into
dictionary form as key value.
below are sub parts of Init.
Below are the sub components used for initialize the setting and kill the process after work
done. Out put of this process will be in form of Config(Dictionary)
1). InitAllSettings
2).KillAllProcesses
3). InitAllApplication
3). Process: here we can process the business data and get the completion status of the job.
Transaction Item -> Process -> Completion Status
Config
1).Process
a).SetTransactionStaus
b). TakeScreenShot
c). CloseAllApplications
d). KillAllProcesses
2).Completion Status
4).End Process : Used for check the status(pass/fail) and according to it close it.
Status -> End Process -> Done
EndProcess
1). CloseAllApplications
2). KillAllProcesses
Step 1: Copy its folder to your project location and rename it to current your project
name.
Step 2: Go into the project folder and, using any text application such as Notepad or
Notepad++, open the project.json file. Write the project name you defined in step 1
into the “id” field. Write a project description into the “description” field. Save and
close the file.
Step 3: Open Main.xaml, navigate to the Init State and change the value of the
logF_BusinessProcessName field from the default “Framework” to your business
process name.
8). What are the key points during developing the framework robot in UiPath?
Ans:- Below are the key rules, keep it in mind during developing the robots.
10). What are the different types of logs stored by UiPath Studio?
There are mainly 2 types of logs in UiPath studio:
1. Default Log or System Generated Log: These logs are generated by default when the
execution of a project starts and ends, when a system error occurs and the execution stops,
or when the logging settings are configured to log the execution of every activity. The
events logged by this category are:
Execution Start is generated every time a process is started.
Execution End is generated every time a process is finalized.
Transaction Start is generated every time a transaction within a process is started.
Transaction End is generated every time a transaction within a process is finalized.
Error Log is generated every time the execution encounters an error and stops.
Debugging Log is generated if the Robot Logging Setting is set to Verbose and
contains, activity names, types, variable values, arguments etc.
2. User Generated Log: These logs are generated according to the process designed by the
user in Studio, when using the Log Message activity or the Write Line activity.
11). What are the types of SSL or Web Certificates required for communication
between Robots and Orchestrator in UiPath?
The name of the certificate you provide when prompted by the Windows installer, or the
one mentioned in the command line using -sslCertificate is the same one that appears in
the Issued To column in Server Certificates in IIS
12). What are the issues and limitations of using Native Citrix support for Citrix apps
in UiPath studio?
There are a few limitations of using Native Citrix support for Citrix apps in UiPath
studio:
1. Interactive Selection Does Not Work With High DPI: Interactive selection does not
work for Citrix Apps when the display DPI scaling is higher than 100%.
2. Upgrading to the Citrix Workspace v1810: After you upgrade the Citrix Receiver to
the Citrix Workspace, the UiPath Citrix Extension is automatically uninstalled. In
order to re-enable Native Citrix automation, you need to reinstall the UIPath Citrix
Extension. After upgrading to the Citrix Workspacev1810, the UiPath Citrix Extension
becomes corrupted. This is a known issue with this particular version of Citrix
Workspace, and prevents you from opening any Citrix Apps. To fix this issue, you need to
reinstall the UiPath Citrix Extension and then restart the Citrix Workspace.
3. Automating Browsers as Citrix Apps is Not Yet Supported: Browsers published as
Citrix Apps are not yet supported. This means that you can not generate selectors for them,
and activities such as Attach Browser and Navigate do not work. Support for browsers as
Citrix Apps is to be implemented in a future release.
4. The Citrix Receiver for Universal Windows Platform (UWP) is Not Supported: The
UiPath Citrix Extension can not be installed for the Citrix Receiver for Universal Windows
Platform. This also applies to Citrix Workspace for Universal Windows Platform. To use
Native Citrix automation, please install the standard Citrix Receiver or Citrix Workspace
instead.
5. The Citrix App Session May Enter The Idle State During Background Automation: If
a Citrix App does not receive any input from the user for a while, the associated Citrix
session enters the idle state and disconnects. The idle disconnect timeout value is
configured on the Citrix application server, and is generally about 30 minutes. By default,
the Click and Type Into activities send hardware events to the Citrix App, just as a regular
user would. This prevents the Citrix App from entering the idle state.
13). What are the types of workflows supported by UiPath Studio?
1. Sequences - Sequences are suitable for linear processes, as they enable you to
smoothly go from one activity to another, without cluttering your workflow.
3. State Machine - State Machines are suitable for very large workflow. They use a
finite number of states in their execution which are triggered by a condition
(transition) or activity.
4. Global Exception Handler - For determining the workflow behavior when
encountering an execution error, and for debugging processes, Global Exception
Handler is most suited.
14). What are the types of robots you can create in an Orchestrator in UiPath?
Types of Robots
Standard Robot - works on a single Standard Machine only, namely the one defined
when creating it. This is ideal for the scenario in which a user always works on the
same machine.
Floating Robot - works on any machine defined in Orchestrator, be it Standard or
Template, as the machine name is not relevant when creating it. Only Attended and
Development Robots can be floating, and as such, they become licensed
automatically when you open the Robot tray. These types of Robots only work with
Active Directory users and are useful if the machine you want to add a Robot to has
a different name each time it is spawned, such as for Non-Persistent VDIs. Same goes
for hotseat environments, where different people are working in shifts on the same
computer.
Example:
Let's say you have an environment with 8 users working on non-persistent virtual
desktops. Machine allocation is done randomly, so one user can be allocated any of the
available machines in the VDI.
In the standard scenario, you would have to define a Robot for each user/machine
combination. For a VDI with 8 machines that means 64 Robots.
In the floating scenario, you only need to define one machine template and 8 Floating
Robots (one for each user). The template persists across your entire VDI such that each
of the users can connect to their Robots using one key, the Machine Template key.
Attended - works on the same workstation as a human user and is usually triggered
by the user through their actions (user events). You cannot start processes from
Orchestrator on this type of Robots, and they cannot run under a locked screen.
They can be started only from the Robot tray or from the Command Prompt.
Attended Robots should only run under human supervision.
Unattended - runs unattended in virtual environments and can automate any
number of processes. On top of the Attended Robot capabilities, this Robot is
responsible for remote execution, monitoring, scheduling and providing support for
work queues.
NonProduction - retains all the features of the Unattended Robot, but it should be
used only for development and testing purposes.
Development - has the features of an Unattended Robot, but it should only be used
to connect your Studio to Orchestrator, for development purposes.
High-Density Robots
Regardless of the Windows version a machine is running on, if you have multiple users on
it, you can register a Robot on each of the users. This feature is called High-Density
Robotsand ensures a full utilization of each machine at your disposal at its maximum
potential. It can be applied to all types of Robots (Attended, Unattended and
NonProduction).
you can run the same process with all Robots in the same time;
you can run different processes with all Robots in the same time.
WildCard : We use wildcard for replacing zero or multiple characters in a string.These can
be quite useful when dealing with dynamically-changing attributes in a selector.
Asterisk (*) – replaces zero or more characters
Question mark (?) – replaces a single character
UiPath Orchestrator is a web application that enables you to orchestrate your UiPath
Robots in executing repetitive business processes.
Orchestrator lets you manage the creation, monitoring, and deployment of resources in
your environment, acting in the same as an integration point with third-party solutions and
applications.
UiPath’s Orchestrator power comes from its capability of managing your entire Robot fleet.
Attended, Unattended or NonProduction, they can all be connected and executed from this
centralized point.
Attended - This type of Robot is triggered by user events, and operates alongside a
human, on the same workstation. Attended Robots are used with Orchestrator for a
centralized process deployment and logging medium.
Unattended - Robots run unattended in virtual environments and can automate any
number of processes. On top of the Attended Robot capabilities, the Orchestrator is
responsible for remote execution, monitoring, scheduling and providing support for
work queues.
Development - has the features of an Unattended Robot, but it should be used only
to connect your Studio to Orchestrator, for development purposes.
NonProduction - similar to Unattended Robots, but they should be used only for
development and testing purposes.
Provisioning - creates and maintains the connection between Robots and web
application
Deployment - assures the correct delivery of the package versions to the assigned
Robots for execution
Configuration - maintains and delivers Robot environments and processes
configuration
Queues - ensures the queues and queue items management
Monitoring - keeps track of Robot identification data and maintains user
permissions
Logging - stores and indexes the logs to an SQL database and/or ElasticSearch
(depending on your architecture and configuration)
Inter-connectivity - acts as the centralized point of communication for 3rd party
solutions or applications
Item statuses- let you know if the item has been processed or not, and the stage of the process at a
particular time. They are displayed in the Status column (in the items view of the Queue page).
Queue items can go through the following statuses:
New - the item has just been added to the queue with the Add Queue Item activity;
In Progress - the item was processed with the Get Transaction Item or Add Transaction
Item activities;
Failed - the item did not meet some business or application requirements within the project and
therefore, was sent to a Set Transaction Status activity that changed its status to Failed;
Successful - the item was processed and sent to a Set Transaction Status activity that changed
its status to Successful;
Abandoned - the item remained in the In Progress status for a long period of time (approx. 24
hours) without being processed;
Retried - the item failed with an application exception, and it was retried. After the Robot
finished retrying the item, the status changes to Failed or Successful, according to your workflow.
Revision statuses - let you perform version control but only of queue items that fail with an
application exception. These statuses have to be manually set per item and have no implications in
Orchestrator or Studio, other than changing the value in the Revision column from the Queues page.
The following statuses are available:
None - this is the default status and it is set to all items, even if they failed or not
In Review - a user has marked an item that has failed with app exception as in the process of
being reviewed
Verified - a user has marked that the item has been verified (you cannot retry it after setting this
status)
Retried - the item has been marked manually for retry
20). Difference Between get queue item and get transaction item
The “Rethrow” acitivity is useful if you want activities to occur before the Exception is thrown, so in the
Catch you would put that activity and it will throw the Exception that occurred originally that put you
into the Catch and end the process.
If you are wanting to continue with your process then simply just use the Log message in the Catch and
let it continue.