Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Default system configurations

These configurations are managed by the WEDIA engine on its own and cannot be changed.

They make it possible to 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.

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

relating to all events connected/disconnected in the system

sys_objectdata

for all events related to data access

sys_accesslogs

This configuration records all HTTP accesses made on the application.

It records more or less the same information as that stored in the the access logs of the application server.

It does, however, add a number of useful indicators that do not exist in standard access logs that allow you to trace a user’s entire browsing experience during a session via system settings.

In addition to the standard contextual parameters, this configuration uses the following parameters:

http_content_type

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)

http_version

HTTP protocol version (i.e.: http/1.1)

time_started

UNIX timestamp of the start of the query (i.e.: 144844889797127)

time_ended

UNIX timestamp of the end of the query (i.e.: 144844888897131)

auth

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.

In addition to the standard contextual parameters, this configuration saves the following parameters:

actionid

The action performed by the user. This action may include three different values according to the events:

  • loginok when a user successfully logs in

  • connectionbad when trying to connect failed

  • logout when a user logs off

badlogin

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.

Note
 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

objectuid

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 creation of a new instance of the object

  • update in the case of modification of an instance of the object

  • delete in the case of deleting an instance from the object

  • view when the user accesses the fileview action of the object

  • download when the user uploads the native resource of a DAM content object

Note
 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

For each tracked-event of an instance of an object in the system we will therefore be able to find through these parameters

  • what is the instance on which the event occurred,

  • what was the status of the instance at the time the event occurred (if available)

  • what is the suffix and type of the main resource if the instance is a DAM element

  • etc.

In addition, thanks to the contextual parameters we will also know of the following information:

  • which user performed the action,

  • what was this user role,

  • what was his language of contribution,

  • what was the session in which he carried out the action,

  • what his IP address was,

  • from which application page did the event occur,

  • from which page of the application the user came before the action occurred,

  • what browser the user was working with,

  • etc.

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.

Indeed on a front office it may for example be preferable to notify the sys_objectdata configuration that an asset has been downloaded by a user without creating a dedicated configuration for that front office.

In this case, the sys_objectdata configuration can be used to record events related to content objects such as:

  • download

  • viewing

  • copy

  • synchronization

  • users votes (likes, stars, etc …​)

  • etc.

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_objectdata/extra on any child or childmultiple property of the object to have it added to the event.

When available those parameters will be found under the extra property of the event parameters (ie. event.params.extra.propertyuid).

A custom parameter will always be retrieved with event.params.extra.VARIABLE_NAME.

Note
 The uid suffix at the end of the parameter name is automatically added by the application on child and child multiple properties.
  • No labels