Dear colleagues, good day to you!
Currently we are running several services based on Camunda, and we do not own them (no source code). Is it possible to mimic Operaton in any way to act as Camunda for short-time migration purpose?
Hi @MedPG, Welcome to the forum and thanks for the question!
The answer is „it depends“, I‘d need a little more information on your setup. How are the services connected to Camunda, via REST or via external task client? If that is the case, it might just work out of the box, as the REST API does not have any changes in comparison to the Camunda REST API, which includes the API for external task workers.
Would this fit your setup, or is your architecture a different one?
Thank you for your answer!
We suppose that some of the services use REST as a connection type, and some of them (lesser part) use tasks to operate. We have REST-based plugin without source code that is used to notify other services about Camunda model states.
As an example of Camunda API use, we have tons of import org.camunda.bpm.engine.rest.dto.* - will they work with Operaton out of the box?
Also, thanks you again for your willingness to help, my colleagues will join this topic with more technical details soon!
The imports and the dependency on the REST API would have to be changed to org.operaton.
Operaton helps you automizing this step with OpenRewrite recipes. You would need to execute them once to do the rewrites.
They might, but it’s hard to tell. Can you see which dependencies are really used here? It sounds like you are using a REST client, and the JSON objects delivered by the Operaton REST API should map to its Java classes because the API was really stable, but I cannot guarantee it. If there is software which uses Camunda and you cannot adapt it on your own, my recommendation would be to run some tests against a non-prod Operaton instance. We can only assume what this software does and not give any guarantees upfront, unfortunately.
The datasharingframework project seems to have a similar requirement and they are developing a special class loader to rewrite compiled Java code.
However we have no further information about this and this seems to be in an early development stage. When this turns out to be working, it could be another option for migration use cases.
So to summarize:
- REST Api is 100% compatible (Drop-in Replacement, no need for changes here)
- Java Api → all namespaces changed from org.camunda to org.operaton plus Class Names / Constants that have “Camunda” in their name changed to Operaton. You need to rewrite the Source-Code of it which can be assisted by our OpenRewrite Recipe
- If you don’t have the source code AND the code depends not only on the REST Api but on the Java Api, you should follow the mentioned project/link how they are going to solve this problem. Solving this problem is not on the roadmap for the Operaton project, because this is a rather special use case. Most users do have access to the source code. However we are happy to see contributions for new solutions here.
1 Like
Thank you really much! That’s closely match what I was looking for!!
1 Like