#FeatureBlog - 18.3 - Library (Reusable components)

[ovi (Viorela Preda)]

First, big thanks to @mircea who has helped put this in place.

Today’s topic: Library (Reusable components).

What is it?

A Library is a collection of reusable components. A reusable component is a workflow that can be compiled and packaged as an activity and reused in multiple processes. So go ahead and define all that common code once and reuse it multiple times. You can now create these workflows and publish them as activities.

Why do you need this?

Reuse is a key enabler for improving business efficiency. As developers we can’t afford to do things differently in every process and for every automation, but at the same time to hope for flexibility and innovation. A known best practice in the development world is to divide a business process into smaller parts. Common parts become reusable so that you don’t reinvent the wheel every time.

Who needs this?

This feature mostly addresses to RPA Developers and will help you easily maintain the automation processes, align with internal best practices and reuse existing implementations. RPA developers and IT need it so that they do not do redundant work, so that they can easily maintain process automations, so that they align with internal best practices and reuse existing proven, reliable and robust implementations. Business need it because it is costly to have to implement the same thing every time.

So, how does it work?

The easiest way to explain our new Library feature is to showcase an example. For the purpose of this demo we will keep the example very simple.

Let’s assume we have an existing automation called “Expense Report in Concur” which we built using 18.2. Normally an automation like this would have multiple moving pieces but for the sake of simplicity let’s say this automation has 3 workflows:

• Main which calls a Login subworkflow, then does some expense actions and last calls a Logout subworkflow (via Invoke Workflow)

• Login to Concur

• Logout from Concur

Instead of using 2 invoke workflows like “Login” and “Logout” which represent common logic for any Concur related process, we could build a Library with these 2 components.

Start building a Library of Concur reusables from scratch…

Import your Login and Logout workflows from the initial process (or really build from scratch if you feel like it)…

Publish your new Library project…

Publish screen will appear …

You can now use this Library in any process. Easy!

Let’s go ahead and modify our initial process.

Delete the Login and Logout workflows - you don’t need them anymore. Yes, click ok

Go to Manage Packages and add your local folder as a Feed…

Install the Concur Library …

This will add Login and Logout activities in the Activities Panel. Replace the Invoke Workflows to Login and Logout with the newly added activities.

Finally your new project using reusable components should look like this:

Let us know what you think!

[ClaytonM]

This has me excited.

Just had a quick question.

How are the arguments translated into properties though?
Like if you have AssetName as an input argument, will it translate to an input property called AssetName? or will there be an edit screen that shows all the arguments similar to how the Invoke does currently?

Thanks.

[mircea (Mircea Grigore)]

Good Question! Here’s an explanatory snapshot. In short, all arguments are translated into activity properties. See below:

[loginerror (Maciej Kuźmicz)]

I have to admit, those changes are spectacular and on point to what was needed in library management. I can see many uses for it.

Just a quick question - how would I go about changing something in that exported package if there is a need for it? Is it still worth keeping the source xaml file for that case or can we quickly edit it some other way?

Overall, the beta looks really great

[mircea (Mircea Grigore)]

Libraries will be packaged as nupkg same as processes and will be visible in Orchestrator in a special section. When connected to an Orchestrator instance, you will see, by default, all libraries as a default feed in Studio > Manage Packages. platform.uipath.com however will not be accessible for publishing libraries in 18.3. Only on-premise deployments will have this feature for now. You can add library sources under source control, same as processes and you can change them and republish, same as processes. Libraries will be versioned and you can add them to Processes in Studio as dependencies, same as activity packages (technically they are the same). You also have the option to add a release note to each version and see a changelog in Orchestrator - again, only for on premise for now. We’re planning library publishing availability for our platform.uipath.com Orchestrator instance in the subsequent release. Editing a published library directly from the process that is using that library is not possible.

[Florent_Salendres]

@ovi

You can now create these workflows and publish them as activities.

Wow… this is so great. This resolves the issue of having to pick reusability by copy (you copy manually component from a library) VS Copy by shared reference (point to the same reusable repository) creating share dependencies between Robots deployed.

The fact that they are published as CA will enforce true reusability, as I imagine they will not be editable.

That brings me to ask if there is something handled to obtain back source XAML files from the interface directly.

Let’s imagine my component was actually not so reusable on this version, and I want to get back the source to change it a bit to create a new version. Is that possible? possibly this “help” near include sources checkbox would give me some info?

