Blue Prism v UiPath - Head to Head

I have been fortunate enough over the past 6 months work on two RPA projects simultaneously involving arguably the top two RPA vendor products. I have worked on Blue Prism for 2 years and this is a well-established product in the market. UiPath have exploded in the last 2 years onto the RPA scene and are hungrily eating into the market share.

Independent assessments of their overall capability put them almost equally high on the RPA shakers and movers list yet they are distinctly different products. I am no market analyst so will not try to guess where this competition will lead them in the years to come however, as a technologist, I can share my technical experience with the use of each product. This is by no means an exhaustive comparison and I writing with no agenda other than to share my experience with an RPA savvy audience. This will be technical comparison from a system practitioner perspective i.e. topics like sales, pricing, academies, architecture and system support will not be covered. I will examine topics related to the developers experience covering exception handling, debugging, structured data and integration. I will discuss the differences of each system when capturing an application into a process flow and its aesthetics. After a look at the make-up of each system and how that affects process design, I will close with their source control and deployment methodologies. For those still reading, there will be an Installation section to finish.

Attended versus Unattended

Let start with a key functional difference, Attended versus Unattended. An attended robot runs on «your» PC and «you» decide when to start it. An unattended robot runs on a remote PC out of sight often on a timed schedule. UiPath is the only one that can run in Attended mode. This comes from a vision from the Co-Founder of UiPath that all workers should own a robot to be more effective in the workplace. Unattended robots are also possible in UiPath through their Orchestrator product. Blue Prism are clear in their position to run unattended processes remotely at an enterprise scale thus are not in the business of enabling individuals on their desktop. So smaller agile companies could empower their workforce with robotic training and a friendly robot with UiPath. Larger companies get to choose UiPath or Blue Prism based on the products ability to deliver maximum return on investment. As practitioners, we want to deliver robust, reliable solutions on a feature rich, intuitive and extensible product that dishes out the least amount of headaches. Let us be realistic and accept there will always be headaches but keeping the paracetamol bill down is paramount for a developer.

The Development experience

C# developers will feel instantly at home with UiPath as the visual activities on screen are integrated with code when using variables. Defining a String variable will give you access to all of the native functions that a String datatype has in C#. Intellisense is also available. This gives C# developers a Visual Studio feel but in a UiPath context. Additionally, you can write your own C# packages and import them into UiPath Studio to use as visual activities. By contrast, all of Blue Prisms data types are fixed, unless you use a special “code” block, with no unexpected emissions. The functions on these data types are also fixed with strong coverage making variable manipulation easy. Whilst you don´t have the full scope of functions that native C# has, without dropping to that code block, I have only encountered a few scenarios that I cannot solve with the in-built functions. The expression evaluation makes it simple to test these functions without running the process. The code blocks in Blue Prism allow you fill in any functionality gaps that the in-built objects might have by writing your own C# or Visual Basic code. This suffers from a very simple IDE but development in Visual Studio is possible with a copy paste when complete. I have used these code blocks to do things like re-size a window frame, retrieve the PC screen resolution and pick out a collection from a collection by referencing the column name and row number. I think this low-level development feel between products will probably come down to a matter of personal preference based on past experience.

Exception handling

Try throw catch is central to both systems exception handling capability. UiPath manifests itself in a traditional coding way with a Try Catch activity, that also supports finally. Blue Prism uses Blocks; resizable rectangles that are wrapped around the steps in the process you wish perform a try catch on. Blue Prism has the visual plus with this method as in UiPath it becomes just another block in potentially many blocks of code. Both support native and user defined exception types allowing you to handle different exceptions in different ways in the catch routine. Nesting of try catch blocks is supported in both therefore very comparable in this area.

Debugging

