Process Chaining

With the help of sub-processes it is possible to link several processes. Linking processes or modeling process starts within a process creates dependencies between the processes, because from the time of linking, each overall process combination must be active and compatible as a whole.

Dependencies

Basically, when a process is activated, it is necessary that all processes called in it are also active and that the chain of active processes is consistent in itself. The construct of a chain, however, is basically not to be understood as an independent unit, but is always dynamically composed of the currently active process versions. This is due to the way SAP Business Workflow works, since only one active version can exist in the workflow environment. This means that versioning and activation of a sub-process can also affect processes that are already running.

Based on the above example, the versioning and activation of process B (new version 002) means that even running processes A start process B in the new version 002 after activation, provided that process B was not already started when version 001 was still active.

The knowledge about this behavior is especially important because it shows that processes may actually only be adjusted minimally, since the entire process chain cannot be activated consistently as such.

The activation of a new version of process A and B does indeed lead to new processes being started with version 002. However, processes already running in version 001 of process A always start process B in version 002 from this point on.

This means that used processes must always remain compatible with already activated uses. Special attention is paid to the object list that is transported between processes. If this list is restructured from the perspective of an overall process, this may lead to inconsistencies in processes that are already running.

If entire processes are to be completely restructured, it is recommended to define completely new processes instead of new process versions.

Activation

To ensure that the dependencies described above are adhered to, an automatic activation logic takes place. All processes involved are determined and the target versions are determined. It is ensured that no inconsistencies arise, e.g. by forcing a versioning of process A for the above mentioned case. New versions can be created directly and automatically during activation. Therefore, it is not necessary to manually version all involved processes before activation.
However, if versions have already been created, the user can decide which version should be used. If one assumes the above example, but the user would also have prepared a new version of process A, then this version would be recognized during activation and automatically suggested for activation. In the dialog, however, a new version can still be forced explicitly.

The entire activation process can reach a very high complexity, because each process version can have a different structure. Selecting a specific version can therefore lead to further processes being involved in the concatenation or to chains being broken up or decoupled. For this reason, after each selection of a different version, a complete re-determination of the dependencies is performed.
Once all versions have been determined, it is not yet certain that the constellation is completely correct in every case, since certain process versions may not be compatible with each other. This will be checked immediately after the confirmation of the changes and, if necessary, a complaint will be filed.