Expanding Sub-Process should keep parent untouched

[geroe1]

Description

Given that I import a diagram with nested, collapsed sub-processes. The moment I expand these sub-processes the size changes, triggering a massive relayouting of the entire diagram.

That relayout cannot easily be reverted (on collapse). That is why expanding + collapsing easily gets frustrating.

Context

• You have a nicely formated diagram with a collapsed sub-process

  

• Expanding the diagram will automatically resize the participant, thus breaking the layout:

  

Desired Behavior

• It is possible to inspect the contents of a sub-process without affecting the layout of the parent element. This way I can inspect it without interfering with the host layout.

Alteratives Considered

• It is possible to show (and modify?) sub-processes in a separate tab. This is similar to how we handle editing of decisions in DMN.
• Migrating to Call activities is not an option: The usage of call activities instead of sub processes is no options, since we have plenty of processes, using plenty of sub processes.
• Migrating to un-collapsed sub-processes is not an option: Since these existing processes are fairly big, converting a collapsed sub process in a uncollapsed sub processes is no option, either.
• Even though, feature request (Add ability to extract collapsed sub-process into called process #1354) would help us a lot for new processes.

---

Expand the section below for the original issue:

__Describe the Bug__ After navigating into and afterwards out of a collapsed sub process (see attached file), the following components of the main process (the process, that contains the collapsed sub process) are changed: * the edge to the sub process is moves upwards * the edge from the sub process is moves upwards * the lane is enlarged in all 4 directions (even in negative horizontal direction) according to the lane of the sub process.

Steps to Reproduce

• rename the attached diagram
  MainProzess.txt into MainProcess.bpmn
• open the diagram with camunda modeler
• navigate into the collapsed sub process "sub"
• navigate out of the sub process "sub"

After doing so, the diagram, containing the main process is in disorder.

Expected Behavior

The main process should not be modified, when navigating into a collapsed sub process.

Why and in which context is this behavior crucial?
If you think of a main process, containing a hierarchy of collapsed sub processes (a collapsed sub process in a collapsed sub process in a collapsed sub process...).
If you navigate to the innermost collapsed sub process, change something in this sub process and navigate back to the main process, you have to cleanup all subprocesses, you pass by, in order to conserve the original state.
This is not easily possible and annoying.

Furthermore, of you do roundtrip with signavio, since the root coordinates of the (main) process(es) are changed by navigating into collapsed sub processes, only parts of each process can be shown in signavio after re-importing the process into signavio.

Environment

• OS: ubuntu 18.4
• Camunda Modeler Version: 3.0.1

---

Related to SUPPORT-5355
Related to CAM-10417

[geroe1]

Hi Nico, yes, temporarily and permanently. Meaning: When drilling down into the sub process, the main process should be unchanged, when I come back to the main process by collapsing the sub process. In both cases: - when the sub process is beeing changed - when the sub process stays unchanged. Furthermore, this should also apply to a hierarchy of sub processes. Imagine a main process, that contains a collapsed sub process, that contains a collapsed subprocess. If I drill down into the last sub process, change something in this sub process and finally all sub processes are getting collapsed. Then the main process and the intermediate sub process should stay unchanged. By the way: In https://user-images.githubusercontent.com/58601/56649689-e29af380-6685-11e9-8e55-02fb4aff8f49.png you can see the end event of the main process. This is sometimes confusing. Thanks a lot, Georg

[nikku]

Thanks for your clarification.

In the world of automation you'd generally want to avoid collapsed sub-processes and extract these into their own process models, calling them via a call activity. This is another area where we could improve (cf. #1354).

Depending on where you come from (Signavio in your case) tools have different approaches baked in.

I turned your issue into a feature request and rewrote it accordingly. Could you double check if it represents your intend?

[falko]

I talked to Georg today:
The main intention is to view or edit the contents of the sub-process independent of the parent process. The goal is not to permanently change the collapsed sub-process into an expanded sub-process inside the parent process.

So let us not talk about expanding and collapsing. The focus should rather be on some kind of additional view for working with the hidden contents of a collapsed sub-process. One solution could be an additional model tab similar to how decision tables of a DMN DRD are represented. SUPPORT-5355 goes in that direction, too. This could also be related to working with multiple BPMN diagrams in a single file (see: #524).

[falko]

@geroe1 even if we find a solution in the modeler, this modeling style might cause issues in other tools that visualize the models, e.g. Cockpit and Optimize. It is unclear if similar solutions can be found there and even if so, you might end up with models that are generally uncomfortable to work with and that produce a poor user experience. So I would really invite you to think about permanently expanded Sub-Processes or Call Activities again, as they are well-defined ways to structure processes. Especially, Call Activities might simply be a conversion step during your BPMN export from Signavio. That certainly has some runtime implications but at least you are in the charted territory there.

[mEdling]

As a BPM analyst and developer, I like using subprocesses as a visual way of organizing a large diagram, limiting the number of artifacts in each level/diagram. Also, although this is may be debatable, you may want to hide technical details that sometimes cannot be avoided: internal signals, timers or even temporary version migration workaround flows - stuff around a single task that don't merit an independent process. Coming from IBM BPM, I have also generally used subprocesses rather than linked processes, for execution and variable scope reasons. The last year I have started to use Camunda Modeler for modelling and I have repeatedly been frustrated by the collapse-expand behaviour. I want to drill down and the return back up. A tab like in DMN DRD would work. Regarding 3.5.0, it would make more sense to me to remove expanded subprocesses, rather than collapsed ones - drill down instead of expanding.

[mEdling]

Today I skimmed "Real-Life BPM" 3rd edition by Jakob Freund and Bernd Rücker. In section 2.8 "Subprocesses", hyperlinked navigation is recommended over in-line expansion. Have they changed their minds?

Do you regard call activity as a workaround or an appropriate modelling pattern (meaning true subprocesses are not needed)?

[nikku]

hyperlinked navigation is recommended over in-line expansion.

This is the recommended way to divide and conquer in executable processes.

The reason is two-fold:

• Collapsing and expanding sub-processes is a huge issue when it comes to diagram layout (this is what this issue is about).
• Collapsed sub-processes hide details that are important during process execution and working around that fact is cumbersome. As an example for this you see very limited support for collapsed sub-processes in our runtime and analytics tooling

Do you regard call activity as a workaround or an appropriate modelling pattern (meaning true subprocesses are not needed)?

Yes.

[geroe1]

Hi @falko ,

thank you for your feedback!

It would help us a lot, if collapsed subprocesses could be edited in a seperate tab of the modeler.
Probably a similar functionality would be as helpfull for call activities.
Those two new features would make the camunda modeler much better then signavio, from a developers perspective.

Yes, we considered using call activities instead of collapsed subprocesses, but they have the drawback, that you can not drill into the call activities model.
Furthermore, call activities are, from my point of view no 1:1 match to collapsed subprocesses, since they have their own process context, which makes handling of large process variables possibly uncomfortable.

In future, we want to use call activities, whenever possible e.g. for new processes, but we have plenty of existing processes, using collapsed subprocesses in many levels of hierarchy (subprocess in a subprocess in a subprocess...). For those existing processes, it is currently not possible, to use camunda modeler, unfortunately.

We would be very happy, if the future development of camunda modeler would consider these points.

Thanks a lot,
Georg

[nikku]

Thanks again for the detailed feedback. It helps us a lot understanding your case and we will take it into consideration when developing the tool further.

[theonlynexus]

Hi,
I am relatively new to Camunda and the BPM world, and I am aware that you are already working on the issue, yet you might find my two-cents useful (if not, sorry for wasting 5 minutes of your time).

While on the surface any sub-process can be replaced with a call activity, both you guys at Camunda, as well as other BPMN involved firms, warn about the differences. In particular in your Symbols reference the following is stated about call activities:

The loose connection also affects data transfer between the parent and the subprocess. BPMN assumes that embedded subprocesses can read all the data of the parent process directly, but an explicit assignment is required for global subprocesses to be able to read it. That may seem like merely a technical aspect at first, one that modelers and the consumers of their models care to know about but won’t wish to bother with. After some consideration, however, you may see the impact this difference makes on the organization.

Because of the above I tend to see Sub-processes as a way to "clean-up" the organization of a complex process without the need to explicitly reference an entirely new one. This is also very reasonable since there is often the need to "create alternative visualizations of the same process for different communication purposes and stakeholders".

Being unable to expand or collapse sub-processes, means that every time I want to clean-up a diagram I have to choose one of the following:

• Create two separate diagrams, one collapsed and one expanded, and remember to update both when something changes (which violates the DRY principle and will almost always lead to issues)
• Use a call activity instead of a sub-process, which may seem reasonable, but has deeper implications than just the technical side.

Clearly both of the above are far from ideal (although arguably creating a call activity is the least of two evils), so IMHO collapsible sub-processes are not really optional! :-)

[nikku]

Thanks for sharing your feedback. As an update, expanding sub-processes is on our mid-term roadmap.

[nikku]

Collapsed sub-processes is available in Camunda Modeler v5.0.0-alpha.0. Officially to be shipped with v5.0.0.

Closed via d867b45.