HTTP-Synchronisierung der Abwesenheiten (Webhook)

Bevor Sie beginnen

In diesem Artikel geht es um die sogenannte „HTTP-Synchronisierung“, ein Webhook, mit dem die Abwesenheiten von Timmi Abwesenheiten aus an ein externes Werkzeug übertragen werden können. Dies kann zum Einsatz kommen, wenn wir keinen dedizierten Konnektor anbieten (derzeit bieten wir Integrationen mit Google Calendar, Office365/Exchange und ADP GXP).

 

Synchronisierte Ereignisse

Sie können die Ereignisse auswählen, die vom Webdienst gesendet werden:

  • alle Ereignisse (erstellte Abwesenheiten, die zur Validierung anstehen, validierte Abwesenheiten, gelöschte Abwesenheiten)
  • nur validierte Ereignisse (validierte Abwesenheiten, gelöschte Abwesenheiten)

 

Status der Anträge

Hier ist ein Schema, das die verschiedenen möglichen Zustände der Anträge je nach den in Timmi Abwesenheiten vorgenommenen Aktionen beschreibt.

Figgo_Events_-_SYNC_-_2.png

 

Format der versandten Nachricht

Bei jeder Erstellung wird die Nachricht so versandt:

  • Verbe: POST
  • URL :Sie müssen die URL angeben, die jedes Mal aufgerufen werden soll, wenn eine Abwesenheit erstellt oder gelöscht wird
  • Header :
    - Authorization
    - X-Version
    - X-Resource-Type
    - X-Event
  • Body : Payload in json

Header

Der Header enthält eines der folgenden Felder:

  • Autorisierung, die den von Ihnen bereitgestellten Autorisierungsschlüssel enthält.
    Beispiel: Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

  • X-Version: Version des Payload-Formats (bereitgestellt von Timmi Abwesenheiten)
  • X-Resource-Type: Typ des gesendeten Objekts (leave nur in der aktuellen Version)
  • X-Event: Ereignis, das den Anruf generiert hat (created, approved, deleted)

 

Format der Payload

Abwesenheiten werden in halben Tagen, sogenannten leaves verschickt. Bei einer Abwesenheit von 2 Tagen erfolgen also 4 Anrufe, die jeweils den Payload eines leaves enthalten.

Sonderfall für Abwesenheiten in Stunden: Ein Feld wird hinzugefügt (siehe nachfolgende Beschreibung).

Beispiel für eine 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": ""
}

Beschreibung der Payload

  • id: eindeutiger Benutzername der leave

  • date: Datum der leave

  • isAM: halber Tag (AM: true, PM: false)

  • leaveAccount: Abwesenheitskonto

    • id: Kennung des Kontos in Timmi Abwesenheiten
    • name: Kontoname
    • categoryId: Kennung der Kategorie des Kontos, im Falle von Jahrgangskonten
    • categoryName: Name der Kategorie des Kontos, im Falle von Jahrgangskonten
  • durationInHours: Dauer in Stunden, wenn nur in Stunden gezählt wird (Beispiel: "03:45:00")

  • isConfirmed: Validierungsstatus der Abwesenheit
  • creationDate: Erstellungsdatum

  • isCancelled: Stornostatus
  • cancellationDate: Stornodatum

Wenn Sie eine Liste von Elementen abrufen müssen, um eine Korrespondenztabelle auf Ihrer Zielplattform zu erstellen, lesen Sie bitte unsere API-Dokumentation, in der Sie die Informationen finden, die auch in Ihrer Timmi Abwesenheit-Schnittstelle verfügbar sind (Abwesenheiten, Konten, Kontokategorien usw.).

Rückgabeformat

Timmi Abwesenheiten erwartet beim Versenden der mit einem Ereignis verknüpften Payload kein spezifisches Feedback,. Die Antwort wird nicht analysiert, sondern nur die Antwortnachricht wird zur Anzeige in den Ereignisdetails auf der Verfolgungs-Schnittstelle verwendet.

 

Verfolgungs-Schnittstelle

Gesendete Ereignisse können in der Schnittstelle des Synchronisierung-Webdienstes in Timmi Abwesenheiten nachverfolgt werden.

Für jedes Ereignis wird die detaillierte gesandte Nachricht angezeigt. Bei Fehlern wird das Ereignis manuell analysiert oder als bearbeitet markiert. In diesem Fall wird es nicht mehr als Fehler betrachtet.

Fehler bei der Synchronisierung werden in das „Action to do“-Dashboard des/der Administrators:in eskaliert.

Achtung: Nur Fehler, die beim Empfang der Payload zurückgegeben werden, werden verarbeitet. Wenn Sie eine asynchrone Verarbeitung durchführen, können wir die potenziellen Fehler, die auftreten können, nicht abrufen.

Richtlinien der Wiederholung

Wenn der Abruf fehlschlägt, wird das Ereignis an eine Warteschlange zur Wiederholung gesandt. Es gibt vier aufeinanderfolgende Warteschlangen, die 5 Minuten, 15 Minuten, 1 Stunde und 24 Stunden auseinander liegen.

 

 

Contenu de la page

War dieser Beitrag hilfreich?
1 von 6 fanden dies hilfreich