WO2003036532A1 - Systeme et procede de gestion de flux de donnees evenementielles - Google Patents

Systeme et procede de gestion de flux de donnees evenementielles Download PDF

Info

Publication number
WO2003036532A1
WO2003036532A1 PCT/FR2002/003687 FR0203687W WO03036532A1 WO 2003036532 A1 WO2003036532 A1 WO 2003036532A1 FR 0203687 W FR0203687 W FR 0203687W WO 03036532 A1 WO03036532 A1 WO 03036532A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
data
rules
operating data
event
Prior art date
Application number
PCT/FR2002/003687
Other languages
English (en)
Inventor
Marc Gillot
Jean-Claude Fitere
Eric Ly-Ky
Original Assignee
Ivent Sas
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Ivent Sas filed Critical Ivent Sas
Publication of WO2003036532A1 publication Critical patent/WO2003036532A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/107—Computer-aided management of electronic mailing [e-mailing]

Definitions

  • the present invention relates to a system and method for managing data flows in order to develop a set of predetermined actions for monitoring a service in progress. It finds a particularly interesting application in the logistics of transport and delivery of objects. However, the invention is of a broader framework since it can be applied to companies of any activity sector and of all sizes which deal with complex operations generating data flows and requiring active or passive monitoring actions. We can cite in particular the areas of service provision, monitoring of mass marketing actions, credit / collection, management of arrears, etc.
  • the present invention aims to propose a new tool capable of providing any user with the means to operate a systematic, automatic and personalized analysis of information flows.
  • the invention also aims to extract relevant information in order to deduce and generate communication actions towards predetermined recipients by means of various communication media.
  • the above objectives are achieved with a data flow management system in order to develop a set of predetermined actions for monitoring a service. according to the invention, this system comprises at least:
  • a communication server for receiving and formatting operating data from at least one data source, and for broadcasting the predetermined actions to given recipients
  • a database server for storing configuration data and the operating data, and for executing a decision engine which interprets the operating data, checks whether these operating data meet the conditions included in the data of configure and develop predetermined actions if necessary, and
  • the database server can run a relational database management system (DBMS / R).
  • the administration server can be a web application server.
  • service is meant the subject of the monitoring carried out by the system according to the invention.
  • the service is initiated, that is to say created in an initial state, then the various states representing the stages of its realization are acquired by the system according to the invention.
  • a service is characterized by means of identification and qualification comprising:
  • identifying information such as a code or a key making it possible to refer unequivocally to the service
  • for a delivery for example: the carrier tracking number or delivery note number, and qualification information consisting of all the information used to describe the service
  • for a delivery for example: the name of the recipient, the weight of the package, the date of shipment, etc.
  • a status represents a state of the service during the time.
  • the statutes are transmitted by the author of the service.
  • the communication server therefore has the primary role of acquiring operating data. These operating data are all the information provided by the author of the service, i.e. all or part of the means of identification and qualification of the service, as well as the status of this service.
  • the communication server ensures the integration of status data as they arrive.
  • the main functions of the communication server, in its acquisition mode, are therefore the following:
  • the management server includes software means integrating several acquisition standards in order to be able to interpret statuses expressed according to different standards.
  • An acquisition standard represents the formalism used to read the articles of association from the author of the service. We can mainly cite EDI standards or XML standards
  • the decision engine active in the database server, contains business logic for interpreting the data received.
  • this decision engine comprises means for: - listing all the possible states linked to a service,
  • Each operating data item may include at least information on a possible state of the service, that is to say its status, and on means of identifying and qualifying the service (identification information and information of qualification).
  • the role of the decision engine is notably to extract from operating data the status of the service in progress, normalize this status by identifying it with a predefined internal status, and determine which sub-group or event predefined by the partition this status belongs. Once the event has been identified, we consider the rules that may apply to this event, then we check whether the conditions of each rule considered are met.
  • the invention is remarkable in that the arrangement of several events facilitates the application of the rules on these events. Indeed, the decision engine is not obliged to explore all of the possible states to check the rules, it is directed to predefined subgroups corresponding to criteria specific to each author of the service, this representing a gain in clarity for the user. The grouping into events represents the author's vision on the management of the service.
  • the internal statutes are a set of statutes understandable by all the standards managed by the decision engine. In order to be handled and managed in a uniform manner, the statutes received according to a standard are translated into internal statutes. Each status in a standard corresponds to a internal status.
  • Statutes belonging to different standards can be associated with the same internal statute, if the situation they represent is similar.
  • the decision engine includes a rule manager which can operate according to an ECA ("Event
  • rules relate to conditions applied to the means of identification and qualification of the service and to events.
  • the conditions can be of various forms, depending on the typology of the data.
  • Conditions relating to separate data can be combined by means of logical operators "AND" and OR.
  • a rule can be qualified as level:
  • zero when it relates to the means of identification and qualification of the service and the absence of information on a possible state (or status) of the service; the "zero" level rules allow the absence of information to be interpreted as a decision element;
  • a rule when it carries the means of identifying and qualifying a plurality of services and on the set of events of the plurality of services.
  • a rule can be activated in several modes: - inactive: no examination of conditions;
  • the actions associated with the rules are actions for disseminating information, to a recipient and according to a medium determined in the rule.
  • the message sent is a standard message which can be enriched with data coming from operational data or generated by the decision engine.
  • an action consists of creating a message describing the situation to allow the recipient to interpret it and act accordingly.
  • the message sent is a standard sentence to which contextual data can be added, originating from the service and the status at the origin of the event that triggered the application of the rule.
  • the contextual data is referenced in the message by the description of the data fields to extract to build the message, that is to say when the service is the delivery of a parcel for example, the message can be a standard sentence in which the delivery time is not predetermined contextual data.
  • an attachment with a message, for example an electronic file for sending a message by e-mail.
  • Message redundancy can for example occur when several rules are invoked and verified for the same service and the same event.
  • the decision engine behaves like an autonomous module to which the input data are presented (status files), and which outputs a file of the actions to be executed.
  • the format of the input file must correspond to a standard managed by the system.
  • the format of the output file includes the type of action, the channel to be used, the recipient details on the channel in question, the text of the message to send, and a link to a possible attachment.
  • a broadcasting module creates the messages and sends them. This broadcasting module can be integrated into the communication server.
  • the broadcasting module manages at least the following communication modes: - e-mail: sending a message to the electronic mail address provided by the configuration of the rule.
  • the content is built according to the data corresponding to the service and the event observed.
  • SMS Short Message Service
  • - file transfer sending a file to a resource identified by its URL.
  • the resource can be local (LAN), remote (ftp) or accessible by EDI. In the latter case, the message is posted in an EDI station sending mailbox.
  • a telephone call is established with the number provided by the rule setting, and the message is read to the recipient by a voice synthesis utility.
  • the entire system according to the invention is manageable by means of the administration server which includes means for configuring a user, the nature and format of the data processed, rules and conditions, and associated actions.
  • This administration server also includes means for monitoring statistics on the actions generated, reports, and the visualization of the data. We can for example perform multi-criteria queries on the database.
  • This administration server presents a set of interfaces such as for example an interface allowing to carry out multi-criteria queries on the database.
  • the user specifies the search conditions, the data to be extracted and the mode of transmission of the results (display on the screen or recording in a file). Queries can be saved for later use. Saved queries can use dynamic parameters or results of functions executed when the query is launched.
  • a method of managing data flows is proposed in order to develop a set of predetermined actions for monitoring a service in progress.
  • this method comprises the following stages:
  • the acquisition step involves the following steps:
  • the interpretation step can involve the following steps:
  • an event being a subgroup made up of several possible states and obtained following a partition of the set of predefined possible states, this partition being defined according to criteria transmitted by the author of said service.
  • the steps of applying the rules and of developing a message involve the following steps:
  • Figure 1 is a block diagram of the arrangement of the elements of the system according to the invention.
  • FIG. 2 illustrates a set of data included in a file transmitted to the acquisition module of the system according to the invention.
  • Figure 3 is a schematic view illustrating two different groupings in business profile from a set of possible states.
  • Figure 4 is a view of an interface window illustrating the definition of a rule.
  • This administration server is the entry point for a user managing the system according to the invention. It has two main functions: - configuration of the system according to the invention: configuration of authorizations for several users, types and formats of data processed, definition of rules (conditions and actions) and configuration of business profiles;
  • the communications server 2 mainly comprises two modules.
  • a first acquisition module 3 capable of receiving messages or files from various sources 9, 10 and 11, of formatting them so as to be suitably transmitted to the database server and accepted by the latter.
  • This acquisition module 3 makes it possible to acquire data according to different modes of communication such as: FTP, WEB, EDI, E-MAIL, or other means of exchanging information, in pulled or pushed mode.
  • the data processed by the acquisition module 3 is then collected by the decision engine 6 of the database server 5. All the data thus collected is then stored in a database. data 7, it then constitutes the operational data.
  • the database server 5 also includes data for the configuration of rules and events. Rules and events are data allowing the decision engine 6 to integrate and interpret the operational data 7.
  • the processing performed by the decision engine 6 on the operational data 7 and the configuration data 8 results in a file transmitted to a broadcasting module 4 present in the communication server 2.
  • This broadcasting module 4 is responsible for routing information messages to recipients 13, 14 and 15, according to different modes of communication such as for example: electronic messages, mini-messages from mobile telephony, file transfers by wide area network or Internet (FTP), or EDI, voice synthesis (reading of the message after establishment of a telephone communication).
  • the transporter 9 responsible for delivering a package to a recipient, transmits event-specific information on the status or the current state of a delivery service that it is in the process of performing.
  • the system receives this information via the acquisition module 3 which translates it into an internal format.
  • the decision engine 6 receives this formatted information, extracts the status of the service in order to identify it within a predetermined event.
  • FIG. 2 shows a set 16 of the information transmitted to the acquisition module 3.
  • This set 16 comprises two parts.
  • a first part 17 entitled “header” includes information on the type of service performed, ie a delivery.
  • the header 17 also includes identification information such as a "sender code” corresponding to a delivery number in the sender management system, a “carrier code” corresponding to a parcel number in the delivery system traceability of the transporter 9 and a "recipient code” corresponding to an order number in the recipient's management system.
  • the header 17 also includes qualifying information describing the service provided. This qualifying information includes the date of shipment of the package, the recipient's contact details, the level of service desired, for example priority, the weight of the package transported.
  • the main information transmitted by the carrier 9 is the status 18.
  • This status represents the state in the course of delivery and it includes the information "misused", that is to say that the package is lost.
  • the file 16 after being correctly formatted by the acquisition module 13, and received by the decision engine 6.
  • This engine will then identify this status with a predetermined internal status and classified in an event.
  • Figure 3 defines what the events are. In 19, we distinguish all the possible states for this delivery service. These states are previously introduced into the database 8 in consultation with the transporter 9.
  • the system according to the invention can also involve not only the transporter 9 but also the sender of the package as well as the recipient. These actors can intervene both at the source level to transmit information and at the recipient level to whom messages developed by the system according to the invention are transmitted.
  • the invention is remarkable by the fact that, from all the possible states of the service, a business profile 20 representing a partition of the following is drawn up according to the criteria established in consultation with the sender of the package and the carrier.
  • this set of possible states 19 19.
  • his business profile 20 includes four events: "in progress”, “delivered”, “incident”, and "problem". These possible states are in fact predefined internal statuses. Each possible state is stored in an event. There cannot be two events of the same business profile with the same possible state.
  • the "in progress” event includes the following states: collected; agency entrance; sorted; and update.
  • the "delivered” event only includes the possible state: delivered.
  • the "disaster” event includes the following possible states: damage; rogue.
  • the "problem” event includes the states following possible: address error; and absent recipient. This division is specifically carried out for the transporter 9.
  • another professional profile can be such as that shown at 21. This professional profile includes 3 events.
  • a "reimbursement” event comprising the following states: damage, and misuse.
  • a "correction” event comprising the following states: address error, and recipient absent.
  • a "normal” event comprising the following states: collected, agency entry, sorted, updated, and delivered.
  • the database 8 contains the business profile 20 shown in FIG. 3 for the transporter 9.
  • the decision engine 6 sorts all the data, extracts the "misused” status, identifies this status to a predefined internal status in the assembly 19 and detects in the business profile 20 the event comprising this status, ie the "disaster" event.
  • a rule is a set of predefined conditions that can be applied to one or more events in order to generate a predetermined action.
  • a rule therefore includes the conditions to be applied to all the information relating to the service and the corresponding events, the associated action if the conditions are verified, as well as the recipient of the action.
  • Figure 4 illustrates such a rule defining the conditions to be applied and the actions to be taken when a package is lost. This rule is therefore called a lost package.
  • the interfacing window 22 is a window which can be displayed by a display means associated with the administration server 1.
  • This window 22 includes a first sub-window 23 describing the type of rule and its operating mode.
  • the "lost package” rule is in an active operating mode.
  • the sub-window 24 corresponds to the action to be carried out, that is to say the sending of a message.
  • This message is a standard sentence to which will be added contextual data such as the carrier code number, the shipping date, the name and country of the recipient, coming from the service, the event or a function calculation when reviewing the rule.
  • the sub-window 25 comprises the combination of the conditions to be applied.
  • the message described in pane 24 will be sent if, on examining the "lost package” rule, the business profile of the service concerned includes an active claim event or a non-active delivery event combined with a delay greater than 15 days. An event is active when it has a status just received.
  • the pane 26 indicates all the recipients of the message.
  • this decision engine 6 when the decision engine 6 detects on receipt of a file transmitted by the transporter 9 for the delivery service, a "misused” status, this decision engine 6 activates the "disaster” event included in the profile profession 20 of transporter 9, and also launches the examination of the "lost package” rule. Examination of the "lost package” rule shows that the first condition is satisfied, that is to say that the "disaster” event is active. The decision engine 6 then inserts into a file the message described in the sub-window 24 as well as the recipients and the means of communication specified in the sub-window 26. This information is then transmitted to the broadcasting module 24 which prepares a message 12 to be transmitted to the recipients specified in pane 26. Generally, the recipient of the messages is the sender, but other entities can be designated as the recipient.
  • the system according to the invention can either be directly installed on the site of a user author of the service, or arranged on a remote site managed by a third-party user.
  • the installation on site particularly concerns companies wishing to use the system according to the invention while mastering the technical resources of the system.
  • the architecture of this type of installation includes three main elements: a database server, an administration server and a communication server.
  • the database server provides physical management of the two sets of data: configuration data (configuration of messages, users, rules, profiles, etc.) and operational data (content of service and status records).
  • the database server is also responsible for executing the functions of the decision engine. It can then be materialized by a machine executing a relational database management system.
  • the administration server hosts a website of a system administration application according to the invention.
  • the website communicates with the database server according to a client-server model.
  • the web application can be installed on a corporate intranet server or on another network server equipped with a web application server.
  • the communication server ensures on the one hand the reception of incoming status messages, and on the other hand the broadcasting actions to predefined recipients.
  • the reception module preferably has access to the Internet, to a value added network (VAN "Value added network” in English), for example of the Atlas 400 type for EDI ("Electronic Data Interchange") and to an ftp server ("File Transfer Protocol”).
  • VAN Value added network
  • EDI Electronic Data Interchange
  • ftp server File Transfer Protocol
  • the module responsible for broadcasting preferably supports the ftp protocol and MAPI ("Message Application Programming Interface"), and access to TAPI ("Telephony Application Programming Interface”) telephone interfacing tools.
  • MAPI Message Application Programming Interface
  • TAPI Telephony Application Programming Interface
  • the off-site installation of the user author of the service consists of installing the technical elements thus described at a third party.
  • the system then constitutes a hosted application which users can access via the Internet.

Abstract

La présente invention concerne un système de gestion de flux de données capable de recevoir des informations relatives à l'etat de déroulement d'une prestation. Ces informations sont traduites dans un format de traitement d'un moteur de décision. Chaque état de déroulement est identifié au sein d'un liste prédéfinie d'états possibles, cette liste étant subdivisée en plusieurs sous listes en fonction de critères prédéfinis par le client de la prestation. Un ensembe de règles prédéfinies est appliqué sur certains sous listes, et des messages sont diffusés vers des destinataires prédéfinis lorsque certaines règles sont vérifiées.

Description

" Système et procédé de gestion de flux de données événementielles "
La présente invention est relative à un système et un procédé de gestion de flux de données en vue d'élaborer un ensemble d'actions prédéterminées pour le suivi d'une prestation en cours . Elle trouve une application particulièrement intéressante dans le domaine logistique de transport et de livraison d'objets. Mais l'invention est d'un cadre plus large puisqu'elle peut s'appliquer aux entreprises de tout secteur d'activité et de toutes tailles qui traitent des opérations complexes générant des flux de données et nécessitant des actions de suivi actif ou passif. On peut notamment citer les domaines de réalisation de prestations de service, du suivi d'actions en marketing de masse, du crédit/recouvrement, de gestion des impayés, etc.
Les entreprises disposent de plus en plus de moyens pour communiquer en interne et avec leurs partenaires, clients, fournisseurs, tiers. Cependant, dans le flot d'informations, de plus en plus volumineux, reçues et émises par une entité il est difficile de traiter les données de manière qualitative, en fonction de la nature du message qu'elles transportent. De plus, l'action d'acheminer de manière pertinente une information qualifiée à un décideur ou à un exécutant à même de l'exploiter est souvent mal maîtrisée.
La présente invention a pour but de proposer un nouvel outil apte à fournir à tout utilisateur les moyens d'opérer une analyse systématique, automatique et personnalisée de flux d'information.
L'invention a aussi pour but d'extraire de l'information pertinente afin d'en déduire et générer des actions de communication vers des destinataires prédéterminés au moyen de divers média de communication. On atteint les objectifs précités avec un système de gestion de flux de données en vue d'élaborer un ensemble d'actions prédéterminées pour le suivi d'une prestation. Selon l'invention, ce système comprend au moins :
- un serveur de communication pour recevoir et formater des données d'exploitation en provenance d'au moins une source de données, et pour diffuser les actions prédéterminées vers des destinataires donnés,
- un serveur de base de données pour stocker des données de configuration et les données d'exploitation, et pour exécuter un moteur de décision qui interprète les données d'exploitation, vérifie si ces données d'exploitation remplissent des conditions comprises dans les données de configuration et élabore les actions prédéterminées le cas échéant, et
- un serveur d'administration pour gérer les données de configuration, la communication entre le serveur d'administration et le serveur de base de données étant une communication client-serveur. Le serveur de base de données peut exécuter un système de gestion de bases de données relationnelles (SGBD/R) . Le serveur d'administration peut être un serveur d'applications web. Par prestation, on entend l'objet du suivi réalisé par le système selon l'invention. La prestation est initiée, c'est-à- dire créée dans un état initial, puis les différents états représentant les étapes de sa réalisation sont acquis par le système selon l'invention. Une prestation est caractérisée par des moyens d'identification et de qualification comprenant :
- des informations d'identification, telles un code ou une clé permettant de faire référence de manière univoque à la prestation; pour une livraison par exemple : le numéro de pistage (tracking) transporteur ou le numéro de bon de livraison, et des informations de qualification constituées par l'ensemble des informations permettant de décrire la prestation; pour une livraison par exemple : le nom du destinataire, le poids du colis, la date d'expédition, etc.
Un statut représente un état de la prestation au cours du temps. Les statuts sont transmis par l'auteur de la prestation.
Le serveur de communication a donc un premier rôle d'acquisition des données d'exploitation. Ces données d'exploitation sont l'ensemble des informations fournies par l'auteur de la prestation, c'est-à-dire tout ou partie des moyens d'identification et de qualification de la prestation, ainsi que le statut de cette prestation. Le serveur de communication assure l'intégration des données de statuts au fur et à mesure de leur arrivée. Les principales fonctions du serveur de communication, dans son mode d'acquisition, sont donc les suivantes :
- acquisition des données d'exploitation selon différents modes de communication (ftp ("File Transfer Protocol"), web, EDI ("Electronic Data Interchange"), e-mail,...) - traduction des données reçues sous une forme standard et prédéfinie qui constitue l'interface du moteur de décision,
- mise des données reçues à disposition du moteur de décision, et - déclenchement dans le moteur de décision d'un processus d'intégration de données.
Le serveur de gestion comprend des moyens logiciels intégrant plusieurs normes d'acquisition pour pouvoir interpréter des statuts exprimés selon différentes normes. Une norme d'acquisition représente le formalisme utilisé pour lire les statuts en provenance de l'auteur de la prestation. On peut principalement citer les normes EDI ou les standards XML
("Extensible Markup Language") décrits par des définitions de types de documents (DTD) standards ou spécifiques. D'une façon générale, le moteur de décision, actif dans le serveur de base de données, contient une logique métier d'interprétation des données reçues. Selon un mode de mise en œuvre avantageux de l'invention, ce moteur de décision comprend des moyens pour : - répertorier l'ensemble des états possibles liés à une prestation,
- regrouper ces états possibles en plusieurs sous-groupes selon une fonction surjective, chaque sous-groupe symbolisant un événement. De préférence, ce regroupement en événements est défini en fonction de critères transmis par l'auteur de la prestation. Avec un tel système selon l'invention, pour une prestation donnée, on a partitionné l'ensemble des états possibles. Chaque état est contenu dans une partition donnée. Par conséquent, le système est configuré de façon à exprimer la vision de l'auteur de la prestation. Les états peuvent donc être regroupés selon la volonté de l'auteur.
Chaque donnée d'exploitation peut comprendre au moins une information sur un état possible de la prestation, c'est-à-dire son statut, et sur des moyens d'identification et de qualification de la prestation (information d'identification et information de qualification) .
Le moteur de décision a notamment pour rôle d'extraire des données d'exploitation le statut de la prestation en cours, normaliser ce statut en l'identifiant à un statut interne prédéfini, et déterminer à quel sous-groupe ou événement prédéfini par la partition ce statut appartient. Une fois l'événement identifié, on considère les règles susceptibles de s'appliquer sur cet événement, puis on vérifie si les conditions de chaque règle considérée sont respectées. L'invention est remarquable par le fait que la disposition en plusieurs événements facilite 1 ' application des règles sur ces événements . En effet le moteur de décision n'est pas obligé d'explorer l'ensemble des états possibles pour vérifier les règles, il est aiguillé vers des sous-groupes prédéfinis correspondant à des critères spécifiques à chaque auteur de prestation, ceci représentant un gain de clarté pour l'utilisateur. Le regroupement en événement représente la vision de l'auteur sur la gestion de la prestation.
Les statuts internes sont un ensemble de statuts compréhensibles par l'ensemble des normes gérées par le moteur de décision. Afin d'être manipulés et gérés de manière uniforme, les statuts reçus en fonction d'une norme sont traduits en statuts internes. A chaque statut dans une norme, correspond un statut interne. Des statuts appartenant à des normes différentes peuvent être associés à un même statut interne, si la situation qu'ils représentent est similaire.
Le moteur de décision comprend un gestionnaire de règles qui peut fonctionner selon un formalisme de type ECA ("Event
Condition Action", en langue anglaise) défini pour des serveurs de données actifs. Au sens de ce formalisme, que l'on peut notamment retrouver dans « Active Database Systems : Triggers and Rules for Advanced Database Processing », de Jennifer Widom et Stefano Ceri, Edition Morgan Kaufmann 1996, ISBN 1-55860-304-
2, dans le cas du système selon l'invention, tous les événements sont abstraits et les modes de couplage immédiats .
L ' implémentation de règles est semi-procédurale. Les règles portent sur des conditions appliquées aux moyens d'identification et de qualification de la prestation et aux événements. Les conditions peuvent être de formes diverses, en fonction de la typologie des données. Des conditions portant sur des données distinctes peuvent être combinées au moyen d'opérateurs logiques "ET" et OU". Une règle peut être qualifiée de niveau :
"zéro" lorsqu'elle porte sur les moyens d'identification et de qualification de la prestation et sur l'absence d'information sur un état possible (ou statut) de la prestation ; les règles de niveau "zéro" permettent d'interpréter l'absence d'information comme étant un élément de décision ;
"un" lorsqu'elle porte sur les moyens d'identification et de qualification de la prestation et sur un événement donné (notamment le dernier activé) regroupant un ensemble d'états possibles de la prestation ;
"deux" lorsqu'elle porte sur les moyens d'identification et de qualification de la prestation et sur l'ensemble d'événements associés à la prestation ;
"trois" lorsqu'elle porte les moyens d'identification et de qualification d'une pluralité de prestations et sur l'ensemble d'événements de la pluralité de prestations. Une règle peut être activée selon plusieurs modes : — inactive: pas d'examen des conditions ;
- active : examen des conditions, enregistrement d'un historique de la règle, création des actions et diffusion des messages associés; - veille (ou sommeil) : examen des conditions, enregistrement d'un historique, mais pas de création des actions ni diffusion de messages. Ce mode est utile pour des tests et à des fins statistiques.
Pour chaque règle, les prestations ayant vérifié les conditions sont conservées. L'historique d'invocation des règles permet d'effectuer des analyses globales ou statistiques sur la qualité de la prestation
Les actions associées aux règles sont des actions de diffusion d'information, vers un destinataire et selon un média déterminé dans la règle. Le message envoyé est un message type qui peut être enrichi de données provenant des données d'exploitation ou générées par le moteur de décision.
En d'autres termes, une action consiste en la création d'un message décrivant la situation pour permettre au destinataire de l'interpréter et d'agir en conséquence. Le message envoyé est une phrase-type à laquelle peuvent s'ajouter des données contextuelles, provenant de la prestation et du statut à l'origine de l'événement ayant déclenché l'application de la règle . Les données contextuelles sont référencées dans le message par la description des champs de données à extraire pour construire le message, c'est-à-dire lorsque la prestation est la livraison d'un colis par exemple, le message peut être une phrase type dans laquelle l'heure de livraison est une donnée contextuelle non prédéterminée.
Il est de plus possible d'associer une pièce jointe à un message, par exemple un fichier électronique pour un envoi de message par e-mail.
Pour éviter la redondance de messages, on peut avantageusement hiérarchiser les règles pour un ensemble de prestations. Une redondance de message peut par exemple subvenir lorsque plusieurs règles sont invoquées et vérifiées pour la même prestation et le même événement.
Le moteur de décision se comporte comme un module autonome à qui on présente les données d'entrée (fichiers de statuts), et qui délivre en sortie un fichier des actions à exécuter. Le format du fichier d'entrée doit correspondre à une norme gérée par le système. Le format du fichier de sortie comprend le type d'action, le canal à utiliser, les coordonnées destinataire sur le canal en question, le texte du message à envoyer, et un lien sur une éventuelle pièce jointe. En fonction de ce fichier, un module de diffusion crée les messages et les envoie. Ce module de diffusion peut être intégré dans le serveur de communication.
Selon une caractéristique de l'invention, le module de diffusion gère au moins les modes de communication suivants : - e-mail : envoi d'un message à l'adresse de messagerie électronique fournie par le paramétrage de la règle. Le contenu est construit en fonction des données correspondant à la prestation et à l'événement constaté.
- SMS : envoi du message sur un téléphone mobile, au numéro fourni par le paramétrage de la règle, selon le protocole SMS (Short Message Service) .
- transfert de fichier : envoi d'un fichier sur une ressource identifiée par son URL. La ressource peut être locale (LAN), distante (ftp) ou accessible par EDI. Dans ce dernier cas, le message est posté dans une boîte aux lettres d'envoi de station EDI.
- synthèse vocale : une communication téléphonique est établie avec le numéro fourni par le paramétrage de la règle, et le message est lu au destinataire par un utilitaire de synthèse vocale.
L'ensemble du système selon l'invention est gérable au moyen du serveur d'administration qui comprend des moyens de paramétrage d'un utilisateur, de la nature et format des données traitées, des règles et conditions, et des actions associées. Ce serveur d'administration comprend également des moyens de suivi des statistiques sur les actions générées, des rapports, et de la visualisation des données. On peut ainsi par exemple effectuer des requêtes multicritères sur la base de données.
Ce serveur d'administration présente un ensemble d'interfaces telles que par exemple une interface permettant de réaliser des requêtes multicritères sur la base de données. L'utilisateur spécifie des conditions de recherche, les données à extraire et le mode de transmission des résultats (affichage à l'écran ou enregistrement dans un fichier). Les requêtes peuvent être enregistrées pour une utilisation ultérieure. Les requêtes enregistrées peuvent utiliser des paramètres dynamiques ou résultats de fonctions exécutées lors du lancement de la requête .
Suivant un autre aspect de l'invention, il est proposé un procédé de gestion de flux de données en vue d'élaborer un ensemble d'actions prédéterminées pour le suivi d'une prestation en cours. Selon l'invention, ce procédé comprend les étapes suivantes :
- acquisition de données d'exploitation en provenance d'au moins une source donnée,
- interprétation des données d'exploitations reçues, - application d'un ensemble de règles sur lesdites données d'exploitations,
- élaboration d'un message lorsqu'une règle est respectée, et
- transmission du message vers un destinataire. De préférence, l'étape d'acquisition fait intervenir les étapes suivantes :
- acquisition de données d'exploitation selon différents modes de communication, et
- conversion desdites données d'exploitation sous un format standard prédéterminé.
A titre d'exemple, l'étape d'interprétation peut faire intervenir les étapes suivantes :
- identification de la source et du format des données d ' exploitation, - transfert dans une table de base de données adaptée au format identifié,
- détermination de nouvelles prestations devant être initialisées en fonction desdites données d'exploitation, en fait il s'agit de distinguer, parmi les données reçues, celles qui concernent des prestations déjà connues du système de celles qui concernent de nouvelles prestations,
- détermination des prestations déjà existantes pour lesquelles les données reçues constituent un nouvel état,
- détermination au sein des données d'exploitation d'un état possible relatif à ladite prestation,
- traduction dudit état possible en un état possible prédéfini,
- identification de l'état possible ainsi traduit au sein d'un événement, un événement étant un sous-groupe composé de plusieurs états possibles et obtenu à la suite d'une partition de l'ensemble des états possibles prédéfinis, cette partition étant définie en fonction de critères transmis par l'auteur de ladite prestation.
Selon un mode de mise en œuvre préféré de l'invention, les étapes d'application des règles et d'élaboration de message font intervenir les étapes suivantes :
- sélection des règles à examiner en fonction de leur état d'activité et de la source des données d'exploitation;
- extraction, à partir des données d'exploitation, d'informations supplémentaires relatives à ladite prestation et de l'événement comprenant l'état identifié en fonction d'un ensemble de conditions composant les règles ;
- création de messages en fonction de phrases-types et de données contextuelles ;
- enregistrement de l'historique des règles invoquées,
- extraction des modes de diffusion pour les destinataires des messages ; et
- constitution d'un fichier de messages.
D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après. Aux dessins annexés donnés à titre d'exemples non limitatifs :
La figure 1 est une vue synoptique de la disposition des éléments du système selon l'invention.
La figure 2 illustre un ensemble de données comprises dans un fichier transmises vers le module d'acquisition du système selon l'invention.
La figure 3 est une vue schématique illustrant deux regroupements différents en profil métier à partir d'un ensemble d'états possibles. La figure 4 est une vue d'une fenêtre d'interfaçage illustrant la définition d'une règle.
Bien que l'invention n'y soit pas limitée, on va maintenant décrire un système de gestion de flux de données selon l'invention appliqué à une prestation de livraison. En référence à la figure 1, on distingue un serveur 1 d'administration, un serveur de communication 2 et un serveur de base de données 5. Ce serveur d'administration est le point d'entrée pour un utilisateur gérant le système selon l'invention. Il présente deux fonctions principales : - paramétrage du système selon l'invention: paramétrages des autorisations pour plusieurs utilisateurs, natures et formats des données traitées, définitions des règles (conditions et actions) et paramétrage des profils métier ;
- suivi: statistiques sur les actions générées, rapports, consultations des données de la base.
Le serveur de communications 2 comprend principalement deux modules. Un premier module d'acquisition 3 capable de réceptionner des messages ou fichiers provenant de diverses sources 9,10 et 11, de les formater de façon à être convenablement transmis vers le serveur de base de données et acceptés par ce dernier. Ce module d'acquisition 3 permet d'acquérir des données selon différents modes de communication tels que: FTP, WEB, EDI, E-MAIL, ou autres moyens d'échanges d'informations, en mode tiré ou poussé. Les données traitées par le module d'acquisition 3 sont ensuite recueillies par le moteur de décision 6 du serveur de base de données 5. L'ensemble des données ainsi recueillies est ensuite stocké dans une base de données 7, elle constitue alors les données opérationnelles. Le serveur de base de données 5 comprend également des données pour le paramétrage des règles et des événements . Les règles et les événements sont des données permettant au moteur de décision 6 d'intégrer et d'interpréter les données opérationnelles 7. Le traitement effectué par le moteur de décision 6 sur les données opérationnelles 7 et les données de paramétrage 8 résulte en un fichier transmis vers un module de diffusion 4 présent dans le serveur de communication 2. Ce module de diffusion 4 est chargé de l'acheminement des messages d'informations vers des destinataires 13, 14 et 15, selon différents modes de communication tels que par exemple: messages électroniques, mini-messages de téléphonie mobile, transferts de fichiers par réseau local étendu ou Internet (FTP), ou EDI, synthèse vocale (lecture du message après établissement d'une communication téléphonique) .
Dans le cas d'espèce, le transporteur 9, chargé de livrer un colis à un destinataire, transmet de façon événementielle des informations sur le statut ou l'état en cours d'une prestation de livraison qu'il est en train de réaliser. Le système selon l'invention réceptionne ces informations via le module d'acquisition 3 qui les traduit dans un format interne. Le moteur de décision 6 réceptionne à son tour ces informations formatées, extrait le statut de la prestation afin de l'identifier au sein d'un événement prédéterminé.
Sur la figure 2 est représenté un ensemble 16 des informations transmises vers le module d'acquisition 3. Cet ensemble 16 comprend deux parties. Une première partie 17 intitulée "en-tête", comprend des informations sur le type de la prestation réalisée c'est à dire une livraison. L' en-tête 17 comprend également des informations d'identification telles un "code expéditeur" correspondant à un numéro de livraison dans le système de gestion de l'expéditeur, un "code transporteur" correspondant à un numéro de colis dans le système de traçabilité du transporteur 9 et un "code destinataire" correspondant à un numéro de commande dans le système de gestion du destinataire. L' en-tête 17 comprend encore des informations qualifiantes décrivant la prestation réalisée. Ces informations qualifiantes comprennent la date d'expédition du colis, les coordonnées du destinataire, le niveau de service souhaité par exemple prioritaire, le poids du colis transporté. La principale information transmise par le transporteur 9 est le statut 18. Ce statut représente l'état en cours de la livraison et elle comprend l'information "dévoyé", c'est-à-dire que le colis est égaré. Le fichier 16, après être correctement formaté par le module d'acquisition 13, et réceptionné par le moteur de décision 6. Ce moteur va alors identifier ce statut à un statut interne prédéterminé et classé dans un événement. La figure 3 permet de définir ce que sont les événements. On distingue en 19 l'ensemble des états possibles pour cette prestation de livraison. Ces états sont préalablement introduits dans la base de données 8 en concertation avec le transporteur 9. Avantageusement, le système selon l'invention peut également faire intervenir non seulement le transporteur 9 mais également l'expéditeur du colis ainsi que le destinataire. Ces acteurs peuvent intervenir aussi bien au niveau de la source pour transmettre des informations qu'au niveau destinataire vers qui des messages élaborés par le système selon l'invention sont transmis. L'invention est remarquable par le fait qu'à partir de l'ensemble des états possibles de la prestation, on élabore en fonction des critères établis en concertation avec l'expéditeur du colis et le transporteur, un profil métier 20 représentant une partition de cet ensemble des états possibles 19. Pour le transporteur 9, son profil métier 20 comprend quatre événements: "en cours", "livré", "sinistre", et "problème". Ces états possibles sont en fait des statuts internes prédéfinis. Chaque état possible est rangé dans un événement. Il ne peut y avoir deux événements d'un même profil métier comportant un même état possible. Ainsi l'événement "en cours" comprend les états suivants: collecté ; entrée agence; trié ; et mise à jour. L'événement "livré" comporte uniquement l'état possible: livré. L'événement "sinistre" comprend les états possibles suivants: avarie; dévoyé. L'événement "problème" comporte les états possibles suivants: erreur adresse; et destinataire absent. Ce découpage est spécifiquement réalisé pour le transporteur 9. A titre d'exemple, un autre profil métier peut être tel que celui représenté en 21. Ce profil métier comprend 3 événements. Un événement "remboursement" comportant les états suivants: avarie, et dévoyé. Un événement "correction" comportant les états suivants: erreur adresse, et destinataire absent. Un événement "normal" comportant les états suivants: collecté, entrée agence, trié, mise à jour, et livré. Profil métier du transporteur 9:
« remboursement » (avarie, dévoyé) ,
« correction » (erreur adresse, destinataire absent) ,
« normal » (collecté, entrée agence, trié, livré) .
Un autre profil métier possible : « sinistre » (avarie, dévoyé) ,
« problème » (erreur adresse, destinataire absent) , « livré » (livré) ,
« en cours » (collecté, trié, entrée agence) .
Ces deux profils traduisent deux manières différentes de suivre la prestation réalisée par le transporteur 9, mais ils appartiennent tous deux au même client. Chaque profil est considéré comme spécifique à un transporteur donné car l'ensemble de départ (les statuts) de la fonction de regroupement est défini par les données fournies par le transporteur. En d'autres termes, un autre transporteur fournira a priori un ensemble de statuts différents.
Ainsi, la base de données 8 renferme le profil métier 20 représenté sur la figure 3 pour le transporteur 9. Lorsque le fichier 16 arrive dans le serveur de base de données 5, le moteur de décision 6 trie l'ensemble des données, extrait le statut "dévoyé", identifie ce statut à un statut interne prédéfini dans l'ensemble 19 et détecte dans le profil métier 20 l'événement comportant ce statut, c'est à dire l'événement "sinistre" .
Par ailleurs, lorsque le statut reçu par le serveur de base de données 5 a été identifié, le moteur de décision 6 lance un gestionnaire de règles qui a pour rôle d'appliquer un ensemble de règles prédéterminées sur les événements du profil métier. Une règle est un ensemble de conditions prédéfinies susceptibles d'être appliquées à un ou plusieurs événements de façon à générer une action prédéterminée. Une règle comprend donc les conditions à appliquer sur l'ensemble des informations relatives à la prestation et aux événements correspondants, l'action associée si les conditions sont vérifiées, ainsi que le destinataire de l'action. La figure 4 illustre une telle règle définissant les conditions à appliquer et les actions à mener lorsqu'un colis est perdu. Cette règle est donc intitulée colis perdu. La fenêtre d'interfaçage 22 est une fenêtre qui peut être visualisée par un moyen d'affichage associé au serveur d'administration 1. Cette fenêtre 22 comprend une première sous- fenêtre 23 décrivant le type de règle et son mode de fonctionnement. La règle "colis perdu" est dans un mode de fonctionnement actif. La sous-fenêtre 24 correspond à l'action à effectuer, c'est à dire l'envoi d'un message. Ce message est une phrase type à laquelle seront ajoutées des données contextuelles telles que le numéro de code transporteur, la date d'expédition, le nom et pays du destinataire, provenant de la prestation, de l'événement ou d'un calcul de fonction lors de l'examen de la règle. La sous-fenêtre 25 comprend la combinaison des conditions à appliquer. Ainsi le message décrit dans la sous-fenêtre 24 sera envoyé si à l'examen de la règle "colis perdu", le profil métier de la prestation concernée comprend un événement sinistre actif ou un événement livré non actif combiné à un délai supérieur à 15 jours. Un événement est actif lorsqu'il comporte un statut venant d'être reçu. La sous-fenêtre 26 indique l'ensemble des destinataires du message.
Par conséquent, lorsque le moteur de décision 6 détecte à la réception d'un fichier transmis par le transporteur 9 pour la prestation de livraison, un statut "dévoyé", ce moteur de décision 6 active l'événement "sinistre" compris dans le profil métier 20 du transporteur 9, et lance également l'examen de la règle "colis perdu". L'examen de la règle "colis perdu" montre que la première condition est vérifiée, c'est à dire que l'événement "sinistre" est actif. Le moteur de décision 6 insère alors dans un fichier le message décrit dans la sous-fenêtre 24 ainsi que les destinataires et les moyens de communication spécifiés dans la sous-fenêtre 26. Ces informations sont alors transmises vers le module de diffusion 24 qui prépare un message 12 à transmettre vers les destinataires spécifiés dans la sous- fenêtre 26. D'une façon générale, le destinataire des messages est l'expéditeur, mais d'autres entités peuvent être désignées comme destinataire.
Pratiquement, le système selon l'invention peut être soit directement implanté sur le site d'un utilisateur auteur de la prestation, soit disposé sur un site distant géré par un utilisateur tiers. L'installation sur site concerne particulièrement des entreprises désirant utiliser le système selon l'invention en maîtrisant les ressources techniques du système. L'architecture de ce type d'installation comprend trois éléments principaux : un serveur de base de données, un serveur d'administration et un serveur de communication.
Le serveur de base de données assure la gestion physique des deux ensembles de données : données de paramétrage (paramétrage des messages, utilisateurs, règles, profils, etc.) et données opérationnelles (contenu des enregistrements de prestations et statuts) . Le serveur de base de données est de plus en charge de l'exécution des fonctions du moteur de décision. Il peut alors être concrétisé par une machine exécutant un système de gestion de bases de données relationnelles . Le serveur d'administration héberge un site web d'une application d'administration du système selon l'invention. Le site web communique avec le serveur de base de données selon un modèle client-serveur. L'application web pourra être installée sur un serveur Intranet de l'entreprise ou sur un autre serveur réseau équipé d'un serveur d'applications Web.
Le serveur de communication assure d'une part la réception des messages de statuts entrants, et d'autre part la diffusion des actions vers des destinataires prédéfinis. Le module chargé de la réception possède de préférence un accès à Internet, à un réseau à valeur ajouté (VAN "Value added network" en langue anglaise) par exemple de type Atlas 400 pour l'EDI ("Electronic Data Interchange") et à un serveur ftp ("File Transfer Protocol") . Le module chargé de la diffusion supporte de préférence le protocole ftp et MAPI ("Message Application Programming Interface"), et l'accès à des outils d'interfaçage téléphonique TAPI ("Telephony Application Programming Interface") .
L'installation hors site de l'utilisateur auteur de la prestation, consiste à implanter les éléments techniques ainsi décrits chez un tiers. Le système constitue alors une application hébergée auquel les utilisateurs peuvent avoir accès via Internet.
Bien sûr, l'invention n'est pas limitée aux exemples qui viennent d'être décrits et de nombreux aménagements peuvent être apportés à ces exemples sans sortir du cadre de l'invention.

