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?
@CamundaCommando@jangalinskicamunda-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.
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.
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
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.
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…