The RPA bridge can trigger BPMN errors

The RPA Bridge should provide a mechanism to allow configuration of error handling in the sense that - based on error information from the RPA bot - the external task is either handled as a failure or BPMNError.

In the BPMN model, I can define error event definitions (in the camunda namespace) for external tasks:

    <bpmn:serviceTask id="ServiceTask_2" name="Generate quote"  camunda:type="external" camunda:topic="RPA">
      <bpmn:extensionElements>
        <camunda:inputOutput>
          <camunda:inputParameter name="productName">${product}</camunda:inputParameter>
          <camunda:inputParameter name="count">${count}</camunda:inputParameter>
          <camunda:inputParameter name="price">${price}</camunda:inputParameter>
          <camunda:outputParameter name="pdfStorage">${pdfStorage}</camunda:outputParameter>
        </camunda:inputOutput>
        <camunda:properties>
          <camunda:property name="bot" value="PDFQuoteGenerator" />
        </camunda:properties>
        <camunda:errorEventDefinition id="CamundaErrorEventDefinition" errorRef="Error_0x9vl7b" expression="${true}" />
      </bpmn:extensionElements>
      <bpmn:incoming>Flow_04k3izd</bpmn:incoming>
      <bpmn:outgoing>Flow_1s764or</bpmn:outgoing>
    </bpmn:serviceTask>

Camunda error event definitions extend the bpmn error event definitions by adding an expression that is evaluated when

• ExternalTaskService#complete is called
• ExternalTaskService#handleFailure is called

They are evaluated based on all variables visible in the external task scope (including those that are submitted with those API calls) (#handleFailure must be extended in that way). If a trigger evaluates to true, then the corresponding BPMN error is thrown and (the actual behavior of the API method is not performed).

Implementation ideas/hints

• Technical scope is only for external tasks and the two API methods as defined above, but it can make sense to evaluate if there are synergies with conditional events and if it is possible to easily generalize the feature to all kinds of activities and APIs that accept variables
• Before evaluating expressions a context switch into a process application must be performed, so that beans etc. can be resolved (=> look up how this was decided for conditional events in case of hetergenous clusters and with respect to async continuations on tasks)
• Check if output mappings are evaluated when interrupting events cancel a running activity instance
• Extend BPMN model API