PROCESSING DATA CHANGES OR DATA INSERT REQUESTS

Description

1. Domain

[0001] The invention relates to the optimization of code, resulting from a transactional query, within a database system managing a plurality of counting units. More particularly, the invention relates to the optimization of the execution of the initial transactional query, according to an optimization plan which takes into account values ​​contained in the database system, as a function of values ​​of fields associated with records in the database. 2. Prior Art

[0002] Computerized systems have changed many aspects of modern life. Computerized systems are increasingly used autonomously to perform management, harmonization, or distribution tasks. This is the case, for example, of computerized systems related to robotics, which can be called mechatronics. Such systems are, for example, able to make decisions about the execution of actions without user intervention, which are a function of the environment in which the mechatronic system is located.

[0003] Increasingly, decisions are left to the discretion of an automated processing processor, of the neural type, which will carry out the required actions based on previously learned situations. Thus, from an initial request coming from a server or a user, the automated processing processor will carry out the actions resulting from a decision, itself resulting from the passage of a certain number of input parameters into one or more neural networks.

[0004] This method of processing incoming data, particularly in mechatronics, but also in automation, is interesting in certain situations. For example, when the input parameters vary within known, listed, and previously learned amplitudes, systems based on machine learning can effectively be operational without requiring human intervention. On the other hand, when the input values ​​vary greatly, or even when new input values, corresponding to non-existent types, arise, artificial intelligences then require human assistance, which makes their use more complex or less interesting.US 2015 / 213071 A1 (ALVEY WALTER D [US] ET AL) July 30, 2015, describes a method and system for improving the performance of columnar databases by buffering row insertions: when a new row is inserted, it is split into tuplets corresponding to the column groups, which are copied into dedicated buffers. The actual insertion into the table is deferred until a trigger event (such as a full buffer) occurs, then triggering the flushing of the buffers to permanent storage.

[0005] There is therefore a need to make data processing, particularly for automatic processing systems, simpler to implement, by allowing greater scalability to the data than existing mechanisms. 3. Summary of the invention

[0006] The method proposed by the inventors does not pose these problems of the prior art. Indeed, a method for distributing and apportioning database updates based on a record identifier and an implementation of operational marking is proposed.

[0007] More particularly, a method for processing requests for inserting and / or modifying data is proposed, a method implemented by an electronic processing device, comprising a communication interface intended to receive said requests from a communication network.Such a method comprises a phase of distributing data, within a plurality of buffers, each buffer being associated with a record of a database, the association being carried out by means of a database record identifier present within the insertion and / or modification requests received, said data being inserted in the form of buffer records, comprising a value to be updated and / or inserted within the database; and a phase of distributing, from the buffers of said plurality of buffers, data within the records of the database, said distributing phase comprising, for the buffer records which comprise an operational marking, the execution from a configuration file, of a computer program specifically dedicated to said record and / or specifically dedicated to the data type of said value to be updated and / or inserted.

[0008] This makes it possible to process data insertion and / or update requests within a database more efficiently, by effectively dividing updates into shared operations.

[0009] According to a preferred implementation, the different steps of the methods according to the invention are implemented by one or more software or computer programs, comprising software instructions intended to be executed by a data processor of a relay module according to the invention and being designed to control the execution of the different steps of the methods.

[0010] Consequently, the invention also relates to a program, capable of being executed by a computer or by a data processor, this program comprising instructions for controlling the execution of the steps of a method as mentioned above.

[0011] This program may use any programming language, and may be in the form of source code, object code, or code intermediate between source code and object code, such as in a partially compiled form, or in any other desirable form.

[0012] The invention also relates to an information medium readable by a data processor, and comprising instructions of a program as mentioned above.

[0013] The information carrier may be any entity or device capable of storing the program. For example, the carrier may include a storage medium, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a mobile medium (memory card) or a hard disk.

[0014] On the other hand, the information carrier may be a transmissible carrier such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means. The program according to the invention may in particular be downloaded from a network such as the Internet.

[0015] Alternatively, the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to perform or to be used in the performance of the method in question.

[0016] According to one embodiment, the invention is implemented by means of software and / or hardware components. In this regard, the term "module" may correspond in this document to a software component, a hardware component or a set of hardware and software components.

[0017] A software component corresponds to one or more computer programs, one or more sub-programs of a program, or more generally to any element of a program or software capable of implementing a function or a set of functions, as described below for the module concerned. Such a software component is executed by a data processor of a physical entity (terminal, server, gateway, set-top-box, router, etc.) and is likely to access the hardware resources of this physical entity (memories, recording media, communication buses, electronic input / output cards, user interfaces, etc.).

[0018] Similarly, a hardware component is any element of a hardware assembly capable of implementing a function or set of functions, as described below for the module concerned. It may be a programmable hardware component or one with an integrated processor for running software, for example an integrated circuit, a smart card, a memory card, an electronic card for running firmware, etc.

[0019] Each component of the system described above of course implements its own software modules.

[0020] The different embodiments mentioned above can be combined with each other for the implementation of the invention which is defined by the attached independent claims. 4. Figures

