To code or not to code...

[PvD_SE]

Hi folks,

I have noticed a growing popularity to tackle less easy issues with the BP building blocks by presenting a code stage solution for that particular problem. In my book, a code stage can be used, but only if the issue at hand cannot be solved otherwise, or the alternative would be really hard to do in BP.

If we continue with this habit to grab a code stage whenever we have to go look for what BP stages to use, in the end we might be better off throwing out BP and all start coding instead, which I assume is not in line with BP as a tool. But if we do, a typical process will end up having only a Main Page with a Start stage calling a code stage that calls the End stage, similar to this:

One recent example from this community (there are many more...):
Q: How do I get rid of empty rows in a collection, as well as duplicate rows in the same collection:
A: A code stage!

The problem described in this example could easily be solved by using the standard BP building blocks and does not require a code stage at all. So why is the code stage considered to be a great solution for this type of questions?
Another issue with this is that BP novices and newer visitors of this community might get the impression that playing with BP is all fine and dandy, but to get things done you gotta use code stages.

Take notice that I do not mind the question, we all have to learn this stuff, I only wonder about the answer.

Please explain this new coding frenzy to me!

Note:
I have been a coder since 1990, and still am, so it should be clear that I have nothing against coding. But there's a place and time for everything. Coding your way out of every little problem in BP is perhaps not a good idea.

------------------------------
Happy coding!
Paul
Sweden
------------------------------

[astrid.stollberger]

Dear Paul,

in my opinion, if you can code and a certain problem can be solved with reasonable effort via a code stage, then do it!
Code is usually much faster and more reliable than surface automation. 
Even tasks which don't require surface automation but could be solved using existing Blue Prism functionalities (like removing empty & duplicate rows) might (for experienced developers) be easier to achieve by writing a quick code stage instead of looping multiple times over a collection.

If in the end your process consists of code stages only, then Blue Prism is most likely not the best tool to automate this process. In my opinion, Blue Prism should only be used if there is at least some part of the process which can only be automated through the GUI. 

Does this make sense?

------------------------------
Cheers Astrid
------------------------------

[devneetmohanty07]

Really a great topic put up today and I agree with all the points put forward here. I will like to also add my opinion on this subject.

As per my opinion, code stages should be treated as fundamental blocks for interacting with any application, if connectors are not readily available to interact with that application using any application modeller based business object. To be honest, even most of the actions that Blue Prism provides within it's VBO also incorporates a code stage only. I agree with Paul's point that the usage of the code stage should be done in case there is something that BP might not currently have as a default VBO or any functionality within but there are exceptions to this point as well.

For example, if there is a collection having more than 30,000 records and if someone asks me perform some kind of an operation on each row, I definitely am not going to use Loop stage or any workflow based logic to work on it based on my prior encounters. Here if I have a ready made code stage in hand which can use a LINQ, I will go for that or if I have an OLEDB VBO, I might go for that which also uses a code stage only. If the records would have been less I surely would have gone with a workflow based approach. Such choices majorly depend on the business requirement no matter how easy an operation might look to the naked eye.

Many people new to RPA have even told me you are just copy pasting data from excel what is the big deal as it is simply Ctrl+C and Ctrl+V.  We as developer though know what complexity even such a trivial action can have when you need to handle the exceptions as well as the happy path while executing such an use case.

The real question is not if one should be using code stage all  the time or not, but the question is if it's something which can help you to process some operation with a great speed and reliability, why not go for it? At the end of the day we want an automated use case which can deliver benefits to the business. If Blue Prism operations can handle that surely go for it but if you can enhance the tool with your skillset, I would prefer that more and I personally believe Blue Prism as an RPA tool is something which gives every developer that flexibility to make that choice for himself and isn't that the most wonderful thing about it.

