Default system configurations
These configurations are managed by the WEDIA engine on its own and cannot be changed.
They make it possible to The WEDIA engine ships with default logs that are analyzed by the Analytics system.
These logs record all the system events produced on the application when the user carries out certain actions like for example:
connection to the system,
creations, modifications or deletions of contents in the application,
downloading a DAM asset into a shopping cart,
etc.
They are the source for all Analytics dashboards.
There are several system configurations:
sys_accesslogs
...
related to all HTTP access events
sys_gates
...
for all events related to system performance monitoring
sys_connection
...
related to all events connected/disconnected in the system
sys_objectdata
...
for all events related to data access
| Table of Contents |
|---|
sys_accesslogs
This configuration records all HTTP accesses made on the application.
...
The standard content of the HTTP response (ie:"text/html") http_length
Size of the HTTP response in bytes http_method
HTTP method (i.e.: POST) http_status
HTTP response status (i.e.: 200 | 302 | 500)
...
User login (in the case of basic authentication)
sys_gate
This configuration is used to record events related to monitoring application performance.
It is reserved for internal use within the Wedia engine and will not be detailed in this documentation.
sys_connection
This configuration is used to record events related to connections and disconnections in the system.
...
If the actionid=connexionbad connection fails. Stores the login with which the user tried to identify himself.
sys_objectdata
This configuration records all events related to the application contents (insertion of contents, modification, deletion, views and download, etc …).
It will help to visualize precisely which contents are the most contributed in the application, which are the most seen, which user has interacted with which contents, etc.
...
Those events are automatically handled by the application in objects triggers and in the standard back-office pages (BOV3). Projects developers may need to log extra events in their front-offices or in custom back-office page. This can be done thanks to the LogEvent API (see dedicated section).
In addition to the standard contextual parameters, this configuration uses the following parameters
...
UID of the object on which the event occurred. For example: material_122 (material with ID property equal to 122) objectname
The name of the object on which the event occurs actionid
The ID of the action, this parameter can take one of the following values
insert in the case of
creationof a new instance of the objectupdate in the case of
modificationof an instance of the objectdelete in the case of
deletingan instance from the objectview when the user accesses the
fileviewaction of the objectdownload when the user
uploads the native resourceof a DAM content object
...
More action may be used in your application (see dedicated section)
statusuid
The UID of the status if available damobject_suffix
The suffix of the main resource in the case of a DAM object damobject_type
The main resource type in the case of a DAM object
...
and of course when did this event occurred.
Logging extra events in sys_objectdata configuration
Although sys_objectdata is a system configuration it is possible to programmatically trigger events in this configuration.
...
The production of events is dealt with in the chapter on application configurations.
Logging extra content parameters in sys_objectdata
Since 11.11.0 it is now possible to add custom content parameters to the default sys_objectdata configuration.
Simply add the structure field tag analytics/sys_objectdatasysobjectdata/extra on any child or childmultiple or string property of the object to have it added to the event.
...
A custom parameter will always be retrieved with event.params.extra.VARIABLE_NAME.
...
The uid suffix at the end of the parameter name is automatically added by the application on child and child multiple properties.