@mircea & other people involved, fantastic job overall. This is what clients were asking for.

I can’t wait to finally Beta test all of this, for now, I have all my machine with Enterprise/Trial enabled so that prevents me to activate Community version of the studio. Any plan to find an alternative to this?

Cheers

[mircea (Mircea Grigore)]

We have a beta program for enterprise customers as well. If you want to join this program just contact @ovi in private or send an email via support.

[Florent_Salendres]

Thanks
I actually got an email in my mailbox saying that I am part of the program, did not know that would imply I could have both installed.

Thanks for the info

Cheers

[Watanabe (Atsushi Watanabe)]

I appreciate it
I was longing for this library function.
Currently Main.xaml of process “common” sets the version information in asset, each process gets it assets and refer to each “xaml” in “common”.

[ark]

This is so great.

Just a quick question.

Can I read a file in the project folder from libraries?
I think I cannot use a relative path like “.\setting.json” because the current directory is different in libraries.
I want to put some setting files for libraries in the folder which contains project.json and so on.

Thanks.

[oddrationale (Dariel Dato-on)]

This is cool! Question. Can libraries created and published using 2018.3 be used in older versions of UiPath, for example UiPath 2017? Or do you have to update UiPath Studio to 2018.3 before you can use the custom activities? I’m guessing it should work, since it is packaged as a nupkg?

[ClaytonM]

I had another question and maybe this is more related to how Activity dependencies work:

If you publish a project that uses a Library it adds the version as a dependency. So, what happens when that dependency receives an update? Does the project still continue to use the old version until the dependency is updated through republishing, or can it use the updated version by only republishing the Library (maybe by removing it from dependencies)? My concern is that if we have several projects, it will require an entire day of going through and republishing everything just after a simple update to a Library.

Thanks.

[BenMann]

Man, that is beautiful

[andreiT (Andrei Tapardea)]

Hi oddrationale,
Studio is what creates flows and robot is the one that runs them, even when you press play from Studio.
Unfortunately no, libraries created with 18.3 will not run on 17.1 robots because they will most likely have new core dependencies.
Theoretically, you could add older version of activities and use them in your library that you can try to run on 17.1 robot, this may work, but it is not supported and therefore not recommended.

[andreiT (Andrei Tapardea)]

Hi Clayton,

-You create library L - Version1
-You add this library to your project as a dependency, but with “lowest applicable version”
-You update library L to Version 2 and put it on the robot feeds
-You remove L-Version 1 from the robot feeds AND from the robot download location (%username%.nuget\packages)

=> Robot will not find L-Version1 and will now use L-Version2 for your library

Remember, this only happens if you add the library with “lowest applicable version” from Studio’s package manager and if Version1 is unavailable on any feed and download location.

[badita (Mihai Badita)]

Yes, we have in plan a use highest applicable version or automatic updates on orchestrator.

On the other side there are customers that wanted to be on the safe side without automatically updates, which was not possible until the dependencies per project feature.

[mircea (Mircea Grigore)]

Just to build on top of this: we have in plan to introduce highest minor, highest patch and highest as runtime rules. These, together with strict and lowest applicable version, should suit most of the requests we got so far around change management and control. Let us know what you think. With time, we plan to also give more control to Orchestrator over batch updating process dependencies. That will be a layer on top which would give a centralized way in which to update runtime rules and dependencies. Again let us know what you think.

[Cosmin_Popescu]

@ark

Can I read a file in the project folder from libraries?
I think I cannot use a relative path like “.\setting.json” because the current directory is different in libraries.

Hi @ark, if the file used from the library via relative path is included in the library project (is in the library project folder), then you will be able to access it as such. In this case, the file is packed with the library and the runtime will find it where the package is installed. Again, conditions are that the file is accessed with relative path and the file is included in the project.

[ark]

Hi @Cosmin_Popescu, thank you for your reply.
I know I can read a file in a library project folder.
But I wanna read a file in process project folder from activities.
I want to define activities’ behavior from process project like Java .properties files.

Thanks.

[Cosmin_Popescu]

@ark

But I wanna read a file in process project folder from activities.

At runtime, the current working directory of the compiled activities is the project current working directory (as long as there are no external resources present in the library project, such as .json, .csv, etc.). In this case, you can consume the project resources using relative path.