My development Cookbook : Implementing a business events collection on a business platform
Architect by profession, developer by passion I have gathered my ideas, my algos, my thoughts in a cookbook. Intention is to share, and of course the recipes are very humble solutions to address the challenges I had to face. They were valid in their context especially as an answer to the trade-off “Make or Buy”.
Over the years, I have designed numerous platforms for various industries. For sure, whatever the subject is, I am regularly confronted to deliver some generic services. Among them is the business event tracking (a.k.a BET) to address the challenge: “I want to be able to have a business perception of WHO does WHAT , WHEN on my platform and WHY (sometimes)”.
At first glance, several implementations are possible: From relying on logging framework as “Log4XorY” or tools such a G-Analytics… But at the end of the day, I wanted to have a component, delivered as with a very small footprint, a maximal customization, a tight integration with BI solutions, and no charge for usage.
So I rolled up my sleeves and designed my component.
The package called “Activity Tracker” consists in 2 components to implement the traceability and the audit functions.
Collecting the events
Having seen numerous implementations of such system, I knew that the major risk relied in transforming this, into a black hole ingesting all the events (technical, business…anything) under a neat format and I have never been convinced of such an approach.
So I define my objective: “As a developer, I want to collect the business relevant activities occurring on my platform in order to propose dashboards directly understandable by business stakeholders”.
Defining a business event.
This is the cornerstone of the whole system. Being able to define a versatile description of a business event is the key.
A business event shall be composed of several parts:
- Identifier : the mean to uniquely identified any event occuring on the platform
- Header: The elements to put the business events into context. This is a list of mandatory attributes.
- Details: This is the flexible repository of the business and technical elements so that the BET can cope with any types of event.
The Identifier
It is a unique identifier to clearly define the business event. Simply, It is the result of an action to an object. Therefore, the coding syntax retained for a business event was
OBJECT_ACTION_RESULT
I must admit there is a bit of anthropomorphism is this description. I wanted to be able to
- to sort the events by object easily,
- To regroup all the events occurring to different objects,
- or to rapidly filter errors.
Specially to ease the readability I have defined delimiter (_) that are consequently forbidden as a character within the elements.
All I had to do is to define the taxonomies for the different dimensions (Below are examples that of course need to be adapted to the situation):
1 — OBJECT: The different business objects such as
A business object
- ACCOUNT
- BUSINESS-OBJECT#1
- BUSINESS-OBJECT#2
- …
Or the zones from the site (considered as a ‘business universe’)
- AREA-ADMINISTRATION
- AREA-ANALYTICS
- AREA-ONLINEHELP
- AREA-BUSINESSMAP
- AREA-SITEXYZ(EXAMPLE)
- …
2 — ACTION: Then the list of applicable verbs
- LOGIN
- ACCESS
- CREATE
- FIND
- LOGOUT
- EXPORT
- SEARCH
- …
3 — RESULT: The list of expected results
- SUCCESS
- ERROR-ALREADYEXIST
- ERROR-INVALIDFORMAT
- ERROR-NOOBJECTFOUND
- ERROR
- ERROR-TOOMANYENTRIES
- ERROR-NOTAVAILABLE
- ERROR-UNAUTHORIZED
- …
Remark : to finely quality a result and especially the error, a secondary delimiter (different from the former one) is established (-)
Then creating a business event is only a composition of the former elements.
For example :
- Successful login of a person on the platform: ACCOUNT_LOGIN_SUCCESS
- Access to the administration zone is refused : AREA-ADMINISTRATION_ACCESS_ERROR-UNAUTHORIZED
The contextualisation
The business event is shall now be described with a set of mandatory attributes:
- Timestamp (preferably expressed as UTC Z) of the occurence of the event,
- An identifier of the actor (being a user, an app, or a machine) A special care to confidentiality (GDPR) shall be done to avoid collecting sensitive personal information.
- A label to describe the event. Here there is an alternative : A free label can be inserted, but I strongly recommend to request an external list of localised labels based on the value inserted here (Remark : This adds one level of liberty compared to generate this list based on the event identifier)
As mandatory, this will allow to have default analytics available for the end-user even for the new coming applications.
Optional: An optional instance identifier can be inserted here. It shall contain a identifier that allow to consolidate a list of business event. As an example, a session id associated to a user can be inserted. That way, by sorting with this instance id and the event timestamp, we can reconstruct the workflow done on the platform (even among different systems connected to the BET).
The details
Here the principle is to add different flexible structures in order to store all the details. Detail are split among:
- Business details: Elements that are business related and susceptible to be interesting in term of analytic ( user profile, Business data — considering the confidentiality)
- Technical details: Elements that are technical such as the browser, the station configuration…
This flexible zone will allow to generate refined analytics per module depending on the element sent by the data producer.
Displaying the events
Several options are available. The most classic would be to propose a matrix of the events. But with a very minor adaptation, nice graphics can be easily achieved
Example of the statistics made realying only on the Identifier and the Header zones
Example of the statistics made realying only on the Detail zone/Technical
