Hi guys I have a few questions about the philosophy behind UiPath:
First of all, after working with the Studio for a while, it seems to me that UiPath is built on top of the Windows Workflow Foundation software created by Microsoft, and UiPath has created it’s own custom activities for its users. I am a bit concerned about this because WF doesn’t seem like it is a very active community or all that well supported by Microsoft. Most of the posts I can find for it are from 2015 or earlier, with a couple of posts from last year, but nothing within the last few months really. Here are a few of the posts I was able to find when I look it up Stack Overflow, is workflow foundation dead?, the Wikipedia page also seems fairly dated, it hasn’t been edited much lately and most of the refrences are very old wiki link. These are just a couple of examples of what you find on the first page of a google search when you search for “Windows Workflow Foundation” or “Windows Workflow Foundation support”.
So my first question is, can anyone explain to me why WF is the right choice for RPA implementations?
A few things that go with working in WF that I’ve noticed:
-
There is a fairly steep learning curve on appropriate use of activities and WF in general. It isn’t immediately user friendly. Beyond UI Automation, especially for things like data manipulation or validation, I find that using the Invoke Code activity is simply better because navigating hand written code is easier for complex logic than WF’s visual representations using activities and decisions and loop activities. This is somewhat counter to the idea of WF though.
-
I know it is possible to create custom UiPath activities because WF is an extendable tool that allows custom activities, and UiPath has documented how to create one which is helpful. One thing that I find surprising though is that UiPath is requiring it’s users to use a second licensed tool Visual Studio from Microsoft (there is a cost associated with this at the enterprise level) to be able to use UiPath fully. Shouldn’t this be built in to the tool natively?
-
A corollary of UiPath using WF is that UiPath is using and promoting the use of VB.NET programming. This is from the .NET blog from Microsoft. It implies that Microsoft is moving towards C# a lot more than VB.NET due to popular demand.
The core activities provided by UiPath with the highest value to me are the UI Automation activities such as click, type into, send hotkey, etc. I find the idea of selectors to be a powerful addition to pre-existing scripting tools like python, powershell, and other scripting languages. Beyond data retrieval and data input into systems through their UI’s, it seems to me that WF activities should generally be avoided, since it is more readable and comfortable for a developer to work with code, especially when there is complex logic. It can be cumbersome to try to click each activity to see what one line of code it is performing, and nested ifs can become a nightmare. I see RPA scripts looking something like this:
Retrieve data from UIs
run a script for all data manipulation
input data into UIs
I’m wondering if people generally have had a similar experience with this? If so, does WF really make sense? Would UiPath ever build their own custom interface that links more closely to written code while maybe keeping some of the useful UI components of using prebuilt activities like clicking? If the purpose of WF is to make things “easier to use” and more “user friendly” so you don’t need to have a developer background and so “anyone” can do it, I think that is a bit dishonest. From what I’ve seen, a user with no development background making anything in WF ends up with a giant mess that is not very supportable or maintainable that often won’t even work.
Let me know if anyone has had a similar experience as me with any of this. Maybe someone can help to shed some light on this choice and make me better understand.