At Operaton, we’re all about making things simple, efficient, and user-friendly. That’s why we’ve adopted a centralized approach to managing community plugins:
Popular plugins will be forked and maintained directly within our official GitHub organization.
No extra “community hubs,” no scattered repositories – just a single, reliable source for all plugins under the Operaton umbrella.
This ensures:
Up-to-date plugins
Consistent quality
Easy access for contributors and users alike
Our first fork? The Keycloak plugin!
By integrating the Keycloak plugin into Operaton, we make it easier to manage authentication and authorization for your BPMN workflows. Secure, seamless, and developer-friendly – that’s our promise!
Why a centralized plugin strategy?
• It keeps our ecosystem clean and cohesive.
• Contributors can focus on improving a unified codebase.
• Users know exactly where to find trusted, maintained plugins.
But we want to hear your thoughts!
• Do you think this centralized approach works best for plugin management?
Great initiative with the centralized plugin strategy! Having a single, reliable source under the Operaton umbrella definitely makes sense for maintaining quality and consistency.
The Keycloak plugin is an excellent start – authentication and authorization are fundamental for any production workflow. But I’m curious about the roadmap for other essential plugins:
thanks for the question! Could you elaborate on which problems the mentioned plugins solve? Why would you consider those plugins essential? I guess the RabbitMQ and Kafka Plugins would be adapters to the messaging API? What would a JDBC Plugin do?
In general we are open to implement new engine plugins to be used with Operaton, but we also need to manage our resources, so we need to do a lot of priorization. In the near future, I think it made more sense to port the most commonly used existing Camunda 7 engine plugins to Operaton before implementing new ones
Hi, @javahippie
Let me explain our specific use case regarding the JDBC plugin:
We’re running Camunda in a high-volume environment processing ~100,000 process instances per day. These processes remain in execution for extended periods, waiting for external events to advance or complete.
Our architecture challenge:
To handle this volume, we’ve had to separate our data into two databases:
Process engine database: Contains only the runtime process data (executions, tasks, variables) Business data database: Contains all our business domain data
We’ve also disabled the history functionality because at our scale, the database growth becomes unmanageable very quickly.
Why we need the JDBC Plugin:
Currently, we use custom activities to interact with our business database, but this creates transaction management challenges:
We need to chain the engine’s transaction with our business database transaction to ensure data consistency
Managing distributed transactions or ensuring proper rollback behavior across both databases is complex with custom code
Risk of data inconsistency if one transaction succeeds and the other fails
A JDBC plugin would provide:
Native, standardized integration between the process engine and our business database
Proper transaction coordination between engine operations and business data operations
Cleaner separation of concerns without custom transaction management code
More maintainable and reusable database operations across different process definitions
This would make our architecture much cleaner, safer, and easier to maintain as we scale.
Does this use case align with what other users are experiencing with data separation at scale?
I’d be happy to contribute to this kind of work if there’s an opportunity to collaborate on developing such plugins for Operaton.
I think I understand what you mean. I think this is highly platform-dependent, XA-transactions are usually handled by the platform transaction handler of Spring or the Application server you are running on. There should already be support for including other transactional datbases in Operatons handling via two phase commit, but I never used it personally. May I ask you to open a new issue regarding this requirement here in the forum? Maybe we can find a solution for this together. If we realize that this is something that could be handled by a plugin, this might also be the starting point for this
As Tim mentioned we have to triage which extensions will be under the maintenance of the Operaton project itself. I would like to make you aware of one of our initiatives. The Operaton Hub allows to have a central register for components, like plugins, which are evolved outside of the core project. That way use cases like yours can be developed as separate components, while being visible from the core project.
However, it could also be that we decide for certain plugins and extensions that they can become part of the core project.
Anyway, we are really interested in such real-world use cases and how we can address them. So thank you for these insights and keep on communicating with us. I am sure that we can find a solution that serves both sides.
Popular plugins will be forked and maintained directly within our official GitHub organization.
Up-to-date plugins
Our first fork? The Keycloak plugin!
By integrating the Keycloak plugin into Operaton, we make it easier to manage authentication and authorization for your BPMN workflows. Secure, seamless, and developer-friendly – that’s our promise!
Why a centralized plugin strategy?