Recently had some internal work around building more integrations around hazelcast and camunda!
From this work, I wanted to check if there was some specific interest in any of the components, and can look to open source them:
A RxJava/reactive based external task provider that is a addin to be used instead of the Camunda external task notifications. Provides Observables for events such as new task created, unlocked, etc (and will/can be extended for all of the various possible events in camunda). There is a modernized external task rest api (matches camunda api) that uses the service (including long polling), supports
keep-aliveheaders, and can easily change out the Rest API for things like Web Socket Support.
Hazelcast Variable handling, to store all variables as “Hazelcast Variables”, which are stored in the hazelcast instance of your choice. Connects in with Camunda Session managers, transactions, rollback, etc. Also has JDBC MapStore support with Micronaut-Data. The purpose is to store your variables immediately in business source locations. This gives you JSON query support as well, so all those typical variables you cannot query on in camunda, are now fully query supported. You can enable Hazelcast’s Near-Cache to further increase performance. Variables are enriched with process metadata such as tenant, engine, process instance id, def key, activity id, etc, to make enhance query capabilities without having to do joins)
As part of the work with variable handling, adding a Hazelcast History Handler / History backend was next: This provides all history entities as Hazelcast Maps, so you can setup in-memory index, queries, near cache, event triggers, etc. And even use things like Hazelcast Jet, or kafka streaming to trigger other event handling.
This implementation provides MapStore (persistence) support as well. As with the variables, you get the support for enhanced querys such as SQL style
WHEREstatements, and dot notation traversal of json structures.
addresses[any].firstLine = 123 Fake Streetmeans “in the addresses array, in any item, in the firstLine field where the field equals 123 Fake street”.
For #2 and #3, the purpose of these components were to remove the 99% of actions out of the camunda DB, and off load them to more business purposed systems of the specific implementation’s choice. The underlying data structures are also in json, so you can further export to other systems (elastic, mongo, etc)
Let me know!