Why we should not call process within process?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
05-08-22 12:25 PM
------------------------------
Neha Akhade
------------------------------
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
05-08-22 02:05 PM
There is no issue with calling a process from another. There is an action specifically for calling a sub-process. The issue to be careful of is when calling a sub-process from within a loop.
When a process is called, it is loaded into memory, when it is done, memory is cleared. If this happens in a loop, you can see where this may be a problem.
jack
------------------------------
Jack Look
Sr Product Consultant
Blue Prism
------------------------------
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
05-08-22 04:22 PM
As @Jack Look has suggested there isnt really much to say you shouldn't call a process within a process but there may be limited reasons for this to be useful. If you have a large process that requires to be separated into 2 or more processes and each of these has to run consecutively then you would be best to have the scheduler handle this instead of a process calling one of the other. This allows for easier management and retry if one of these should fail e.g. if the second process fails but its being called by a main process then you may need to retry the entire main process and any processes called within it. If there are 4 processes run consecutively by the scheduler and the second one fails then you can retry the second process through the control room itself.
Another reason to not use this is whether the amount of actions within the second process would require it be used as a process. In most cases, if required, then you should create a vbo to handle these actions. For example if within a process you have a requirement to manage a significant number of calculations at a certain point then rather than adding these calculations to a separate process to be called you could create a vbo to contain these calculations and be called when needed which could also, potentially, be reusable by other processes.
------------------------------
Michael ONeil
Technical Lead developer
NTTData
Europe/London
------------------------------
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
08-08-22 06:40 AM
------------------------------
Neha Akhade
------------------------------
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
18-09-23 08:19 AM
Thanks for the insights in the topic on sub process as this is often less explored across teams. I agree with the 2nd reason you stated wrt processes that can be built as actions into VBOs.
But, one thing I would like to clarify on your 1st reason to not use sub process "for easier management and retry" is that we can use Process startup parameters to fix that. Explained broadly below -
We have a requirement to automate a big process that has 6 different sub processes to run by using inputs from the same source and generate 1 processing report at the end. We can use a main process to add the items to the queue and call each sub process at a time to work on the items it is tagged with. Once done the bot will generate the report. Now , we can have a 7 startup parameters ; 6 flags suggesting which process to run and 1 to determine if queue addition is needed. Incase of a termination, say 2nd process terminates, we can manually trigger the Main process with set queue addition as False, and all other flags starting from 2nd one as True. Based on these flag setup and the Main process design, the bot will continue processing from the 2nd one(also retried items) and complete till the 6th.
This seems like an easy way to deal with subprocess termination etc. Could you add onto this as why using a set of subprocesses is not feasible ?
------------------------------
Swapnadeep Deb
Tech Lead, Robotics
TCS
------------------------------
RPA Developer
TCS
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
18-09-23 10:25 AM
Hi swapnadeep Deb,
There are some good points Michael O'Neil mentioned above, but as you mentioned on your specific automation, using different approach based on the requirment There is always not one approach will not fit for all the automation.
There's always tradeoff between one vs other . I always use either one of the approach mentioned
1) using main process to call subprocess( as long there will be less chance to fail what i mean that is all the exception are well handled, forethought about memory consideration,easy for maintenance of the automation and allow for multi bots to run)
2) creating separate subprocess all together.( for better management and allow multi bots to run) obviously this will give lot of flexibility for the support and memory management.
What I'm against is building everything in one process.
------------------------------
-----------------------
If I answered your query. Please mark it as the "Best Answer"
Harish Mogulluri
Lead developer
America/New_York TX
------------------------------
If I answered your query. Please mark it as the Best Answer
Harish Mogulluri
