Sub Process vs Start Process

AFAIK this is basically just a case of "feature convergence" - originally-separate features being fleshed-out (separately) to the point where they become nearly interchangeable, if not totally interchangeable.

They may be planning to phase out the classic subprocess node altogether - though it's impossible to say either way.  The "start process" node needs a few more improvements before that can happen, though.

• the node icon needs to let us differentiate synchronous from asynchronous, like the subprocess node currently does and traditionally always has
• it needs to more-flexibly handle opening the subprocess from the parent level; running subprocess instances, for example, as well as subprocess model when defined by expression (at least when defined by something stupidly-easy / nonconditional, like via a single constant)
• probably needs the ability to pass variables by reference, for the rare occurrence when it's the only way to handle something
• when searching a model by name in the process model editor search bar, we need a way to "drag and drop" the target model as a Start Process node instead of (or preferably, in addition to) the classic subprocess node.

Activity Chaining in start process

The documentation says, we can't get the process variable back from child process. "Chaining through a synchronous Start Process node means the original process will wait for other process to complete before continuing. Any activity chaining in the started process is not connected to the original process, so a broken chain will not return process variables to the original process."

Synchronous Start Process

Here documentation says, we can take the output variable from child process.

Can anyone please clarify what it's referring to as per the latest updates in start process and sub-process?

What Mike Schmitt said is right, a long term goal is to move away from the subprocess node and converge the features into one node, start process smart service. However, it is correct to say this requires more improvements and may take a long time, there is no set roadmap as of now. 

 preethist The most important part of what is being said in that copied text from docs is that the start process smart service no longer (the version of the node prior to 24.4 does do this) uses activity chaining to define synchronous behavior. Instead, you define whether or not to run the child process synchronously in the node configuration (setup tab). If you choose to run the child process asynchronously, no output data is returned. However, if you choose to run the child process synchronously, then the PVs of the child are returned at the end of the child process, NOT the end of the child activity chain.

As to the chaining behavior: If you have an activity chain in your parent process, and that chain is on the flow before the Start Process node, the chain in the parent will wait for the entire child process to complete, that is, we are chaining through the child process rather than into the child process. This is akin to chaining through a call integration node, for example. The subprocess node chains into the child process, where the chain in the parent continues into the child. Start process does not work that way.

What Mike Schmitt said is right, a long term goal is to move away from the subprocess node and converge the features into one node, start process smart service. However, it is correct to say this requires more improvements and may take a long time, there is no set roadmap as of now. 

 preethist The most important part of what is being said in that copied text from docs is that the start process smart service no longer (the version of the node prior to 24.4 does do this) uses activity chaining to define synchronous behavior. Instead, you define whether or not to run the child process synchronously in the node configuration (setup tab). If you choose to run the child process asynchronously, no output data is returned. However, if you choose to run the child process synchronously, then the PVs of the child are returned at the end of the child process, NOT the end of the child activity chain.

As to the chaining behavior: If you have an activity chain in your parent process, and that chain is on the flow before the Start Process node, the chain in the parent will wait for the entire child process to complete, that is, we are chaining through the child process rather than into the child process. This is akin to chaining through a call integration node, for example. The subprocess node chains into the child process, where the chain in the parent continues into the child. Start process does not work that way.

James Lepone said:

no longer (the version of the node prior to 24.4 does do this) uses activity chaining to define synchronous behavior

On this note - I believe this behavior change requires some sort of additional enhancement before it's ready to fully replace some of the use cases that the original behavior facilitated easily.

For instance, from a particular Site form I have a Start Process invoked from a button click, where the process started generates a report (excel export) relevant to the report on the form in question, and once the document is generated, the process hits a timer node and chaining breaks.  The usual turnaround time for this is 1 - 3 seconds, for reference.  Thanks to chaining being broken, the start process node is able to retrieve my process data, including the generated Document ID, and displays a Document Download Link to the user to download their freshly-generated excel document.  This is intended to be transient and therefore, after a brief period of time in the original process, the timer node expires and the process goes through a Delete Document node and then ends.

AFAIK this use case will be impossible to replace with the newer behavior, lest we force the user to sit there waiting for 30 seconds or whatever the "timeout" value is for the "on incomplete" condition.  I could make the process end immediately but that would require me to do new and silly bending-over-backwards to use the delete-on-timer end of the process.  It seems like there should be a way to signal the end of the synchronous portion of the intended process call - chaining worked OK for this, and i'd be willing to consider alternative options, but i'm not sure I understand why the one they settled on was "actually, nothing at all, sorry"?

 Mike Schmitt The behavior is possible with the new version if you split the process you are calling into two processes. The first process would handle the excel report, and then call the asynchronous part of your process to delete the document after a set amount of time via another SPSS node running that process asynchronously.

I understand this is a bit of a lift from a development perspective, but it was a conscious decision we took to make the meaning of synchronous and asynchronous more clear throughout the platform. I understand the desire to do what you are talking about though to keep process model designs simpler. However, it is not a planned improvement as of now.