Connecter les éléments
Comme on l’a vérifié dans le PoC, tous les composants du problème peuvent être connectés de manière native :
- le SIRH-GTA dispose d’un module de synchronisation, pour déclencher
un traitement lors d’une approbation ou une annulation d’absence
(techniquement, un webhook) ;
- l’ERP permet de créer, valider et annuler des absences via son Application Programming Interface, API ;
- Kaizen Solutions dispose de SnapLogic, un outil d’intégration de données et d’applications, et les traitements peuvent être déclenché via un appel à son API.
Ce dernier point est vraiment important : lorsque Kaizen Solutions a sélectionné SnapLogic comme outil Extract, Transform, Load (ETL),
le déclenchement de traitements via API avait été identifié mais pas
comme un critère essentiel. SnapLogic implémente cela de manière native,
ce qui nous a permis d’élargir vraiment le champ des usages, et cette
fonctionnalité nous est aujourd’hui incontournable. SnapLogic permet
donc bien plus que l’acronyme ETL le laissait supposer, et est
réellement une plateforme d’« intégration d’applications ».
Bref, on sait travailler à la demande, on peut partir sur une conception événementielle :
dès qu’une absence est validée ou annulée, le module GTA déclenche un
traitement dans SnapLogic, qui créée ou annule l’absence correspondante
dans l’ERP.
En pratique, le module GTA gère une queue d’événements, la tâche
SnapLogic est une tâche basique, bref la synchronisation prend quelques
minutes, ce qui est normal au vu des ressources mutualisées et du nombre
de composants dans la chaîne.
Donc pas besoin d’attendre la nuit pour qu’une synchronisation de type batch tourne, “années 90-style”, ce qui apporte un vrai confort à l’utilisation.
Traduire les données
Le webhook du SIRH émet donc des changements ; reste à assurer la traduction vers le modèle de données de l’ERP.
En première approche, les structures sont comparables :
- une période d’absence est liée à un motif (Congé Payé, RTT…) ;
- une période d’absence est une période contigüe, avec une granularité à la demi-journée ;
- une période d’absence a un statut de validation, par le manager ou autre,
- les collaborateurs portent un matricule unique.
Quelques surprises cependant :
- Le webhook émet quand une période d’absence est validée ou annulée, mais avec un événement par demi-journée contenue dans la période d’absence ! Ce qui démultiplie le nombre de requêtes, et contraint à l’efficacité.
- Les motifs d’absence sont structurés de manière légèrement
dissimilaire, le SIRH permettant de gérer finement les congés sur base
annuelle (CP, RTT) et l’ERP non.
- Le circuit de validation d’une absence dans l’ERP dépend du profil associé au collaborateur.
- L’ERP ne permet pas de saisir des absences sur des jours non ouvrés,
ce qui pourtant a bien un sens pour le SIRH, par exemple pour les
absences maladie.
Ce qui amène une architecture du projet dans SnapLogic en deux temps :
- Chaque jour, un traitement planifié :
- extrait la liste des collaborateurs, et construit la table de correspondance entre SIRH et ERP,
- extrait la liste des jours considérés comme ouvrés par l’ERP,
- enregistre le tout dans notre base de donnée interne.
- À chaque appel par le webhook du SIRH, un second traitement :
- récupère les correspondances de collaborateur et de motif d’absence via la base de données,
- vérifie si l’absence est sur un jour ouvré ou non,
- émet les requêtes vers l’ERP pour créer/valider, ou annuler,
- enregistre les événements dans notre base de données.
