Programmer des mises à jour automatiques de données

Un traitement périodique récupère des données à une source, les transforme si nécessaire, puis les publie dans un jeu de données de la plateforme. Répété à intervalle régulier, c'est le moyen de maintenir un jeu de données à jour automatiquement, sans intervention.

Chaque traitement repose sur un plugin, qui détermine la source et le type de transformation : transfert d'un fichier, appel d'une API JSON ou XML, import d'un GTFS, et bien d'autres. Ce cours décrit la mécanique commune à tous les traitements ; les particularités de chaque plugin sont documentées dans les cours dédiés.

Les traitements se gèrent depuis Connecteurs → Traitements périodiques.

La création se fait en deux étapes.

Commencez par choisir le plugin [2]. Les plugins les plus courants sont regroupés sous Essentiels, les autres — souvent des connecteurs vers des bases de référence françaises — sous Autres. Le champ de recherche [1] filtre la liste.

Nommez le traitement [1], puis validez avec Créer [2]. Ce titre identifiera le traitement dans la liste : choisissez-le explicite, vous en aurez plusieurs.

Le titre [1] reste modifiable à tout moment.

L'état [2] — actif ou inactif. Rendre un traitement inactif suspend sa planification sans la supprimer : les règles sont conservées, elles cessent simplement de déclencher des exécutions. C'est le bon geste pour mettre une mise à jour en pause — le temps d'une migration, ou d'une source indisponible — sans avoir à reconstruire son calendrier ensuite.

L'action [3] détermine ce que le traitement fait du résultat. Les choix proposés dépendent du plugin : tous savent créer un jeu de données, mais les modes de mise à jour varient.

• Créer un jeu de données — un nouveau jeu est créé à la première exécution ;
• Mettre à jour un jeu de données — le jeu existant est réalimenté à chaque exécution. Selon le plugin, ce mode peut être précisé : (fichier) remplace intégralement le contenu, (incrémental) n'ajoute ou ne modifie que les lignes concernées et conserve le reste.

Certains plugins n'offrent qu'un seul mode de mise à jour, d'autres les deux. Quelques-uns — comme Export dans un fichier — ne proposent aucune action, parce qu'ils ne produisent pas de jeu de données : reportez-vous au cours du plugin concerné.

Après la première exécution d'un traitement en mode créer, l'action bascule automatiquement en mettre à jour : les exécutions suivantes alimentent le même jeu au lieu d'en créer un nouveau.

Le jeu de données [4] — son titre en mode création, ou le jeu existant à alimenter.

Les paramètres propres au plugin (adresse de la source, authentification, champs à récupérer…) se trouvent dans les onglets voisins et sont décrits dans le cours de chaque plugin.

Sans règle de planification, un traitement ne s'exécute que manuellement. La planification est ce qui le rend périodique.

Quatre rythmes sont disponibles — mensuel, hebdomadaire, journalier, ou toutes les N heures — chacun avec un fuseau horaire, à ne pas négliger si vos données ont un sens horaire.

Un traitement peut porter plusieurs règles, qui s'additionnent. C'est ce qui permet des calendriers que les quatre rythmes ne couvrent pas seuls :

• une fois par mois — une règle mensuelle, le 1er à 6 h 00 ;
• tous les lundis, mercredis et vendredis — trois règles hebdomadaires [1][2][3], une par jour, toutes à 6 h 00 ;
• toutes les heures — une règle toutes les N heures avec un intervalle de 1.

Le bouton [4] ajoute une règle supplémentaire.

L'action Exécuter lance le traitement immédiatement, sans attendre la planification. C'est ce qu'on fait après une première configuration, pour vérifier que tout fonctionne.

Chaque exécution apparaît dans la liste Exécutions, avec sa date, sa durée et son issue. La prochaine exécution planifiée [1] y figure également, au-dessus des exécutions passées [2].

En cliquant sur une exécution, vous accédez à son journal : le détail des étapes, et en cas d'échec le message d'erreur. C'est le premier endroit à regarder quand un jeu de données n'est plus à jour.

Seules les 500 dernières exécutions sont conservées. Au-delà, les plus anciennes sont supprimées. Pour un traitement horaire, cela représente environ trois semaines d'historique : si vous avez besoin d'en garder une trace au-delà, ne comptez pas sur ce journal.

Par défaut, seuls les administrateurs de l'organisation peuvent consulter et exécuter les traitements.

Pour ouvrir ces droits, ajoutez des permissions. Chacune associe un profil [1] à une cible [2] :

• profil lecture — accéder aux informations essentielles du traitement, dont les journaux, mais pas aux informations sensibles ;
• profil exécution — les mêmes accès, plus la possibilité de déclencher le traitement.

La cible est soit un utilisateur désigné par son adresse e-mail, soit une organisation partenaire.

Vous pouvez vous abonner à quatre évènements :

• le traitement s'est terminé sans erreurs ;
• le traitement a échoué ;
• le traitement s'est terminé correctement, mais son journal contient des erreurs ;
• le traitement a été désactivé car il a échoué trop de fois à la suite.

Le troisième cas est le plus insidieux : le traitement a produit un jeu de données, donc rien ne semble cassé, alors qu'une partie des données a pu être perdue.

Le quatrième correspond à la désactivation automatique décrite plus haut — c'est la notification à activer en priorité sur un traitement dont vous dépendez.

Les notifications arrivent via la cloche de la plateforme ou par e-mail.

Si vous avez des remarques sur ce cours, n'hésitez pas à nous les communiquer.