Skipping an async ServiceTask with the ManagementService

[damokles]

In our JavaServiceTask we are calling an external REST-Service that is unfortunately not idempotent. Due to an exception the Activiti execution was rolled back after the service call was made. In the subsequent retries the REST call fails since it already knows the transaction id. We need a way to skip the actual service task execution and move to the next step, which in our case is a complex event gateway with three messages.

Using the ManagementService we have wrote this command, that almost does what we want. The problem is that it does not delete the async job for the current task, and that it somehow creates a new ProcessInstanceId, while keeping the ExecutionId the same, I would have expected the opposite behavior.

Any tipps what we are missing here?

public class PerformOutgoingBehavior implements Command<Boolean>, Serializable {

    private final Execution execution;

    public PerformOutgoingBehavior(@Nonnull Execution execution) {
        super();
        this.execution = execution;
    }

    @Override
    public Boolean execute(CommandContext commandContext) {
        ExecutionEntityManager executionManager = commandContext.getExecutionEntityManager();
        ExecutionEntity executionEntity = executionManager.findExecutionById(execution.getId());

        new BpmnActivityBehavior().performDefaultOutgoingBehavior(executionEntity)
        return true;
    }
}
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

[jbarrez]

No, the job won't be deleted in this case. It simply moves the execution pointer further, but leaves the job as-is.
If you need it, you really would have to delete the job in the same command.

However, can't you solve it more gracefully with a try - catch in the async service task? And then in the catch to the appropiate routing?

[damokles]

The problem is that the return code of the REST-Service is not descriptive enough to use a try catch for this scenario, since there might be other errors that have the same status code that should be retried. No ideal I know, but that is how it is at the moment.

EDIT:
Deleting the job would not be the problem. Is there anything else I should be aware of?

Regarding the new ProcessInstanceId, that was an unfortunate error in our monitoring tool which switched executionId and processInstanceId.

[jbarrez]

No, if you do a delete of the job, and execute a default bpmn 2.0 leave with the execution - should mimic what the job would normally do.