One of the biggest draw backs with UiPath from a development perspective is the inability to step through a process and make changes dynamically. The routine of make a change, debug in read only mode, see if change works, stop running, fix the change and repeat becomes very tiresome when you are developing all day. Blue Prism allows you to interact dynamically whilst debugging. You can change variable values to test various scenarios without the ´start stop´ nature of UiPaths debugging. You can step back and forward to your chosen step in the process and add more steps as you go. This dynamic approach not only allows you to develop easily on the fly but also fix data problems in a Production environment without making changes to the process – a god send!

Structured Data

Another key difference from my experience is during the use of structured data in your processes. Both UiPath and BluePrism support Collections or Data Tables. This allows for tables of data to be manipulated in your process. In addition, nested tables (a table within a table) are supported with these data types and are relevant when you are working with XML or JSON data structures. Blue Prism has this covered. The Collection is a native datatype that can easily be defined with a column of type Collection. What is more you can inspect the content of a collection by double clicking it. You can drill down into a nested collection by double clicking it. It is incredible simple to work with structured data in Blue Prism. There are a few missing functions with the out of the box collection manipulation objects but these can easily be plugged by writing your own. UiPath by contrast makes it difficult to interact with structured data. I have not found a way to view the content of a Data Table from the application. I must view each cell value with a write line, message box or alternatively write the data out to excel…long winded when developing. In addition, it is not possible to create a column on a Data Table of type Data Table through the application, meaning that any nested tables can only be handled at the code level. The marketing lure of ´low code´ process development is not that applicable when dealing with structured data. I guess this can be said of either product as a degree of technical knowledge is required to handle the recursive nature of mining the data.

Application Integration

Both products integrate very well into our everyday desktop applications, as you would expect. Both have rich built in handling for Excel, Word, Email and other common desktop applications. Integrating with a web browser is straightforward and both offer some advanced features including Java and Javascript within a web page. Windows application integration is standard and both support keyboard level integration to invoke shortcuts or simulate keystrokes. UiPath has been stronger in it´s ability to recognise an image on the screen. In Blue Prism version 5 this is a complex business to try and replicate compared to the UiPath built in activities. When integrating with a system through a Citrix environment then UiPath performed easily better compared to Blue Prism version 5 (I´ve not tried with version 6 yet but it is billed to distinctly better in this area).

System-to-System Integration

Blue Prism has an excellent integration feature that UiPath must address in a future version. The use of web services in Blue Prism, as a client and a server, is incredibly simple to set up and a powerful addition to the system-to-system integration opportunities. As a client, you can enter the WSDL of a SOAP web service and a business object is generated automatically with all of the web services methods, ready for use in a process. As a server, you can expose any business object, or process, and it will generate a WSDL ready for any other system to make a SOAP request to your logic. This is an excellent way to input data into Blue Prism as it gives the calling system a unique ID that can be stored and used later to check on the status of the transaction. Both systems support standard REST calls. External systems can make a REST call to UiPath in order to start a process from the Orchestrator. For that matter REST can be used to action most of the functions within the Orchestrator. This would be a nice addition to the standard offering in Blue Prism. Both companies recognise that they are not able to increase the functionality of their offerings at the pace that the market demands and therefore have joined forces with others to plug-in on services. My reckoning is that the integration capabilities with both products will only get better and better as new versions are released.

Process Capture

How easy is it to model a process with these products? How simple is it capture the steps in a reliable and robust way producing a trouble free process? Both products differentiate themselves from other RPA offerings in this area by offering a visual tool to perform this task. Other products such as Automation Anywhere, NICE and Jidoka rely purely on a coded solution. Blue Prisms Application Modeller feels more like an open API than UiPaths semi-automated capture mechanisms. Blue Prism is saying; here is the capability at a low level now you go and use it…but beware, it is easy to misuse. UiPath is trying to cover off some of these pitfalls by wrapping this low-level stuff into it´s application. For example, clicking a button on a webpage in UiPath will wait until the web page is loaded and give you back control for the next step in the process. Blue Prism will click the button but will not wait for the page to load before continuing. Instead, it offers a “Document Loaded?” action that should be used in conjunction with the click action to achieve a robust flow. The net effect is UiPath becomes quicker to develop on as there is less to consider. Building a robust process often involves slowing down time in a Matrix type way to imagine each human interaction with the system, often overlooked in the documented specification. UiPath removes some of this Neo magic but it has to be considered with Blue Prism.

