API philosophy

In its broad outline, the Mobilic API is a simple activity recording system, in a spirit very close to that of the tachograph.

The API aggregates for each mobile worker the succession of his activities from the information transmitted by the business applications. These applications can in turn request access to all or part of the time series.

Activity

The concept of activity is central. It is characterized by :

  • the identity of the mobile worker performing the activity

  • the start timestamp

  • the end timestamp

  • its nature (travel ; work outside the vehicle)

Thus an activity can be seen as a period of the day of a mobile worker associated to a type of work. The rest times are deduced as the gaps between the different periods. The history of activities for a given worker is sufficient to recalculate the aggregated working (and rest) times at different scales and thus verify compliance with the regulations.

Mission

The mission allows the grouping of activities of the same worker or of different workers. It is a concept that has no impact on the measurement of working time and regulatory control, which are entirely activity-based.

Rather, the concept is geared toward the needs of operators:

  • to calculate the actual total time of a "job site", and thus the actual cost, and contrast it with the invoiced price

  • to account for the notion of team

  • to validate in one block the working time rather than activity by activity

Real time

There are two ways to record activities:

  1. the real-time approach that relies on activity change occurrences. The duration of an activity is only determined a posteriori, at the time of the next activity change.

  2. the deferred recording where the activities are filled in with their duration, like a timetable (e.g.: I worked from 9am to 12pm, from 2pm to 5pm and in between I was on break).

The Mobilic API allows to do both but strongly favors the real time approach. The second approach is mainly thought as a tool for punctual corrections. In the "real time" mode, the API carefully takes into account the time of reception by the server of the events, while allowing the caller to specify the real business time (very useful when the events cannot be submitted right away, for connectivity reasons for example).

This is intended to ensure the following benefits:

  • by recording changes in activity as soon as they occur, the inaccuracy in the measurement of working time is greatly reduced compared to an a posteriori declaration

  • the risk of falsification is also reduced

To understand in more detail how the real-time approach works, see Activity recording.

Attachment of employees

User accounts are linked to the person who holds the account, regardless of his or her company or profession (mobile worker or manager).

Thus, a person who changes company still keeps one and the same account. The membership (variable over time) of a person to a company is represented by an attachment.

An account can have several attachments over time, as the person moves from one company to another. An account can also be attached to several companies simultaneously, to accommodate the frequent case of sister companies that may occasionally pool their workers.

By default the working time recorded by a mobile worker account will be associated with the company to which it is attached at the time of the activity. If there are several simultaneous attachments, the main (unique) attachment will prevail in the absence of further details.

For security reasons the attachment of a person to a company must be approved by both the company and the employee. This is done in the following order:

  1. The company (i.e. a Mobilic user who has the administration rights of this company) makes a request to attach the employee by API, specifying a start date of the attachment (and optionally an end date)

  2. The attachment request is registered but remains inactive until it is approved by the employee

  3. The employee account approves the attachment request by API. The old reattachments are eventually terminated if needed.

Last updated