Passer au contenu principal

Synchroniser comme vous le voulez : Penser à travers le système de protocoles de « Synchronisation »

La « synchronisation » permet à deux systèmes de se retrouver dans un état d'harmonie. Cela peut signifier de tenir une liste de patients à jour, bien que des modifications puissent être apportées dans l'un ou l'autre système. Cela peut signifier copier des transactions d'un système à un autre sur une base de nocturne. Cela peut signifier beaucoup de choses, mais le concept clé est que lorsque vous synchronisez les systèmes, vous leur demandez de travailler ensemble en même temps en respectant l’indépendance des deux systèmes logiciels.

Dans ce message, nous discuterons de deux protocoles de synchronisation différents à considérer lors de la conception de votre intégration de données. Cela inclus :

  1. Synchronisations en temps réel ou basées sur des événements
  2. Synchronisations planifiées

Pour un projet récent au au Cambodge, OpenFn est utilisé par les travailleurs sociaux pour automatiser les renvois de cas entre les systèmes de logiciels Primero et OSCaR. Dans la phase de conception, nous avons évalué ces deux options de synchronisation. Ci-dessous, nous allons expliquer ce que chacun est, les différences et quelle option nous avons choisi à la fin.

Synchronisations en temps réel/événement

La première option envisagée pour cette intégration était la synchronisation en temps réel/événement. Ce type de synchronisation est déclenché chaque fois qu'un événement spécifique a lieu dans un système. Avec cette approche, chaque fois qu'un cas est référencé en Primero (via l'interface de l'utilisateur, c'est à dire lorsqu'un vrai travailleur de cas clique sur le bouton « référer ») OpenFn reçoit un petit chargement avec les données de cas et la transmet à OSCaR et vice versa.

Synchronisation en temps réel

En raison de leur nature instantanée, les synchronisations en temps réel/événement sont idéales pour les intégrations qui impliquent des paiements mobiles ou des SMS aux destinataires. Vraiment, tout ce qui doit être fait « maintenant » ! En outre, en fonction de vos volumes de données les synchronisations en temps réel peuvent vous faire économiser de l'argent parce que vous utilisez uniquement des ressources lorsque des événements spécifiques ont lieu. Par exemple, dans l'exemple ci-dessus, une exécution est déclenchée par une recommandation, donc s'il n'y a que 10 références/mois de cas, vous ne traiterez que 10 exécutions par mois.

Ce type de synchronisation est génial car il est instantané, généralement simple à configurer, ne nécessite pas de « gestion de l'état » sur OpenFn, et permet le retraitement des événements individuels. Il y a cependant des inconvénients.

Par exemple, que se passe-t-il si l'application qui envoie des notifications à OpenFn ne parvient pas à envoyer ? Que se passe-t-il si AWS ou GCP ne marche plus, prenant la moitié de l'internet avec ? Si Primero « pense » qu'il a envoyé la référence, OpenFn ne la reçoit jamais, que le cas pourrait ne pas être référencé à Oscar !

Planifier une synchronisation

Synchronisation planifiée_dépendante

La deuxième option considérée, une synchronisation bidirectionnelle dépendante de la planification , résout le problème discuté ci-dessus. Sur une base planifiée (toutes les 5 minutes, par exemple) OpenFn vérifie avec Primero et Oscar pour voir si les recommandations de cas doivent être transmises entre les deux systèmes, puis renvoie le cas si nécessaire. Dans le cas improbable où l'un des systèmes logiciels impliqués planterait, la stabilité fournie par la synchronisation bidirectionnelle signifie que toutes les données sont préservées et éventuellement le rendent à sa destination en toute sécurité.

Le principal inconvénient ici est la complexité. Nous avons dû utiliser 4 jobs au lieu de 2, et le job qui est responsable de « tirer » les données qui ont été mises à jour depuis le moment de la dernière synchronisation réussie doit garder « l'état » — ou une sorte de mémoire fonctionnelle de ce qu'il fait dans le passé. En tirant des cas modifiés de Primero, OpenFn ne tire maintenant que les cas modifiés sur ou après AAAA-MM-JJ HH:MM:SSAAAA-MM-JJ HH:SS est l'heure du dernier succès, synchronisation aller-retour. OpenFn a des fonctionnalités intégrées pour gérer exactement cette exigence, mais tous les systèmes ETL ne le font pas et c’est une implication de conception qui doit être prise en considération.

En fin de compte, pour le projet au Cambodge, nous avons décidé que cette option de synchronisation est le bon choix car l'intégrité des données est plus importante que la vitesse de ce flux de données. C'est un point crucial à comprendre : les organisations opérant au Cambodge ont décidé que pour ce cas d'utilisation particulier, être en mesure de garantir éventuellement la synchronisation était plus importante que d'avoir une synchronisation en temps réel.

Les deux options de synchronisation ont leurs Avantages et Inconvénients

Les deux options ont définitivement leur cas d'utilisation et la polyvalence de la plateforme OpenFn permet à votre équipe de décider quel type de synchronisation convient à votre projet.

Comme toujours, nous sommes là pour vous aider à répondre à toutes les questions que vous avez en ce qui concerne l'option de synchronisation qui a le plus de sens pour votre projet.