Skip to Content

Referenced vs. Embedded processes in SAP NetWeaver BPM


    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.


    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-process example

    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-process example

    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:


  • 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.



    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:





























Loose coupling, runtime patchability









Tight coupling, strict versioning









Tree-like runtime structure









Process context monitoring/editing









Inherit parent process context










  1. SAP Help Portal – Modeling processes with Process Composer
  2. 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.

You must be Logged on to comment or reply to a post.
  • Hi Kristiyan,
        I guess you painted this situation quiet well. Depending on the use cases, you can pick which one will fullfil your requirements better. In addition to this very extensive list of things to consider, I would add the following:
        1. If for some reason, you need to decompose a step into more details and this extension requires more context variables, this will have an impact on where these are added. The referenced sub-process can hide some of this additional overhead without “poluting” the higher level business process.
        2. There is an implicit participant inheritance in embedded sub-processes compared to re-usable sub-processes. This is relavant for sub-processes containing user centric activities. In the former sub-process case (embedded), it inherits the role or lane which the sub-process is placed. On the referenced sub-process, you can define which one you want to bind it to. It is always true you can assign tasks directly to individuals, but we it comes to role-based security, this may have some implications.
        3. Side effects: You can safely implement changes to embeddable sub-processes as they are only consumed by the embedding process. On the referenced sub-process case you need to have into consideration who else is using it. This is specially important when you change input and output parameters of the referenced sub-process.
        4. Lifespan of process instances: In the embeddable case, you are safe as all is self contained. In the referenced sub-process case, you need to make sure all process instances remain available for traceability and monitoring purposes. If you are planning some data prunning and cleanup, do not forget about cross process references.
         Hope these additional comments help !


  • Hi Kristiyan,

    in old time(7.11,7.2), the referenced process is supposed to have automated task(short running) only,

    now it seems we can have human activity.

    when this enhancement is implemented?

    Best regards.


      • Hi Kristiyan,

        so for all the process we can use synchronous operation? in old times, we have to use asynchronous operation.

        Best regards,


        • It depends – if you use a synchronous operation then the parent process will wait for the child to complete. If you use an async operation then the child has to send a message to the parent before completing to notify it; the parent needs to be modeled to listen for that message.


          • ok, in old times the parent process cannot wait for too long that’s why the referenced sub process contains short running activity. now (7.3 onwards) the parent  process can wait for longer(even forever)?

          • That is correct. The parent process doesn’t time out anymore if a referenced process is called using a synchronous interface. I can confirm that for 7.4 SP 8.

          • I tested in 7.31 sp8, which is also working.

            I think this is a huge improvement(previously the referenced process is completely useless in most case), why it is not mentioned in sp new feature……

            it’s a shame I designed bad solution for my previous customer because of unawareness of this feature.