Robustness - just in time, just in case
Cafienne version 1.1.13 contains a major overhaul of the timer service. It no longer relies on snapshot based storage, but leverages an independent set of database tables in the event db.
Furthermore this release includes a couple of new APIs to more easily search cases and tasks based on the business identifiers.
New Timer Service implementation
The very first timer service implementation of Cafienne was fully in-memory, making cases with long lasting timers not production worthy. This was solved somewhere in 2018 by snapshotting the timers into the akka journal. This made the system much more reliable, but when the number of timers grows, the snapshot also grows, so we needed a better solution. We are pleased to announce that this release 1.1.13 contains a reliable, saga based overhaul of the timer service, enabling it to handle potentially millions of parallel timer events (volunteers that want to setup a test for this are welcome ;). The new implementation adds tables to the configured akka event database that hold track of individual timers.
New API for business identifiers
When retrieving cases, the set of business identifiers of that case are also returned in a separate json structure. In addition a new API has been introduced to retrieve a list of all business identifiers with their values. This helps filtering, sorting and retrieving more specific case instances at the front end.
Cafienne IDE contains a simple debugger, that can list the events generated in cases and tenants. When there are thousands of events, loading becomes too slow. The special engine debug route has been extended with pagination to overcome this.
The internal build street has been extended to run the full test cycle - including compability tests - on each master build. Furthermore a few external dependencies have been upgraded and some internal Java APIs have been made public to enable external pluggability of the engine.
|Master-build should also run a build with empty event store for PostgreSQL and SQLServer
|Internal tenant user state is not updated upon TenantAppliedPlatformUpdate