Synchronisation des absences HTTP (webhook)

Avant de commencer

Cet article concerne la synchronisation dite "HTTP", qui est un webhook permettant d'envoyer les absences de Timmi Absences vers un outil externe. Il peut être utilisé si nous ne proposons pas de connecteur dédié (nous proposons pour l'instant des intégrations avec Google Calendar, Office365/Exchange et ADP GXP).

 

Evénements synchronisés

Vous pouvez choisir les événements qui seront envoyés par le web-service :

  • tous les événements (absences créées en attente de validation, absences validées, absences supprimées)
  • uniquement les événements validés (absences validées, absences supprimées)

 

Etats des demandes

Voici un schéma décrivant les différents états possibles des demandes selon les actions faites dans Timmi Absences.

Figgo_Events_-_SYNC_-_2.png

 

Format du message envoyé

A chaque créationLe message sera envoyé ainsi :

  • Verbe : POST
  • URl : vous devez fournir l'URL à appeler à chaque création ou suppression d'absence
  • Header :
    - Authorization
    - X-Version
    - X-Resource-Type
    - X-Event
  • Body : le payload en json

Header

Le header contient un les champs suivants :

  • Authorization, qui contient la clé d'autorisation que vous fournissez.
    Exemple : Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

  • X-Version : version du format du payload (fourni par Timmi Absences)
  • X-Resource-Type : type d'objet envoyé (leave uniquement dans la version actuelle)
  • X-Event : événement ayant généré l'appel (created, approved, deleted)

 

Format du payload

Les absences sont envoyées par demi journées, appelées leaves. Pour une absence de 2 jours, il y aura donc 4 appels contenant chacun un payload d'une leaves.

Cas particulier pour les absences en heures : un champ est ajouté (voir dans la description plus bas).

Exemple de payload

{
"id": "78287-20180424-PM",
"date": "2018-04-24",
"isAm": false,
"owner": {
"id": 134,
"name": "Luca Pacioli",
"email": "luca.paccioli@lucca.fr",
"employeeNumber": "00001"
},
"leaveAccount": {
"id": 1718,
"name": "Congés payés 2018",
"categoryId": 1,
"categoryName": "Congés payés"
},
"isConfirmed": true,
"confirmationDate": "2018-04-04T22:34:47.797",
"isCancelled": false,
"cancellationDate": ""
}

Description du payload

  • id : identifiant unique de la leave

  • date : date de la leave

  • isAM : demi journée (AM: true, PM: false)

  • leaveAccount : compte d'absence

    • id : identifiant du compte dans Timmi Absences
    • name : nom du compte
    • categoryId : identifiant de la catégorie du compte, dans le cas des comptes millésimés
    • categoryName : nom de la catégorie du compte, dans le cas des comptes millésimés
  • durationInHours : durée en heures, si compte en heures uniquement (ex: "03:45:00")

  • isConfirmed : état de validation de l'absence
  • creationDate : date de création

  • isCancelled : état d'annulation
  • cancellationDate : date d'annulation

Si besoin de récupérer une liste d'items pour réaliser une table de correspondance dans votre plateforme cible, merci de vous référer à notre documentation API dans laquelle vous trouverez les informations disponibles également dans votre interface Timmi Absnences (absences, comptes, catégories de comptes...etc). 

Format du retour

Timmi Absences n'attend pas de retour spécifique à l'envoi du payload lié à un évènement. La réponse n'est pas analysée, seul le message de retour est utilisé pour être affiché dans le détail des évènements sur l'interface de suivi.

 

Interface de suivi

Les événements envoyés peuvent être suivis dans l'interface du web-service de synchronisation dans Timmi Absences.

Pour chaque événement, on peut voir le détail du message envoyé, et en cas d'erreur, rejouer l'événement manuellement, ou le marqué comme traité. Dans ce cas il ne sera plus considéré en erreur.

Les erreurs de synchronisation sont remontées sur le tableau de bord des actions à réaliser de l'administrateur.

Attention : seules les erreurs renvoyées à la réception du payload sont traitées. Si vous effectuez un traitement métier asynchrone, nous ne pouvons pas récupérer les potentielles erreurs que vous rencontrez.

Politique de rejeu

En cas d'échec de l'appel, l'événement est envoyée dans une queue pour rejeu. Il y a 4 queues en cascade, à 5 minutes, 15 minutes, 1h, 24h.

 

 

Contenu de la page

Cet article vous a-t-il été utile ?
Utilisateurs qui ont trouvé cela utile : 1 sur 6