Explode the number of available Excel object actions

[JeremyRTDean]

There are dozens of Excel functions that are not included in BP out-of-the-box but can be added with the use of a simple enumerator in the code.  For example 'Save as CSV' changes wb.SaveAs(filename) to wb.SaveAs(filename,6)

Explode the number of actions available to users by including these enumerators as variables in the interface or passing the variable to the action OOTB - rather than forcing users to re-code the VBO statements individually.

BP Innovation Idea.docx

[PvD_SE]

In my ignorance, I would not suppose making changes to any original BP object could be considered a good idea. A BP reinstall after whatever calamity, or even an upgrade, would make such new functionality disappear, rendering processes that use it unmaintainable.
In my ignorant view, if new functionality is required on eg. Excel, then a new object should be created or downloaded.
I could be wrong though...convince me!

[JeremyRTDean]

Lots of ways to manage that.  Keep them as relatively separate Objects that come out of the box with release updates as long as they have good naming conventions and don't stomp all over previous releases: Excel Release 2022, Excel Release 2023...?
But preferably, since Excel isn't going away and many of the functions have a long life, then integrate them into BP 'properly'.  Preferably simply select from a comprehensive list of Excel actions that makes it feel like the software is 'whole' and working for you rather than something you have to code at every turn.

[MikkoKamppila]

If I got the idea right and take it a step further, I would introduce a concept of "virtual object"? It's a reusable component having no code in BP, can be seen as an object, but is just a wrapper having only parameters exposed. Having said that, I'm not aware if it's technically feasible, but that's not my headache...

The approach would be closer to API style programming, something similar to how a new Web API is added to Blue Prism. The API would be visible in a Process Designer just like the Web APIs are currently.

Instead of currect approach adding custom code to wrapper (object action) list of actions would match the ones Excel, Word etc. already have.

Yeah, there must be a reason this approach isn't used, so feel free to shoot me down 🙂