FR3027131A1 - Procede et dispositif d’extraction de donnees standardisees - Google Patents

Abstract

Procédé d'extraction de données standardisées caractérisé en qu'il comporte les étapes suivantes : - lecture d'une requête d'extraction préenregistrée comportant des instructions de nommage explicite de colonnes ; lecture d'une source de données selon une association de la requête préenregistrée à ladite source de données ; - exécution de la requête d'extraction lue via une connexion à la source de données lue pour produire un jeu de données extraites ; production, à partir du jeu de données extraites d'un message de données selon les noms des données du jeu de données extraites.

Description

Procédé et dispositif d'extraction de données standardisées DOMAINE TECHNIQUE DE L'INVENTION [0001] L'invention se rapporte à un procédé d'extraction de données standardisées. L'invention se rapporte à la portabilité des applications et a la réduction des investissements pour la réalisation d'une portabilité. En particulier le domaine de l'invention est celui des applications mobiles. En particulier encore le domaine de l'invention est celui des applications connectées à au moins un moteur de stockage de données. [0002] On entendra par portabilité dans le cadre de la présente demande le fait qu'une application soit accessible dans une pluralité d'environnements d'exécution. Les environnements visés sont en particulier les environnements mobiles, mais pas seulement. Par investissement on entend surtout l'acquisition de connaissances spécifiques aux environnements visés.

