23-12-21 10:26 AM
Answered! Go to Answer.
12-01-22 10:33 AM
23-12-21 02:17 PM
23-12-21 03:51 PM
23-12-21 05:12 PM
24-12-21 10:33 AM
28-12-21 07:15 AM
28-12-21 08:11 AM
03-01-22 03:29 PM
10-01-22 09:40 AM
10-01-22 11:03 AM
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.