Brevet FR3036512A1 — publié le 20161125

La présente invention concerne une méthode pour échanger des données depuis une application hébergée sur une plate-forme mobile (désignée par le terme application cliente) d'une manière pseudo-synchrone avec un hôte distant (désigné par le terme application distante). Actuellement, la méthode la plus commune d'échange de données, consiste à communiquer les informations nécessaires, ou crées par l'application cliente, via des API REST vers un serveur. Cette méthode nécessite que le système hôte de l'application cliente soit constamment connecté à internet pour permettre l'échange d'information et donc l'utilisation de l'application cliente, et la même information peut transiter plusieurs fois entre les systèmes clients et distants. De part l'observation que la plate-forme mobile comporte de nombreuses limitations en 10 terme de ressources allouées pour une application cliente, la méthode décrite ci-après vise à minimiser l'impact de l'échange de l'information sur les ressources disponibles dans la plate-forme mobile. La méthode introduite par cette invention se divise en 3 processus distincts et indépendants qui peuvent communiquer avec une ou plusieurs application(s) distante(s) et une ou plusieurs base(s) 15 de données interne(s) à la plate-forme mobile pour la persistance de l'information. Ces processus se répètent au cours du cycle de vie de l'application (exemple : toutes les X secondes), et le temps d'attente jusqu'à la prochaine itération est impacté par la quantité d'information traitée à pendant l'itération courante. Ce procédé incrémenta) intelligent permet ainsi une économie conséquente des ressources, notamment à cause du coût en performance et batterie des communications inter- 20 systèmes. La description des processus suivante s'appuie sur le schéma FIG. 1 annexé, qui représente la structure des systèmes pour laquelle cette méthodologie est prévue ainsi que ses différentes étapes d'exécution. Le processus 1 est dédié à la récupération de données. Dans un premier temps, l'application 25 cliente communique (1) avec l'application distante pour récupérer les nouvelles informations générées du côté de l'application distante. La réponse reçue induit le découpage de la dite réponse en une ou plusieurs informations appelée(s) message(s) dont la syntaxe, la structure et le langage sont définis par une des 2 applications. Chacun de ces messages doit posséder un identifiant unique généré par l'application distante. Ces nouveaux messages sont ensuite stockés (2) en base de 30 données, dans une collection edimessage recu_queue, dans un état "nouveau message" du workflow : non-acquitté et non-interprété. L'identifiant distant de ces messages est ensuite renvoyé à l'application distante (3) pour acquittement : on envoie ainsi l'ordre à l'application distante de ne plus envoyer ces messages pour l'instance courante d'échange de données informatisé. A la réception de la réponse lors de l'acquittement, si l'application distante a répondu un code de retour 35 OK, les messages concernés sont mis à jour comme étant acquittés en base de données dans la collection précédemment citée. 3036512 2 Le processus 2 est dédié à l'interprétation des messages. Dans un premier temps, on sélectionne (4) les messages de la collection edi message_recu_queue qui n'ont pas encore été interprétés. On va ensuite lire (5) chacun de ces messages pour savoir comment impacter l'application cliente qui embarque cette méthodologie d'échange de données informatisé. C'est 5 notamment cette étape du processus qui va créer les nouvelles instances d'informations selon le modèle de données de l'application cliente (exemple : un nouveau client dans l'annuaire de l'application cliente) et les faire persister. Les messages interprétés sont alors mis à jour dans la précédente collection comme étant lus pour éviter de les interpréter une nouvelle fois lors de la prochaine itération. Les nouvelles instances d'objets génèrent un identifiant côté application cliente une fois persistées dont le type et la syntaxe dépendent du système de persistence : ces identifiants doivent être renvoyés à l'hôte distant pour faire vivre une correspondance entre les identifiants des instances d'information de l'application distante et les identifiants des instances de l'application cliente. Par exemple, un client créé sur une application distante dans un annuaire aura comme identifiant 42, mais rien n'assure le fait que le client créé sur l'application cliente aura ce même identifiant (les types de bases de données peuvent différer, et donc leur gestion de génération d'identifiant). Les correspondances générées par ce processus, ainsi que les actions utilisateurs (création, modification ou suppression d'une instance d'information côté application cliente), vont générer des événements (6) à envoyer à l'application distante. Cette étape de générations d'événements va traduire un traitement d'information (exemple : création de client d'un annuaire) ou une correspondance en un message compréhensible par l'application distante, message qui va être inséré dans la collection edi message_envoie_queue en l'état de début de workflow : non-envoyé. Le processus 3 est dédié à l'envoie des nouveaux messages générés par l'application cliente vers l'application distante. Dans un premier temps, on sélectionne (7) les nouveaux messages de la collection edi message envoie queue qui sont en l'état "non-envoyé". Cette étape permet aussi de vérifier la consistance des messages (syntaxe, structure, langage) avant envoie afin d'éviter de générer des erreurs sur l'application distante : à ce moment là, un message peut alors être mis à jour comme étant en erreur dans la collection edi message envoie queue pour traitement postérieur. L'étape (8) va ensuite venir générer une requête, conforme aux spécifications distantes s'il y en a, contenant une partie ou l'ensemble des messages à envoyer (selon la configuration du cadencement des traitements des messages). Une fois la requête envoyée à l'application distante, la réponse est lue (9) et interprétée : si l'application distante a répondu un code de retour OK, les messages envoyés sont mis à jour dans la collection edi message envoie queue en tant qu'envoyés, sinon on essaie de les renvoyer à la prochaine itération du processus. Chaque processus est cadencé, c'est à dire qu'ils ne travaillent que sur un nombre restreint d'informations à la fois. Ce sont généralement les ressources Processeur et Mémoire vive du système 3036512 3 hôte mobile qui vont permettre de calculer une limite aux nombres de messages traités par chacun des processus. Par exemple, on met en place un système de palier : pour un processeur de 2GHz et une mémoire de 2Go, on décide de traiter au maximum 500 messages à la fois dans chacun des processus. Ceci permet d'éviter les surcharges des ressources allouées à l'application cliente à cause 5 d'un trop gros nombre de messages transitants dans les processus de l'échange de données. Les 2 collections edi message recu queue et edi message envoie queue doivent être considérées comme des files d'attente (FIFO) pour éviter qu'une vieille information ne soit pas traitée pendant trop longtemps à cause d'un nombre important d'informations à traiter. Le fait d'avoir une file d'attente des messages à envoyer va permettre de mettre en attente l'envoie des nouvelles 10 informations si le système hébergeant l'application cliente n'est pas connecté à internet, ce qui permet une utilisation constante de l'application cliente. Les 3 processus décris ci-dessus s'exécutent en parallèle dans le système hôte mobile. Ils ne ralentissent alors pas l'expérience utilisateur de l'application cliente qui embarque l'échange de données mobile : l'exécution en parallèle permet en effet de garder une certaine priorité sur le 15 processus principal de l'application cliente qui ne s'occupe en aucune manière de la communication avec l'application distante. De même, il n'y a aucune concurrence entre les différents processus qui gèrent des parties différentes des workflows des messages qui transitent dans le système. Enfin, cette méthodologie de communication permet de ne faire transiter une information qu'une seule fois : chaque traitement (création, mise à jour, changement d'état...) implique un message envoyé à 20 tous les systèmes qui interprètent et font persister le résultat de ce traitement. L'information n'est donc plus récupérée au besoin, mais à chacun des traitements métiers effectués dans un système. La dite méthode permet de communiquer avec différentes applications distantes sans perte de performance. Chaque processus ne travaille que sur la communication d'une application distante à la fois : s'il y a X applications distantes, il faudra au moins X itérations du processus pour 25 synchroniser les informations des X applications. Un ordonnancement par configuration administrateur ou utilisateur est alors possible, de manière incrémentale ou par priorisation. Chaque communication avec une application distante peut stocker les informations dans une base de données dédiée à cette communication : on peut alors utiliser un groupe de base de données et configurer l'échange de données pour qu'il utilise la bonne base de données à chaque itération, d'où 30 le terme BD Channel X dans le schéma, Channel X étant une référence à l'application distante en cours de synchronisation. Les 2 collections edi message_recu queue et edi message envoie queue peuvent alors être répliquées mais avec des informations différentes les unes des autres. La méthode selon l'invention est destinée à tout type de synchronisation de données depuis une application embarquée sur une plate-forme mobile. REVENDICATIONS1) Méthode pour synchroniser de manière pseudo-synchrone des données entre une application cliente sur plate-forme mobile et une application distante destinée à minimiser l'impact d'une donnée transitantes entre les 2 applications sur les ressources de l'application cliente allouées par le système mobile. 2) Méthode selon la revendication 1 divisé en 3 processus distincts ayant chacun un rôle différent dans le workflow de traitement des informations transitantes. 3) Méthode selon la revendication 2 dont le premier des 3 processus est destiné à récupérer les nouvelles informations distante, les stocker et les acquitter. 4) Méthode selon la revendication 2 dont le deuxième des 3 processus est destiné à lire et interpréter les nouvelles informations et générer les nouveaux événements internes à l'application cliente. 5) Méthode selon la revendication 2 dont le troisième des 3 processus est destiné à envoyer les nouvelles informations internes à l'application distante. 6) Méthode selon les revendications 3 et 4 qui définit un workflow pour chaque nouvelle information reçue : nouvelle, acquittée, traitée, inconnue. 7) Méthode selon les revendications 4 et 5 qui définit un workflow pour chaque nouvelle information générée : nouvelle, envoyée, en erreur. 8) Méthode permettant la synchronisation d'une application cliente avec une ou plusieurs application(s) distante(s) de manière cadencée selon les spécifications systèmes et ordonnancée selon des configurations administrateurs ou utilisateurs.