In what situations would any of you use an asynchronous sub-process as opposed to the start process smart service. Based on my understanding, because the smart service will better balance the execution engines without any other negative impacts - I don't see the scenario where I would ever use an asynchronous sub-process. Can someone please elaborate if there is something that I may be missing?
Thank you!
Discussion posts and replies are publicly visible
Asynchronous subprocesses are still a little less painful to actually use, owing to a few potential factors but the biggest (i assume) being that the Start Process smart service is quite a bit newer overall. Given that I spend much of my time monitoring and troubleshooting existing process instances, I build with the consideration that drilling down through subprocess layers (as well as defining subprocess parameters) tends to be a lot more straightforward with the subprocess node. Thus for me at least, the start process node is only prioritized for use in cases where a particularly heavy load will be placed on that particular subprocess call - like bulk instances or things that would typically be fired hundreds of times per day. In most other cases, the performance gain from using Start Process would be so mild that it isn't worth the extra configuration and monitoring hurdles.
Adding to Mike, When you use start process, the new process may use different execution engine based on the load on engines. So the load balance will automatically handled when you use start process. I think sub process will use same execution engine as parent process.
I agree with Mike. I use the start process node when I am initiating bulk activities (maybe from integration call) that are more like system activities and should take advantage of balancing. When I have user activity that needs to trigger/call a process, I use subprocesses. You get the benefits in debugging to follow the path, etc.
What I really think you need to do in this situation is a cost-benefit analysis.
Asynchronous Sub-Process: Cost: Potentially unbalanced load Benefit: Greatly enhanced ability to track for triage of any incidents, or investigation of bugs.
Asynchronous Start Process Node: Cost: Lack of traceability to the process that started it Benefit: Load balanced onto potentially different engine.
Ideally, unless you're doing several million of something, you shouldn't normally see a noticeable impact on the balance of your engines. All the processes that call the subprocesses are themselves load balanced, after all. That lack of traceability, though, will bite you all the time once you get to Production. Not being able to quickly get at the answers can add hours and days to incident triage, which can cause your Tier 3 Support to miss SLAs and make the project look bad.
I'm with Mike and Christine in general, but if you ARE doing a million of something, or your subprocesses are required to be huge, or deeply nested, or take forever, there may be times where you can see negative impact on load balance. I'd do what I can to minimize the factors that make it important to load balance, but in the meantime switch to startProcess if I have to.
If you want to have more control over performance, use a start process. If performance is not an issue, but you would like to have quicker and easier access to your sub-process instances - for example, for testing purposes - I recommend choosing an asynchronous sub-process.
EX:Asynchronous sub-process: If you want to send a notification to your supervisor useasynchronous sub-process.
Asynchronous Start Process:unlike above if you want to get an approval from you supervisoruse start process. A start process is another tool that will allow you to initiate a new process from your main process.