Access remote Camunda service programmatically

Hello, I have a remote server installation of the Camunda BPM Platform (installed using the Camunda BPM Platform Helm Chart - camunda-helm/charts/camunda-bpm-platform at main · camunda-community-hub/camunda-helm · GitHub). It is working as expected and, while new to BPM, I have been able to try out some workflows and examples successfully.

I am now trying to connect to it remotely and register for thrown events. I’ve been following Signal Events | however I am stumped as to how I can get a handle to runtimeService. Other than using the REST API is there another way to connect to a remote Camunda service? I’ve tried using the camunda-bpm-spring-boot-starter-external-task-client but no RuntimeService gets initialized. Perhaps I’m missing some remote-specific configuration but I have not found anything in the documentation so far. Based on Camunda Best Practices - Deciding About Your Stack I understand that this should be possible - however, all examples I’ve found deal with an embedded service. Any help is appreciated!

Can you explain in more detail exactly what you mean by this - what is the overall goal you’re trying to achieve? Why do you think signal events are the way to go?

Sure, the bpm workflow outlines the steps in the process. Each step will be handled by a separate microservice, not directly but through a message bus. So effectively, Camunda signal events will be transformed to message bus events and those in turn will be consumed asynchronously by microservices. The responses will be handled in the reverse way.

Signal’s in Camunda are specific BPMN events so they may not be suited for that kind of functionality.
What you can do is create an external task worker that subscribes to a bunch of topics in the engine and when a topic becomes live in the engine the worker can create some kind of even to the message bus.

I would then expect that the message is picked up by something that tried to do the work and sends a message back to the engine that it has been completed

You can check out the best practice docs for more details:

Thank you Niall for your response!

So what I’ve put together since yesterday, uses an intermediateThrowEvent of type external and a designated topic name and on the client side the EnableTaskSubscription annotation with said topic name. This way the event does get back to the client. Not sure if it is similar to what you have suggested (and the signal event is probably something entirely different that I have mixed up). Part of my question is whether this is standard practice, or if I am just hacking it.

What I haven’t looked up yet is how to broadcast back an event afterwards, I assume that would be via the REST API.

Yes :slight_smile: I think thats probably the case :slight_smile:

Indeed it is - there’s a specifically call for completing external tasks.