Another catalyst for speedy development in UiPath is the Macro recorder. Blue Prism does not intend to add this to their product by design. Press Record, perform your process and press Stop. UiPath will capture the steps you performed into a single sequence. Genius right? If so, why would Blue Prism state it is not a feature they will ever add? I think this goes back to the attended versus unattended argument. A macro is great for a regular user looking to make a quick process for their own use. From a process design perspective it does not work that well. By having all of your steps in a single sequence, you are not considering the parts of the process that should be abstracted for re-use. Of course, you can revisit the sequence and choose to split parts out. A top down approach. The Blue Prism philosophy is bottom up. Consider what you wish to abstract in your process prior to starting and build up from the outset. Don´t think for a minute that the UiPath recorded Macro will repeat the process perfectly every time you run it. There will be a degree of rework on the selectors to make them more accurate. Selectors are the criteria that will identify an element on the screen. A big plus for Blue Prism in this area is the ability to use “regular expressions” in your selector. This has often been a get out of jail free card for me.

Process readability

With the application details mastered and the modelling done, how does the final process actually look? In my opinion Blue Prism gives a far superior aesthetic feel to a built process. The visual elements in the process can be repositioned, resized and recoloured. This allows you to position the flow of the process on screen in a way that is intuitive. It also allows you to adopt an in-house development style. UiPath has fixed sized elements, limited positional capability and no colour coding. Rather than expanding the process across the page in a 2-dimensional way that might represent the business logic intuitively we have a very top down linear feel to the steps in a process. A sequence quickly becomes cumbersome to read when you have nested loops that are all vertically linear to your eye line. Even a flow chart has fixed oversized dimensions and awkward linking lines meaning you quickly run out of space on the screen. Both offer process view zoom in and out allowing you to resize the entire screen to the quality of your eyesight.

Process Design

Is a process a sequence of unique events that run top to bottom? Alternatively, is there enough commonality across multiple processes to warrant some upfront thought about the design to maximize reuse? Are we making building blocks or one off scripts? Blue Prism is a clear winner for me in this department with its object and process separation. Objects to interact with the applications, or act as stand-alone class objects, and Processes to use the object actions in a flow mimicking the business logic. UiPath tries to replicate this concept with both the Library and Invoke functionality. Both attempts fall short of what Blue Prism offers. It is possible to load a small utility sequence into UiPath Studio that exposes it in the library function area. You can simply drag this across on to your process to get a copy of the code. Therein lies the rub! The code is ´copied´ across…meaning if this library function is used in 10 processes and you decide to make a change to it, you need to re-import the modified library function into 10 processes. Blue Prisms object model means any change that you make to a business object action will take effect immediately for any process that calls it. This is the definition of library! UiPaths alternative to calling common code is the Invoke activity. It makes a call to another process giving you the power to write re-usable common library functions that are modelled as processes. The problem being that this library process is not in the context of any similar library functions. In Blue Prism, you can create a string manipulation object with many actions that do weird and wonderful things to your string. They are logically grouped together in a business object meaning you can even write “private” internal actions that more than one of the “public” actions can utilise. UiPath would need to write many different processes for each string manipulation that could only reuse code by invoking more processes! Invoking a process in UiPath also involves making a reference to the file where this process lives. Blue Prism takes care of this by storing everything in the database. In addition, the object model in Blue Prism opens up a good development practise of Test Driven Development – read my other Linked In article for details.

