uPortal includes a database-persistent event logger capable of tracking a large amount of information about portal usage. Interesting loggable activities include user sessions, portlet interactions, and portlet rendering times. Adopters may also add new loggable events.
Database Event Logging Concerns
When logging portal events to a database serious considerations need to be made about the amount of available space and the performance of the database. A uPortal database is mostly read oriented with only a few writes when a new user logs in or a user changes their layout. The event log database will be primarily writes and can write a significant amount of data.
Event Logging Configuration
The default uPortal configuration has the database event logger disabled. To enable it two files need to be edited.
To configure which events are logged refer to the JavaDocs for the AbstractLimitedSupportEventHandler. The QueueingEventHandler which sits in front of the persisting bean extends AbstractLimitedSupportEventHandler to event filtering can be configured there.
The QueueingEventHandler is used to batch the persist action for better performance and to reduce database IO. The default configuration is to only store events when there are at least 50 in the queue or every 60 seconds, whichever comes first. This configuration should not need to be changed.
The following tables are used to log portal event information.
Each PortalEvent has a corresponding event type. This is tied to a unique key specified by each implementation of PortalEvent. These keys are logged to STATS_EVENT_TYPE which is referenced by the STATS_EVENT table.
PortalEvents always include an IPerson object representing the portal user that triggered the event. The model this event logger uses is that the first time a PortalEvent is logged for a user a statistics session is created which logs the user id and the groups that user is in to the STATS_SESSION and STATS_SESSION_GROUPS tables. The ID of the stats session is then included with each entry in the STATS_EVENT table.
For each event there will be an entry added to the STATS_EVENT table. Along with possibly entries in STATS_FOLDER, STATS_CHANNEL, and STATS_RENDER_TIME based on what the PortalEvent is for.
Adding Events / Modifying Mappings
The Hibernate entity mappings for the logged PortalEvents is done in the file uportal-impl/src/main/resources/properties/db/stats/portalEvents.hbm.xml. If you add a new PortalEvent implementation that should be logged to the database it needs to be mapped correctly in this file. Unmapped PortalEvents are ignored by the database logging code.
The Hibernate entity mappings and PortalEvent classes are not designed to be read from the database using Hibernate, only to be a logging facility. Any reporting tools should just use straight SQL as doing large reporting tasks via ORM is not easy and the PortalEvent object model is not designed for such use.