cancel
Showing results for 
Search instead for 
Did you mean: 

Practical advice on how to call nested objects

prachaya
Level 3

Hi,

I have looking for practical advice on how to call nested objects more effectively in Blue Prism workflows.

Example.

Process -> ObjectFunction -> ObjectApp

prachaya_0-1730789139934.png

Do you have any concern/risk/suggestion?

Thanks for your advance.

2 BEST ANSWERS

Helpful Answers

Asilarow
MVP

Hi Prachaya,

Referencing App Objects within other Objects is not recommended due to the below:

 
 Asilarow_0-1730798235898.png

 


The amount of memory used when the process consumes the object into memory will be increased.

This is because when an object refers to another object and is used by a process, both objects are then loaded into memory by the process.

The above example shows a short process containing 3 Objects:

  • Notepad Object
  • Swingset Object
  • Notepad Object with Swingset Launch Action added

 

As can be observed on the diagram, when launching the third Object, that contains all the contents from the Notepad Object and an Action that calls the Swingset Object, both Objects are loaded into memory resulting in higher memory usage.

Please also note that the larger the objects are, the higher the differences will become potentially even causing “System.OutOfMemoryException” errors.

 
Andrzej Silarow

View answer in original post

stepher
Level 6

Prachaya,

Memory usage, as noted by Asilarow, is the most common argument.  However, if you are truly running these applications concurrently, I think the argument is probably moot as the memory usage will probably be about the same.

But I would add in two points, only from my own experience.

1. If you absolutely must run the applications concurrently, then it is what it is, but I would strongly lean towards running my applications consecutively and using the BP work queues to manage the handoffs.  This does help to address the memory issue.

2. Nested Objects create headaches when troubleshooting, and even creating Releases/Packages.  If you check the Dependencies at the 'ObjectFunction-Group' level (from your example), it will not show the dependencies of the nested Objects.

We have about six 'Wrapper Objects' (there are a few threads on this topic) intended to address very specific, oft-repeated steps.  As an example, the steps to extract values from an Excel Worksheet to a Collection.  Once every few months or so, I forget to check the 'lower' dependencies, only to be reminded when I am importing a Release to the next environment.  Not the end of the world, but it gets a bit annoying.

Take care,

Red

Robert "Red" Stephens Application Developer, RPA Sutter Health Sacramento, CA

View answer in original post

3 REPLIES 3

Asilarow
MVP

Hi Prachaya,

Referencing App Objects within other Objects is not recommended due to the below:

 
 Asilarow_0-1730798235898.png

 


The amount of memory used when the process consumes the object into memory will be increased.

This is because when an object refers to another object and is used by a process, both objects are then loaded into memory by the process.

The above example shows a short process containing 3 Objects:

  • Notepad Object
  • Swingset Object
  • Notepad Object with Swingset Launch Action added

 

As can be observed on the diagram, when launching the third Object, that contains all the contents from the Notepad Object and an Action that calls the Swingset Object, both Objects are loaded into memory resulting in higher memory usage.

Please also note that the larger the objects are, the higher the differences will become potentially even causing “System.OutOfMemoryException” errors.

 
Andrzej Silarow

stepher
Level 6

Prachaya,

Memory usage, as noted by Asilarow, is the most common argument.  However, if you are truly running these applications concurrently, I think the argument is probably moot as the memory usage will probably be about the same.

But I would add in two points, only from my own experience.

1. If you absolutely must run the applications concurrently, then it is what it is, but I would strongly lean towards running my applications consecutively and using the BP work queues to manage the handoffs.  This does help to address the memory issue.

2. Nested Objects create headaches when troubleshooting, and even creating Releases/Packages.  If you check the Dependencies at the 'ObjectFunction-Group' level (from your example), it will not show the dependencies of the nested Objects.

We have about six 'Wrapper Objects' (there are a few threads on this topic) intended to address very specific, oft-repeated steps.  As an example, the steps to extract values from an Excel Worksheet to a Collection.  Once every few months or so, I forget to check the 'lower' dependencies, only to be reminded when I am importing a Release to the next environment.  Not the end of the world, but it gets a bit annoying.

Take care,

Red

Robert "Red" Stephens Application Developer, RPA Sutter Health Sacramento, CA

Hi Asilarow,

Thank you for your great information.

Let me explain the issue. I have a large process (over 70 pages) and am trying to come up with ideas to reduce the number of pages.

 

What do you think about using nested processes? Do you have any suggestions?