Another key differentiator between UiPath and Blue Prism is their perspective on queue usage. Queues are the persistence layer in your process that can store the data related to a transaction. Blue Prism expects queue usage to play a central role in any process automation. As such there is a very rich integration with the queue item that allows the developer to get creative with how it can use a queue. Statuses, Tags, Exception, Delete and Defer capability give some flexibility to manage a transaction regardless of the complexity of the process you are automating. Unique Identifiers for each item placed on the queue is the pièce de résistance that opens the door to a service oriented process design. UiPaths documentation on queues reads more like a nice approach to manage a large list of things. The integration capability is much less rich and this steers the developer away from wanting to use a queue if the complexity is much more than read from the queue and set a success or failure status. Blue Prism also drive all of its process statistics from the queue with built in average and total run times available. Another frustration with the UiPath queue concept is it is only viewable from the web based Orchestrator. This is a poor web page with no resizing of columns available making reading queue details very difficult. You must export to csv and reformat to make sense of the content. No such issues with the Blue Prism queue viewer with very rich filter and export features.

Source Control

Source control is the method by which each version of a process under development can be saved securely without risk of it being deleted. Source control also allows the developer to inspect the differences between versions of a process to help identify what has changed. UiPaths processes are saved to zammel files (.xaml) that exist on a file server. This gives license to a variety of source control solutions and UiPath has options built into the Studio; TFS and SVN. It would be nice to see more well used source control solutions such as Git and BitBucket in future versions. The trouble I have with UiPaths source control solution is that whilst we can version quite easily we cannot compare the differences between versions in a visual way. The zammel files are XML based and do not lend themselves to comparison in an understandable form. Contrast this will Blue Prisms approach to store all process source code in the central database. This big difference here is that Blue Prism gives the ability to compare any two versions of a process in a visual format where differences can be easily identified. This is golden when you need to look back to understand when certain changes were introduced and by whom. This full source code audit is built in with Blue Prism but must be added on independently in UiPath.

Deployment across Environments

UiPath requires a connection from the Studio, which you develop in, to the Orchestrator where the processes are triggered. You then “Publish” your process to the Orchestrator and it creates a new version. This works well enough but introduces problems when you are working across multiple environments. Moving the same version of a process to your Production environment involves disconnecting from the Development Orchestrator, Publishing the process to a file and importing the file in the Production Orchestrator. A bit messy even if it worked smoothly. All of the dependencies that lies under a process are supposed to be handled automatically and uploaded to the Orchestrator. When a robot runs the process the dependencies are supposed to be automatically downloaded to the robot machine from the Orchestrator. This never worked that well in my experience and we ended up copy and pasting dependencies over to the robot machine. Blue Prisms central database approach makes life very easy in this department. Create a package, Export it and Import it. Job done.

Installation

If you are still reading this by now then you must really be interested in these differences so I will touch on the much less sexy topic of installation. This is often only a one-time event per environment but plays a part in upgrading from version to version. Blue Prism is incredibly easy to install. Based on a windows packaged installation file, connected to a SQL Server database, the time from download to a working application is within the hour. Optionally you can run an Application Server service to run as a client server solution which increases hardware costs but adds little to none extra installation time. Layering on more advanced features can be configured later.

UiPath has a different architecture and therefore the installation is not so clean cut. The Studio, where processes are developed and tested, is a straightforward windows package to download and install. The Orchestrator, where the monitoring and scheduling of processes takes place is a web solution with many dependencies and therefore installation hurdles to overcome. There is a list of pre-requisites that will need be installed before the Orchestrator can be tackled. A SQL Server database is also required to support the Orchestrator. The documentation will get you most of the way but be prepared for some head scratching, support calls and creative thinking. As an add-on you can install the database ElasticSearch to capture process logging and Kibana as a visualization tool for process reporting. This is very powerful and sexy to use.

Conclusion

How to conclude? I see Blue Prism as the suited banker; smartly presented, smooth and accurate but perhaps a little behind on the newest trends. UiPath is a graphic designer; vibrant with tonnes of potential, energy and big ambitions but lacking some of the discipline of its older cousin. Both are excellent products that are highly capable of a return on investment but this article was about the headaches. As a developer, I would have to say my paracetamol bill would be bigger with UiPath. However, the same product on a good day might make me smile that bit more.