Claims

REVENDICATIONS
1. Système de gestion de flux de données en vue d'élaborer un ensemble d'actions prédéterminées pour le suivi d'une prestation, comprenant au moins :
- un serveur de communication pour recevoir et formater des données d'exploitation en provenance d'au moins une source donnée, et pour diffuser les actions prédéterminées vers des destinataires donnés, - un serveur de base de données pour stocker des données de configuration et les données d'exploitation, et pour exécuter un moteur de décision qui interprète les données d'exploitation, vérifie si ces données d'exploitation remplissent des conditions comprises dans les données de configuration et élabore les actions prédéterminées le cas échéant, et
- un serveur d'administration pour gérer les données de configuration, la communication entre le serveur d'administration et le serveur de base de données étant une communication client-serveur ; caractérisé en ce que le moteur de décision comprend des moyens pour déterminer, au sein des données d'exploitation, un état possible relatif à ladite prestation; des moyens pour traduire ledit état possible en un état possible prédéfini ; et des moyens pour identifier l'état possible ainsi traduit au sein d'un événement, un événement étant un sous-groupe composé de plusieurs états possibles.
2. Système selon la revendication 1, caractérisé en ce que pour chaque prestation et pour réaliser une partition de l'ensemble des états possibles, le moteur de décision comprend des moyens pour :
- répertorier l'ensemble des états possibles liés à une prestation, - regrouper ces états possibles en plusieurs sous-groupes selon une fonction surjective, chaque sous-groupe symbolisant un événement, et en ce que ce regroupement en événements est défini en fonction de critères transmis par l'auteur de ladite prestation.
3. Système selon l'une des revendications 1 ou 2, caractérisé en ce que chaque donnée d'exploitation comprend au moins une information sur un état possible de la prestation et des moyens d'identification et de qualification de la prestation, ces moyens d'identification contenant un identifiant sous forme de code d'identification de la prestation, et une description de la prestation.
4. Système selon la revendication 3, caractérisé en ce que les conditions comprises dans les données de configuration sont combinées sous forme de règles applicables sur les moyens d'identification et de qualification de la prestation et sur l'absence d'information sur un état possible de la prestation
5. Système selon la revendication 3, caractérisé en ce que les conditions comprises dans les données de configuration sont combinées sous forme de règles applicables sur les moyens d'identification et de qualification de la prestation et sur un événement donné regroupant un ensemble d'états possibles de la prestation
6. Système selon la revendication 3, caractérisé en ce que les conditions comprises dans les données de configuration sont combinées sous forme de règles applicables sur les moyens d'identification et de qualification de la prestation et sur l'ensemble d'événements associés à ladite prestation.
7. Système selon la revendication 3, caractérisé en ce que les conditions comprises dans les données de configuration sont combinées sous forme de règles applicables sur les moyens d'identification et de qualification d'une pluralité de prestations et sur l'ensemble d'événements de la pluralité de prestations .
8. Système selon l'une quelconque des revendications 4 à 7, caractérisé en ce que les règles comprennent des moyens pour déterminer une action en fonction desdites conditions et de spécifier un canal de diffusion d'un message vers un destinataire donné.
9. Système selon la revendication 8, caractérisé en ce que le canal de diffusion comprend un mini message via un téléphone portable.
10. Système selon la revendication 8 ou 9, caractérisé en ce que le canal de diffusion comprend un message électronique via un réseau de communication de type Internet.
11. Système selon l'une quelconque des revendications 8 à 10, caractérisé en ce que le canal de diffusion comprend un message vocal.
12. Système selon l'une quelconque des revendications 4 à 11, caractérisé en ce qu'il comprend des moyens pour rendre une règle active, inactive ou la mettre en veille.
13. Procédé de gestion de flux de données en vue d'élaborer un ensemble d'actions prédéterminées pour le suivi d'une prestation en cours, comprenant les étapes suivantes : acquisition de données d'exploitation en provenance d'au moins une source de données, via un mode de communication, interprétation des données d'exploitations reçues, - application d'un ensemble de règles sur lesdites données d'exploitations, en déterminant au sein des données d'exploitation un état possible relatif à ladite prestation, en traduisant ledit état possible en un état possible prédéfini, et en identifiant l'état possible ainsi traduit au sein d'un événement, un événement étant un sous-groupe composé de plusieurs états possibles, - élaboration d'un message lorsqu'une règle est respectée, et - transmission du message vers un destinataire notamment par voie électronique ou téléphonique.
14. Procédé selon la revendication 13, caractérisé en ce que l'étape d'acquisition fait intervenir les étapes suivantes :
- acquisition de données d'exploitation selon différents modes de communication, et conversion desdites données d'exploitation sous un format standard prédéterminé.
15. Procédé selon l'une des revendications 13 ou 14, caractérisé en ce que l'étape d'interprétation fait intervenir les étapes suivantes : identification de la source et du format des données d'exploitation, transfert dans une table de base de données adaptée au format identifié, détermination de nouvelles prestations devant être initialisées en fonction desdites données d'exploitation,
- détermination des prestations déjà existantes pour lesquelles les données reçues constituent un nouvel état, et en ce que chaque sous-groupe est obtenu à la suite d'une partition de l'ensemble des états possibles prédéfinis, cette partition étant définie en fonction de critères transmis par l'auteur de ladite prestation.
16. Procédé selon la revendication 15, caractérisé en ce que les étapes d'application des règles et d'élaboration de message font intervenir les étapes suivantes : sélection des règles à examiner en fonction de leur état d'activité et de la source des données d'exploitation ; extraction, à partir des données d'exploitation, d'informations supplémentaires relatives à ladite prestation et de l'événement comprenant l'état identifié en fonction d'un ensemble de conditions composant les règles ;
- création de messages en fonction de phrases-types et de données contextuelles ;
- enregistrement de l'historique des règles invoquées,
- extraction des modes de diffusion pour les destinataires des messages ; et
- constitution d'un fichier de messages.
PCT/FR2002/003687 2001-10-26 2002-10-25 Systeme et procede de gestion de flux de donnees evenementielles WO2003036532A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0113924A FR2831691A1 (fr) 2001-10-26 2001-10-26 Systeme et procede de gestion de flux de donnees evenementielles
FR01/13924 2001-10-26

