While documenting some initial ideas for the set of virtual applications that could be implemented for the Savara desktop web app, I realised that there is going to be two ways to determine whether an activity event represents an error (or warning) situations:

1) Statically - when an activity event is being stored, as part of performing the processing of the event, its status can be determined based on pre-configured criteria - e.g. whether some analysis info is present with certain values.

2) Dynamically - when retrieving the information for display, the same pre-configured info could be used to late bind the error status of an event.

The second dynamic option obviously sounds best, as the additional processing is being performed at a less time critrical stage, and it enables the criteria for deciding what is an error/warning to be modified and automatically applied to all previously stored activity event information.

The issue is that the aggregated 'business transaction' view is based on correlation ids, which are indirectly related to a set of activity events. To be able to display an 'error' status against a correlated business transaction, it would need to underlying activity events to be queried, their individual error status determined, and then reflected in the UI associated with that correlation id.

If the error status was directly recorded against the correlation id, then the business transaction viewer would only need to access the correlation id table to present its information, but this would rely on the (1) static approach.

A possible compromise might be using some form of cache (possibly part of the same activity store db - or maybe stored elsewhere, as providing potentially just one interpretation of the business transactions), that is refreshed anytime the configuration (e.g. what constitutes an error) is changed - and loads all activity events and business transactions, and re-assesses them. Refreshing shouldn't necessarily discard old data before creating new, but instead the new result be used to update the existing cached entry. The same mechanism should be used for any relevant 'derived' information based on activity events or correlation ids.

Thoughts?