Would anyone like a Camunda Java REST client library?

Community Contributions & Discussions
1

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
2

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
3

@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
4

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

6

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

7

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

8

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.

9

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

10

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")?

11

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:

12

Thank you for the API client.

Is there a similar Client in JavaScript.

13

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

14

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.

15

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
16

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
17

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

1 Like
18

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…

19