FR2831691A1 - SYSTEM AND METHOD FOR MANAGING EVENT DATA FLOWS - Google Patents

Abstract

The invention concerns a system for managing data flow capable of receiving data concerning the course of a delivery. Said data are translated into a processing format of a decision engine. Each state of the course is identified in a list of predefined possible states, said list being subdivided into several sub-lists based on criteria predetermined by the client of the delivery. A set of predetermined rules is applied on certain sub-lists, and messages are broadcast to predefined recipients when certain rules are verified.

Description

<Desc / Clms Page number 1>

"System and method for managing event data flows"
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 scope since it can be applied to companies of any sector of activity and of all sizes which deal with complex operations generating data flows and requiring active or passive monitoring actions. We can notably cite the fields of service provision, monitoring of mass marketing actions, credit / collection, management of unpaid debts, etc.

 Companies are increasingly able to communicate internally and with their partners, customers, suppliers and third parties. However, in the flow of information, more and more voluminous, received and emitted by an entity it is difficult to process the data in a qualitative way, according to the nature of the message which they transport. In addition, the action of conveying relevant information in a relevant manner to a decision-maker or an implementer able to use it is often poorly controlled.

 The present invention aims to provide 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

<Desc / Clms Page number 2>

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. 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 actions

predetermined 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 this operating data fulfills conditions included in the configuration data and elaborates the predetermined actions if necessary, and an administration server to manage the configuration data, the communication between the administration server and the database server being a client-server communication .

 The database server can run a relational database management system (DBMS / R). The administration server can be a web application server.

 By 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: identification information, such as a code or a key making it possible to refer unequivocally to the service; for a delivery for example: the tracking number of the carrier or the delivery note number, and qualification information consisting of all the information enabling the service to be described; 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

<Desc / Clms Page number 3>

 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: - acquisition of operating data according to different communication modes (ftp ("File Transfer Protocol"), web, EDI ("Electronic Data Interchange "), e-mail, ...) - translation of the data received in a standard and predefined form which constitutes the interface of the decision engine, - making the data received available to the decision engine, and - triggering in the engine decision of a data integration process.

 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 ("Extensible Markup Language") described by standard or specific document type definitions (DTD).

 In general, the decision engine, active in the database server, contains business logic for interpreting the data received. According to an advantageous embodiment of the invention, this decision engine comprises means for: - listing all the possible states linked to a service, - grouping these possible states into several sub-groups

<Desc / Clms Page number 4>

 according to a subjective function, each subgroup symbolizing an event.

 Preferably, this grouping of events is defined according to criteria transmitted by the author of the service.

With such a system according to the invention, for a given service, all the possible states have been partitioned. Each state is contained in a given partition. Consequently, the system is configured to express the vision of the author of the service. States can therefore be grouped according to the will of the author.

 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 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

<Desc / Clms Page number 5>

 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 Condition Action) formalism defined for active data servers. In the sense of this formalism, which can notably be found in Active Database Systems: Triggers and Rules for Advanced Database Processing>>, by Jennifer Widom and Stefano Ceri, Edition Morgan Kaufmann 1996, ISBN 1-55860-304-2, in in the case of the system according to the invention, all the events are abstract and the coupling modes immediate.

The implementation of rules is semi-procedural. The 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 described 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; - "one" when it relates to the means of identification and qualification of the service and a given event (in particular the last activated) grouping together a set of possible states of the service; - "two" when it relates to the means of identification and qualification of the service and the set of events associated with the service; - "three" 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:

<Desc / Clms Page number 6>

 - inactive: no examination of conditions; - active: examination of conditions, recording of a history of the rule, creation of actions and dissemination of associated messages; - standby (or sleep): examination of conditions, recording of a history, but no creation of actions or dissemination of messages. This mode is useful for testing and statistical purposes.

For each rule, the services having checked the conditions are retained. The history of invocation of the rules allows global or statistical analyzes to be carried out on the quality of the service
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 typical message which can be enriched with data coming from the operating data or generated by the decision engine.

 In other words, 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.

 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 package for example, the message can be a standard sentence in which the delivery time is not predetermined contextual data.

 It is also possible to associate an attachment with a message, for example an electronic file for sending a message by e-mail.

 To avoid redundancy of messages, it is advantageous to prioritize the rules for a set of services. A message redundancy can for example occur

<Desc / Clms Page number 7>

 when several rules are invoked and verified for the same service and the same event.

 The decision engine behaves like a stand-alone module to which the input data is 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. Based on this file, a broadcasting module creates the messages and sends them. This broadcasting module can be integrated into the communication server.