Publications (1)

Publication Number Publication Date
WO2003036532A1 true WO2003036532A1 (fr) 2003-05-01

Family

ID=8868802

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2002/003687 WO2003036532A1 (fr) 2001-10-26 2002-10-25 Systeme et procede de gestion de flux de donnees evenementielles

Country Status (2)

Country Link
FR (1) FR2831691A1 (fr)
WO (1) WO2003036532A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0683466A2 (fr) * 1994-05-20 1995-11-22 Thomas & Betts Corporation Procédé et système électronique pour la commande et la surveillance d'informations concernant des transactions commerciales
US5627764A (en) * 1991-10-04 1997-05-06 Banyan Systems, Inc. Automatic electronic messaging system with feedback and work flow administration
US5826270A (en) * 1995-12-28 1998-10-20 Csg Systems, Inc. Methods and systems for client or customer-site transaction processing in a distributed database system
WO2001022335A2 (fr) * 1999-09-23 2001-03-29 Raymond Leonard G Traitement de notifications/avertissements a l'aide de plusieurs supports de communication
US6301609B1 (en) * 1999-07-07 2001-10-09 Lucent Technologies Inc. Assignable associate priorities for user-definable instant messaging buddy groups

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5555346A (en) * 1991-10-04 1996-09-10 Beyond Corporated Event-driven rule-based messaging system

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5627764A (en) * 1991-10-04 1997-05-06 Banyan Systems, Inc. Automatic electronic messaging system with feedback and work flow administration
EP0683466A2 (fr) * 1994-05-20 1995-11-22 Thomas & Betts Corporation Procédé et système électronique pour la commande et la surveillance d'informations concernant des transactions commerciales
US5826270A (en) * 1995-12-28 1998-10-20 Csg Systems, Inc. Methods and systems for client or customer-site transaction processing in a distributed database system
US6301609B1 (en) * 1999-07-07 2001-10-09 Lucent Technologies Inc. Assignable associate priorities for user-definable instant messaging buddy groups
WO2001022335A2 (fr) * 1999-09-23 2001-03-29 Raymond Leonard G Traitement de notifications/avertissements a l'aide de plusieurs supports de communication

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
MCCARTHY D., DAYAL U.: "The architecture of an active database management system", PROCEEDINGS OF THE 1989 ACM SIGMOD INTERNATIONAL CONFERENCE ON MANAGEMENT OF DATA. ACM PRESS, 1989, NY, USA, pages 215 - 224, XP002209329 *

