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.
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.
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.
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 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:
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 |
| + |
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
35 | |
21 | |
17 | |
15 | |
11 | |
9 | |
8 | |
8 | |
8 | |
7 |