ETAT DE LA TECHNIQUE ANTERIEURE [0003] Le besoin d'un accès permanent à l'information a conduit les éditeurs de solutions de mobilité à chercher des moyens pour permettre cet accès sur tous supports, ordinateur, tablette et téléphone intelligent. Les paramètres à prendre en compte sont principalement la surface d'affichage, l'interface homme machine et le système d'exploitation sous-jacent. [0004] Les principales difficultés techniques à résoudre pour satisfaire un besoin dans le domaine de la mobilité sont au moins : - diversité et hétérogénéités des données à traiter : - moteurs de stockage différents : SQL-Server, Oracle, MySql, SQLite, MongoDB, ... de tels moteurs sont usuellement désignés comme des bases de données. On inclut y les services web de données ; - différences de modélisations : des données a priori de même nature peuvent être modélisées de façon différentes en utilisant des tables, des relations, des objets dont les structures varient d'une mise en oeuvre à l'autre d'une couche de persistance de données. 3027131 2 - diversité des interfaces hommes machines souhaitées - diversité des plateformes logicielles à partir desquels les données doivent être accessibles : - Androïd ; 5 - iOS ; - Windows ; [0005] La solution historique à ce problème consiste à passer en mode projet avec des phases : 10 - d'identification et de hiérarchisation des besoins ; - de choix des plateformes et des outils de mise en oeuvre associés ; - mise en oeuvre d'une solution logicielle pour chacune des plateformes restantes. Cette phase requiert des compétences de programmation pour chacune des plateformes et des compétences relatives à une 15 couche de persistance de données qui doit être interrogée. [0006] A l'origine les compétences de programmation étaient natives, c'est-à-dire qu'il y avait une branche de code informatique par plateforme le code étant spécifique à chaque plateforme. En cas d'évolution du besoin il fallait donc faire évoluer l'ensemble des branches sans exception et de manière différente. 20 [0007] Avec le temps sont apparus des environnements de développement permettant de « coder une fois, exécuter partout ». Un tel environnement de développement est, par exemple, « Java ». Ces environnements impliquent l'utilisation d'une couche intermédiaire, parfois appelé machine virtuelle, requise pour l'exécution des fichiers produits via un tel environnement. Les machines 25 virtuelles les plus connues sont la machine virtuelle java (ou JVM) et l'interpréteur de code Javascript. [0008] Les principaux problèmes de ces environnements sont : - qu'ils constituent une couche supplémentaire entre l'application et le microprocesseur, limitant ainsi ses performances et rendant, entre 30 autre, l'interface homme machine moins fluide ; - les implémentations des machines virtuelles ne sont pas forcément homogènes d'une plateforme à l'autre ; 3027131 3 - comme pour les plateformes citées précédemment, la mise en oeuvre d'une application nécessite l'écriture de code informatique spécifique à à l'environnement utilisé, voire même, dans certains cas, à la version spécifique de celui-ci 5 - pour certaines plateformes il n'existe tout simplement pas de machine virtuelle. [0009] Une dernière approche est celle du client universel aussi connu sous la dénomination « HTML + Javascript ». Un tel client universel est classiquement un navigateur web ou navigateur. Un tel navigateur est une application en tant que 10 telle, ou un composant logiciel intégré dans une application englobante. Mais là encore tous les navigateurs : - constituent une couche supplémentaire entre le code de l'application et le système d'exploitation. De ce point de vue un navigateur peut être perçu comme une machine virtuelle et tous les inconvénients liés aux 15 machines virtuelles sont donc aussi présents pour les navigateurs ; - ne se valent pas en termes de : - performances, notamment sur les plateformes mobiles, - conformité aux standards, c'est-à-dire qu'une instruction du standard n'implique pas forcément des comportements 20 identiques sur tous les navigateurs prétendant respecter les standards. [0010] Une alternative au client universel est l'application dite hybride dont l'esprit est d'utiliser le plus possible l'aspect client universel en embarquant un composant web mais en conservant quelques parties de l'application en code 25 purement natif. On obtient donc une application native mais développée, au moins pour partie, en langage universel. Les applications hybrides sont donc limitées au même titre que celles basées sur l'approche client universel. [0011] II n'y a donc actuellement pas de bonne solution connus permettant d'une part, de déployer une nouvelle application sur une pluralité de plateformes 30 matérielles et logicielles et, d'autre part, de garantir une homogénéité des expériences sur lesdites plateformes. Les solutions actuelles correspondent à un plus petit dénominateur commun des différentes plateformes ciblées. Ce 3027131 4 dénominateur commun n'exploite pas les ressources spécifiques de chaque plateforme, en particulier les ressources graphiques. EXPOSE DE L'INVENTION 5 [0012] L'invention vise à remédier à tout ou partie des inconvénients de l'état de la technique identifiés ci-dessus, et notamment à proposer des moyens pour permettre de déployer rapidement une nouvelle application. L'invention est basée sur une analyse de l'état de la technique précédemment décrit. [0013] Dans l'invention on considère que, pour garantir une performance 10 optimale sur un support il est préférable d'utiliser ses technologies natives. Cela évite l'empilement de couches logicielles, chaque couche prélevant ses cycles CPU [0014] Dans l'invention on utilise donc des clients natifs consommant chacun des données standardisées produites par un serveur auquel le client adresse une 15 requête. [0015] Les clients, quel que soit la plateforme, sont capables d'interpréter les données reçus. Pour ce faire l'invention propose la mise en oeuvre d'étapes permettant la production de données standardisées. De plus avec l'invention, la configuration de la production de ces données est possible en ne connaissant 20 qu'une technologie, hors celle de l'invention, mais surtout sans avoir de compétence de programmation native. L'invention permet donc de concevoir une application multiplateformes sans connaissance spécifique des dites plateformes. [0016] Dans ce dessein, un aspect de l'invention se rapporte à un procédé d'extraction de données standardisées caractérisé en qu'il comporte les étapes 25 suivantes : - lecture d'une requête d'extraction préenregistrée comportant des instructions de nommage explicite de colonnes ; - lecture d'une source de données selon une association de la requête préenregistrée à ladite source de données ; 30 - exécution de la requête d'extraction lue via une connexion à la source de données lue pour produire un jeu de données extraites ; - production, à partir du jeu de données extraites d'un message de données selon les noms des données du jeu de données extraites. 3027131 5 [0017] Outre les caractéristiques principales qui viennent d'être mentionnées dans le paragraphe précédent, le procédé selon l'invention peut présenter une ou plusieurs caractéristiques complémentaires parmi les suivantes, considérées individuellement ou selon les combinaisons techniquement possibles: 5 - le message est un message texte selon une sérialisation des données extraites ; - le procédé comporte les étapes suivantes : - réception d'une liste de couples d'éléments [nom, valeur] ; - les couples de la liste de couples sont utilisés pour la mise à jour d'un 10 contexte de session ; - le procédé comporte les étapes suivantes : - modification d'une clause de filtrage de la requête enregistrée en fonction des couples de la liste reçue, - remplacement de la requête enregistrée par la requête 15 modifiée pour l'exécution ; - pour la modification, pour un couple d'éléments, l'élément nom est une indirection vers une syntaxe prédéterminée ; - la requête est lue en fonction d'au moins un couple [nom, valeur] ; - les requêtes d'extraction sont des requêtes paramétrées ; 20 - le message de données est associé à un identifiant d'un modèle de consommation des données ; [0018] L'invention se rapporte également à un support d'enregistrement lisible par ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions de code de programme pour l'exécution d'étapes du procédé 25 selon une combinaison des caractéristiques précédentes. [0019] L'invention se rapporte également à un dispositif mettant en oeuvre le procédé selon une combinaison des caractéristiques précédentes. BREVE DESCRIPTION DES FIGURES 30 [0020] D'autres caractéristiques et avantages de l'invention ressortiront à la lecture de la description qui suit, en référence aux figures annexées, qui illustrent : - la figure 1, une vue d'une infrastructure permettant la mise en oeuvre de l'invention ; 3027131 6 - la figure 2, une illustration d'étape du procédé selon l'invention. [0021] Pour plus de clarté, les éléments identiques ou similaires sont repérés par des signes de référence identiques sur l'ensemble des figures. [0022] L'invention sera mieux comprise la lecture de la description qui suit et à 5 l'examen des figures qui l'accompagnent. Celles-ci sont présentées à titre indicatif et nullement limitatif de l'invention. DESCRIPTION DETAILLEE D'UN MODE DE REALISATION [0023] La figure 1 montre un dispositif serveur 100 d'application. Le serveur 10 d'application comporte : - un microprocesseur 110 ; - des moyens de stockage 120, par exemple un disque dur qu'il soit local ou distant, qu'il soit simple ou en grille (par exemple RAID) ; - une interface 130 de communication, par exemple une carte de 15 communication selon le protocole Ethernet. D'autres protocoles sont envisageables comme IP, « Fibre Channel » ou InfiniBand. [0024] Le microprocesseur 110 du serveur d'application, les moyens 120 de stockage du serveur d'application et l'interface 130 de communication du serveur d'application sont interconnectés par un bus 150. 20 [0025] Lorsque l'on prête une action à un dispositif celle-ci est en fait effectuée par un microprocesseur du dispositif commandé par des codes instructions enregistrés dans une mémoire du dispositif. Si l'on prête une action à une application, celle-ci est en fait effectuée par un microprocesseur du dispositif dans une mémoire duquel les codes instructions correspondant à l'application sont 25 enregistrés. Lorsqu'un dispositif, ou une application émet un message, ce message est émis via une interface de communication dudit dispositif ou de la dite application. Un dispositif est réel ou virtuel. [0026] La figure 1 montre que les moyens de stockage du serveur d'application comportent plusieurs zones : 30 - une zone 120.1 d'extraction comportant des codes instructions correspondant à la mise en oeuvre d'étapes du procédé selon l'invention ; - une zone 120.2 de paramétrage structurée pour : 3027131 7 - enregistrer des requêtes d'extraction de données ; - enregistrer des sources de données, une source de données est par exemple une chaîne de connexion à un système de base de données tel que ceux déjà cités, 5 - associer une requête d'extraction de données avec une source de données ; - associer une requête d'extraction de donnée avec un identifiant de modèle de consommation de données. [0027] La zone 120.2 de paramétrage est, par exemple, une base de données 10 selon par exemple l'un des .moteurs déjà cité. Plus généralement la zone 120.2 est une zone de stockage de données dont la structure est connue. [0028] Un modèle de consommation de données est, par exemple un code permettant de déterminer à un traitement à effectuer sur les données. [0029] La figure 1 montre un dispositif serveur 200 de données. Le serveur de 15 données comporte : - un microprocesseur 210 ; - des moyens de stockage 220 ; - une interface 230 de communication. [0030] Le microprocesseur 210 du serveur de données, les moyens 220 de 20 stockage du serveur de données et l'interface 230 de communication du serveur de données sont interconnectés par un bus 250. [0031] Un serveur de données est un dispositif mettant en oeuvre un moteur de stockage de données tel que ceux précédemment cités. Dans la pratique le moteur de stockage de données pourrait être mis en oeuvre par le serveur 25 d'application. [0032] La figure 1 montre un dispositif 300 mobile. Le dispositif mobile comporte : - un microprocesseur 310 ; - des moyens de stockage 320 ; 30 - une interface 330 de communication, par exemple une carte de communication sans fil ; - un écran 340. 3027131 8 [0033] Le microprocesseur 310 du dispositif mobile, les moyens 320 de stockage du dispositif mobile, l'interface 330 de communication du dispositif mobile et l'écran 340 du dispositif mobile sont interconnectés par un bus 350. [0034] La figure 1 montre que les moyens de stockage du dispositif mobile 5 comportent plusieurs zones : - une zone 320.1 de consommation comportant des codes instructions pour consommer des données et des codes instructions pour émettre des requêtes vers le serveur d'application ; - une zone 320.2 de paramétrage comportant, par exemple une adresse 10 du serveur d'application et un identifiant d'une application. [0035] Un identifiant d'application est interprété par le serveur d'application pour sélectionner au moins une requête d'extraction. Un identifiant d'application est, par exemple : connu a priori, ou obtenu pendant une étape préalable d'authentification non représentée. 15 [0036] Un dispositif mobile est par exemple un téléphone mobile ou un une tablette. Mais l'invention fonctionne aussi avec des ordinateurs individuels portables ou fixes. [0037] Le serveur d'application, le serveur de données et le dispositif mobile sont interconnectés par un réseau 500, par exemple le réseau Internet. Ce n'est 20 qu'un exemple, un autre cas fréquent est que le dispositif mobile ne voit que le serveur d'application qui lui voir le serveur de données. [0038] La figure 2 montre une étape 1000 préliminaire dans laquelle un utilisateur du dispositif mobile active un élément d'interface pour provoquer l'émission d'une requête réseau vers le serveur d'application. Cette requête est 25 produite en fonction des données enregistrées dans la zone 320.2 de paramétrage des moyens de stockage du dispositif mobile. La requête émise comporte au moins un identifiant d'application, celui lu dans la zone de paramétrage du dispositif mobile. [0039] Dans une étape 1010 le serveur d'application reçoit la requête réseau 30 émise lors de l'étape préliminaire et en extrait les informations. [0040] Dans une étape 1020 de lecture d'une requête le serveur d'application utilise les données contenues dans la requête reçue pour lire une requête d'extraction préenregistrée associée à l'identifiant contenu dans la requête reçue. 3027131 9 [0041] Toutes les requêtes préenregistrées selon l'invention comportent des instructions de nommage explicite de colonne. Un nom pour le renommage est utilisé en fonction de l'usage qui devra être fait de la colonne au niveau du dispositif mobile. 5 [0042] Une clause de sélection d'une requête préenregistrée obéit donc au formalisme suivant dans un langage SQL : select { nom_de_colonne alias_de_colonne} [1, n] [0043] Ou nom_de_colonne dépend de structure des données enregistrée dans la base de données et alias_de_colonne est un mot clé d'une application 10 selon l'invention. Dans l'invention on utilise donc des alias prédéfinis pour les colonnes extraites des bases de données. [0044] Du point de vue de l'invention, le recours à cette syntaxe permet de standardiser le résultat de l'exécution de la requête. Le résultat peut ainsi être traité sans programmation autre que l'enregistrement de la requête d'extraction.

