[FEAT] CasePathResolver: distinguish completed and pending elements passed as input parameters to infer more flows/edges in the path

[tbouffard]

DISCLAIMER: this issue describes path computation for a single instance/case only. So the implementation will go to the CasePathResolver class as it differs from PathResolver which is a generic implementation that both deals with single instance or all instances of a process.

Is your feature request related to a problem? Please describe.

In https://github.com/process-analytics/bonita-day-demo-2023/ but also in the prediction demo of the bpmn-visualization-examples repository, elements provided to compute the path are either completed or pending.

The completed state is intended for:

• executed
• definitively cancelled (for BPM engines that support this and allow cancelled elements to be continued
• i.e. no further user action or automation will update the element.

The pending state is intended for:

• executing
• activated
• in progress
• waiting (for user actions, external system, ...)
• no status
• in error and waiting for a resolution

IMPORTANT: the pending state is only for flownode/shape. The flow/edge is considered transient and quick to execute, so it is not supposed to be pending.

Describe the solution you'd like

Enrich the existing method to support this use case:

• Pass a dedicated object to categorize the input ids: completed and pending
• In the "provided" elements returned by the implementation, also returns the related "pending" elements retrieved from the model
• Compute the flow/edge related to the pending elements: there will be considered as "completed computed" elements

IMPORTANT: this is the first implementation, there won't be any specific processing for elements with special behavior due to the BPMN Semantic (for instance, parallel gateway). This will be described in dedicated issues.

Questions to answer prior starting the implementation

Do we de-duplicate completed and pending elements in the provided property of the object returned by the method?
i.e. if the same ids is passed in both the completed and pending elements,

• do we return the related elements in both pending and completed of the "provided" object?
• Should the two lists be duplicated? Which should be preferred?

Use case validity: loop. A task is first completed, go to a gateway and go to a path that triggers the task again.
The diagram would contain: completed --> pending --> completed
The flow/edge between the "pending" and its following "completed" element should not be inferred.

Which would mean:

• For completed elements represented by a shape, we can considered that both the incoming and the outgoing flows/edges are part of the path. This is what is done in [FEAT] CasePathResolver: add a method that returns the "full path" i.e compute both Shapes and Edges #22.
• However, this is not the case for those from pending elements : we can only considered that the incoming flows are part of the path

Tasks

Beta Give feedback

1. Update the JSDoc to clearly explain what are completed elements [FEAT] CasePathResolver: add a method that returns the "full path" i.e compute both Shapes and Edges #22
2. Update the JSDoc to clearly explain what pending elements are
3. Validate the types of the input parameter and the returned value. The initial proposal is available in feat: introduce CasePathResolver #142. If something changes, please describe it here
4. Add tests for all use cases described in the issue, in particular, for special cases mentioned in the pending questions