First item I wanted to discuss: regardless of the event types we are capturing and
storing, we will want to use some of them purely for audit/historical analysis purposes
but others will need to be applied to the alerts engine to detect situations of interest.
I believe currently the alerts engine does not subscribe to the bus for events, so events
need to be supplied to the alerts engine explicitly?
Do we want the alerts engine to have that capability? i.e. as part of the trigger
definition, we offer the ability to define a bus topic/queue/selector to feed the alert
engine?
Or should the "event store" allow a listener to be defined (in the glue) that
could supply events to the alert engine - but then this slightly separates the alert
definition into two parts - the bit bridging the event store and alert engine, and the
trigger definition on how the event should be processed.
Thoughts?
Regards
Gary