15 La maîtrise d'un langage d'extraction de données permet donc de paramétrer une application selon l'invention. Dans l'invention alias_de_colonne correspond à un comportement préprogrammé de l'application. [0045] Dans une étape 1030 de lecture d'une source de données le serveur d'application utilise les données contenues dans la requête reçue pour lire une 20 source de données associée à l'identifiant contenu dans la requête reçue. Cette associant peut être : - directe : la source de données et associée à la requête reçue, ou - via une requête d'extraction, la requête reçue étant associée à une requête d'extraction qui est elle associée à une source de données. 25 [0046] Une source de données est un enregistrement qui donne toutes les informations pour se connecter à un moteur de stockage de données, par exemple celui mis en oeuvre par le serveur de données. [0047] Dans une étape 1040 d'exécution de la requête d'extraction lue le serveur d'application, de manière classique effectue les opérations suivantes : 30 - établissement d'une connexion selon les informations de la source de données lue. A cette fin la zone 120.1 d'extraction comporte des codes instruction permettant l'interprétation des sources de données, c'est-à-dire de l'évaluation d'une chaîne de connexion ; 3027131 10 - envoie de la requête d'extraction lue à travers la connexion établie ; - réception d'une réponse comportant les données correspondant à l'interprétation de la requête d'extraction lue par le serveur de données. Une telle réponse s'appelle aussi un jeu de données. 5 [0048] A la fin de l'étape 1040 d'exécution le serveur d'application est en connaissance d'un jeu de données correspondant à la requête d'extraction lue et à la source de données lue. [0049] Dans une étape 1050 de production d'un message de données, le serveur d'application produit un message texte à partir du jeu de données et selon 10 le nom des colonnes de ce jeu de données. Il s'agit, par exemple, d'une sérialisation texte selon un format JSON ou XML. On parle alors d'un message sérialisé. [0050] A ce stade le procédé selon l'invention permet, à quiconque ayant une connaissance d'un langage d'extraction, de produire des données standardisées 15 aptes à être consommées. [0051] Dans une étape 1060 le serveur d'application, émet le message de données en réponse à la requête émise lors de l'étape 1000 préliminaire. [0052] Dans une variante de l'invention, à l'étape 1050 de production d'un message de données, le serveur d'application enrichit ce message avec un 20 identifiant d'un modèle de consommation. [0053] Dans une étape 1100 de réception d'une réponse le terminal mobile reçoit le message de données comportant des données standardisées. Le terminale mobile applique donc un traitement standard à ces données. Le traitement standard en question est soit connu a priori, soit désigné par un 25 enrichissement du message de données. [0054] Le traitement standard est désigné par un code qui va activer un traitement préprogrammé ou préinstallé sur le terminal mobile. On parle de modèle de consommation car un tel traitement est, par exemple la production d'une image. Une image est, par exemple, un graphe, une courbe, un 30 camembert... associé à des éléments d'interface permettant d'interagir avec le serveur d'application. Un autre type de consommateur est, dans un autre exemple, un contrôle. Un contrôle est, par exemple, une liste de sélection, une grille de données,... la liste n'est pas exhaustive. Chacun de ces contrôles a au 3027131 11 moins un paramètre « jeu de donnée » qui est initialisé, dans l'invention, avec les données standardisées. [0055] II est ainsi clair pour l'homme du métier qu'il devient simple de déployer une application basé sur des traitements standards préinstallés. Il suffit de 5 paramétrer une extraction de données selon l'invention. Les possibilités ne sont pas celles d'un codage ouvert en code natif par exemple, mais la mise en oeuvre demande un minimum de connaissance et est universelle. La limitation principale vient du nombre de modèle de consommation préinstallé sur les dispositifs mobiles. L'invention offre un gain important en termes de rapidité de conception et 10 de rapidité de déploiement, la portabilité étant acquise. [0056] Dans une autre variante de l'invention la requête émise lors de l'étape préliminaire comporte des paramètres sous formes de couple [nom, valeur]. [0057] Dans une variante des valeurs de paramètres sont transmises par formatage d'URL aussi connu sous le nom d'« URL-rewriting ». Dans encore une 15 autre variante des valeurs de paramètre sont transmises par intégration dans une URL de paramètres d'URL sans valeur associée. [0058] Ces couples, ou paramètres, sont exploités après la lecture de la requête d'extraction, mais avant son exécution. [0059] Cette exploitation est une modification de la clause de filtrage de la 20 requête. Dans le langage SQL on parle aussi de clause WHERE. La clause de filtrage est augmentée par des critères sur des colonnes dont on obtient le nom via le nom du couple et la valeur via la valeur du couple on obtient alors des critères de sélection tel que. nom = valeur 25 [0060] Dans une autre variante contextuelle, ces paramètres reçus, et leurs valeurs sont utilisés pour alimenter un contexte de session. Un tel contexte est matérialisé par une zone des moyens de stockage du serveur d'application. Un contexte de session est classiquement une liste de clés associées ou non à des valeurs. On parle alors de variables de session. Cette liste est elle-même associée 30 à un identifiant de session. Un identifiant de session a été obtenu lors d'une étape d'authentification. Dans cette variante contextuelle la requête est choisie en fonction du contenu du contexte chaque requête étant associée à une liste de variables, on lit, à l'étape 1020 de lecture d'une requête d'extraction, la requête 3 02 7 13 1 12 dont la liste de variables correspond aux variables contenues dans le contexte. Cette correspondance se fait en fonction du nom et ou de la valeur des variables. [0061] Dans cette variante contextuelle, une zone 120.2 de paramétrage est structurée pour associer des requêtes d'extraction à des listes de variables. Il est 5 ainsi possible de trouver une requête associée à un jeu de variables. [0062] Dans le cas d'une telle association d'une requête à une liste de variables, on prévoit une requête par défaut pour le cas où le contexte serait vide, où pour le cas où le contexte ne contiendrait pas les variables adéquates. Cette requête se fait, par exemple, soit en associant un drapeau « par défaut » à une 10 requête, soit en ayant une requête associée à une liste de paramètre vide. Une telle requête par défaut est aussi utilisée quand il n'a pas été possible d'associer le contenue du contexte à une requête. [0063] Dans une variante un identifiant de session est le « UDID » du dispositif mobile 11 s'agit d'un identifiant unique de dispositif aussi appelé Universal Device 15 ID. Une alternative, dans une autre variante est d'utiliser une adresse MAC. Ces exemples ne sont pas limitatifs. [0064] Par exemple, dans la variante contextuelle, une requête du type : Domain.t1d/Order?continent=EU&year=2014 [0065] On alimente le contexte comme suit : [action, Order ], [continent, EU] et 20 [year, 2014]. On a donc dans le contexte 3 couples ou variables de session, [nom, valeur]. On recherche alors, dans l'étape 1020 de lecture d'une requête d'extraction, une requête d'extraction correspondant. [0066] Cette requête d'extraction sera du type Select * from table where cl = @continenr and c2 = @year 25 [0067] II s'agit d'une requête paramétrée, ses paramètres ayant les noms « continent » et « year ». Ces noms de paramètre sont choisis de manière arbitraire ainsi que les noms de table et de colonnes. [0068] Ici la correspondance est du type : - La requête est associé à une variable nommée « action » dont la valeur 30 est « Order », et - La requête comporte un paramètre nommé « continent », et - La requête comporte un paramètre nommé « year ». 3 02 7 13 1 13 [0069] On voit ici que l'association d'une requête d'extraction à une variable comporte une propriété selon que l'évaluation de cette association se fait en testant la présence de la variable, ou en testant la valeur de la variable. [0070] L'évaluation de la requête d'extraction se fait en utilisant les valeurs des 5 variables contenues dans le contexte. Dans notre exemple une requête équivalente à celle qui est effectivement exécutée est : Select * from table where cl = 'EU' and c2 = 2014 [0071] Dans une autre variante l'opérateur de comparaison est une sous partie du nom ou de la valeur. Par exemple on a un couple [C1, >V1], ce qui donnera le 10 critère suivant : Cl > V1 [0072] Dans une variante le nom du couple est une indirection vers un nom de colonne ou une syntaxe de pagination par exemple. Un ensemble de couples tels que le suivant 15 [tp, 10][p, 3] permettrait d'obtenir une clause offset 30 rows fetch next 10 rows only C'est-à-dire une instruction de pagination selon une syntaxe SQL. tp est la taille de la page à retourner, p est le numéro de la page à retourner. 20 [0073] Les paramètres sont transmis selon le protocole http avec de préférence une requête GET ou POST. D'une manière générale on peut aussi utiliser un protocole de communication réseau de niveau application, selon la normalisation OSI, tel que http, WebSocket, SPDY,... la liste n'est pas limitative. [0074] L'invention est donc un moteur paramétrable d'extraction de données 25 en vue de la consommation des données extraites par un client standardisé.

