@JoakimEklundObjects can have many purposes, including at least two big categories of utilities and application UI interaction. I'm assuming you're more referring to objects that handle interaction with a specific application. Is that right? Because if so, I'm more referring to utilities such as strings or json. The reason you should not abandon allowing objects to call other objects is that you lose the ability for reuse in so many ways. Think of string manipulation. If I build an object that is supposed to retrieve data using a web service or even from the UI of an application, it is often necessary to do some string manipulation so that just the right value is passed back to the process or the object can do some validation to ensure the value was actually retrieved or whatever. We lose the opportunity for reuse if we don't call the Utility - Strings actions from within this object. Surely you wouldn't suggest that raw data be passed back to the process every time for you to build in logic to parse that data every time.
As I pointed out before, Blue Prism has already demonstrated the benefit of this. Look at the Webservices - REST object. It calls the Utility - JSON object, the Webservices - OAuth2.0 object, and the Utility - HTTP object. To require all object calls from the process level would mean much more complex logic than is necessary.
A further reason for allowing objects to call other objects is for unit testing. I often see Blue Prism processes designed with an excessive number of stages and pages. Because you cannot call into a Blue Prism process except to the Main Page, it becomes very difficult to unit test any logic within it. By moving the logic into objects that can be called at any point, you can enable both reuse and unit testing since you can call those object actions and testing specifically the logic inside them.
Another quick example to show what I mean. The most common interaction I see with the MS Excel VBO is Create Instance, Open Workbook, Get Worksheet As Collection, and Close Instance. It's not always like that but I see it very frequently. We built a reuse action in an object that takes the name of a workbook, etc. and performs those 4 actions for us. Now anytime I have the basic requirement of just getting the full collection of data from a spreadsheet, I only need to call one action to make that happen. This action can be called from inside of an object or from a process and it works really well.
For your second paragraph about page 11, this is different from what I was disagreeing with. It is talking about calling the actions in the same object because it's possible to use a page reference to refer to the same instance of the object rather than instantiate a new object instance. If you were disagreeing with my talking about recursion, I would agree with you that it's really not a great idea in Blue Prism due to memory limitations. I was merely noting that I've tested having a ton of instances of an object before with no noticeable issues but I wasn't suggesting it's a good idea.
------------------------------
Dave Morris
3Ci @ Southern Company
Atlanta, GA
------------------------------
Dave Morris, 3Ci at Southern Company
