UiPath Libraries are Not Used Enough in RPA

Insights

UiPath is proving a real game changer for accessible developer tools, with a range of new capabilities emerging in the past year. A tool is only as good as its user, however, and some of these tools have an unlocked potential to really make the most out of RPA initiatives. UiPath Libraries is one of them. Particularly now, companies are looking for ways to minimise cost, implement new technology fast, and free up their human resources. Reuse is a great way to start towards these goals, and Libraries are one of the best ways to store, manage, and implement reuse in your RPA work. 

In this blog I’ll walk through the benefits of UiPath Libraries, an example Library, how to create a Library, and some best practices to ensure your UiPath RPA work reaches its potential. 

Benefits of Using UiPath Libraries

Libraries is a tool in UiPath Studio that allows you to store, organise and deploy collections of common RPA workflows. This is a great tool as instead of rewriting the same or similar code every time a common activity appears, you can simply reuse – saving time and effort. Take a generic use case such as determining the number of days between two different dates. It’s a fairly non-specific set of code that could apply in many projects across many technologies. Libraries allow you to write this code as you would normally in Studio, then reuse it exponentially across as many other projects as needed. This is ideal because it offers the reuse factor but doesn’t really change the way you develop. 

Libraries are developed with UiPath studio, the same as the rest of your RPA work. The main thing that changes is the structure, which makes it easier for others to come in and reuse your work later on. This is a helpful feature for enterprises, where you might have two or more developers working on very similar things. It also makes it easier to maintain a folder structure using correct naming, ensuring organisation across large projects. 

 

An Example of a Library – Search Engine Library

A great example of a workflow that could be better done as a library is a search engine image download. This is a very generalised activity and can be used over a variety of use cases, for example, downloading training images for a Machine Learning Image Classification Model.

 

How to Create a Library

First, open UiPath and select the library option.

 

When naming your library items, it’s important to group based on purpose. For example, in the use case outlined later in this piece, by creating a toolset called “Search Engine Tools” as the high level library name I can split each group of tools into sub categories and create library items per toolset, which can be version controlled independently.

 

This will display in the package manager to be downloaded as needed…

 

…and when installed will group together in a folder structure:

 

Drawbacks/Considerations for UiPath Libraries

It’s a bit ironic that reuse is struggling to gain traction in RPA, when bots are really all about repetition. But there are, of course, reasons why this is the case. As I mentioned above, Libraries have great potential across larger businesses, where activities can be reused internally across different projects. But this is not designed to be shared publicly, as in the UiPath Connect marketplace. This means Libraries are most helpful on an enterprise scale, though smaller companies can still benefit. 

Using Libraries can also make it tricky to debug internal workings. When running a project that contains Library items, you won’t get an appropriate log of the internal activity or the sequence of events. This poses a challenge for determining what went wrong and where within the sequence of the Library project. However, it is fairly easy to work around this with good logging when creating the library, which I’ll explain in more detail below. 

Still, the main reason for Libraries’ underuse may just be that people aren’t as aware of its potential. There is a tendency among developers to use invoke workflows instead (as this is promoted in most UiPath training for reuse). Invoke workflows may get around the issue of debugging slightly better, but they are generally internal to projects and not as easily shifted across multiple projects. This reduces their ability to contribute to reuse and gain time and cost savings. 

Best Practices for Libraries

As I discussed above, Libraries come with a few drawbacks that, nevertheless, can be mitigated through some best practices. Firstly, communication. Nice, clear annotations and logging within your libraries will go a long way. This can help mitigate the debug issue outlined above – if a Library item in a project fails, you can go back into the Library and use the logging there to determine the issue. It is important to ensure the developer of the library uses clear annotations throughout, particularly annotating arguments representing their function. It is also a good idea to annotate every argument going in and out, ensuring it is clear what the input and output data should be. All these annotations and clear appropriate logging help anyone reusing your Library to understand how to use it correctly, and see where things go wrong. 

Annotate Arguments…

 

…so they display to other developers:

 

A second best practice is to create libraries per application, but to also create a library of general components. This will make it easier to identify existing activities based on their function eg. create a google library that may have subcategories – ‘Open Google’, ‘Google Search’, ‘Google Image Search’ etc. 

Finally, I recommend having a comprehensive skeleton Library Template that can be used for building further library models. This can not only save you time, but also help add a level of structure to your Library items, allowing prepopulation on items that will help organise and streamline your coding.

Libraries, as with everything, don’t offer a magic solution. But their potential for enterprise reuse and better organisation is often overlooked, and I have found their application an important part of my work. It will be interesting to see how these trends evolve over time, with organisations facing a more volatile and competitive market, and with RPA continuing its rise in the enterprise space. 

Author Details

Aaron Karlsen
Aaron is a software developer with over 10 years’ experience in the IT industry. Aaron has a strong technical background, with particular expertise around Automation, Robotic Process Automation (RPA), Intelligent Document Recognition (IDR, OCR, ICR), and Business Process Automation (BPA).

You might be interested in these related insights