UiPath REFramework Manual
Author: Mihai Dunareanu
Peer reviewer: Andrei Cioboata
Revision 1.0
2
Table of contents
About the framework and its purpose 4
Understanding a business process 5
Introduction 7
About state machines 7
Framework component functions 8
Global Variables 9
Init State 10
InitAllSettings.xaml workflow 10
InitAllApplications.xaml workflow 10
Init Transitions 11
Get Transaction Data State 12
GetTransactionData.xaml workflow 12
Get Transaction Data Transitions 13
Process Transaction State 14
Process.xaml workflow 14
SetTransactionStatus.xaml workflow 15
TakeScreenshot.xaml workflow 17
CloseAllApplications.xaml workflow 17
KillAllProcesses.xaml workflow 17
Process Transaction Transitions 18
End Process State 19
CloseAllApplications.xaml workflow 19
KillAllProcesses.xaml workflow 19
End Process Transitions 19
Additional Functions 20
GetAppCredentials.xaml workflow 20
Logging 21
Logged Messages 22
Custom Log Fields 24
Field Descriptions and explanations 25
Getting started, examples 27
Deploying the framework 27
Defining the scope of the process component and preparing the framework 27
Usage example 1 29
Changes to GetTransactionData.xaml 29
Changes to Process.xaml 31
UiPath_REFramework manual
3
Changes to InitAllApplications.xaml 31
Changes to CloseAllApplications.xaml 32
Changes to KillAllApplications.xaml 32
Usage example 2 32
Changes to GetTransactionData.xaml 32
Changes to Process.xaml 33
Changes to InitAllApplications.xaml 33
Changes to CloseAllApplications.xaml 33
Changes to KillAllApplications.xaml 33
Glossary of terms (marked in italics) 34
UiPath_REFramework manual
4
About the framework and its purpose
The framework is meant to be a template that helps the user design processes that offer, at a
barebones minimum, a way to store, read, and easily modify project configuration data, a robust
exception handling scheme and event logging for all exceptions and relevant transaction
information.
Because logs generated by each process are a vital component of its report generation, the
framework logs messages at each relevant step toward solving a business transaction and
sends those logs to the Orchestrator
server
. This is turn can be connected to the ELK
stack
(Elasticsearch,
logstash,
kibana
platform)
which enables data storage and countless ways of
representing the data.
When we build tools, we try to first define their purpose and, in this scenario, the purpose of our
framework is to solve a collection of business transactions. Notice i did not write business
process, as all but the most simple business processes are typically composed of multiple,
distinct in scope and in purpose, collections of business transactions. Thus, let us henceforth
call such a collection of relatable business transactions a business
process
component
, a part
of a complete business process.
Thus, we could define a business process component as the sum of actions by which the data
needed for a set of transactions is obtained, processed, and is input into or out of an IT
resource
.
Such a component needs to be easily deployed to the machines it will run on (Orchestrator
server maintains versioning and easy deployment across all runtime machines), needs to be
scalable and needs to be able to communicate it’s output data with external mediums so that
other components of the business process may pick up the work where it left off. Such a
medium could be a shared folder, a data server, ftp server, email, Orchestrator server queue
e.t.c.
UiPath_REFramework manual
5
Understanding a business process
Take the following business process: a user has to check fuel prices using web resource 1
(external company website) weekly and update a file with the new values. Another user will then
utilize web resource 2 (internal company website) to obtain information about distances traveled
by vehicles in company service and correlates this information with the new costs of fuel. He
then uses web resource 3 (external company website) to pay for the deliveries.
In this example, we could use three business process components:
● The first, a weekly one, would read data from resource 1 to check and update the fuel
price file.
● The second would download information about distances from resource 2 and reference
the values obtained by the previous sub-process to filter and further refine that data.
Once done, it would save the data.
● The third component would read the information produced by process 2 use it to input
data into resource 3.
This business process could, of course, be expressed as the sum of two business process
components instead of three, for example by grouping sub-processes 1 and 2 together.
And, of course, it could be also broken up, for example sub-process 2 might be broken up into
two further pieces, one that downloads information from resource 2 and another that reads both
resource 1 and 2 information and processes it.
This technique of splitting a problem into easily definable, simple components is a great tool in
solving any business process, no matter how complex.
It also helps deal with a fundamental aspect of reality, time.
To see exactly how, let’s make a change to the business process described above: after the file
containing fuel prices was updated a user would need to confirm the validity of the values by
opening the file and signing it.
This means that before we utilize web resource 2 to obtain information we first need to wait for
the fuel cost file to be signed by a supervisor.
You can easily see how, If we implemented this using 3 components, the change would be
small, as we would need to only add one check in subprocess number two: is the file signed. If it
is, proceed. If it is not, exit and try again later. This also means that the robot is free to process
other tasks.
UiPath_REFramework manual
