The goal of logging is to fill the logging table with useful data. Here's a quick summary of what's written into the table. The full details can be found here. Note that the goal was to get data into one flat table without the need to later join the table with any other olat table. The idea was to get a snapshot of the information 'at the time the activity happens' - since course or user information might later change (e.g. a user might change university or a course' title might change etc). That's why the logging table is rather wide.

There are a few things to remember when issuing a user activity log:

Here is an example usage of how the logging is initialized with a course as context information.

// from RunMainController
public RunMainController(final UserRequest ureq, final WindowControl wControl, final ICourse course, final String initialViewIdentifier,
		final boolean offerBookmark, final boolean showCourseConfigLink) {
	super(ureq, wControl);		
			
	... other stuff ...

	// initialize the logging with the course
	addLoggingResourceable(LoggingResourceable.wrap(course));
	
	... other stuff

	// issue a logging action
	ThreadLocalUserActivityLogger.log(CourseLoggingAction.COURSE_ENTERING, getClass());
	
}
					

Once the above is done, then during an event further logging actions can be issued as follows:

// from EditorMainController					
public void event(UserRequest ureq, Controller source, Event event) {
	
	... other stuff ...
	
		ThreadLocalUserActivityLogger.log(CourseLoggingAction.COURSE_EDITOR_PUBLISHED, getClass());
	
	... other stuff ...
}
					

Anything that is passed to the logging and stored in the logging table is treated via the interface ILoggingResourceable. The ILoggingResourceable contains the following properties which are stored to the logging table:

As mentioned above, you are encouraged to pass ILoggingResourceables to the IUserActivityLogger in a Controller's constructor.

There are factory methods with which to construct ILoggingResourcesables. Here are some examples:

org.olat.util.logging.activity.LoggingResourceable.wrap(ICourse);
org.olat.util.logging.activity.LoggingResourceable.wrap(CourseNode);
org.olat.util.logging.activity.LoggingResourceable.wrap(BGArea);
					

Once created, the ILoggingResourceable can be passed to the IUserActivityLogger as follows:

// within a Controller:

addLoggingResourceable(LoggingResourceable.wrap(someResourceable));


// before creating a Controller with the intension to pass it to the Controller:

ThreadLocalUserActivityLogger.addLoggingResourceable(LoggingResourceable.wrap(anotherResourceable));
					

The ILoggingAction describes the actionverb and actionobject as well as what the expected ILoggingResourceables to be stored along with such that logging action are. The idea behind this class is to have a well defined place (subclasses of ILoggingAction) where everything about the existing logging actions is defined. This can be useful when determining what statistics can be done, which parts of OLAT are logged and where more logging might be required. In short, this is a in-code documentation of the logging actions.

Therefore whenever you want to log something via the activity logger, you need to have an ILoggingAction (along with a set of ILoggingResourceables which were collected by the Controller's IUserActivityLogger - or when in a Manager in the ThreadLocalUserActivityLogger). The main log method therefor looks as follows - note that the main info you need to pass to the log() method is the ILoggingAction:

// from IUserActivityLogger
public void log(ILoggingAction loggingAction, Class callingClass, ILoggingResourceable... loggingResourceInfosOrNull);
					

Besides being a container for actionverb and actionobject, the ILoggingAction contains a paranoia safety check for ILoggingResourceables: The ILoggingAction must be given a ResourceableTypeList. The latter is the specification of which ILoggingResourceables are mandatory, optional or not allowed when logging this particular ILoggingAction. This information is then used at runtime to check if the provided set of ILoggingResourceables is correct and issue WARNs and ERRORs if that's not the case. This should allow to - over time - find both errors in this ILoggingAction definition but also prevent you from a situation where you 'thought that the ICourse' was available in the Controller XY - but actually at runtime it is not.

The GUI is integrated into OLAT via the ExtManager and a subclass of GenericActionExtension. Adding a new kind of statistic is done by adding a section in the olat_extensions.xml, providing a StatisticActionExtension with a Controller classname and a IStatisticManager implementation (see existing olat_extensions.xml for examples).

The Controller normally doesn't have to be extended and one can usually use the existing - generic - StatisticDisplayController. The StatisticDisplayController has a IStatisticManager which it uses for customizing the ColumnDescriptors it uses to display the table as well as for generating the actual statistics. The result of the statistics is encapsulated in its own object called StatisticResult.

Each statistic needs an IStatisticUpdater which is capable of updating the statistics given additional logging actions in the o_loggingtable. The way this update is done is entirely up to the IStatisticUpdater.

The configuration of the IStatisticUpdaters is done in the following file:

olat3/webapp/WEB-INF/src/serviceconfig/org/olat/course/statistic/_spring/olatdefaultconfig.xml
					

The suggested best practice is to write an updater which is capable of adding new statistic information to an existing table - aka incremental update.

Incremental updates can be further optimized by adding an IStatisticUpdaters (at the first position in the config) which does a

SELECT * FROM o_loggingtable WHERE ACTIONVERB='launch' AND ACTIONOBJECT='node' AND creationdate>...;					
					

The result of this select can be stored in its own temporary delta table which all other IStatisticUpdaters then read their data from - rather than having each of a number of IStatisticUpdaters doing a SELECT in the 'big' o_loggingtable.