Claims (11)

1. REVENDICATIONS1. Procédé d'extraction de données standardisées caractérisé en qu'il comporte les étapes suivantes : lecture (1020), par un serveur d'application, d'une requête d'extraction préenregistrée comportant des instructions de nommage explicite de colonnes ; lecture (1030), par le serveur d'application, d'une source de données selon une association de la requête préenregistrée à ladite source de données ; exécution (1040), par le serveur d'application, de la requête d'extraction lue via une connexion à la source de données lue pour produire un jeu de données extraites ; production (1050), par le serveur d'application, à partir du jeu de données extraites d'un message de données selon les noms des données du jeu de données extraites.
2. 2. Procédé d'extraction de données selon la revendication 1, caractérisé en ce que le message est un message texte selon une sérialisation des données extraites.
3. 3. Procédé d'extraction de données selon l'une des revendications précédentes, caractérisé en ce que le procédé comporte les étapes suivantes : réception (1010) d'une liste de couples d'éléments [nom, valeur].
4. 4. Procédé selon la revendication 3, caratérisé en ce que les couples de la liste de couples sont utilisés pour la mise à jour d'un contexte de session.
5. 5. Procédé d'extraction de données selon l'une des revendications 3 ou 4, caractérisé en ce que, le procédé comporte les étapes suivantes : modification d'une clause de filtrage de la requête préenregistrée en fonction des couples de la liste reçue, remplacement de la requête préenregistrée par la requête modifiée pour l'exécution.
6. 6. Procédé d'extraction de données selon la revendication 5, caractérisé en ce que pour la modification, pour un couple d'éléments, l'élément nom est une indirection vers une syntaxe prédéterminée.
7. 7. Procédé d'extraction de données selon l'une des revendications 3 ou 4, caractérisé en ce que la requête est lue en fonction d'au moins un couple [nom, valeur]. 3027131
8. 8. Procédé selon l'une des revendications précédentes, caractérisé en ce que les requêtes d'extraction sont des requêtes paramétrées.
9. 9. Procédé selon l'une des revendications précédentes, caractérisé en ce que le message de données est associé à un identifiant d'un modèle de consommation des données.
10. 10. Support d'enregistrement lisible par ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions de code de programme pour l'exécution d'étapes du procédé selon l'une des revendications 1 à 9.
11. 11. Dispositif mettant en oeuvre le procédé selon l'une des revendications 1 à 5 précédentes.