Also Published As

Publication number Publication date
FR2831691A1 (fr) 2003-05-02

Similar Documents

Publication Publication Date Title
US10997531B2 (en) System, method and graphical user interface for workflow generation, deployment and/or execution
US7461039B1 (en) Canonical model to normalize disparate persistent data sources
US8707336B2 (en) Data event processing and application integration in a network
CA2688509C (fr) Systeme reparti destine a la surveillance d'evenements lies a des informations
US8140887B2 (en) System and method for providing data services via a network
US8316386B2 (en) Multiple application integration
US20100161616A1 (en) Systems and methods for coupling structured content with unstructured content
US20060168062A1 (en) Virtual calendar
US8028025B2 (en) Apparatus, system, and method for setting/retrieving header information dynamically into/from service data objects for protocol based technology adapters
JP4937944B2 (ja) ネットワーク化された商業的やり取りの管理方法
FR2882164A1 (fr) Procede et dispositif de transfert de donnees numeriques a format progressif
WO2005083620A2 (fr) Systeme et methodes de traitement de fichiers d'audit
EP2105002A2 (fr) Systeme et procede de traçabilite de contenus sur internet
WO2007044237A2 (fr) Systeme de communication entre applications a base de messages
US8090873B1 (en) Methods and systems for high throughput information refinement
WO2016138183A1 (fr) Système réparti de détection de blanchiment d'argent
US7383305B2 (en) Method, system, and storage medium for providing search and reference functions for a messaging system
US20090222414A1 (en) Methods and systems for providing additional information and data in cooperation with a communication application
US20090144236A1 (en) Methods and systems for classifying data based on entities related to the data
CN111162989A (zh) 邮件审计日志的处理方法及装置
WO2003036532A1 (fr) Systeme et procede de gestion de flux de donnees evenementielles
JP2004246901A (ja) ドキュメントコンテンツおよび配信設定を駆動するためのデータマッピングの使用
CN114240392A (zh) 信息处理方法、任务审批方法和信息处理装置
EP1676233A2 (fr) Procede d'enquete electronique
FR3110793A1 (fr) Procédé de gestion de la transmission d’un message depuis un premier dispositif à destination d’un deuxième dispositif, procédé de gestion de la réception d’un tel message.

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LU MC NL PT SE SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: CONSTATATION DE LA PERTE D UN DROIT CONFORMEMENT AE LA REGLE 69(1) CBE (NOTIFICATION DU 06-07-04, OEB FORM 1205A)

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP