Camunda Connect: How to work outside an embedded WFE

We are trying to use Camunda connect as a standalone WFE (accessible via external services). As such we donot plan to embed it as part of a Java application.

While going through the Camunda Connect capabilities, we were excited to see the http-soap connector. However, from the limited documentation available, it seems that this can only work with a embedded version (adding it into the POM file and then building it).

Is that correct? also any clear, step-by-step tutorial on how to add a Connect service would be greatly appreciated

1 Like

Could you please clarify your desired use-case?

Camunda Connect is not a standalone workflow engine. It is an extension of the workflow engine. Connect comes into play when your BPM processes need to access other external systems or APIs via REST or SOAP.

Camunda Connect is a set of process engine plugins that allow a workflow to make outbound REST and SOAP connections to external APIs and then work with their responses. It allows “modeling” of these connections with out-of-the-box capabilities. The alternative would be to write your own Delegate code for Service Tasks that uses something like Spring REST Templates, etc., for your processes to make outbound calls.

You do not have to embed Camunda within your own application. You can run the standalone Camunda instance such as within a Tomcat or JEE container and your other applications can communicate with the engine via the Camunda REST API, but this usage does not involved the Connector. All you have to do is deploy the Camunda REST API engine and install your process models.

So to be clear, we are curently using Camunda as a stand-along REST accessible engine as you suggest as the second strategy.

Currently, with the default deployment of this engine, I dont believe the engine comes with the Camunda connector, so that we can — for simple activities — call a REST out-of-the-box (without having to write a worker as we are currently doing for some more involved service activities).

My use-case, therefore, is the following: Can we possibly have a stand-along engine, running in Tomcat, handle activities that use the Connect and in the same workflow some activities that have workers running for executing the service task? If yes, I cant seem to find a tutorial on updating a standalong Camunda WFE with such capability. Do help if such exist.

Here is a diagram of what I want to achieve i.e. Service A is called by an activity for a process in the standalone WFE, and then another activity to a second service has the workers polling on a topic. (ascii art is not showing correctly here — sorry for the confusion!)

±----------+ ±-----------+
| Service | | Service B |
| A | | |
±----^-----+ ±—^----±-+
| | |
| | |
| ±–±—v–+
| | Worker |
| ±–±----±+
| | |
±–±---------------------v-----v------+
| |
| |
| Camunda WFE Engine |
| |
±--------------------------------------+


The standalone Camunda deployments should come with the connector plugins configured and installed. If by “workers” you mean that you want to have models that contain both service tasks backed by a java delegates (or script tasks) that perform some of the workflow effort, and have other service tasks that are configured as connectors to call external APIs, then, yes, that should work out-of-the box.

To deploy java delegates you need to create a BPM application that contains your java code, any forms, script resources, etc., and deploy that application to the container. You can do this via a Java IDE such as Eclipse or Intellij, or from console via maven. The easiest way to create a BPM Application project is to use an IDE with the Camunda-supplied maven archetypes to generate the project structure.

You can also use the Camunda spring-boot to create a standalone app. This is a more modern approach that is suited for deployment to scalable cloud environments, etc. If you use Camunda spring-boot then you have to be sure to manually include the connector plugins in your maven pom.xml as they would not automatically be included.

You mentioned polling on a topic. Camunda doesn’t come with JMS integration out of the box to subscribe to message queues, but you can write some java classes to do that integration. A listener class can be created to automatically create process instances for each message that shows up on a queue, or you can have a task that monitors a queue for a specific response based on a correlation key.

With regard to remote RESTful services that might not respond synchronously but require either polling or a callback, you can build a model that loops with a timer to poll the remote REST service at an interval whenever the initial call indicates the need to do so (typically something like an HTTP 200 would mean synchronous return of data while a 201 or 202 might indicate the need to poll for a result).

Some remote APIs may support passing a URL for a callback when the request is done processing, but for those you typically would need to write your own listener or REST endpoint that would receive those calls and then create a message correlation to pass the final results to the workflow.

The Getting Started guides cover both the traditional Java Process Application as well as the Spring Boot approach.

https://docs.camunda.org/get-started/

Thanks Daniel — my case was the first. So the standalone comes with the email and http-soap connector. Let me try it out.

We are not a java-shop, so we are using the REST API to poll for a service. The workers are glue code that polls for a particular topic for the external implementation of a service task.

I would suggest you keep this approach, connectors are harder to configure, harder to test and harder to maintain than external tasks.

2 Likes

Niall, thanks for your input. Your videos (and the hawk) are amazing!

So you suggestion is about the connector is general to new connectors? It would seem that the http-soap connector, if part of the standalone WFE, can be a quick solution for simple API call.

My current thought is that we bring in our custom workers to implement a service task only when the input to the task engine requires multiple back-end calls to application and some extra logic.