Wrap repeatedly called processes in an object?

[RonAng]

We know that a process can call another process. But based on the Solution Design Overview document:   A process can also call another as a child, enabling layers of processes to be created. However, the way in which Blue Prism manages its memory needs to be considered carefully when thinking about using a child process. Unlike an object, a child process is not preserved in memory by the parent; once the child process has ended, the parent process releases the memory for the .Net Garbage Collector to reclaim. Because of this, if the child process is being used repeatedly by the parent, it is possible for unwanted memory leaks to build up if memory is being consumed by the child process (and its objects) faster than the Garbage Collector can clean up. It is therefore recommended not to use a child process where it will be called repeatedly, e.g. in the case working loop. As an alternative use objects to wrap other object€™s actions. If I have processA that needs to call processB and processC, possibly repeatedly. Will making an objectB (object) and objectC each calling processB and processC respectively be the solution? So it will be something like:   processA > objectB (which executes processB) > objectC (which executes processC) instead of: processA > processB > processC

[John__Carter]

Only experimentation will tell, because it depends on what the sub-processes are doing and what objects/applications they are using. The multi-layered nesting arrangement you describe sounds over-complicated to me, does it have to be that way? The standard process layer + object layer is sufficient for most projects, and sometimes it's worth housing a common sequence of steps (like Find Account or Add Note) inside an empty object to make a reusable unit. This sort of unit is often called a Component and can be visualised as a middle layer between processes and objects. A Component has no application model and usually only has one page called something like Run or Execute, and merely serves a container for a handful of action stages that perform a set of steps that multiple processes can share.

[RonAng]

I am just concerned that if I use the standard process layer + object layer, I will have 30+ (or maybe more) pages in my process wherein each process does different things. For example, I am getting items to be worked on from a workflow. In this workflow, there can be 30+ different items which of course will need 30+ different types of process to complete. To illustrate the scenario, please see attached file Scenario.JPG. To depict the solution with process layer(multiple pages) + object layer please see Scenario with BP. Is this what you have in mind?

[RonAng]

*Attaching Scenario

[RonAng]

*Attaching Scenario with BP

[John__Carter]

OK I see your dilemma. If you have case types A-Z, would it be possible to work all the As, then all the Bs, all the Cs, all the Ds etc? That way you could have each sub-process do it's own Get Next Item->Mark Complete, using the Tag Filter to select particular case types. This way the parent process would call the child process only once, rather than repeatedly for each case. This might make the build, test and implementation phases easier: developers can work in parallel; testing can focus on one case type at a time rather than 30+; go-live can be done gradually, covering more and more case types with the addition of new child processes. Managing 30+ happy paths and all their unhappy paths all at the same time is a big undertaking.  

[MaheshShinde1]

What does mean memory leaks ? How it will impact if I called sub process  repeatedly?

[RonAng]

Thanks John. So just to confirm, calling sub-processes is ok as long as it is not done repeatedly? Yes it is possible to do all the work for As then Bs then Cs and so on. And yes, that's the plan: to go-live gradually. Just add processes along the way.   @Mahesh, calling sub-processes repeatedly can cause memory leak. Memory leak is case where the application fails to release memory when no longer needed. Over time, memory leaks affect the performance of both the particular application as well as the operating system. A large leak might result in unacceptable response times due to excessive paging. Eventually the application as well as other parts of the operating system will experience failures.* *reference: http://bit.ly/2hySedV