According to a characteristic of the invention, 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 constructed according to the data corresponding to the service and the event observed.
SMS: sending the message on a mobile phone, to the number provided by the rule setting, according to the SMS (Short Message Service) protocol.

 - 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.

 - voice synthesis: 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 comprises 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

<Desc / Clms Page number 8>

 perform multi-criteria queries on the database.

 This administration server presents a set of interfaces such as for example an interface making it possible 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.

 According to another aspect of the invention, a method for managing data flows is proposed in order to develop a set of predetermined actions for monitoring a service in progress. According to the invention, this method comprises the following steps: - acquisition of operating data from at least one given source, - interpretation of the received operating data, - application of a set of rules on said data d 'operations, - elaboration of a message when a rule is respected, and - transmission of the message to a recipient.

 Preferably, the acquisition step involves the following steps: - acquisition of operating data according to different communication modes, and - conversion of said operating data into a predetermined standard format.

 As an example, the interpretation step can involve the following steps: - identification of the source and format of the operating data, - transfer to a database table adapted to the identified format, - determination of new benefits to be

<Desc / Clms Page number 9>

 initialized according to said operating data, in fact it is a question of distinguishing, among the data received, those which relate to services already known to the system from those which relate to new services, - determination of the already existing services for which the data received constitute a new state, - determination within the operating data of a possible state relating to said service, - translation of said possible state into a predefined possible state, - identification of the possible state thus translated within a event, an event being a subgroup made up of several possible states and obtained following a partition of all the predefined possible states, this partition being defined according to criteria transmitted by the author of said service.

 According to a preferred embodiment of the invention, the steps of applying the rules and developing a message involve the following steps: selection of the rules to be examined according to their state of activity and the source of the operating data; extraction, from the operating data, of additional information relating to said service and of the event comprising the state identified as a function of a set of conditions making up the rules; creation of messages based on standard sentences and contextual data; recording of the history of the invoked rules, extraction of the broadcasting methods for the recipients of the messages; and - creation of a message file.

 Other features and advantages of the invention will appear in the description below. At drawings

<Desc / Clms Page number 10>

attached given as nonlimiting examples:
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.

 Although the invention is not limited thereto, a description will now be given of a data flow management system according to the invention applied to a delivery service.

 With reference to FIG. 1, a distinction is made between an administration server 1, a communication server 2 and a database server 5. 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; - monitoring: statistics on the actions generated, reports, consultation of the database.

 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.

<Desc / Clms Page number 11>

 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 carried out 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 the routing of information messages to recipients 13, 14 and 15, according to different communication modes such as for example: electronic messages, mini-messages in mobile telephony, file transfers by wide area network or Internet (FTP), or EDI, voice synthesis (reading of the message after establishment of a telephone call).

 In the case in point, 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 performing. The system according to the invention receives this information via the acquisition module 3 which translates it into an internal format. The decision engine 6 in turn 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 provided, that is to say 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 package 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.

<Desc / Clms Page number 12>

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 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. Advantageously, 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. For the transporter 9, 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. Thus the course event "includes the following states: collected; agency entry; sorted; and updated.

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

<Desc / Clms Page number 13>

 following possible: address error; and absent recipient. This division is specifically carried out for the transporter 9. By way of example, 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.

 Profile of the transporter 9: reimbursement (damage, misappropriated), correction (address error, recipient absent), normal (collected, agency entry, sorted, delivered).

 Another possible business profile: disaster (damage, misappropriated), problem (address error, recipient absent), delivered (delivered), in progress (collected, sorted, agency entry).

 These two profiles reflect two different ways of monitoring the service provided by the transporter 9, but they both belong to the same customer. Each profile is considered to be specific to a given transporter because the starting set (the statutes) of the grouping function is defined by the data provided by the transporter. In other words, another carrier will provide a priori a set of different statuses.

 Thus, the database 8 contains the business profile 20 represented in FIG. 3 for the transporter 9. When the file 16 arrives at the database server 5, the decision engine 6 sorts all the data, extracts the "misused" status, identifies this status with a predefined internal status in the assembly 19 and detects in the business profile 20 the event comprising this status, ie the "disaster" event.

 By the way, when the status received by the base server

<Desc / Clms Page number 14>

 5 has been identified, the decision engine 6 launches a rules manager which has the role of applying a set of predetermined rules on the events of the business profile.

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 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. FIG. 4 illustrates such a rule defining the conditions to be applied and the actions to be carried out 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 contextual data will be added 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. Thus, the message described in pane 24 will be sent if, when examining the "lost package" rule, the business profile of the service concerned includes an active loss 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.

 Consequently, 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

