Camunda工作流引擎：注册流程中并行任务完成其一后自动取消另一任务的实现咨询

Hey there, let's tackle this problem you're facing with your Camunda registration workflow. The core issue here is that your two parallel tasks aren't aware of each other's completion—so when one finishes, the other stays active, creating duplicate execution paths. Here are a few reliable approaches to fix this:

1. Use a Cancel Boundary Event on Parallel Tasks #

This is the most straightforward model-driven approach for your existing parallel setup:

• Attach a Cancel Boundary Event (triggered by a signal) to each of your two parallel tasks: Edit Request by User and Approve/Reject by Admin.
• Configure each task to send a unique signal upon completion:
  • When Edit Request by User finishes, emit a signal like user_completed_edit
  • When Approve/Reject by Admin finishes, emit a signal like admin_completed_review
• Set each boundary event to listen for the opposite signal. For example, the boundary event on Approve/Reject by Admin will listen for user_completed_edit—when this signal is received, it immediately cancels the admin task and its associated execution path.
• Important: Scope the signal to the process instance's execution to avoid accidentally canceling tasks in other running workflows.

2. Code-Based Task Termination with Camunda APIs #

If you need more custom logic, use Camunda's APIs to cancel the inactive task when one completes:

• Add a Task Listener (attached to the "complete" event) to both tasks.
• In the listener code, query for the other active task in the same process instance using the task definition key and process ID.
• Once found, delete the task and cascade the cancellation to its execution path.
• Example Java snippet for the listener:

  @Component
  public class TaskCompletionListener implements TaskListener {
      @Autowired
      private TaskService taskService;
  
      @Override
      public void notify(DelegateTask delegateTask) {
          String processInstanceId = delegateTask.getProcessInstanceId();
          String currentTaskKey = delegateTask.getTaskDefinitionKey();
          // Swap to the opposite task key based on current task
          String oppositeTaskKey = currentTaskKey.equals("editRequestUser") 
              ? "approveRejectAdmin" 
              : "editRequestUser";
  
          // Find active instances of the opposite task
          List<Task> oppositeTasks = taskService.createTaskQuery()
                  .processInstanceId(processInstanceId)
                  .taskDefinitionKey(oppositeTaskKey)
                  .active()
                  .list();
  
          // Cancel each found task
          for (Task task : oppositeTasks) {
              taskService.deleteTask(task.getId(), true);
          }
      }
  }
  

• For REST API users, you can replicate this logic by calling the /task endpoint to find the task, then sending a DELETE request to /task/{taskId}?cascade=true.

3. Replace Parallel Gateway with Event-Based Gateway #

Since your use case is an "either/or" scenario (only one task needs to complete), an Event-Based Gateway is a more semantically accurate modeling choice:

• Swap your parallel gateway with an event-based gateway.
• Connect the gateway to each of your two user tasks. The gateway will wait until the first task is completed, then trigger that path and automatically cancel the other task's execution.
• This makes your workflow intent immediately clear to anyone reviewing the BPMN diagram, as it explicitly shows only one path will be taken.

Key Tips for Success #

• Test edge cases: Make sure the solution handles scenarios where one task is completed just before the other (to avoid race conditions).
• For signal-based approaches, use instance-specific signal correlation to prevent cross-process interference.
• When deleting tasks via API, verify that no orphaned executions or data are left behind in Camunda's database.

That should resolve your issue of having duplicate active execution paths. Let me know if you need help with any specific modeling or coding steps!

内容的提问来源于stack exchange，提问作者Simin Ghasemi