This document describes the
Tracking Framework feature of the Enfinity platform.
The work of web analytics engines like WebTrends, Omniture, Google Analytics can be divided into three major parts:
It is nearly the same for recommendation engines like Prudsys, Avail, which mostly do the same three things:
Tracking Framework defines events that can be triggered, provides components to pipeline developers, and offers interfaces and managers for web analytics engines or recommendation engines respectively.
The pipeline developer adds
Tracking Framework specific pipelets to pipelines, so that events are triggered. An event is an object that is passed to the tracking manager (
TrackingMgr) by the pipelet. The
TrackingMgr is the bridge between the events and the registered handlers.
The picture above shows how the parts work together. The Fire...Event pipelets (these are
Tracking Framework specific pipelets, e.g.
FireUerLoginEvent), build up the event objects based on its input parameters and call the
TrackingMgr with the event.
TrackingMgr looks into its dictionary to see which
TrackingEventHandler s are registered for the certain event and calls them one after another. With the help of the Component FW the event handler will be registered on the corresponding tracking service definition. The service definitions are registered on the service definition registry (See Service Definition Registryfor details).
Events can be basically any
Object, though it should be considered as a non-persistent POJO. The framework is supertyping-aware. That means, if a sub-type event occurs, but a handler is registered for super-type events, it is still triggered for that event.
The image above shows how the call structure is built up. The core functionality is enclosed in
Basically, we consider there is an event called B which is a sub-type of A. At the
TrackingEventHandler s are registered: Handler X, Handler Y, and Handler Z.
Now we consider there is a corresponding pipelet called FireBEvent. What happens if it calls the
TrackingMgr with a B event?
TrackingMgr finds Handler Z registered for B events, so it calls Handler Z with B.
TrackingMgr finds Handler Y registered for A events, so it calls Handler Y with B. Handler Y accepts B objects even if it only "knows" A objects, since B are A objects.
TrackingMgr finds Handler X registered for any event, so it calls Handler X with B. It also finds Handler Y registered for any event, but please note: This handler has already been called with A, so it will not be called again with the B object.
It is common usage to define events in XSD. This is because it
The following table displays all available events.
Is subtype of
The root event for any other events
The root event for all viewing events; Note: This event exists as a concrete event object itself and is not just an abstract superclass
The root event for all product action events
The root event for all user action events
An event for viewing pages
An event for viewing the basket
An event for viewing products
An event for viewing categories
An event for adding a product to the cart
An event for removing a product from the cart
An event for user is now logged in
An event for user is now logged out
An event for viewing order information
This table describes all data objects for implemented tracking events.
Is subtype of
A container object for basket-related information
A container object for category-related information
A container object for money-related information
A container object for order-related information
A container object for page-related information
A container object for product-related information
A container object for product-item-related information
A container object for search-related information
A container object for search result item related information
A container object for search-result-item-related information, e.g. a feedback form to let customers comment upon the search result. There is no such functionality yet in the demo store.
A container object for current session-related information
A container object for current session-related information
All Events inherit from other Tracking Events. It is possible to listen to the corresponding events or to a root event, e.g., listen to the UserLoginEvent and UserLogoutEvent Events or to the root event UserActionEvent. New Events should inherit from an applicable Business Tracking Event. So think about the correct inheritance and do not simply use the TrackingEvent.
Any event defines its own set of data that it needs for processing. For these purposes, so-called Tracking Data Objects can be used. These objects should be created if they are used multiple times (for a number of events) or if they should represent a business object relation. As they are not directly connected with Enfinity's business objects, it is suggested to implement JAXB objects. This requires some mappers that map Enfinity's business objects to those JAXB objects. These mappers are called inside the Concept - Business Tracking#Fire..Eventpipelets.
TrackingEventHandler expects that the Events and their data are only data containers. This means that they do not have methods which determine, calculate, create, or remove something. It is suggested to use JAXB to create new Events and new Event Data Objects.
The TrackingService implementing
ServiceDefinition is a stateless service object. It is created when loading the cartridge from the Component FW and is registered on the managed service framework.
It also manages the TrackingEventHandler.
TrackingEventHandler is a stateless component that receives an event and does "something" with it. It may call any remote tracking services or perform some local tracking tasks - whatever is needed.
The "do something" functionality is encapsulated in the handleEvent method. Since a "certain something" cannot not be more precisely described, both input and output parameters are generic (The event and tracking data container are just of the type
There are 2 more methods defined in the
TrackingEventHandler and the
TrackingService must be imagined as a stateless object. However, it should be possible to use some data from previous calls of that handler or service to enable that the pipeline is a holder of an object that is used as a tracking data container. It has no defined interface because it is completely unclear what kind of attributes and methods a tracking data container may own. So it is defined as being an
Object. Each pipelet accepts a tracking data container as an input parameter and serves a tracking data container as an output parameter.
null. The pipeline will never do anything with it, it just reads and writes it to the pipeline dictionary. A handler or service implementation may instantiate an object as needed and return it as a tracking data container.
The Fire..Event pipelets are the bridge between the tracking framework and pipeline development. Placing a Fire..Event pipelet anywhere in a pipeline means to let a certain event occur at runtime.
The tasks of Fire..Event Pipelet are
Since the creation of the event object from the input values is the most complex from the tasks above, it is sourced out to mappers. By now, those mappers are hard-wired. It is important to prove that the event can be built up by the mandatory input parameters, but the mapper must not fail if a value that is not mandatory is missing.
The components described here are wired with the help of the Component FW. Adding another
TrackingEventHandler means to register it on the corresponding tracking
ServiceDefinition is registered on the service definition registry (see Service Definition Registryfor details).
Usually an exception in a
TrackingService or in a
TrackingEventHandler should not interrupt the process flow. On the other hand, it might be necessary during development or qa tests to find exceptions very early. This is why it is configurable how the system acts on an exception: it can just log the error and return and continue as if nothing happened, and it can throw the exception so the user will get an exception page displayed.
The difference between Default configuration and Fallback is: The Default configuration is the configuration to be found in the file when setting up the system. The Fallback is used if no configuration for that key is to be found at all or if no known value can be found.