<Desc / CRUD Page number 15>

 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 the sub-window 26. In general, the recipient of messages is the sender, but other entities can be designated as recipients.

 In practice, 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.

 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 data sets: 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

<Desc / Clms Page number 16>

 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"). The module responsible for broadcasting preferably supports the ftp and MAPI ("Message Application Programming Interface") protocol, and access to TAPI ("Telephony Application Programming Interface") telephone interfacing tools.

 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.

 Of course, the invention is not limited to the examples which have just been described and numerous modifications can be made to these examples without departing from the scope of the invention.

Claims (16)

 CLAIMS 1. Data flow management system in order to develop a set of predetermined actions for monitoring a service, comprising at least: - a communication server to receive and format operating data from '' at least one given source, and to broadcast the predetermined actions to given recipients, a database server for storing configuration data and operating data, and for running a decision engine which interprets the data operation, checks whether this operating data meets the conditions included in the configuration data and develops the predetermined actions if necessary, and an administration server to manage the configuration data, the communication between the administration server and the database server being client-server communication. 2. System according to claim 1, characterized in that for each service, the decision engine comprises means for: - listing all the possible states linked to a service, - grouping these possible states into several sub-groups according to a surjective function, each sub-group symbolizing an event, and in that this grouping of events is defined according to criteria transmitted by the author of said service. 3. System according to one of claims 1 or 2, characterized in that each operating data item includes at least information on a possible state of the service and means of identifying and qualifying the service, these means of containing an identifier in the form of <Desc / Clms Page number 18>  service identification code, and a description of the service. 4. System according to claim 3, characterized in that the conditions included in the configuration data are combined in the form of rules applicable on the means of identification and qualification of the service and on the absence of information on a state possible of the service 5. System according to claim 3, characterized in that the conditions included in the configuration data are combined in the form of rules applicable on the means of identification and qualification of the service and on a given event grouping together a set of states possible of the service 6. System according to claim 3, characterized in that the conditions included in the configuration data are combined in the form of rules applicable on the means of identification and qualification of the service and on the set of events associated with said provision. 7. System according to claim 3, characterized in that the conditions included in the configuration data are combined in the form of rules applicable on the means of identification and qualification of a plurality of services and on the set of events of the plurality of services. 8. System according to any one of claims 4 to 7, characterized in that the rules include means for determining an action according to said conditions and for specifying a channel for broadcasting a message to a given recipient. 9. System according to claim 8, characterized in that the broadcasting channel comprises a mini message via a telephone <Desc / Clms Page number 19>  portable. 10. System according to claim 8 or 9, characterized in that the broadcasting channel comprises an electronic message via an Internet type communication network.  11. System according to any one of claims 8 to 10, characterized in that the broadcasting channel comprises a voice message. 12. System according to any one of claims 4 to 11, characterized in that it comprises means for making a rule active, inactive or putting it on standby. 13. Data flow management method with a view to developing a set of predetermined actions for monitoring a service in progress, comprising the following steps: - acquisition of operational data from at least one source data, via a communication mode, - interpretation of received farm data, - application of a set of rules on said farm data, - creation of a message when a rule is observed, and transmission of the message to a recipient, in particular by electronic or telephone. 14. Method according to claim 13, characterized in that the acquisition step involves the following steps: - acquisition of operating data according to different communication modes, and - conversion of said operating data into a predetermined standard format . 15. Method according to one of claims 13 or 14, characterized in that the interpretation step involves the following steps: - identification of the source and format of the data <Desc / Clms Page number 20>  - transfer to a database table adapted to the identified format, - determination of new services to be initialized according to said operating data, determination of already existing services for which the data received constitute a new state, determination within the operating data of a possible state relating to said service, translation of said possible state into a predefined possible state, identification of the possible state thus translated within an event, an event being a composed subgroup of several possible states and obtained following a partition of all of the predefined possible states, this partition being defined according to criteria transmitted by the author of said service. 16. The method as claimed in claim 15, characterized in that the steps of applying the rules and developing a message involve the following steps: selection of the rules to be examined according to their state of activity and the source of the data operating; extraction, from the operating data, of additional information relating to said service and of the event comprising the state identified as a function of a set of conditions making up the rules; - creation of messages based on standard sentences and contextual data; recording of the history of the invoked rules, - extraction of the broadcasting methods for the recipients of the messages; and creation of a message file.