Using the RabbitMQ Connectors to make RPC calls

Camunda 8 Topics Discussion & Questions
2

Hi @MichaelArnauts,

Currently there’s no simple out-of-the-box solution for RPC tasks via RabbitMQ Connector. The setup you’ve come up with is definitely a viable option, but as you mentioned, it’s somewhat cumbersome.

To mitigate this complexity, I would recommend one of the following approaches:

  1. You can encapsulate the complex implementation in a subprocess and invoke it using a Call Activity. See more info here. This way you will only have to implement the RPC pattern only once and reuse it from other processes.

    Note that you can further simplify the usage of the call activity by creating a custom element template. You can hardcode the called process ID and other relevant properties in an element template. See examples attached.

    Combined_Process.bpmn (5.3 KB)
    echo_call_activity.bpmn (2.8 KB)

Call activity element template 
{
  "$schema": "https://unpkg.com/@camunda/zeebe-element-templates-json-schema/resources/schema.json",
  "name": "Combined Connector",
  "id": "io.camunda.connectors.Combined",
  "documentationRef": "https://docs.camunda.io/docs/components/connectors/out-of-the-box-connectors/automation-anywhere/",
  "version": 1,
  "appliesTo": [
    "bpmn:CallActivity"
  ],
  "elementType": {
    "value": "bpmn:CallActivity"
  },
  "groups": [
    {
        "id": "message",
        "label": "Message"
    }
  ],
  "properties": [
    {
      "type": "Hidden",
      "value": "Combined_Process",
      "binding": {
        "type": "zeebe:calledElement",
        "property": "processId"
      }
    },
    {
        "group": "message",
        "type": "Text",
        "label": "Message ID",
        "description": "The message ID to be echoed",
        "constraints": {
            "notEmpty": true
        },
        "binding": {
            "type": "zeebe:input",
            "name": "messageId"
        }
    },
    {
        "type": "Hidden",
        "value": "echoedId",
        "binding": {
            "type": "zeebe:output",
            "source": "=echoedId"
        }
    }
  ]
}
  1. If hosting an on-premises connector runtime is an option for you, you can create a custom RabbitMQ connector implementation using the Connector SDK. You can then spin up a self-managed connector runtime instance and either connect it to a SaaS cluster or use it with Camunda 8 Self-Managed.

Regarding multiple connectors subscribing to the same queue, this is currently not recommended because every connector in the diagram currently leads to creation of a separate RabbitMQ subscription. Because of that, if you run it without additional server-side configuration, consumers will be stealing messages from each other. While this may technically work if you set the correct activation condition in your connector, unexpected things can happen due to messages being constantly requeued after being read by a wrong consumer.

The good news is that we’re considering a way to support more flexible configuration of how connectors are mapped to subscriptions. See similar issue here. We will share more details when it’s available, but for now we recommend using one queue per connector.

1 Like