Robotic Process Automation (AD-802 (C)) Unit 5 Notes

How unit 5 is examined

This unit covers publishing a finished bot as a package, setting up the server (Orchestrator) that controls robots, connecting and deploying robots, and managing package versions; no topic has been asked recently, so learn the definitions and the flow.

Publishing using publish utility

Not asked since 2022

Definition. Publishing is the process of packaging a finished automation project, with its workflows, dependencies and settings, into a versioned package that a robot can run.

Key points.

The Publish option in the RPA tool (for example UiPath Studio) bundles the project into a single NuGet package with the extension .nupkg.
The publish window asks for the package name, a version number and release notes.
The package can be published to a local folder, to the Orchestrator feed, or to a custom NuGet feed.
A package must be published before a robot can execute it, because robots run packages and not the open project.
Before publishing, the project should be run and debugged once, since a package with an error would fail on every robot that receives it.
Publishing to the Orchestrator feed saves the separate upload step, while publishing to a local folder suits testing on one machine. Example. A bot named InvoiceBot is published as version 1.0.0 to the server feed, and the file InvoiceBot.1.0.0.nupkg is created.

Creation of Server

Definition. The server (Orchestrator) is the central web-based management platform that creates, deploys, schedules, monitors and controls all the robots of an organisation.

Key points.

The server is installed on a machine or on the cloud, and users reach it through a browser with a login.
Setup involves installing the platform, connecting it to a database (such as SQL Server) and creating an organisation or tenant.
Administrators then create users, roles and folders so that each team sees only its own robots and processes.
The server stores packages, queues, assets, logs and schedules in one place.
Folders and roles give role-based access, so a developer, tester and administrator get different rights.
One server can manage hundreds of robots, which is why it is needed once bots move beyond a single desktop.

Using Server to control the bots

Definition. Controlling bots from the server means managing, starting, stopping and monitoring robots and jobs centrally instead of on each machine.

Key points.

A user starts a job on chosen robots manually, on a schedule, or through a trigger.
The server allocates each job to a free robot and can stop or kill a running job.
Queues share work items among many robots, and assets store shared credentials and settings safely.
Logs and dashboards show job status, faults and robot health, and roles restrict who may perform each action.
Job states include pending, running, successful, faulted and stopped, and a faulted job can be retried after the cause is fixed.
Central control gives one audit trail of who ran which bot and when, which helps compliance.

Creating a provision Robot from Server

Definition. Provisioning a robot means registering a robot in the server, with a name, type and machine, so that it is allowed to receive jobs.

Key points.

The administrator opens the Robots or Machines page and chooses Add Robot.
The robot is given a unique name, a type (attended or unattended) and the Windows user name it will run under.
The server generates a machine key or client secret for that robot.
Without provisioning, the server does not recognise the robot and will refuse its connection.
Attended robots work beside a human user, whereas unattended robots run on their own on a virtual machine.
The same machine can be reused, but each robot needs its own unique name.

Connecting a Robot to Server

Definition. Connecting a robot to the server links the robot software on a machine to the server, using the server URL and the machine key, so that it can receive and report jobs.

Key points.

In the Robot tray settings the user enters the server URL and the machine key given at provisioning.
After a successful connection the tray shows the robot as connected.
The robot then keeps a link with the server, which sends jobs and receives logs and status.
A wrong key, a blocked network or an unprovisioned robot causes the connection to fail.
Newer setups connect with a client ID and secret instead of a machine key, but the idea is the same.
The robot keeps sending a heartbeat, so the server can show it as available or unavailable.

Deploy Robot to Server

Definition. Deploying means sending the published package to the server and assigning it, as a process, to robots so that it can be run.

Key points.

The project is published directly to the Orchestrator feed, or its package is uploaded to the server.
A process is then created from the package and given a package version and an environment or folder.
The process is assigned to the robots that may run it.
Robots download the package automatically and execute it when a job starts.
Because the package is stored centrally, changing it once changes it for every robot assigned to the process.