[0021] Other characteristics and advantages of the invention will appear more clearly on reading the following description of a preferred embodiment, given as a simple illustrative and non-limiting example, and the appended drawings, among which: [ fig 1 ] there figure 1 describes the general principle of the invention; [ fig 2 ] there figure 2 describes the different stages of the process in an example of implementation; [ fig 3 ] there figure 3 briefly illustrates a device capable of implementing the system of the invention. 5. Detailed description 5.1. Description of an embodiment

[0022] As explained previously, an object of the invention is to allow optimization of the distribution of actions resulting from the reception of a request comprising an instruction to insert or update at least one data item representative of a quantity (for example a quantity of time, a quantity of water, a quantity of electricity, wood, etc.) as a function of data representative of the quantities existing in one or more depots or receptacles within a database. The database in question is not necessarily a relational database, and may, depending on the embodiments and operational implementations, take the form of flat files, registers of a RAM memory or fields in a flat file or indeed database record fields.To do this, two complementary techniques are implemented: on the one hand, a distribution technique, implemented by a distributor component, of the data received in the data insertion or update requests (called incoming requests), possibly associated with an operational marking and on the other hand, a technique for balancing the distribution of the quantity (to be inserted or updated) within a set of records likely to accommodate an insertion / update of said value and for applying the operational marking during the insertion / update. Once updated or inserted, the value is optionally consumed or counted, depending on the implementation methods and the operational implementation.