Obviously, I don't suggest automating an entire process within a code stage as it won't be easy to maintain or even isolate errors as you are simply not making your workflow modular in the first place but I will always suggest if you feel that you can create great wonderful reusable modules be it using a code stage or any application modeller based object, go for it because RPA is also a form of coding and is based on programing principles. Be it business user or even a developer, he/she is always going to use logic to automate a process and if a developer can help the business user by creating reusable code stages which can lessen their pain point why both of them can't coexist together.

And like Astrid mentioned if GUI is something a process can be automated through definitely Blue Prism has it's strength no doubt there and with inclusion of code stages, the strength of the tool simply gets enhanced to automate complicated use cases as well.​​ This is why even people are putting more assets in DX exchange as well for creating such useful modules. All this is at the end is a part of the same ecosystem.

------------------------------
----------------------------------

Regards,
Devneet Mohanty
Intelligent Automation Consultant
Blueprism 6x Certified Professional
Website: https://devneet.github.io/
Email: devneetmohanty07@gmail.com

----------------------------------
------------------------------

[ewilson]

For suggesting that Blue Prism can't do everything @astrid.stollberger has been moved the Naughty List for Christmas. 😂

Cheers,
​

------------------------------
Eric Wilson
Director, Integrations and Enablement
Blue Prism Digital Exchange
------------------------------

[Neel1]

Thanks Paul for such a good post which is too good to discuss and astrid and devneet has nicely reflect on this topic. i am also sharing my experience below 

i am in support that if code stage is able to complete the work faster, correct way and  it is easy to maintain as well then go for code stages. bcz sometime we caught up in situation that Business team want bot to be more quicker and Blue Prism can take time in rendering through the blocks one by one specially for the case rightly mentioned by devneent for excel having many rows. 