Studio -> Publish -> Package (.nupkg) -> Server feed -> Process -> Robot runs job

Publishing and managing updates

Definition. Managing updates means publishing a new version of a package after changes and rolling it out to robots, while older versions are kept for rollback.

Key points.

Each publish must carry a higher version number, such as 1.0.1 after 1.0.0.
The process in the server is updated to point to the new version.
Robots download the new version, and the update can be automatic or done manually.
If the new version fails, the process can be rolled back to an earlier version.
Release notes written at each publish record what changed between versions.
A new version should be tested on one robot before it is rolled out to all robots.

Managing packages

Definition. Package management is the control of all bot packages, their versions and dependencies, in the server package feed.

Key points.

The Packages page lists every package with its name, versions and publish date.
Packages are stored in the NuGet format, so dependencies are tracked with the package.
Users can view details, check versions and see which processes use a package.
Keeping only needed versions and using clear version numbers keeps deployment orderly.
Custom feeds let a company keep private packages apart from the public library packages.
Package management differs from process management: a package is the stored file, and a process is the package made ready to run.

Item	Package	Process
Meaning	Stored .nupkg file	Package prepared for running
Created by	Publish or upload	Assigning a package version
Runs on robots	No, it is only stored	Yes, through jobs
Has versions	Yes, many	Points to one version

Uploading packages

Definition. Uploading a package means adding a .nupkg file to the server so that it becomes available for processes.

Key points.

On the Packages page the user chooses Upload and selects the .nupkg file from the machine.
The file must be a valid package, and the same name and version cannot be uploaded twice.
Once uploaded, the package appears in the list and a process can be created from it.
Publishing straight from the tool to the server does the same task without a manual upload.
A file that is corrupt or built for another framework version is rejected with an error message.

Deleting packages

Definition. Deleting a package removes a package version from the server feed when it is obsolete.

Key points.

The user selects the package version on the Packages page and chooses Delete.
A package version that is still used by a process cannot be deleted until the process is changed or removed.
Deletion is permanent, so the package has to be republished if it is needed again.
Deleting old versions saves storage and stops robots from running outdated logic.
Before deleting, it is safer to check the usage list, so that no scheduled job breaks.
Only users with delete permission in their role can remove a package.

Last-minute revision

Publish converts a project into a versioned .nupkg package.
The server (Orchestrator) centrally manages, schedules and monitors robots.
Provisioning registers a robot in the server with a name, type and machine key.
A robot connects using the server URL and the machine key.
Deploying means package, then process, then assignment to robots.
Every update needs a higher version number, and rollback is possible.
Packages are listed, uploaded and deleted on the Packages page.
A package version in use by a process cannot be deleted.
Attended robots work with a human, and unattended robots run alone on virtual machines.
Provisioning is done before connecting, and connecting before deploying.
Roles and folders control who may manage robots, processes and packages.
Job states are pending, running, successful, faulted and stopped.

Memory hooks

Flow: Publish, Provision, Connect, Deploy, Update.
Robot needs two things to connect: URL and key.
Package, then Process, then Robot.
Old version in use? Delete blocked.
PCDDUM: Publish, Create server, Deploy, Update, Manage packages, in that working order.
Attended = with a person; Unattended = alone.

Coverage checklist

Publishing using publish utility: no past questions.
Creation of Server: no past questions.
Using Server to control the bots: no past questions.
creating a provision Robot from Server: no past questions.
connecting a Robot to Server: no past questions.
Deploy Robot to Server: no past questions.
Publishing and managing updates: no past questions.
managing packages: no past questions.
uploading packages: no past questions.
Deleting packages: no past questions.

Account

Robotic Process Automation (AD-802 (C)) - Unit 5 Short Notes

How unit 5 is examined

Publishing using publish utility

Creation of Server

Using Server to control the bots

Creating a provision Robot from Server

Connecting a Robot to Server

Deploy Robot to Server

Publishing and managing updates

Managing packages

Uploading packages

Deleting packages

Last-minute revision

Memory hooks

Coverage checklist