Background
While modeling your business process you might come across a step that requires a more complex flow than a simple task or automated activity. That is where sub-processes come into play. The point of this article is to explain the differences in detail between the two choices of sub-processes – referenced and embedded.
Have in mind that we will not be going through the basics of BPM modeling but rather require a minimum level of understanding of the core concepts of it. For more info on process modeling please refer to the SAP Help Portal here.
Aspects in which sub-processes differ
Sub-processes appear naturally while modeling your business workflow. Other than the obvious differences between them (how they get triggered and how they get displayed on the diagram), there are a few aspects of which you should be aware prior to deploying your processes to a productive environment and all of those can be viewed as either pros or cons, depending on your use case.
Versioning
The concept of versioning is quite simple – every time you change your business process in any way and build it, it gets a new version number which is higher than the old one. Every time you deploy a changed process version it becomes the ‘Active’ one – meaning that every new instance of your process from this moment on will be of the new version but currently running processes will continue to use the old one until completion.
One of the main differences between embedded and referenced sub-processes is their versioning behavior.
Referenced sub-processes
Referenced sub-processes are an entirely separate, reusable unit in the BPM model. As such, they have their own version and are packaged as separate entities. They are decoupled from their parent process via the web service interface that triggers them. Every time the parent process starts an instance of its sub-process it will essentially call a web service with the defined input. When the sub-process instance is being created the BPM runtime will choose the newest available version (assuming that the input has not changed or has changed in a compatible way). This behavior (also known as runtime patchability) allows you to patch already running processes by swapping out their referenced parts and is a conscious design decision of the framework.
Embedded sub-processes
Embedded sub-processes, on the other hand, are more of a convenience in this aspect – they do not exist as separate artifacts and thus are not reusable. As such the embedded processes carry the version of their parent process (which contains their definition) and are tightly coupled to it. Being a part of their parent process also means that even if a new version is deployed during process execution, the BPM runtime will execute the old version which is a part of the currently running parent process. Notice that the parent process and sub-process are actually tightly coupled and cannot exist separately. This behavior can be viewed as strict versioning.
Supportability
As was mentioned above, referenced processes are loosely coupled while embedded ones are tightly coupled to their parents. Because of this property the two kinds of sub-processes differ greatly in supportability.
Referenced processes, on one side, are detached using a web service interface and if they fail while being executed the failure will be isolated to them only. When they fail their parents remain intact. In a way that makes referenced processes more flexible and guarantees you that if one of your nested processes fails your entire process will not fail as well.
Embedded processes, on the other one, are tightly integrated into their parents as a part of their flow and if they fail the entire process that contains them fails.
Traceability
Traceability refers to the completeness of the information about every step in a process flow – another point in which the two kinds of sub-processes differ. There are several aspects to this:
- Process Manager in NetWeaver Administrator – there is a difference in how processes are displayed on runtime. In the case ofreferenced sub-processes, they form a tree-like structure that is clear to understand and easy to navigate. It is clear which sub-process belongs to which process. In the case of embedded sub-processes there is no tree-like structure – they are not visible as separate entities in NWA at all, they are a part of their parent process, semantically and syntactically.
- Process Context monitoring– here referenced sub-processes, due to their nature of being completely standalone objects, behave just like top level processes. Their embedded sub-processvariants lack this context monitoring during their whole lifecycle, even when they have already finished. On the other hand, a benefit for embedded processes here is that since they reside within their parent, they inherit its context and can use it without duplicating it as local data objects.
- Debugging – looping embedded sub-processes suffer from a limitation that the currentCollectionItem element is not visible during debug in the NetWeaver Developer Studio.
Summary
There are pros and cons to both approaches and use cases that mandate using either one. The table below tries to summarize the conceptual differences between them:
| Feature | Referenced | Embedded |
| Loose coupling, runtime patchability | + |
|
| Tight coupling, strict versioning |
| + |
| Tree-like runtime structure | + |
|
| Process context monitoring/editing | + |
|
| Inherit parent process context |
| + |
References
- SAP Help Portal – Modeling processes with Process Composer
- SAP Developer Network – Business Process Management
The Author
Kristiyan is part of the NetWeaver CE/BPM Integration Projects team at SAP Labs Bulgaria. The team has years of experience developing customer-like Composite Applications. Implemented scenarios are focused on Business Process Management and working on complex hardware environments with heavy integrations with other SAP solutions like NW MDM, NW PI, ERP and others.
- SAP Managed Tags:
9 Comments