In my org - For one use case in which we have the strict capping on Bot run time  - we have incorporate python Script  for bulk processing on excel which is having more benefit bcz once you involve python code( PL apart from Native support C# ,J#, VB.net), Blue Prism will not wait for whole script part to get complete and bot can go back again back to another URL  to fetch the information while Python script was working in backend and it saves us all the processing time.


------------------------------
Neeraj Kumar
Software Engineer
------------------------------

[astrid.stollberger]

😛

------------------------------
Cheers Astrid
------------------------------

[PvD_SE]

Thanks y'all for putting in the time and effort to formulate your answers, much appreciated! I'd vote for all answers (excluding Eric's 🙂 to be the 'Best Answer' but I reckon that button can only be pressed once.

------------------------------
Happy coding!
Paul
Sweden
------------------------------

[ewilson]

All joking aside, I'll add my $.02...

I think looking at Blue Prism as simply a tool for automating user interfaces (UIs) is shortsighted. Yes, Blue Prism got its start, 20+ years ago, as a tool focused on UI automation at a time when developers weren't typically exposing APIs in their applications, but over the past 2 decades Blue Prism has evolved significantly. Consider features like Interact (Smart Forms), Decipher (Intelligent Document Processing), and Decision (Native Machine Learning & Decision Modeling). Add to that Blue Prism's native support for coding, if you need it, and I think it's clear this is a much broader platform.

Is Blue Prism a panacea? No, but it should be viewed, IMHO, as a first-class citizen (to borrow from Christopher Strachey) among the developers tools. Would I use Blue Prism to develop an application that lives close-to-the-metal (ex. a device driver)? What about a solution that places emphasis on speed (ex. a stock trading application)? I think it's clear those are not ideal use cases, but for many other use cases, beyond UI automation, Blue Prism is absolutely an option.

Circling back to the original question regarding whether we should leverage Blue Prism for solutions that primarily require coding? I believe you should at least consider it. Review the use case and determine if there is a fit. Would the problem benefit from the native work distribution and scaling capabilities of Blue Prism? Think about whether the assets/components (i.e. VBOs) you may need to deliver as part of the solution could be leveraged elsewhere (ex. by Citizen Developers) within your organization or the Blue Prism community as a whole (i.e. via the Digital Exchange).  Again, just because there may not be a UI component to the problem should not eliminate Blue Prism from consideration.

My ramblings above can be boiled down to "it depends". As much as we might like to think in 0's and 1's as developers, most things in life fall into that range of infinite numbers between the 0 and 1. 😉

Cheers,

------------------------------
Eric Wilson
Director, Integrations and Enablement
Blue Prism Digital Exchange
------------------------------

[AndrewPascal]

While agreeing with the opinions of all those who've already replied, there's one more point I'd like to flag up: I think it depends what you're coding around. 

If you're coding around some Blue Prism functionality - like sorting through a collection - then I'd agree that a code stage is fine. Do it or don't - it's your choice.

Where I want people to be a little careful is when they think of coding around some application functionality. Remember, one of the key advantages of RPA over more general IT development is the lower cost of deployment. As long as the robot is driving the application, just the same way as a human user would, you can be sure that the robot will get the same results. Risk is reduced, and so testing and governance overhead can be scaled back.

Once you  decide to take a short-cut around the UI, you risk bypassing functionality like verification, error-checking or automatic calculations. For example, imagine you're interacting with a web application. It's tedious to find the image that represents the button you want to press and send a click to it. Maybe it's easier to figure out what URL gets called when you click on the button, and then just jump your browser session to that URL. But... if the website later adds some validation to that button-click - or adds some important parameters to the URL it's calling - then your automation will silently bypass those new features and you will never know about it.

For this reason, I would urge caution when thinking about any design that avoids walking through the same UI steps as a human user - regardless of whether it uses a code stage or some other mechanism to take the shortcut. As Eric said, this isn't a "yes/no" debate - but there are factors to be carefully weighed up.

------------------------------
Andrew Pascal
------------------------------

[Denis__Dennehy]

I totally agree with Paul's idea that code stages should be seen as a last resort.  

The main reason for me that code should be used only as a last resort is simple - Blue Prism is a business tool,  business users should be able to use the product and read/understand the majority of the flows within the product,  SMEs should be able to validate the flows are correct during a verification phase with the developer,  the most successful customers I have ever know have been where business users are automating processes in their own business area.   
Also,  scripting has a major support overhead that using the Blue Prism product as a business tool does not,  and Blue Prism is not a development IDE - it is not built for the creation, sharing and version control of code like something like Visual Studio +Github are.  You will run the risk of poorly supported code within a business tool (much like macro scripts created in Excel can become).

I think the move to more and more code stages where the core Blue Prism tool could have done it (I have seen code used where functions exist that do the same in the calculation stage) - aligns with the movement of the RPA industry into being more and more owned by IT and used by programmers rather than a business tool used by business users.  This is a shame as it is also a move away from being a transformative business tool.  Even though there is a lot of buzz about Citizens Development in the RPA vendors marketing these days - what i fear for our industry is a move in the opposite direction.

Saying all that - I'll now say something probably counter to it!!   Sometimes code stages are very much needed - hence why our product has them.  If there is an easy to use and maintain API that offers significant benefit (or if the process is for realtime front office),  then code may well make sense - I've build APIs in Blue Prism for apps like Siebel and Lotus Email in the past.  There will also occassionally be things that need a code workaround,  such as a strange web service different to what Blue Prism supports,  or some new approximate matching logic you want to use.   All the digital assets on the Digital Exchange are smart stuff developers have built to help Blue Prism to do more... there is a fundamental need for this stuff.   All these are totally valid and why my ideal RPA team of 10 people would include one or two great .NET developers to do this kind of work.   

My recommendation would be to look out for die hard programmers that do not want to use a business tool and want to create code - encourange them to use the RPA tool where ever possible rather than add an additioanl maintenance overhead to your solutions.  Maybe add a check for unneeded code into your build review quality gate.  Maybe have all use of code something that needs to be agreed as part of your Design Authority quality gate.

------------------------------
Denis Dennehy
Head of Professional Services, EMEA
Blue Prism Ltd
Europe/London
------------------------------