Would anyone like a Camunda Java REST client library?

A while back we started using Camunda and I noticed there is no REST library for Java.

Would people be interested if I open sourced it? The API covers the core features for Process Engine at the moment.

It uses OkHttp3 for making the calls, I had considered using RestEasy as well.

1 Like

We’ve been working on camunda swagger (https://github.com/camunda/camunda-bpm-swagger) a while ago. It had some issues with historic data and should be updated to support latest service API, but in general this can be a nice approach to generate clients for any language supported by swagger/OpenAPI. If you are intersted, maybe we can revive this project instead of building something specialized for java?

1 Like

@CamundaCommando @jangalinski camunda-rest-client library development was completed? If not I would like to write this library.

I would like to build camunda-rest-client library with below features.

  • Supports camunda java rest api version >=7.11
  • Uses Okhttp library to make rest api call to camunda server
  • Swagger support will be provided for all camunda rest api’s
  • Users can add this dependency to springboot applications
  • Basic Authentication/JWT Authorization will be added as optional
  • Retry functionality will be added for all the GET requests to camunda server
  • Spring AOP will be added to provide cross cutting concerns to all rest api for finding time taken by the each rest api
  • Multi-tenancy will be supported
  • Client-side load balancing feature will be added(microservice architecture)
  • Exception handling(@RestControllerAdvice)/Logging(Lombok) features will be added

@jangalinski if you would like to correct or add any additional features let me know. Also let me know if you think this library would be useful for others, i will take this responsibility and deliver it.

3 Likes

Hello,

Any progress on this? Any code that we can test / use / contribute?

I’ve hit this issue as well: https://forum.camunda.io/t/is-there-a-java-client-for-the-rest-api/15049

Hi,

I started to implement an opinionated (Spring, Feign) Java client. In doing so, I’ll provide feature-by feature, so please file the issues and I’ll try to implement those. Current use case is to use the client for communication between two process applications, so I start with message correlation, start of processes and other black-box-like-activities.

@DanielMeyer, @falko.menge, @BerndRuecker : any chance to get this topic being supported as Camunda Extension? So, I’m looking fo the sponsor.

Hope this helps,

Simon

You are very welcome to join the development. Regarding the features:

  • newest Camunda will be supported
  • OkHttp can be supported, because you can configure Feign to use it
  • Native support for SpringBoot
  • Auth will be handled by feign

Let start by providing required MVP supporting some basic remote features and extend further as time passes.

Kind regards,

Simon

Have you thought about using the original dto classes from the engine-rest module, e.g. https://github.com/camunda/camunda-bpm-platform/blob/master/engine-rest/engine-rest/src/main/java/org/camunda/bpm/engine/rest/dto/task/TaskDto.java ? That could save a lot of effort and make maintenance easier.

I’m using them in the response of the Feign client. Then I transfer back to Camunda Engine (core) API

Great! Interesting also how you provide the RuntimeService in a remote version.
Would the client be usable in a Java app as well or does it require Kotlin?
When creating variables in the Kotlin example, is it necessary to use typedValues, e.g. strignValue("my string")?

Since the RuntimeServiceis a pure Java API Interface it’s usage is straight forward and no Kotlin is required. So the usage is Java / Kotlin, and Kotlin runtime JARs are on the classpath.

For variables handling, @jangalinski and me discussed the feature set of “camunda-bpm-data” extension. This will provide convenience methods for nice variable access including type-safe fluent API in Java and some extension functions for Kotlin. There we will need a sponsor too :slight_smile:

Thank you for the API client.

Is there a similar Client in JavaScript.

This example that shows how to run Java Delegates as External Task implementations might be a good addition to it: https://github.com/camunda-consulting/code/tree/master/snippets/remote-process-engine

Will be Swagger (OpenAPI) project be continued?

I think it’s a good idea. We’re using Node.js with TypeScript so if OpenAPI YAML spec is available, we can generate TypeScript+axios client using openapi-generator.

This will be useful for all programming languages supported by openapi-generator.

On Camunda’s part, if auto-generating OpenAPI from source code annotations is possible, that is preferred: https://github.com/springdoc/springdoc-openapi. While manually writing OpenAPI is possible (I have done it quite a few times), generating from code is better because will always be in sync.

I am sorry to tell that we discontinued the swagger community extension. It was way too much effort to build an open-api annotated version on top of the camunda REST API .
So from that perspective, it’s merely a proof of concept.

But it seems, there might be an official solution on its way: https://github.com/camunda/camunda-bpm-platform/tree/rest-openapi

2 Likes

OpenAPI support is available since Camunda 7.13: https://docs.camunda.org/manual/latest/reference/rest/openapi/

It covers the following features: https://docs.camunda.org/manual/latest/reference/rest/openapi/#coverage

1 Like

Here is an example Java client for OpenAPI: https://twitter.com/falko_menge/status/1283045391123058694

1 Like

In the same time, we will update the camunda-swagger project to create a 7.13 compatible version. It covers everything apart the history API.

Let me have a look how an upgrade version can look like.

It is definitely not a replace to the official solution, but it is possible that for now the coverage of camunda-bpm-swagger has a higher coverage than the official one. So, stay tuned…