In Cockpit, I cannot cancel subprocess body when modifying process instances via batch

[tasso94]

Environment (Required on creation)

Any Camunda version in which the modification feature is present.

Description (Required on creation; please attach any relevant screenshots, stacktraces, log files, etc. to the ticket)

I cannot cancel the subprocess body (expanded or collapsed) in Cockpit when modifying process instances via batch.

Steps to reproduce (Required on creation)

1. Create a BPMN with a collapsed or expanded subprocess and deploy it.
2. Start a process instance and continue the token to the subprocess.
3. Click on the modify tab on the process definition runtime view.
4. Hover over the subprocess in the diagram.

Observed Behavior (Required on creation)

No cancel button is present.

Expected behavior (Required on creation)

Cancel button is present.

Root Cause (Required on prioritization)

• The frontend displays the cancel button only on activities that have a count of > 0 active instances
• This is determined by the process definition statistics query
• The query does not return the information about subprocesses

Solution Ideas

• Render the cancel button for subprocesses unconditionally
  • Variant: Render it only when there are statistics results for any contained activities (similar to when the three dots as the activity instance count are currently displayed)

Hints

• The process definition statistics query cannot be easily extended to include the count of subprocess instances. That is because ACT_RU_EXECUTION doesn't store the activity ID for non-leaf executions. So it is impossible on SQL level to figure out which execution belongs to which subprocess. In postprocessing of results, that is also not easily doable because the statistics do not tell us how many activity instances are contained in one subprocess instance

• This bug is already present for quite some time (cf. https://jira.camunda.com/browse/CAM-8166).
• The problem doesn't exist on the process instance runtime view. That is because there the entire execution tree is loaded from the database and the scope hierarchy is reconstructed by using the BPMN model. This approach is not feasible for the process definition statistics query due to the potentially large amount of process instances.

Links

• [ ] https://jira.camunda.com/browse/SUPPORT-17986

Breakdown

### Pull Requests
- [ ] camunda/camunda-bpm-platform-ee/pull/893
- [ ] https://github.com/camunda/camunda-bpm-platform-ee/pull/898

Dev2QA handover

• [ ] Does this ticket need a QA test and the testing goals are not clear from the description? Add a Dev2QA handover comment

[venetrius]

As it is mentioned in Solution Ideas the cancel button could be rendered for subprocesses unconditionally OR rendered only when there are statistics results for any contained activities. For leaf processes showing the Cancel button also relies on the activity instance count and not shown if the runtimeActivityInstanceMetrics is disabled in config.js .

When showing a Cancel dialog the current behaviour is to send a POST request to camunda/api/engine/engine/default/process-instance?firstResult=0&maxResults=12

{
  activityIdIn: ["activityIdOfThePRocessToCancel"]
  firstResult: 0
  maxResults: 12
  processDefinitionId: "processDefinitionIdOfDiagram"
  sortBy: "instanceId"
  sortOrder: "desc"
}

This query does not return instances for nested processes. OPTIONS:

• Change the front-end to send a request with: activityIdIn: ["activityIdOfLeafActivity1", ... "activityIdOfLeafActivityN"]
• Change the back-end query to recursively select instances for all child activities as well.

[venetrius]

Solution proposal. To enable the cancel functionality send the list of child activity ids as a list to the BE.

Existing behaviour for cancel:

• In the cancel popup the activityIds are shown
• Request sent to api/engine/engine/default/process-instance/count containing activityIdIn: [< activityId >]
• This method is currently not supported for subprocess cancellation.
• There is no option in ProcessInstanceQuery that returns all instances for a multi-level subprocess.

Proposed change:

• Show the cancel button for subprocess which has instances
• Collect the activityIds for all of the subprocess` activity ids
• Send request containing ["activityId1", ... "activityId"]

PRO:

• We already have the BPMN diagram parsed in the FE in the current scope and it understands the parent-child relationships.
• Listing all the activityIds provides clearer insight into the process for the user.
• It does not change the behaviour of the BE
• No change required to the request body other than adding more items to the activityId array

CON:

1. Sending a lot of activityIds can be problematic if:

• We hit some kind of limit with either the length of valid URL or the number of params the BE accepts.
• Having a lot of ids in a search query that relies on self joining a table can slow down the DB.

Mitigatigation:

• Test the functionality with a subprocess that has relatively high number of children activities.
• Set a parameterizable limit. If close to this number, a warning will appear to inform the user. In cases of a large number of activity IDs, we will default to showing all activities for the diagram and display a warning explaining the behavior.

Alternative solutions via BE changes:

Solution ideas w/ drawbacks:

1. Change the ProcessInstanceQuery behaviour to return activities that are registered for the children:

• It would be a breaking change as processes built on previous behaviour would work differently.

2. Create a new end point / new query flag to support this behaviour.

• It sounds more like a new feature rather then a bug fix.

Regardless of previous question (using a new or existing route/ settings) we also need to get the data. To get the data 2 options were considered:

Create an in query.

1. Check if the activityId belongs to a collapsible process. If yes load the BPMN diagram to parse the diagram and do an in search against ACT_RU_EXECUTION.

• This also has similar drawback as the front end solution. Degrading DB performance in case of a large subprocess with lot of activities.
• Less option showing a warning /danger message if the selected subprocess has many instances

2. Implement a recursive SQL query (Further investigation is required.):

• This requires careful planning and testing to mitigate performance risks.
• It is dependent on SQL implementation details.

[venetrius]

Based on team feedback: Having too many activities in a SubProcess is unlikely and only result in a slow page load, it does not worth the time investment to create a warning and property just in case.

[gbetances089]

This one looks pretty good, nice one @venetrius

Video: https://www.loom.com/share/808eedab15a041cfab2bf2798a2fce71?sid=77bedcaa-a7bf-4ed3-9948-9c891e90a01a