Event Log Design
An Architectural guide on Event Handling
In complex use cases, typically with a lot of integrations or important services running on a schedule, errors are bound to happen at some point.
Appfarm allows the developer to catch and handle Exceptions in the Actions flow (e.g. notifying the user that something went wrong), but there may be cases where you also want to explicitly log the exception and where it originated.
This is where building functionality for logging Events comes into play.
This article suggests a simple data model design for capturing such Events when they occur, as well as having a dashboard for monitoring and handling the Event Log.
Why use an Event Log?
Using an Event Log can be especially useful when working with solutions where the developers are regularly circulated, to have a unified design on how to log and track errors that may occur.
It is also excellent for being counteractive rather than reactive on errors and specific events. For example: An important nightly sync job (service) has failed. This should be logged to an Event Log (and optionally also notified by email) so that immediate action may be taken, instead of waiting until someone discovers the error (it may even be too late to fix).
The concept can also be applied to logging system events that are not necessarily exceptions or errors, but merely documenting that an event has taken place. This can be useful when extending your system with numerous integrations that pull or post data throughout your application, or performs various processing steps on a schedule.
The event log can then be monitored on a schedule and reported to a dynamic set of users or recipients. In systems where an error should be accounted for and resolved, you may also extend the design to include features for manually resolve certain events.
Example Data Model
This is a suggestion of Object Classes and Enumerated Types that may be created for implementing an Event Log.
Event Log
Event Log (extended, if entries may require resolvement)
Enum entries
An example setup
In our example solution, we have two Apps and a Service that runs on a Schedule. In addition, we have a Watchdog Service responsible for reporting our Event Logs to a set of recipients.
App A encounters an error when communicating with an external API through a web request, which we fortunately catch in our exception handler. The user is gracefully informed of the event, but we also want to log this to our event log in order to follow up on the incident. We create an event log of Type Web Request with Critical Severity, our action name as Originated in Action and App A as Source.
In another area of App A, we have an action that does some sort of calculation when executed and it is important that we have control of when it was executed. We create an Event Log of Type Action with Information Severity, our action name as Originated in Action and App A as Source.
We have implemented the same design both in our App B and Service 1 for handling critical exceptions and logging key events from our service.
You may also create a Dashboard or Monitor area in an administration App for displaying and investigating the Event Log using e.g. a Table component and (if necessary) functionality for resolving Event Log entries. This design can be extended as well to provide a short cut for viewing Event Logs last hour/last day and search/filtering features. This area should also have functionality for handling the recipient list if you choose to have a dynamic list of recipients to notify.
The Watchdog Service runs on a periodic schedule (hourly, daily, weekly, whatever), reads all Event Logs created since the last execution, and creates a report. The report is sent by e-mail to a list of recipients. As a final step, it marks the read Event Logs as reported.
For the example found in Showroom (see link in the top area of this article), we’ve constructed the Watchdog as a callable action from an App rather than a Service on a Schedule -to enable a smoother testing experience. The logic from the action could and should be transferred to an action running as a Service on a Schedule.
Aftermath and clean-up
An Event Log system may generate large amounts of data over time. You should take precautions in your data filters when reading and displaying the logs, and also provide search and filtering possibilities.
Default settings may be three views with Event Log entries from last hour, last day and last week, and with the possibility of performing a search on the Event Log data.
You may also instruct the watchdog to perform some sort of cleanup and deletion of old Event Logs that satisfies a given criteria.
Last updated