Deux systèmes qui doivent dire la même chose : synchroniser Business Central avec Azure Functions

Dans un billet précédent, j'ai présenté un planificateur visuel intégré à Business Central : on y déplace les rendez-vous à la souris. Celui-ci explique ce qu'il y a derrière : comment un rendez-vous déplacé dans le planificateur se retrouve dans Business Central, et comment les deux restent d'accord.

C'est un problème que bien des PME connaissent. Deux logiciels contiennent la même information, et quelqu'un passe son temps à la recopier de l'un à l'autre. Ou personne ne le fait, et les deux ne disent plus la même chose.

Le rendez-vous et la facture, liés dès le départ

Dans Business Central, chaque rendez-vous était rattaché à une ligne de commande de vente, avec une ressource. C'est un lien naturel : le travail qu'on planifie est celui qu'on va facturer. Le rendez-vous et la ligne facturable restent donc ensemble, du calendrier jusqu'à la facture.

Quand quelqu'un déplaçait un rendez-vous, ce qui devait changer dans Business Central était simple : l'heure de début et l'heure de fin.

Un intermédiaire entre les deux

Le planificateur aurait pu parler directement à Business Central. J'ai plutôt placé un intermédiaire entre les deux : des Azure Functions, de petits programmes hébergés chez Microsoft qui ne roulent que lorsqu'on a besoin d'eux, et qu'on paie à l'usage.

Cet intermédiaire s'occupe de tout ce qui touche à Business Central : s'identifier, réessayer quand la connexion échoue, garder une trace de ce qui s'est passé, et traduire ce que le planificateur connaît en ce que Business Central attend. Dans ce projet, il servait aussi à synchroniser l'application mobile que les vétérinaires utilisaient sur la route.

Dans les deux sens

La circulation se fait dans les deux directions :

• Du planificateur vers Business Central. On déplace un rendez-vous, et l'heure est mise à jour dans Business Central.
• De Business Central vers le planificateur. Quand quelqu'un modifie une commande dans Business Central, le planificateur en est averti.

Personne ne ressaisit rien, et aucun des deux systèmes n'est « le bon » pendant que l'autre est en retard.

Tout de suite, ou dans cinq minutes

Tout n'a pas besoin de se faire à la seconde. La règle que j'applique :

• Quand une personne attend le résultat, ça se fait tout de suite. Elle déplace un rendez-vous, elle voit le changement.
• Quand personne n'attend, une tâche planifiée s'en occupe. Ici, toutes les cinq minutes, elle comparait les deux côtés et corrigeait les écarts.

C'est ce qui rend le système à la fois rapide et solide : l'utilisateur n'attend pas, et si un changement s'est perdu en chemin, le prochain passage le rattrape.

Est-ce que c'est rapide ?

Oui. Un rendez-vous déplacé faisait l'aller-retour jusqu'à Business Central sans que l'utilisateur ait à attendre.

Ce qu'il faut prévoir

Des conseils généraux, pas une liste de problèmes rencontrés :

• Deux personnes, le même rendez-vous. Si deux personnes peuvent modifier le même rendez-vous en même temps, il faut décider qui l'emporte, et avertir l'autre.
• Les accès. Les deux systèmes se parlent avec un compte de service, et son mot de passe est gardé dans un coffre, jamais dans le code.
• Les commandes déjà libérées. Peut-on encore déplacer un rendez-vous une fois la commande libérée ? C'est une décision d'affaires, à prendre avant de programmer.
• Les doublons. Le même changement peut arriver deux fois. Il faut que le système le supporte sans rien briser.
• Les traces. Quand une synchronisation se passe mal, l'intermédiaire est le seul à avoir vu les deux côtés. C'est là qu'on garde le journal de ce qui s'est passé.

Et chez vous ?

Vous avez deux systèmes qui devraient dire la même chose, et quelqu'un qui recopie de l'un à l'autre ? C'est le genre de problème qui se règle une fois, pour de bon.

Les développeurs trouveront le code (C# et AL) dans la version anglaise.

Parlons-en. La première consultation est gratuite et sans engagement.