[0023] The system is briefly described in relation to the figure 1It comprises two main components: the distributor (Dsitrib.) and the dispatcher (Repart.). The distributor (Dsitrib.) receives, via a communication interface (iCom), a set of requests (RqO, ...RqZ) whose objects are the insertion and / or updating of records (Enr#1, Enr#2, ..., Enr#x) within a database. The distributor (Dsitrib.) extracts data (explained below) from these requests, and in particular a record identifier (IdEnr#1, IdEnr#2, ...IdEnr#x) making it possible to determine the record (Enr#1, Enr#2, ..., Enr#x) within which the insertion and / or update must be carried out. The distributor (Dsitrib.), from the data of the request being processed, creates a so-called buffer record (E1, E2, ..., Ex) associated with the record identifier (IdEnr#1, IdEnr#2, ...IdEnr#x), and inserts (E1, E2, ..., Ex) this buffer record into the buffer (Buff#1, Buff#2, ..., Buff#x) associated with the record identifier (IdEnr#1, IdEnr#2, ...IdEnr#x). There is one buffer per record identifier. A timestamp is optionally applied. An operational marking may also be present or dynamically performed when the buffer record (E1, E2, ..., Ex) is created. The dispatcher (Repart.) for its part, is in charge of the actual updating of the data in the database (BDD). It processes the buffer records (E1, E2, ..., Ex), according to a dynamic processing method (serial, parallel or mixed, as described below) and uses the operational marking of the buffer records (E1, E2, ..., Ex) to obtain, from a configuration file (Conf.), and execute a program (PA, PB, etc.) associated with the data type and / or the value of this data in the buffer record being processed. The programs (PA, PB, etc.) can be programs defined by configurators and / or users, to perform predefined functions associated with the record or type of value processed. These programs (PA, PB, etc.) may or may not modify the value (val) finally updated or inserted in the database records (Record#1, Record#2, ..., Record#x).

[0024] Thus a database record (DB) includes (at least) one value to be updated and each buffer (Buff#1, Buff#2, ..., Buff#x) is associated with the update (cumulative or programmatic) of at least one value, of at least one database record. As explained, the distributor distributes the insertions / updates in the buffers according to distribution criteria of the incoming requests and it creates buffer records. The dispatcher (Repart.) updates data in the database (DB). It processes the buffer records (E1, E2, ..., Ex) of each of the buffers, to update the database, either by accumulating the updates inserted in the buffers, or in another way, as explained later.

[0025] Thus, unlike prior art systems, it is not necessary to use artificial intelligence systems to be able to balance the updates of values ​​in various receptacles. The system is also scalable because it allows optimal load distribution in the update, for example by authorizing the accumulation of updates (when there is no operational marking) and the processing method implemented by the dispatcher (Repart.) can be adapted in real time, for example according to an estimated load level in the buffers, by a scheduler (not shown).

[0026] An incoming request, received by the processing device, includes a number of fields, including for example one or more of the following fields. The function of these fields is identified in the third column [Table 1] Incoming request ID <pmt0infid>< / pmt0infid> Internal identification code. Checksum <ctrl1sum0>< / ctrl1sum0> The system provides the total of each value. Instruction priority <pmt2tpinf>< / pmt2tpinf> Processing priority defined in processing options, allowing the distributor to mark such priority for the dispatcher. <instr3prty>< / instr3prty> Execution date <req4dext>< / req4dext> Timestamp for timestamped processing. If empty, timestamping is done by the distributor. Transmitter ID <ld5>< / ld5> Transmitter identification: allows you to know the original device Unit of value <c6cy>< / c6cy> Unit in which the value is expressed (e.g. liter, ampere, watt, force, momentum, cumulative, consumable or expendable unit) Value <val7>< / val7> Value: This is the quantity of unit Instruction Identification <instr8id>< / instr8id> The system generates a unique key for each request, including the record ID, submitter, execution date, and a verification control number (not listed). Database record ID <cdtr9acct>< / cdtr9acct> The system uses a database registration code. This is the identifier used for the buffer. Database ID <id10>< / id10> The system uses a basic identification number, when multiple databases are present. Object code <purp11>< / purp11> The system uses a request reason value defined in processing options to determine a possible reason code. If one of these fields is set, it constitutes the operational marking <cd12>< / cd12>

[0027] There figure 2 explains the two phases implemented: a data distribution phase (P10), within a plurality of buffers, each buffer being associated with a record of a database, the association being carried out by means of a database record identifier present within the insertion and / or modification requests received, said data being inserted in the form of buffer records, comprising a value to be updated and / or inserted within the database; in an exemplary embodiment the distribution phase (P10) comprises: A step of extraction (P10-1), from the current insertion and / or modification request, of a database record identifier; A step of search (P10-2), within the database, of a record corresponding to the previously extracted database record identifier, delivering a database record identifier buffer; When the search is negative, a creation step (P10-3), in memory, of a buffer associated with said record identifier; A creation step (P10-4) of a current buffer record, including the value to be inserted or updated within the database; and A step (P10-5) of inserting the record of buffer current previously created within the buffercorresponding to said buffer identifier. And a distribution phase (P20), from the buffers of said plurality of buffers, of data within the records of the database, said distribution phase comprising, for the buffer records which comprise an operational marking, the execution from a configuration file, of a computer program specifically dedicated to said record and / or specifically dedicated to the data type of said value to be updated and / or inserted; in an exemplary embodiment, the distribution phase (P20) comprises: a step of determining (P20-1) a processing to be executed relative to said value to be updated and / or inserted in said buffer record; this determination is carried out, for example, as a function of an operational marking (an indicator) present in the buffer record; and a step of executing (P20-2) said processing determined in the previous step;a step of updating (P20-3) said record within the database according to the value to be updated and / or inserted and according to the result of execution of said processing previously determined when such processing has been implemented and it has delivered a result in this sense.;

[0028] The advantage of proceeding in this way is that there is a synergistic effect between the distribution and the actual update. Indeed, as each buffer is associated with a record of a database, and the association is carried out by means of a database record identifier present within the insert and / or modification requests received, the distribution phase (for buffer records which include an operational marking for which the execution from a configuration file, of a computer program specifically dedicated to said record and / or specifically dedicated to the data type of said value to be updated and / or inserted) is facilitated and grouped within the same buffer: it is necessary and sufficient to accelerate the processing, within the same buffer,group the records that are free of operational marking to perform a cumulative update from these buffer records and if there are still records with operational marking, process these records subsequently, by performing the necessary operations (i.e. execution of a computer program). This optimizes the processing of buffers.,

[0029] Thus, in general, the technique of the invention comprises two complementary components. The first component consists of carrying out a distribution, by the distributor, of the data received from the incoming requests: this distribution essentially depends on the identification, or not, of a database record (and possibly of a database) likely to be associated with the incoming request. When a database record can be associated with an incoming request (for example because the incoming request includes an identifier of the database record), then so-called useful data of this incoming request are inserted, by the distributor, into a buffer associated with this database record.When no database record can be associated with an incoming query (e.g. because the incoming query identifier does not match - or the query does not include - a database record identifier), then a buffer associated with the query identifier is created by the distributor, and the payload data of the incoming query is then inserted into this buffer; the data inserted into the buffers is optionally timestamped (e.g. when such a timestamp does not already exist in the query).

[0030] An operational marking of the incoming request also makes it possible to categorize the value contained in the incoming request and which must be inserted or updated in the record. More specifically, this operational marking can be carried out upstream (i.e. at the time of the preparation of the request by the sender of the latter) or dynamically, according to the execution parameters associated with the data distribution process. Thus, for example, when a value, for a given type, is located in a predetermined value range, then the distribution process (the distributor) can carry out, by itself, the operational marking of this value.Thus, operational marking can be implemented dynamically or statically (static marking being present in the request upon receipt of the latter in the system, and resulting from a marking operation carried out prior to receipt of the request in the system, as indicated in the fields of the previous request). Dynamic marking includes a step of searching, within a configuration file (or a database), for possible default operational marking data to be inserted, for example depending on the type of value (integer, real, double precision, character string) and / or the value itself (for example if the value exceeds a certain ceiling, is between two predetermined values, is below a given threshold, etc.) and / or the unit of the value (Ampere, Watt, Liter, any accounting or accounting unit).It is used to enable the system to perform specific processing on the value contained in the record, possibly in connection with related records of the record for which the value is intended. In other words, according to the invention, operational marking is a means of forcing the execution of a value balancing operation, possibly by using the values ​​contained in related or dependent records of the record within which the value contained in the incoming query is to be inserted or updated. According to the invention, a related record is for example a record in the database that is linked to the current record. The link that exists between the related record and the current record can be of any nature: for example by a dependency relationship, an overflow relationship - iewhen a record is full, an ancestry relationship is dumped into another record - i.e. processing the related record as a priority before the current record.

[0031] Thus, as an example of dynamic marking, an incoming request includes a value v1 of electrical intensity (measured in Amperes) associated with a record X included in an electrical intensity configuration file of a device (this configuration file being the database). The data distributor identifies that the value relates to an electrical intensity value; it searches within a configuration file, if an operational marking rule relates to data of type electrical intensity. When at least one such rule is present, the data distributor performs a comparison of the electrical intensity value with the rule(s) in question and performs a dynamic operational marking if the result of one of these rules is positive. The data representing the marking is a function of the rule(s) in question. For example, the marking may be different depending on the value v1.For example, if v1 exceeds 2A, the marking can be of type #M1, while if the intensity value is between 1.5A and 2A, the marking can be of type #M2. Generally speaking, we note that the data distributor is not informed of the meaning of the marking that he performs. He only has a marking indication that he transcribes according to tests and reference values ​​present in a configuration base. In addition, the marking can be automatic, whatever the value, that is to say that the marking is not correlated to the implementation of a test on the value (marking linked for example to the type, the unit or any other consideration).

[0032] When the incoming request is already marked (i.e. the marking has been done by the sender of the incoming request), a specific field of the incoming request includes the operational marking indication, as explained previously. In this case, the distributor can check that the marking is correct, or do nothing and simply transcribe the marking done. The scheduler can be informed of this marking (in the form of a counter or a percentage of marked requests), for example for load management (balancing of the distribution done by the dispatcher) or to manage the scalability of the system.

[0033] Depending on the embodiments, the incoming request is inserted into a message, the message being received by the communication interface of the electronic device. A message may comprise several incoming requests, originating from the same sender. Each incoming request of the message may relate to different database records. A message typically comprises the following information: [Table 2] Message identification <msgld>< / msgld> Date and time of creation <credttm>< / credttm> Number of incoming requests <nboftxs>< / nboftxs> Checksum <ctrisum>< / ctrisum> Issuer ID <id>< / id>

[0034] What has just been described for an electrical intensity is also valid for other types of quantitative data, as described previously.

[0035] These buffers are then processed by another component, called a distributor, responsible in particular for the distribution and balancing of values, which constitutes the second part of the technique of the invention.

[0036] More specifically, the dispatcher (or dispatch component) is responsible for the effective updating of the database, from the record buffers previously valued and / or created by the distribution component (distributor). The operating mode of the dispatcher can be serial, parallel or mixed and can be dynamically modified according to the overall load of the system, measured by the scheduler (i.e. number of records waiting in the buffers, percentage of records with an operational marking, number of incoming requests on the dispatcher). The scheduler is therefore responsible for measuring the adaptation of the processing carried out to the conditions undergone or encountered by the system. In particular, it manages the operating mode of the dispatcher, and the operations carried out by the dispatcher.It is also able to manage the dynamic marking of incoming requests, if necessary, always with the aim of system stability.

[0037] The operating principle is as follows: for a given buffer, associated with a database record, the dispatcher executes the actions for updating the value or creating the record (and inserting the value into the created record).

[0038] So, for each buffer, the dispatcher performs the following operations: Optionally, a concatenation (sum) of all or part of the values ​​of the buffer, to obtain a final value; The final value can be positive, negative or equal to zero: the final value can be directly used to update the value of the record in the database, without performing the unit operations corresponding to each record of the buffer; for example, if the unit of value is “Watt”, liter, kilogram or any other unit of accounting or accumulation, and the final value is “ -50 ", it is possible to add this value directly to the record identified by the buffer; such an operation can be carried out for example only on buffer values ​​whose records do not include operational marking; This optional step is reserved for certain situations where such an update can be carried out without operational constraints; an iteration, comprising for each record of the buffer: a step of verifying the presence of an operational marker associated with said buffer record; and when an operational marker is present: a step of determining a processing to be executed relative to said value of said buffer record; and a step of executing said previously determined processing.

[0039] The processing to be executed is determined by searching within a configuration file for a specific processing associated with an operational marking identifier. This may be a dispatch processing performed from the value of the record in the buffer. For example, the operational marking references, within the configuration file, a computer program to be executed, taking as input the value of the buffer record. This computer program may be in the form of scripted code, pseudocode for a virtual machine or compiled code, adapted to be executed on the device that performs the processing. The computer program is predefined, by a user or by a configurator to perform a certain number of specific tasks depending mainly on the value of the buffer record.Such modularity makes it easy to perform new processing operations on incoming data without having to completely modify a processing chain. The processing operations that can be performed can be of any type. Primarily, these processes aim to balance or distribute "reservoirs", depending on the value of the record and possibly other information related to the incoming request. For example, when the incoming value relates to a number of steps to be performed on an actuator (of the stepper motor type), the processing may consist of verifying that the number of steps of the value does not exceed a predetermined number of steps and, if so, distributing the number of steps between the designated actuator and another actuator previously identified by another record in the database.This type of processing is useful in that it helps avoid capacity overflow issues that can be caused by receiving requests that are not necessarily ". adapted » to the capacities (hardware, software, or any other nature) of the receptacle. This provides a certain scalability to the system: it is possible to manage increases in load or changes in the scale of the values ​​received, and intended to be inserted or updated in the database by only modifying specific computer programs adapted to a given recording (and therefore to a given functionality).

[0040] In another configuration, the described technique allows to assign monetary values ​​to different accounting accounts in a simple and efficient manner, including at high frequency.

[0041] Another example, in the "logistics" field, is managing the capacity of a storage center. If the record relates to a volume of pallets to be stored in a first section of the storage center, the automated processing may consist of identifying a maximum capacity of this first section, then determining whether the value will result in this capacity being exceeded; and if so, identifying a second section of the storage center (i.e.a new database record of the same type), perform a difference between the original value and the maximum capacity of the first section, delivering a “differential value” and generate, in a buffer associated with the second section (a buffer associated with this database record), a new buffer record comprising this differential value and an operational marking (which is of the same type as that associated with the first section of the storage center) so that a similar processing can be carried out.

[0042] Generally speaking, the timestamp performed on newly added buffer records by a process executed by the dispatcher is identical to the timestamp of the initial buffer record. This ensures that all processing operations that are performed are executed in the order in which they were received. This ordering, which is preserved by the described technique, is important for two reasons: firstly, it ensures that the values ​​are updated in a consistent manner with respect to the reception of requests within the system; secondly, it ensures the progressiveness of the update and the implementation of the distribution processing associated with the different operational markings.

[0043] Generally speaking, three possibilities are offered for buffer processing, mainly depending on the operating system: serial, parallel or mixed.

[0044] A first possibility is to process the buffers one after the other. The buffers are then ordered (essentially, a scheduling parameter determines the order in which the buffers are processed). The dispatcher then takes as input the buffer whose processing is to be performed according to its order and manages the entire buffer, according to the mechanism described previously. When the processing of the current buffer is finished, the process moves on to the next buffer. As previously indicated, when the data is timestamped within the buffer, the records in the buffer are processed according to this timestamp. Optionally, when the date and / or time of the buffer record is greater than the current date and / or time, the record is not not processed. It will be processed when the current date and / or time is greater than or equal to the date and / or time of the buffer recording. This allows you to receive, in advance, additions or updates to be made without them being done immediately, and therefore to resolve certain problems linked to possible network congestion or possible transmission problems or anticipation of updates for example.

[0045] A second possibility is to process the buffer records one after the other, without taking into account the buffer to which they belong. The dispatcher then takes as input the buffer record with the oldest date and / or time and performs the update and / or addition associated with this buffer, possibly adding processing in the event of operational marking. In this case, all the buffers are processed in parallel, whereas in the first possibility, the buffers are processed serially. This second possibility is more real-time oriented and ensures concurrent updating of database records, particularly when the frequency of receiving update requests is high and many records are referenced.Conversely, serial processing of buffers ensures efficient record updating since the final state of a database record is known much more quickly, which is not the case with the second processing possibility which implies that the system reaches a stable state (corresponding to the processing of all the buffers and therefore all the records in the database) much later, the stable state of the system being obtained during the last round of processing of the buffer records.

[0046] Ultimately, the proposed technique ensures that value additions and updates are carried out simply and efficiently while ensuring a certain resistance to error and easy scaling. 5.2. Description of an example of implementation

[0047] In this exemplary embodiment, the application of the aforementioned technique to the updating of actuation or activation data within an electronic device (Delec), for example of the robotic type, is described. More particularly, in relation to the figure 2 , such a device comprises a processor (P), a memory (M) and at least one communication interface (Icom). The communication interface (Icom) is capable of receiving, from a communication network with which the electronic device (Delec) is connected, one or more requests for updates, insertion of data, via messages.

[0048] As explained above, a request is presented in the form of a message that includes a query data structure. The query data structure includes a predetermined number of fields, including a record identifier. At least one of these fields includes a value to be inserted or updated in a database managed within the electronic device (Delec). The database includes a certain number of records, each record including at least one field that can be updated or created based on values ​​from requests originating from one or more other devices, via the communication network.

[0049] Records are typed, as are the data to be updated, and records include an identifier field. For example, a record may relate to an actuator, and the value associated with that actuator may be binary (0: actuator not activated; 1: actuator activated). As yet another example, a record may relate to a light-emitting diode, and the value associated with that diode may be an integer between 0 and 256, each value representing a brightness of the diode: 0: diode off; 256: maximum illumination; 128: half-intensity illumination. In this example, too, records may relate to amounts of time and / or numbers of revolutions to be performed by a servo motor or numbers of revolutions (performed by a motor) to be controlled by a control probe.In this example, each field in the database relates to at least one element of the electronic device in question.

[0050] This database may in this exemplary embodiment take the form of a set of predetermined registers of the electronic device, each register being intended to participate in the control (activation, deactivation, modification of behavior) of one or more elements of the electronic device itself (or of another device to which the electronic device is connected). In any case, in this example, the method previously described is implemented to carry out on the one hand a reception of the insertion or update request, via a first process. This first process is implemented by the processor, in real time, using a computer process for receiving and distributing requests. This distribution process implements the distribution method (processing and allocation), as described previously. More particularly in this example, the process comprises, permanently (i.e.at least one iteration of the steps): . Monitoring of a reception, at the level of the communication interface (Icom), of the reception of a request to update / insert data, called an incoming request; and When a request is received on the communication interface (ICOm): Extraction, from said query, of a record identifier; Verification, within the database, of the presence of a record comprising said record identifier extracted from said query; When there is a record comprising the record identifier, insertion of the useful fields of the incoming query into a buffer associated with said record, optionally accompanied by a timestamp; When there is no record comprising the record identifier, creation of one associated with said record and insertion of the useful fields of the incoming query into this buffer, optionally accompanied by a timestamp.

[0051] The useful fields of the incoming request are of various natures. In this example implementation, however, the following fields are necessarily present: Origin of the incoming request, for example, identifier of an electronic device transmitting the incoming request or identifier of an entity that transmitted the incoming request; Value to be inserted / updated; Unit of the value to be inserted / updated; Identifier of the record in which the value is to be inserted / updated.

[0052] Optionally, the incoming request may also include an operational marking field, as described above. The operational marking field is a field that allows the value to be inserted / updated to be processed according to a specific procedure, several examples of which are explained below.

[0053] Thus, the communication interface (ICOm) is continuously monitored by the distribution process. When an incoming request is identified on the communication interface (ICOm), the distribution process is responsible for verifying the validity of the incoming request and assigning it to a destination buffer, possibly with a timestamp of the useful data of the request. The request itself can also be stored in another data receptacle, for example to be subject to subsequent analysis and processing. It should also be noted that the communication interface can be used to transmit and receive data other than incoming requests. This communication interface can in particular be used to transmit and / or receive diagnostic data for example, or even records of operations carried out.

[0054] Each destination buffer is continuously processed. More specifically, in this example implementation, the dispatcher process is also implemented in real time and continuously. Such an implementation is context-specific and could be different in other contexts. In any case, the dispatcher process, as described earlier, in this example processes the buffers in parallel, essentially based on the timestamp of the buffer records. This means that the buffer records are all processed at the same time, based on the date and / or time they have, as explained earlier.

[0055] What is described here in the context of an electronic movement management device can also be implemented in any other type of value allocation and / or updating system.

[0056] For each buffer record, the following process is performed: a step of verifying the presence of an operational marker associated with said buffer record; and when an operational marker is present: a step of determining a processing operation to be executed relative to said value of said buffer record; and a step of executing said processing operation determined in the previous step, said processing operation being in the form of executable machine code; a step of updating said record within the database as a function of the value to be inserted / updated and as a function of the result of executing said processing operation previously determined if such processing operation has been implemented and it has delivered a result in this sense; a step of consuming said value of said updated database record;

[0057] In the exemplary embodiment, the consumption of the value of the record consists of its use by the actuator or component with which the record is associated. For example, in the case of a number of steps of a stepper motor, the consumption consists of the implementation of the stepper motor for the number of steps corresponding to the value of the record. In the case of an electrical intensity value, the component targeted by the record consumes the value by adjusting the electrical intensity according to this value. In the case of a power, the power is adjusted to the indicated value. 5.3. Other features and benefits

[0058] The following characteristics are also specified. Insertion modification requests include one or more data to be inserted (or modified) in one or more fields of one or more records. The distributor distributes these updates / insertions according to the data and therefore creates buffers to be able to stack these insertions / updates. Thus, a request can contain one or more record identifiers. In the majority of cases, however, the request includes a record identifier. Furthermore, the distribution of data in the buffers is essentially guided by the identifier or record identifiers present in the request: when the identifier is already present in the database, the buffer, a priori, already exists and therefore this buffer is used; when the identifier is absent in the database, as indicated previously, a new buffer is created.Thus, an association is made by the identifier(s) present within the query. A buffer record is created for each identifier present in the query (if there are several) and the buffer record is inserted within this buffer, possibly with the addition of an operational marking (i.e. an indicator) which can correspond to a present marking or a marking dependent on the identifier of the record in the database. During the distribution, for each buffer, the buffer records can be processed in batches or individually, and when an operational marking is present, a verification or obtaining of a configuration file or directly of a program is carried out. The configuration file can include instructions (parameters) allowing the execution of a configurable program (i.e.the configuration file containing the parameters is loaded using the indicator and the configurable program uses this file to run). Either, the program itself performs the insertion / update in the database and distributes the data, or it performs other operations and the updated insertion in the database, within the database records, is performed subsequently. Whatever the method used, the updates / insertions are performed using the identifier of the record to which the record buffer relates.

[0059] We present, in relation to the figure 4, a simplified architecture of an electronic execution device capable of performing the processing and execution of code according to at least one of the methods described above. An electronic execution device comprises a memory 41 (and / or possibly secure and / or two separate memories, one secure and the other not), a processing unit 42 equipped for example with a microprocessor (and / or possibly secure and / or two separate processors, one secure and the other not), and controlled by the computer program 43, implementing all or part of the methods as previously described. In at least one embodiment, the invention is implemented at least partially in the form of a set of software and / or hardware components integrated into this device,which may be in the form of one or two servers connected to a communications network. This provides a device (or a system in the case of a plurality of servers) for processing data insertion and / or modification requests, a device comprising a processor, a memory and a communications interface intended to receive said requests from a communications network. This device comprises means for distributing data, within a plurality of buffers, in the memory of the device (or system), each buffer being associated with a record in a database, the association being carried out by means of a database record identifier present in the insertion and / or modification requests received, said data being inserted in the form of buffer records comprising a value to be updated and / or inserted into the database; and distribution means,from the buffers of said plurality of buffers, of data within the records of the database, these distribution means comprising, for the buffer records which include an operational marking, the means of execution from a configuration file, of a computer program specifically dedicated to said record and / or specifically dedicated to the type of data of said value to be updated and / or inserted within the database.,

[0060] For the execution of the functions assigned to it, the device also includes the means for implementing all of the steps previously mentioned, either in hardware form, when specific components are dedicated to these tasks, or in software form linked to one or more microprograms running on one or more processors of the execution device.

Claims

1. Method for processing data insertion and / or modification requests (RqO, ... RqZ), the method being implemented by an electronic processing device (DElec) comprising a communication interface (iCom) for receiving said requests (RqO, ... RqZ) from a communication network, the method being characterized in that it comprises a data distribution phase (P10), within a plurality of buffers (Buf#1, Buff#2, ..., Buf#x), each buffer (Buf#1, Buff#2, ...., Buf#x) being associated with a single record (Enr#1, Enr#2, ..., Enr#x) of a database (BDD), the association between each buffer (Buf#1, Buff#2, ..., Buf#x) and each record (Enr#1, Enr#2,..., Enr#x) being performed by via a record identifier (IdEnr#1, IdEnr#2, ...IdEnr#x) within the database (BDD), these record identifiers (IdEnr#1, IdEnr#2, ...IdEnr#x) being present within the received insertion and / or modification requests (RqO, ...RqZ), said data being inserted, from values contained in the insertion and / or modification requests (RqO, ...RqZ), into the plurality of buffers (Buf#1, Buff#2, ..., Buf#x), in the form of buffer records (E1, E2, ..., Ex), comprising a value (val) to be updated and / or inserted within the database (BDD); and a dispatching phase (P20), from the buffers (Buf#1, Buff#2, ..., Buf#x) of said plurality of buffers (Buf#1, Buff#2, ..., Buf#x), of data within the records (Enr#1, Enr#2, ..., Enr#x) of the database (BDD) with which these buffers (Buf#1, Buff#2, ..., Buf#x) are associated, said dispatching phase comprising, for the buffer records (E1, E2, ..., Ex) which comprise an operational marking defining a process to be performed, the execution from a configuration file, a computer program (PA, PB, etc.) specifically dedicated to said record and / or specifically dedicated to the data type of said value (val) to be updated and / or inserted.

2. Method according to claim 1, characterized in that said data distribution phase (P10) comprises, for a current insertion and / or modification request (RqO, ...RqZ) received by the communication interface (iCom): - A step of extracting (P10-1), from the current insertion and / or modification request (RqO, ...RqZ), a database record identifier (IdEnr#1 , IdEnr#2, ...IdEnr#x); - A step of searching (P10-2), within the database (BDD), for a record (Enr#1, Enr#2, ..., Enr#x) corresponding to the previously extracted database record identifier (IdEnr#1, IdEnr#2, ...IdEnr#x), delivering a buffer identifier; - When the search is negative, a step of creating (P10-3), in memory (M), a buffer (Buf#1, Buff#2, ..., Buf#x) associated with said record identifier (IdEnr#1, IdEnr#2, ...IdEnr#x); - A step of creating (P10-4) a current buffer record (E1, E2, ..., Ex), comprising the value (val) to be inserted or updated in the database (BDD); and - An step of inserting (P10-5) the previously created current buffer record (E1, E2, ..., Ex) previously created within the buffer (Buf#1, Buff#2, ..., Buf#x) corresponding to said buffer identifier.

3. Method according to claim 2, characterized in that said step of creating the buffer record (E1, E2, ..., Ex) comprises: - A step of searching, within the current insertion and / or modification request (RqO, ...RqZ), for a piece of data representative of an operational marking; - When a piece of data representative of an operational marking is found, a step of copying this data within a marker field of the current buffer record (E1, E2,..., Ex); - When a piece of data representative of an operational marking is not found, a step of searching, within a configuration file, for a possible default operational marking piece of data to be inserted; - When a piece of data representative of a default operational marking is found, a step of copying this piece of data within the marker field of the current buffer record (E1, E2, ..., Ex).

4. Method according to claim 2, characterized in that said step of creating the buffer record (E1, E2, ..., Ex) comprises: - A step of searching, within the current insertion and / or modification request (RqO, ...RqZ), for a piece of data data representative of time stamping; - When a piece of data representative of time stamping is found, a step of copying this piece of data into a date field of the current buffer record (E1, E2, ..., Ex); - When a piece of data data representing a time stamping is not found, a step of inserting a piece of data representative of the current date and / or time within the date field of the current buffer record (E1, E2, ..., Ex).

5. Method according to claim 1, characterized in that said dispatching phase (P20) comprises, for a current buffer record (E1, E2, ..., Ex) of a current buffer (Buf#1, Buff#2, ..., Buf#x) of the plurality of buffers (Buf#1, Buff#2, ..., Buf#x): - a step of determining (P20-1) processing to be executed with respect to said value (val) to be updated and / or inserted from said buffer record (E1, E2, ..., Ex); and - a step of executing (P20-2) said processing determined in the previous step; - a step of updating (P20-3) said record (Enr#1, Enr#2, ..., Enr#x) within the database (BDD) according to the value (val) to be updated and / or inserted and according to the result of execution of said processing previously determined when such processing has been implemented and has delivered a result accordingly;6. Processing method according to claim 5, characterized in that the step of executing said processing comprises: - a step of determining, within the database (BDD), a record related to said record (Enr#1, Enr#2, ..., Enr#x) identified by the record identifier (IdEnr#1, IdEnr#2, ...IdEnr#x) of the database (BDD), within which a calculated part of the value (val) to be updated and / or inserted may be inserted and / or updated; - a step of creating, within a buffer (Buf#1, Buff#2, ..., Buf#x) associated with said related database record, a buffer record (E1, E2, Ex), based on the current buffer record (E1, E2, ..., Ex), and comprising said calculated part of the value (val) to be updated and / or inserted.

7. Processing method according to claim 1, characterized in that said dispatching phase is implemented in series, so that all records (E1, E2, Ex) of a current buffer (Buf#1, Buff#2, ..., Buf#x) are processed before processing the records (E1, E2, ..., Ex) of the next buffer (Buf#1, Buff#2, ..., Buf#x).

8. Processing method according to claim 1, characterized in that the said dispatching phase is implemented in parallel, so that the records (E1, E2, Ex) of all the buffers (Buf#1, Buff#2, ..., Buf#x) are processed according to a time stamping piece of data associated with each buffer record (E1, E2, ..., Ex), by processing first the record (E1, E2, ..., Ex) whose date and / or time is the oldest with respect to the date and / or time of all buffer records (E1, E2, ..., Ex) of all buffers (Buf#1, Buff#2, ..., Buf#x).

9. Device (DElec) for processing data insertion and / or modification requests (RqO, ...RqZ), the device (DElec) comprising a processor (P), a memory (M) and a communication interface (iCom) for receiving said requests (RqO,...RqZ) from a communication network, the device (DElec) being characterized in that it comprises means for distributing data (Distrib.), within a plurality of buffers (Buf#1, Buff#2, ..., Buf#x), each buffer (Buf#1, Buff#2, ...., Buf#x) being associated with a single record (Enr#1, Enr#2, ..., Enr#x) of a database (BDD), the association between each buffer (Buf#1, Buff#2, ..., Buf#x) and each record (Enr#1, Enr#2, ..., Enr#x) being effected via a record identifier (IdEnr#1, IdEnr#2, ...IdEnr#x) within the database (BDD), these record identifiers (IdEnr#1, IdEnr#2, ...IdEnr#x) being present within the received insertion and / or modification requests (RqO, ...RqZ), said data being inserted, from values contained in the insertion and / or modification requests (RqO, ...RqZ), into the plurality of buffers (Buf#1, Buff#2, ..., Buf#x), in the form of buffer records (E1, E2, ..., Ex) comprising a value (val) to be updated and / or inserted within the database (BDD); and means for dispatching (Repart.), from buffers (Buf#1, Buff#2, ..., Buf#x) of said plurality of buffers (Buf#1, Buff#2, ..., Buf#x), of data within the records (Enr#1, Enr#2, ..., Enr#x) of the database (BDD) with which these buffers (Buf#1, Buff#2, ..., Buf#x) are associated, said dispatching phase comprising, for the buffer records (E1, E2, ..., Ex) which comprise an operational marking defining a process to be executed, executing from a configuration file, a computer program (PA, PB, etc.) specifically dedicated to said record and / or specifically dedicated to the data type of said value (val) to be updated and / or inserted within the database (BDD).

10. A computer program product downloadable from a communication network and / or stored on a computer-readable medium and / or executable by a microprocessor, characterized in that it comprises program code instructions for the execution of a process according to claim 1, when executed on a computer.