Closed jonathanlukas closed 1 year ago
Hi @jonathanlukas, this sounds like an excellent extension, thank you for the detailed write up! Is it something you are looking to transfer into the Camunda Community Hub, or do you need me to create a new repo for you?
Hi @xomiamoore I will require a new repo for this: internal-task-handler-camunda-7
I would name it.
Excellent! I opened a new repo for you here: https://github.com/camunda-community-hub/internal-task-handler-camunda-7
I also sent an invite for you to become a member of the Camunda Community Hub.
You should be able to update the repo as needed now.
Let me know if there is anything else I can help with!
Extension description
The extension aims to combine all advantages of embedding code and engine to the same application with the advantages of the external task pattern.
The extension contains Java Native Factories to spin up an external task client that is attached to the Camunda Java API. The API is very close to the external task worker Java API, but it does not require network traffic or a REST API. Workers can be registered and work on tasks. The API also contains the possibility to manage the threads that the workers use.
Building up on this, there is also a spring-boot-starter in place that manages the lifecycle of this client.
Suggested use case
If there is a valid reason to use the external task pattern, but the setup / environment makes it hard to run multiple applications or the REST API cannot be used for various reasons.
One thing to keep in mind is that migration to C8 will be a lot easier when the external task pattern was used in first place.
Configuration
The extension requires the external task service of the Camunda 7 Java API to function. There are some more properties which can be added via builder pattern.
Dependencies
core: only org.camunda.bpm:camunda-engine is required. spring-boot: core and org.springframework.boot:spring-boot-starter is required.
There are some test dependencies required as well.
Issues/Challenges
I am still investigating on how I should create the binding between task handler and threadExecutor. Currently, it is done via bean name, but I am not yet fully decided.
Extension lifecycle
Despite having test setups and examples added, the extension is in a POC phase and should be hardened by at least one production setup using it. One reason is that the thread management could require some more investigations.
Additional context
EOL will be together with C7, however I like the idea and would like to offer it to the community.
Maintainer eeded?
no