FR3144351A1 - Infrastructure logicielle légère pour l’intégration de nœuds de décision dans un traitement automatisé de forage de données - Google Patents
Infrastructure logicielle légère pour l’intégration de nœuds de décision dans un traitement automatisé de forage de données Download PDFInfo
- Publication number
- FR3144351A1 FR3144351A1 FR2214244A FR2214244A FR3144351A1 FR 3144351 A1 FR3144351 A1 FR 3144351A1 FR 2214244 A FR2214244 A FR 2214244A FR 2214244 A FR2214244 A FR 2214244A FR 3144351 A1 FR3144351 A1 FR 3144351A1
- Authority
- FR
- France
- Prior art keywords
- micro
- interface
- data processing
- logical core
- services
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000012545 processing Methods 0.000 title claims abstract description 41
- 238000007418 data mining Methods 0.000 title description 4
- 230000000694 effects Effects 0.000 claims abstract description 13
- 230000006854 communication Effects 0.000 claims abstract description 8
- 238000004891 communication Methods 0.000 claims abstract description 8
- 101150104728 GPR88 gene Proteins 0.000 claims abstract description 7
- 238000013500 data storage Methods 0.000 claims description 3
- 230000007175 bidirectional communication Effects 0.000 abstract 1
- 238000004458 analytical method Methods 0.000 description 8
- 238000000034 method Methods 0.000 description 7
- 230000006870 function Effects 0.000 description 6
- 238000004364 calculation method Methods 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 230000010354 integration Effects 0.000 description 3
- 238000012423 maintenance Methods 0.000 description 3
- 230000008569 process Effects 0.000 description 3
- 230000001360 synchronised effect Effects 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 238000007596 consolidation process Methods 0.000 description 2
- 238000012544 monitoring process Methods 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 238000004220 aggregation Methods 0.000 description 1
- 230000002776 aggregation Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 238000013473 artificial intelligence Methods 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 238000003066 decision tree Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000005538 encapsulation Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000002688 persistence Effects 0.000 description 1
- 230000004043 responsiveness Effects 0.000 description 1
- 238000013341 scale-up Methods 0.000 description 1
- 238000000638 solvent extraction Methods 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000001131 transforming effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Pipeline de traitement de données, comprenant une pluralité de micro-services (MicServ) partageant une même structure et configurés pour échanger des données entre eux par l’intermédiaire d’un bus de service d’entreprise (ESB), chaque micro-service étant mis en œuvre au moyen d’un bloc de base (100) comprenant un cœur logique (Lgc) encapsulé par structure logicielle (FWK) limitée à cinq blocs d’interface chacun en communication avec le cœur logique (Lgc) : un premier bloc d’interface (ASync) de messagerie asynchrone ; un deuxième bloc d’interface (Sync) de communication bidirectionnelle directe de manière synchrone avec le bus (ESB) ; un troisième bloc d’interface (Journ.Intrf) d’enregistrement dans un fichier journal (Journ) de l’activité des cinq blocs d’interface et du cœur logique (Lgc) ; un quatrième bloc d’interface (Strg.Intrf) de lecture et d’écriture dans un stockage permanent (Strg) ; un cinquième bloc d’interface (Config.Intrf) de chargement de configuration. Figure à publier avec l’abrégé : Fig. 2
Description
L'invention concerne une infrastructure logicielle légère facilitant l’intégration de nœuds de décision dans une activité de traitement automatisé de forage et de classification de données par des modules d’intelligence artificielle et des règles métiers élémentaires.
Le forage de données désigne l’analyse de données brutes selon différentes méthodes, complémentaires les unes des autres, ayant pour but de transformer ces données brutes en informations utiles, en établissant des relations entre les données, par exemple en effectuant un tri de ces données. Une telle analyse repose sur des algorithmes pouvant être complexes et mettant en œuvre différents types d’analyse au sein d’un arbre décisionnel comportant des nœuds dits nœuds de décisions.
Parmi les types d’analyse mis en œuvre, on peut citer la recherche d’associations entre des données ou des événements, la recherche de séquences d’événements, la recherche de nouvelles classifications pertinentes pour le classement des données, le partitionnement de données qui consiste en la division d’un ensemble de données en groupes homogènes, ou encore l’analyse prédictive qui consiste à analyser des faits présents pour en tirer des hypothèses prédictives sur des événements futurs. Une analyse complète peut nécessiter la combinaison de chacun de ces types d’analyse, qui peuvent chacun être décomposés en tâches de base relativement simples prises individuellement, mais dont l’assemblage peut s’avérer ardu.
En effet, l'acheminement des données à travers différents nœuds de décision, formant un ensemble complexe de traitement des données et d'inférence dit « pipeline de traitement de données », est d’autant plus difficile que l’analyse souhaitée est exhaustive et que la quantité de données à disposition est massive, que ces données sont continuellement renouvelées et proviennent de sources de formats hétérogènes. Il existe de nombreux principes de conception pour réaliser un tel pipeline, tels que la construction de micro-services ou l'architecture hexagonale, mais il n'existe pas de cadre concret ni de guide opérationnel pour le développer et le rendre facile à intégrer rapidement, à superviser et à maintenir.
Ainsi, une solution satisfaisante d’un point de vue pratique reste encore à mettre en place.
Un objet de l’invention est de fournir une infrastructure logicielle légère avec des interfaces de programmation d’application (API) et une encapsulation logique standardisée permettant d'accélérer et d'harmoniser la création de micro-services communiquant entre eux par l’intermédiaires des APIs, formant ainsi une chaîne de traitement intégrée. Au moyen de cette infrastructure, les micro-services peuvent échanger de manière bidirectionnelle des données de manière transparente par le biais de méthodes asynchrones ou synchrones et mettre en œuvre une séquence complexe de processus de décision, par exemple composée de nœuds de décision d'intelligence artificielle et de règles de consolidation d'entreprise.
Chaque nœud, intégré dans la chaîne de traitement, utilise l’infrastructure logicielle selon l’invention, conçue pour fournir les fonctions essentielles à tout algorithme (chargement de paramètres, persistance de données, production de traces sur l’activité interne, échanges synchrones et échanges asynchrones de messages) tout en (1) limitant les technologies utilisées et (2) standardisant les pratiques de codage. Cela permet de simplifier le processus de supervision et de maintenance en connectant chaque nœud de la chaîne de traitement de manière cohérente avec une méthode unique.
En vue de la réalisation de ce but, un aspect de l’invention est un pipeline de traitement de données, comprenant une pluralité de micro-services partageant une même structure et configurés pour échanger des données entre eux par l’intermédiaire d’un bus de service d’entreprise, dans lequel chaque micro-service est mis en œuvre au moyen d’un bloc de base comprenant un cœur logique encapsulé par structure logicielle limitée à cinq blocs d’interface chacun en communication avec le cœur logique, dans lequel les cinq blocs d’interface sont : un premier bloc d’interface comprenant une messagerie asynchrone ; un deuxième bloc d’interface configuré pour permettre une communication bidirectionnelle directe de manière synchrone avec le bus de service d’entreprise ; un troisième bloc d’interface configuré pour enregistrer dans un fichier journal l’activité des cinq blocs d’interface et du cœur logique ; un quatrième bloc d’interface configuré pour permettre la lecture et l’écriture de données dans ou vers un stockage permanent de données ; un cinquième bloc d’interface est configuré pour charger la configuration du cœur logique et des quatre autres blocs d’interface mentionnés ci-dessus à partir d’un fichier de configuration.
Un pipeline de traitement de données selon l’invention est particulièrement simple et aisé à mettre en place, à maintenir et à modifier, reposant sur une architecture légère et extrêmement modulaire à base de blocs présentant une même structure et gérables par l’intermédiaires d’un même système d’interfaces.
Selon des caractéristiques additionnelles non-limitative du premier aspect de l’invention, considérées individuellement ou selon toute combinaison techniquement réalisable :
- chacun des blocs d’interface peut être configuré pour échanger des données avec les autres blocs d’interface ;
- chacun des blocs d’interface peut être configuré pour échanger des données avec les autres blocs d’interface sans passer par le cœur logique ;
- chaque micro-service peut être configuré pour échanger des données avec les autres micro-services du pipeline de données au moyen du bus de service d’entreprise (ESB) via les premiers blocs d’interface ;
- chaque micro-service peut enregistrer son activité interne dans le fichier journal selon un format standardisé commun à la pluralité de micro-services ;
- un enregistrement dans le fichier journal d’un événement d’une activité interne de chaque micro-service peut comprendre au moins une date, une indication de criticité, une identification du micro-service concerné, une identification de l’événement, et une description de l’événement ;
- chaque micro-service peut utiliser un même horodatage pour enregistrer l’activité des cinq blocs d’interface et du cœur logique dans le fichier journal la structure logicielle est unique et partagée entre chacun des micro-services ;
- le deuxième bloc d’interface peut être configuré pour diriger un appel externe vers l’un des quatre autres blocs d’interface ou vers le cœur logique, sur la base d’un identifiant du type d’appel porté par le message ;
- un premier des micro-services peut comprendre un cœur logique configuré pour enregistrer une identité de chacun des micro-services connectés au pipeline de traitement de données ; et
- un second des micro-services peut comprendre un cœur logique configuré pour consulter les identités de chacun des micro-services enregistrées par le cœur logique du premier des micro-services.
D’autres caractéristiques et avantages de l’invention ressortiront de la description détaillée de l’invention qui va suivre en référence aux figures annexées sur lesquels :
Les figures 1 et 2 illustrent l’infrastructure logicielle selon l’invention.
La illustre un bloc de base 100 de l’architecture logicielle selon l’invention. Ce bloc constitue un micro-service MicServ. Le cœur logique du bloc, Lgc dans la , est constitué d’une logique informatique dédiée à une tâche unique et traduisant un algorithme applicatif, par exemple une règle métier ou une composante d’une application de forage de données.
La illustre une intégration de cinq micro-services MicServ au sein de l’infrastructure logicielle selon l’invention, formant par exemple un pipeline de traitement de données DataPip connecté à une application App au moyen d’un module de supervision SuperV qui est contrôlé par un utilisateur Usr via une interface d’utilisateur Usr.Interf, par exemple une interface graphique. Un bus de service d’entreprise ESB (Enterprise Service Bus, en terminologie anglaise) est configuré pour communiquer avec chacun des micro-services MicServ ainsi qu’avec un module Calc de l’application App, dédié au traitement de données. Chacun des micro-services comprend un cœur logique qui lui est propre, assurant une fonction particulière au sein du pipeline de traitement de données.
Une structure logicielle FWK encapsule le cœur logique Lgc de chacun des micro-service MicServ du pipeline de traitement de données et les isole des communications extérieures. Cette structure logicielle FWK comprend cinq blocs d’interface permettant au cœur logique du micro-service de fonctionner de façon optimale en le déchargeant de toutes les tâches ne relevant pas directement de la tâche unique à laquelle il est dédié. En outre, l’interface logicielle FWK est configurée de manière à fournir des connexions directes entre chacun des blocs d’interfaces, ce qui leur permet de communiquer directement les uns avec les autres et évite d’avoir à perturber les calculs du cœur logique Lgc pour des opérations ne relevant pas directement de sa fonction particulière. Bien entendu, d’autres modules ou services extérieurs que ceux cités dans ce document peuvent communiquer avec les micro-services, soit via le bus de service d’entreprise ESB soit directement via le deuxième bloc d’interface Sync.
Un premier bloc d’interface ASync est configuré pour permettre une communication bidirectionnelle indirecte au moyen d’une messagerie asynchrone avec un autre composant externe tel qu’un autre micro-service, en utilisant une méthode de publication et d'abonnement (Publish-subscribe en terminologie anglaise). Le cœur logique peut ainsi demander de router un message sur le bus de service d'entreprise ESB. Les autres micro-services qui sont abonnés à cette route peuvent recevoir et interpréter ce message. Aucune réponse n'est attendue de l’émetteur du message, sauf si le cœur logique est configuré pour écouter et recevoir des messages sur une route spécifique, par exemple un canal de réponse défini dans un fichier de configuration.
Un deuxième bloc d’interface Sync est configuré pour permettre une communication bidirectionnelle directe de manière synchrone selon une approche ReST (Representational State Transfer).
Certains appels externes reçus par ce deuxième bloc peuvent être traités directement au niveau des blocs d’interfaces, par exemple pour fournir des informations concernant le statut ou la version du micro-service. Le deuxième bloc Sync d’interface est configuré de manière à générer un message à destination de l’un des quatre autres blocs d’interface en fonction du type d’appel reçu, sans passer par le cœur logique Lgc.
Alternativement, un appel externe peut être transféré au cœur logique, à la condition que le traitement de cet appel soit lié à la tâche unique du cœur logique Lgc, comme par exemple la transmission du dernier résultat calculé par le cœur, tel que la prédiction d’un coefficient de pertinence ou le résultat d’une opération de tri.
Un appel externe est un message émis par un élément extérieur à un micro-service considéré. L’élément extérieur peut être un autre micro-service, l’application App ou tout autre composant connecté directement ou indirectement au micro-service considéré. Cet appel externe est porteur de métadonnées comportant un identifiant du type d’appel. Le deuxième bloc d’interface est configuré pour orienter chaque appel externe vers l’un des quatre autres blocs d’interface ou vers le cœur logique, selon le type de l’appel, sur la base de l’identifiant du type d’appel porté par le message et de l’identifiant de son émetteur. Le type d’appel peut être indicatif d’un degré d’urgence à traiter l’appel en question, d’un bloc d’interface auquel il doit être transmis, ou encore du fait que l’appel est lié à la tâche unique du cœur logique du micro-service considéré.
Dans un micro-service, les traitements ou calculs effectués par le cœur logique Lgc et les deux blocs Sync et Async sont parallélisés en multithreading de manière à pouvoir agir indépendamment les uns des autres. Un intérêt de ce principe apparaît lorsque, par exemple, le cœur logique est en cours de calcul : le cœur logique peut mettre à disposition l’état d’avancement de ce calcul pour le bloc Sync ou le bloc Async, qui, en cas d’interrogation externe, pourront consulter et transmettre cet état d’avancement à un élément externe au micri-service sans stopper ni perturber le travail en cours de son cœur logique.
Un troisième bloc d’interface Journ.Intrf est configuré pour enregistrer dans un même fichier journal Journ l’activité interne des éléments composant le micro-service MicroServ (les cinq blocs d’interface et le cœur logique) selon un format standardisé. Cela signifie que, dans le pipeline de traitement de données, les événements enregistrés dans le fichier journal sont identifiés selon une nomenclature commune à tous les micro-services concernés du pipeline.
La fonction du fichier journal est d’enregistrer tous les événements liés à l’utilisation du pipeline. Il permet par exemple de retrouver, pour un ensemble de micro-services échangeant des messages portant des données, l’ordre dans lequel les messages ont été envoyés et traités. La nomenclature est définie de manière à associer à chaque événement enregistré, une date d’occurrence, un niveau de criticité, une identification de l’élément émetteur (l’un des blocs d’interfaces ou le cœur logique d’un micro-service identifié), un code descriptif du type de l’événement (démarrage, arrêt, réception, envoi, etc…), et une description détaillée. Grâce à l’interconnexion interne de la structure logicielle FWK des blocs d’interfaces, il est par exemple possible de reconfigurer la nomenclature en question en fonction des informations stockées dans le fichier de configuration.
En ce qui concerne le cas particulier de la date d’occurrence, un horodatage commun est utilisé par les micro-services du pipeline. Il peut s’agir de l’utilisation d’une horloge commune en utilisant un protocole tel qu’un protocole de temps réseau ou NTP pour Network Time Protocol en anglais, par exemple dans le cas où tous les micro-serveurs sont hébergé par un même serveur, l’horloge du serveur peut constituer l’horloge commune. Il peut également s’agir d’une pluralité d’horloges de différents serveurs lorsque les micro-services du pipeline sont hébergés par ces différents serveurs, l’important étant que ces différentes horloges soient synchronisées entre elles. Dans tous les cas, les dates d’occurrences des événements enregistrés sont immédiatement comparables les unes vis-à-vis des autres de manière à pourvoir reconstituer de manière immédiate l’ordre d’occurrence des événements distribués dans les fichiers journaux de chacun des micro-services.
L’intérêt de cette centralisation standardisée est de permettre une agrégation aisée des données enregistrées, permettant leur consolidation temporelle et événementielle de manière extrêmement simple, et leur traitement ultérieur par un analyseur de journal pour comprendre globalement l’activité d’un micro-service donné ou dans le cadre d’un passage à l’échelle de l’ensemble du pipeline de traitement de données DataPip.
Un quatrième bloc d’interface Strg.Intrf est configuré pour permettre la lecture et l’écriture de données dans ou vers un stockage permanent Strg de données tel qu’une base de donnée, par exemple afin de stocker les résultats de traitement de données par le cœur logique Lgc, sans que ce dernier ne prenne en charge les détails de l’écriture des données mais au contraire délègue cette tâche au quatrième bloc d’interface.
Un cinquième bloc d’interface Config.Intrf est configuré pour charger les configurations respectives du cœur logique et des quatre autres blocs d’interface mentionnés ci-dessus à partir d’un fichier de configuration Config, et transmettre à ses éléments leurs configurations respectives. Il peut s’agir par exemple de charger la configuration du journal, la version du micro-service, ou la configuration spécifique du cœur logique Lgc.
Chacun des blocs d’interface est configuré pour échanger des données (configuration, journal, données à stocker de manière permanente etc…) avec les autres blocs d’interface sans passer par le cœur logique.
Intégré au sein d’un pipeline de traitement de données, chaque micro-service MicServ est configuré pour échanger des données avec les autres micro-services du pipeline de traitement de données au moyen du bus de service d’entreprise ESB via les premiers blocs d’interface ASync chacun constitués d’une messagerie asynchrone. Ce mode de fonctionnement permet d’optimiser le fonctionnement du cœur logique Lgc en le laissant terminer, sans l’interrompre, les traitements en cours.
Dans le pipeline de traitement de données illustré par la , deux des cinq micro-services ont un rôle de supervision des autres micro-services.
L’un de ces deux micro-services constitue un registre : son cœur logique, indiqué comme Reg dans la , est configuré pour enregistrer dans sa mémoire Strg l’identité et la tâche unique associées à chacun des micro-services MicServ connectés au pipeline de traitement de données. Ce micro-service permet ainsi la découverte centralisée des services offerts par le pipeline : une application se connectant au pipeline consulterait en premier le registre pour savoir s'il existe une application particulière, telle qu’un classifieur permettant une prédiction binaire dans un domaine particulier ou toute autre fonction recherchée par l’application et potentiellement offerte par le pipeline.
L’autre de ces deux micro-services joue un rôle de surveillance, c’est-à-dire de chien de garde ou de watchdog en terminologie anglaise, des micro-services du pipeline de traitement de données : son cœur logique, indiqué comme WDog dans la , est configuré pour consulter le registre formé par le micro-service de cœur logique Reg, vérifier le statut de chacun des micro-services qui y sont enregistrés par exemple en lisant et copiant les derniers événements enregistrés dans leurs fichiers journaux respectifs, et mettre les derniers événements enregistrés ainsi récupérés à disposition d’une application extérieure à travers le bloc d’interface Sync. Toutes ces opération sont effectuées sans avoir besoin d’accéder aux cœurs logiques des micro-services surveillés, les blocs d’interface suffisant à cette tâche et déchargeant donc le cœur de celle-ci.
Le pipeline de traitement de données est configuré de sorte qu’un utilisateur Usr peut, via par exemple une interface, échanger des données avec le deuxième bloc d’interface Sync. Comme décrit plus haut, ce bloc est configuré de manière à minimiser les transmissions d’appels externes au cœur logique. Il permet cependant une bonne réactivité du système vis-à-vis de l’utilisateur.
Ici, le micro-service de cœur logique WDog sert d’intermédiaire entre le module de supervision SuperV contrôlé par l’utilisateur et les autres micro-services, jouant un rôle de concentrateur évitant au module de supervision d’avoir à interroger l’ensemble des autres micro-services.
La structure logicielle FWK peut être dupliquée de sorte que chaque micro-service en possède son propre exemplaire, ou bien peut être partagée par ces micro-services. Dans ce dernier cas, la maintenance du pipeline est facilitée en ce qu’une mise à jour de la structure logicielle s’applique implicitement à chacun des micro-services.
Une architecture logicielle telle que décrite ci-dessus, avec des blocs de base contenant un cœur logique Lgc encapsulé par structure logicielle FWK limitée à cinq blocs d’interface assurant les services essentiels de fonctionnement d’un service informatique, permet d’assurer une excellente compatibilité entre des micro-services chacun mis en œuvre au moyen de l’un de ces blocs de base. En effet, la limitation du type d’interfaces amène une limitation du type de données ou d’appels à gérer, et donc facilite l’intégration, la supervision, ou encore la maintenance d’un pipeline de données basé sur cette architecture logicielle.
Bien entendu l'invention n'est pas limitée au mode de mise en œuvre décrit et on peut y apporter des variantes de réalisation sans sortir du cadre de l'invention tel que défini par les revendications.
Claims (11)
- Pipeline de traitement de données, comprenant une pluralité de micro-services (MicServ) partageant une même structure et configurés pour échanger des données entre eux par l’intermédiaire d’un bus de service d’entreprise (ESB), dans lequel chaque micro-service est mis en œuvre au moyen d’un bloc de base (100) comprenant un cœur logique (Lgc) encapsulé par structure logicielle (FWK) limitée à cinq blocs d’interface chacun en communication avec le cœur logique (Lgc), dans lequel les cinq blocs d’interface sont :
- un premier bloc d’interface (ASync) comprenant une messagerie asynchrone ;
- un deuxième bloc d’interface (Sync) configuré pour permettre une communication bidirectionnelle directe de manière synchrone avec le bus de service d’entreprise (ESB) ;
- un troisième bloc d’interface (Journ.Intrf) configuré pour enregistrer dans un fichier journal (Journ) l’activité des cinq blocs d’interface et du cœur logique (Lgc) ;
- un quatrième bloc d’interface (Strg.Intrf) configuré pour permettre la lecture et l’écriture de données dans ou vers un stockage permanent (Strg) de données ;
- un cinquième bloc d’interface (Config.Intrf) est configuré pour charger la configuration du cœur logique et des quatre autres blocs d’interface mentionnés ci-dessus à partir d’un fichier de configuration (Config). - Pipeline de traitement de données selon la revendication 1, dans lequel chacun des blocs d’interface est configuré pour échanger des données avec les autres blocs d’interface.
- Pipeline de traitement de données selon l’une quelconque des revendications 1 à 2, dans lequel chacun des blocs d’interface est configuré pour échanger des données avec les autres blocs d’interface sans passer par le cœur logique.
- Pipeline de traitement de données selon l’une quelconque des revendications 1 à 3, dans lequel chaque micro-service (MicServ) est configuré pour échanger des données avec les autres micro-services du pipeline de données au moyen du bus de service d’entreprise (ESB) via les premiers blocs d’interface (ASync).
- Pipeline de traitement de données selon l’une quelconque des revendications 1 à 4, dans lequel chaque micro-service (MicServ) enregistre son activité interne dans le fichier journal selon un format standardisé commun à la pluralité de micro-services.
- Pipeline de traitement de données selon la revendication 5, dans lequel un enregistrement dans le fichier journal d’un événement d’une activité interne de chaque micro-service comprend au moins une date, une indication de criticité, une identification du micro-service concerné, une identification de l’événement, et une description de l’événement.
- Pipeline de traitement de données selon l’une quelconque des revendications 1 à 6, dans lequel chaque micro-service (MicServ) utilise un même horodatage pour enregistrer l’activité des cinq blocs d’interface et du cœur logique (Lgc) dans le fichier journal.
- Pipeline de traitement de données selon l’une quelconque des revendications 1 à 7, dans lequel la structure logicielle (FWK) est unique et partagée entre chacun des micro-services.
- Pipeline de traitement de données selon l’une quelconque des revendications 1 à 8, dans lequel le deuxième bloc d’interface est configuré pour diriger un appel externe vers l’un des quatre autres blocs d’interface ou vers le cœur logique, sur la base d’un identifiant du type d’appel porté par le message.
- Pipeline de traitement de données selon l’une quelconque des revendications 1 à 9, dans lequel un premier des micro-services comprend un cœur logique (Reg) configuré pour enregistrer une identité de chacun des micro-services (MicServ) connectés au pipeline (DataPip) de traitement de données.
- Pipeline de traitement de données selon la revendication 10, dans lequel un second des micro-services comprend un cœur logique (WDog) configuré pour consulter les identités de chacun des micro-services enregistrées par le cœur logique (Reg) du premier des micro-services.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2214244A FR3144351A1 (fr) | 2022-12-22 | 2022-12-22 | Infrastructure logicielle légère pour l’intégration de nœuds de décision dans un traitement automatisé de forage de données |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2214244A FR3144351A1 (fr) | 2022-12-22 | 2022-12-22 | Infrastructure logicielle légère pour l’intégration de nœuds de décision dans un traitement automatisé de forage de données |
| FR2214244 | 2022-12-22 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR3144351A1 true FR3144351A1 (fr) | 2024-06-28 |
Family
ID=86329324
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR2214244A Pending FR3144351A1 (fr) | 2022-12-22 | 2022-12-22 | Infrastructure logicielle légère pour l’intégration de nœuds de décision dans un traitement automatisé de forage de données |
Country Status (1)
| Country | Link |
|---|---|
| FR (1) | FR3144351A1 (fr) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20200327371A1 (en) * | 2019-04-09 | 2020-10-15 | FogHorn Systems, Inc. | Intelligent Edge Computing Platform with Machine Learning Capability |
| US20200396140A1 (en) * | 2019-06-17 | 2020-12-17 | Sap Se | Microservice Generation System |
-
2022
- 2022-12-22 FR FR2214244A patent/FR3144351A1/fr active Pending
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20200327371A1 (en) * | 2019-04-09 | 2020-10-15 | FogHorn Systems, Inc. | Intelligent Edge Computing Platform with Machine Learning Capability |
| US20200396140A1 (en) * | 2019-06-17 | 2020-12-17 | Sap Se | Microservice Generation System |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11809492B2 (en) | Online artificial intelligence algorithm for a data intake and query system | |
| US11113353B1 (en) | Visual programming for iterative message processing system | |
| US11194552B1 (en) | Assisted visual programming for iterative message processing system | |
| US10776355B1 (en) | Managing, storing, and caching query results and partial query results for combination with additional query results | |
| US11269939B1 (en) | Iterative message-based data processing including streaming analytics | |
| US11106734B1 (en) | Query execution using containerized state-free search nodes in a containerized scalable environment | |
| US11222066B1 (en) | Processing data using containerized state-free indexing nodes in a containerized scalable environment | |
| US10775976B1 (en) | Visual previews for programming an iterative publish-subscribe message processing system | |
| US11003714B1 (en) | Search node and bucket identification using a search node catalog and a data store catalog | |
| US11294941B1 (en) | Message-based data ingestion to a data intake and query system | |
| US10984044B1 (en) | Identifying buckets for query execution using a catalog of buckets stored in a remote shared storage system | |
| US11663176B2 (en) | Data field extraction model training for a data intake and query system | |
| US11636116B2 (en) | User interface for customizing data streams | |
| US9965330B2 (en) | Maintaining throughput of a stream processing framework while increasing processing load | |
| US20220036177A1 (en) | Data field extraction by a data intake and query system | |
| US11704490B2 (en) | Log sourcetype inference model training for a data intake and query system | |
| US11550847B1 (en) | Hashing bucket identifiers to identify search nodes for efficient query execution | |
| US20230134578A1 (en) | Search-time field extraction in a data intake and query system | |
| US8918517B2 (en) | Publish/subscribe mashups for social networks | |
| CN113678156A (zh) | 用于使用神经序列模型进行客户旅程事件表示学习和结果预测的系统和方法 | |
| US20130191185A1 (en) | System and method for conducting real-time and historical analysis of complex customer care processes | |
| US11620336B1 (en) | Managing and storing buckets to a remote shared storage system based on a collective bucket size | |
| US11663219B1 (en) | Determining a set of parameter values for a processing pipeline | |
| US11687487B1 (en) | Text files updates to an active processing pipeline | |
| US11809395B1 (en) | Load balancing, failover, and reliable delivery of data in a data intake and query system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20240628 |