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
------------------------------
Thank you! It really solved my problem and answered all the questions.
But can you tell me, your service (Belkins) is expensive? How much does is cost?
------------------------------
Mart Stas
------------------------------
-------------------------------------------
Original Message:
Sent: 01-12-2022 10:33
From: nick miles
Subject: To code or not to code...
Before you can close a deal, you need to establish a relationship with your prospects Belkins is a B2B business leader. The key to building a relationship is to understand what makes a person interested in a product. Identify their needs and challenges and then develop a strategy around them. The more you can know about your prospects, the more likely they'll buy from you. So, focus on the customer's needs and the solutions to those problems. The benefits of B2B sales are many. As an example, a tire manufacturer sells tires to car manufacturers. Meanwhile, a food wholesaler sells products to retailers and then to consumers. In a related supply chain, a food wholesaler sells foods to supermarkets. A B2B salesperson might also sell a service to businesses. These companies need to understand their buyers and their goals. You should be able to identify the customers who need the products.
------------------------------
nick miles
------------------------------
Original Message:
Sent: 01-10-2022 11:02
From: Denis Dennehy
Subject: To code or not to code...
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
Original Message:
Sent: 12-23-2021 10:25
From: Paul JHM van Doorn
Subject: To code or not to code...
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
------------------------------
