Configuration details
These configurations will help developers to build custom dashboards for their projects.
...
Custom loggers are defined with name (unique on the system) and parameters.
Configuration name
The configuration name is used to differentiate the different configurations and isolate the various analysable events.
...
the name must be in lower case,
the length of the name must not exceed 30 characters,
the name can only contain letters (a-z) and numbers (0-9) or the following spacers
-or_.the name cannot starts or end with a spacer.
| Info |
|---|
TipA configuration will store all the events related to it, it can be "seen" as a table in a database. |
Events parameters
These parameters are defined by the developer at development time.
...
Parameters are key/values entries represented in a java.util.Map<String,Object>
Parameter names
As with configuration names, parameter names must respect the following parameters the following constraints :
...
objectname
objectid
actionname
Parameter values
Parameters values can use the following java types : String, Long, Boolean , List<String>
It is very important to always store the value of a parameter with the same type, otherwise it will not be possible to carry out analyses reliable statistics with these parameters.
Application parameters
Application parameters are all stored under the event.params key and can be accessed with their keynames event.params.VARIABLE_NAME, e.g. event.params.actionname for the application parameter actionname.
...
| Code Block |
|---|
connexion_search_option.putAggregation( "cardinality", Analytics.CardinalityAggregation("event.params.actionname") ); |
Event generation
The addition of new events in the system is done via the unique entry point located in Analytics APIs in the wsnoheto.log.analytics.EventsLogger class.
...
Allows to create a new event in the sys_objectdata configuration in order to feed the system configuration with events taking place outside the standard scope of application (standard back-office).
For example, on a customised front-office we may wish to notify the sys_objectdata configuration when a user consults the asset detail.
| Info |
|---|
TipSee the javadoc of the class wsnoheto.log.analytics.EventsLogger for more information. |
Event production via EventsLogger.logEvent
This is the most common way to record application events in the system.
...
| Code Block |
|---|
Map<String, Object> myParameters = new HashMap<String, Object>(); myParameters.put( "actionname" , "action1" ); myParameters.put( "param2" , "value2" ); myParameters.put( "param3" , false ); myParameters.put( "param4" , 15 ); EventsLogger.logEvent(CTSurfer.from(request), "myConfiguration", myParameters ); |
Note
The logEvent method call is enough to create the event in the system and its application configuration (myConfiguration) if it doesn’t already exist.
Event creation via EventsLogger.logSysObjectDataEvent
This method allows you to create a new event in the configuration system sys_objectdata.
...
| Code Block |
|---|
// activeObject being the current object that the user consults. EventsLogger.logSysObjectDataEvent(CTSurfer.from(request), "view", activeObject); |
Good practices
Log an empty or zero value
When you want to save an empty or zero value in one of the parameters application it is recommended to save the character - instead of not logging anything. This makes it possible, among other things, to easily create filters in the dashboards later and makes it easy to write queries.
Logging a child property value
When you want to record the value of a child property type in an application parameter it is recommended to log the value of the instance’s UID instead of logging the instance identifier or the value of one of the properties of the related instance.
...