Changes to how "Situations" are stored in RTGov

[objectiser]

In the previous version of RTGov, the 'Situations' (created as a result of applying policies or detecting violations) were stored in a relational DB using the JPAEventProcessor, as part of a preconfigured EPN.

With the introduction of the new RTGov UI, it makes use of a SituationStore API to retrieve Situations, and also update information associated with them (e.g. properties), to manage the lifecycle of the situations, etc.

Currently this API has only been used for reading the existing situations, not actually storing them at the point they are created.

As part of the work to leverage ElasticSearch as a store for activity and situation information, an alternative EPN configuration has also been used to store situations in the ElasticSearch repository.

However, to make the infrastructure consistent and more easily configurable wrt the store implementation used for situations, I propose to add a 'store' method on to the SituationStore API, and use it for persisting the Situations within an EPN.

So whether a particular RTGov installation uses JPA, ElasticSearch or any other impl, for storing the situations, it will be a single configuration property to configure this - and then both the EPN and UI will be correctly configured to use the appropriate implementation.

Let me know if this will cause any issues.

[imckinle]

Currently Sitaution Storage is done by listening on the Situation event (EPN). If i understand your proposal  correctly this would mean

- ElasticSearchSituation EPN is removed. We no longer persist based on the situation event

- Storage of situation is perform similarly to how activityStore would work. persistence on creation

- The storage implementation (jpa, ES). Is not controlled via central config.

This might create issues

- Switching to a jpa-Store based  implementation for situations and activities means any kibana based interface would not have data.

Currently the epn based approach means we will alway have data in ES

[objectiser]

ivan mckinley wrote:

- ElasticSearchSituation EPN is removed. We no longer persist based on the situation event

- Storage of situation is perform similarly to how activityStore would work. persistence on creation

- The storage implementation (jpa, ES). Is not controlled via central config.

No, I don't think the mechanism would change - we would still have an event processor subscribing for situation events, and then storing them in the SituationStore. This has the benefit that many EPN's can create situations, but they are only persisted in one place.

The configuration of the SituationStore implementation would be central.

This might create issues

- Switching to a jpa-Store based  implementation for situations and activities means any kibana based interface would not have data.

Currently the epn based approach means we will alway have data in ES

The current default Kibana dashboard is only based on responsetime information - so if a user decided they wanted JPA stores for the activity and situation data, then it should still work fine - it just means they would have access to less information to be able to analyse other aspects.

Its also possible they could use JPA store implementations, but then use the ES Event Processor to store activity and situation data - if they don't want to rely on ElasticSearch as their primary persistence store for such information.