FR3067490A1 - TREATMENT OF MULTINOUS MESSAGES - Google Patents

Abstract

Messages are processed on a messaging system distributed by a message processing engine. Message targets operate according to a first standard or a second inherited standard. In response to receiving a validation indication from a database, a message envelope is generated for each message target to be notified as being functional according to the first standard and at least one of the messages in each message envelope. ; The message envelope dependencies between the message envelopes generated for the same message target are calculated. The message dependencies between the messages in each message envelope are calculated based at least on the message standard of the respective message envelope and message functions. The messages are sent to the respective message target in a sequence based on the message envelope dependencies and the message dependencies.

Description

PROCESSING MULTINORM MESSAGES

FIELD OF THE INVENTION

The present invention generally relates to message processing. More specifically, the present invention aims at processing messages while respecting the dependencies between the messages and the order of the messages.

CONTEXT

According to the prior art, various message processing systems are known.

US 7,240,097 B2 describes a system which is capable of preserving the order of messages for parallel processing. This messaging system processes messages entered immediately upon receipt and preserves the order of messages entered when messages are sent to destinations.

US 8,200,765 B2 describes a centralized system in which messages are queued in order based on a message primacy value, p. ex. the most crucial messages take priority over the less crucial messages. Entry and exit queues are used. The proposed system is implemented like a distributed / parallel system with a connection to a centralized database or output queues are used in each node server in a fleet. Message order is calculated before messages are placed in the output queue.

US 2007/0124398 Al is capable of sending messages to receivers based on an assigned sequence identifier. The proposed method can prioritize the messages that are generated for an envelope and the envelopes are connected to each other using the sequence identifiers.

US 7,680,793 B2 sends messages in an order based on the validation timestamp. Messages are sent in an order based on both a commercial valet and the validation timestamp.

US 8,875,155 B2 manages the orders of the messages for groups of messages.

EP 2,811,437 proposes an SOA system for sequencing incoming messages, in particular for messages based on HTTP (hypertext transfer protocol), SOAP (simple object access protocol) or XML (extensible markup language).

Furthermore, certain message standards are known such as the teletype, or briefly, TTY messages. For example, P 2254046 Bl describes a sequencing of TTY messages in order to determine an order in which TTY messages are sent.

In addition, the “New Distribution Capacity” standard, more briefly referred to as NDC below, was issued by IATA, the International Air Transport Association in 2015. NDC is a distribution format for airlines for the development and adoption by the market of a data transmission standard based on XML between airlines and global distribution systems (GDS). NDC, for example, allows airlines to respond directly to requests for consultation of offers from travel agents, in order to manage order processing and allow real comparison of offers. NDC is not a system, software or database, but a standard for the exchange of information between airlines and travel agents.

ABSTRACT

It is an object providing a message processing system capable of processing both messages conforming to a legacy format and messages conforming to a successor to the legacy format, eg. ex. a new format, while ensuring that messages conforming to both formats are sent to receivers in the correct message order. Specifically, it is an object providing a message processing system that can process messages uniformly, based on XML according to the NDC standard and on a legacy format such as TTY.

NDC allows a database change validation to trigger multiple messages to a message target. These messages can be of different types, can be submitted to different sending methods and can have a certain dependence and causality. It is therefore an object providing a messaging system that supports NDC message flows and at the same time is inversely compatible with legacy message systems with simpler functionality, so both types of flows messages are supported in an integrated and seamless manner, not as two independent messaging systems.

Furthermore, it is an object providing an open and extensible messaging system and which can thus support future message standards that can accommodate an even wider range of features than the NDC standard.

In a first aspect, a method is provided for processing messages in a distributed messaging system by a message processing engine. At least one message target of a plurality of message targets operates according to a first standard and at least one message target of the plurality of message targets operates according to a second inherited standard. The method is implemented by a message processing engine.

A plurality of database validation indications are received, wherein each database validation indication indicates a change in a record of a database. In response to the receipt of a database validation indication from the plurality of database validation indications, a message envelope is generated for each message target to be notified, operating according to the first standard and at least one message in each message envelope is generated.

The message envelope dependencies between the message envelopes generated for the same message target are calculated. Message envelope dependencies define an order of message envelopes for the same message target.

The message dependencies between the messages in each message envelope are calculated based at least on the message standard of the respective message envelope and the message functions. Message envelope dependencies define an order of messages in each respective envelope.

The messages are sent to the respective message target in a sequence based on the message envelope dependencies and the message dependencies.

In a second aspect, a messaging system, arranged to implement the above process, is provided.

In a third aspect, a computer program product that implements the above process when executed on a computer is provided.

SUMMARY DESCRIPTION OF THE DRAWINGS

The present invention will be described with reference to the accompanying drawings. Similar reference numbers generally indicate identical or functionally similar elements.

FIGS. 1, 2, 3 and 4 are flow diagrams for a method of processing messages functionally as described herein.

FIG. 5 is a visual representation of the dependencies at the message envelope and at the message level as defined by the message processing system described herein.

FIG. 6 is an exemplary, process-oriented visual representation of the message processing system.

FIG. 7 illustrates exemplary architectural hardware for the message processing system.

FIGS. 8 and 9 are more detailed flowcharts of an exemplary implementation of message processing and dependency.

FIG. 10 is a detailed flow diagram of an exemplary implementation of a message sending process.

FIGS. 11, 12, and 13 show different states of a table containing message envelopes and messages, as well as the dependencies between message envelopes and messages.

FIG. 14 is an exemplary schematic view of the internal architecture of a database table and / or of a requesting client.

DETAILED DESCRIPTION

Before explaining an example of a more specific implementation compared to FIGS. 6 and 14, some general aspects will first be discussed with reference to FIGS. 1 to 5.

Generally, the order of messages to be sent to message targets and an aspect to be addressed in the message processing system. For example, a correct order of reservation messages must be maintained for information flows in a GDS. For example, a reservation (simple reservation) in a database of a reservation system is modified in one or more change confirmations. A receiver is expected to receive corresponding notifications of the reservation change in the form of an exchange of messages, specifically of these change validations, in order, in order to maintain data consistency across the system. If the order of change approvals is changed, a discrepancy or inconsistency could arise between GDS records and / or airline systems. For example, a travel agency cancels a flight and then makes a new reservation for the same flight on a different date, via two subsequent change confirmations. The client, i.e. the airline needs to receive the cancellation message first and only afterwards a message for the new flight reservation for synchronization to be correct. Therefore, a correct sequence of messages sent to the target of the message ensures that the reservation remains consistent between a reservation source and a reservation target in order to avoid any possibility of recording anomalies.

Nowadays, in messaging flows such as GDS reservation synchronization flows, usually - for a message target - at most one TTY message per validation of change of a reservation record (designated as end of transaction for a passenger name registration, in other words a PNR) is generated to exchange changes between nodes of GDS. A dedicated process for a traditional TTY context has been proposed by EP 2254046 B1. However, in the context of NDC reservations, the scenario changes, as NDC standards implementations are usually considered to trigger multiple messages for validation of change from a reservation record to message targets operating in accordance with NDC specifications and thus implementing NDC characteristics. These multiple messages can be of different message type (TTY, XML, even other types in the future), have different messaging functions (such as adding or deleting messages), sending methods (synchronous: the message is sent and a confirmation response is received during the same session, then the session is closed once the successful delivery of the message is observed; or asynchronous: the session is closed on the sender's side the message is sent, the confirmation response is sent back to the sender in another session), they can use various network and transmission protocols (such as HTTP / SOAP) and also send priorities which define the relationships between messages. Also, legacy TTY message flows are still provided by message processing systems, i.e. message processing systems must be inversely compatible, since TTY flows and NDC flows will coexist to synchronize reservation records. In order to obtain robustness, reverse compatibility, and maintain stability, a new message processing mechanism is therefore sought.

In summary, this new message processing mechanism must address the problem of message sequences in the context of NDC reservations in which multiple messages which may be dependent on each other are triggered by change validation and therefore need to be sent to a message target in a well-defined order. The new message processing also makes it possible to address the problem of integrating NDC message flows and TTY legacy flows into a single generic message processing framework which synchronizes the reservation record in a hybrid mode in which TTY, XML or other types of messages are used.

To address these problems, it is proposed to process messages and manage message orders in an integrated manner unlike the management of legacy message flows and NDC message flows by two separate and independent message processing systems. Referring to FIG. 1, messages are processed in a messaging system distributed by a message processing engine.

The distributed messaging system includes multiple types of message targets. At least one message target of a plurality of message targets operates according to a first standard and at least one message target of the plurality of message targets operates according to a second inherited standard. The target message term as used herein includes message destinations at various levels, including large systems such as a global distribution system (GDS); a departure control system (DCS), a wide area network (WAN), or a local area network (LAN) of a particular company, such as an airline as well as individual receiving stations.

In some embodiment, message targets operating according to the first standard are entirely inversely compatible and therefore also operate according to the second standard, i.e. that they are arranged to also process messages according to the second standard, whereas the message targets which operate according to the second standard are inherited message targets which do not implement the first standard and are therefore incapable of processing messages according to the second standard. Thus, a reference to the first standard mentioned herein generally includes the first standard and the second standard and the respective messages conforming to the first and second standards, while a reference to the second standard mentioned herein does not include than message targets and messages conforming to the second standard.

Referring again to FIG. 1 and in FIG. 2, a plurality of database validation indications is received by the message processing engine. Each database validation indication indicates a change to a database record. A database validation indication is a content of all changes made to a database record such as a passenger name record (PNR), between a retrieval request and a database validation finalizing the changes to the database record in the database which is located upstream of the message processing engine. Therefore, each time a change is committed to the upstream database, a database change validation indication is generated and published to the message processing engine. The database validation indications thus feed the message processing engine.

In response to receiving a database validation indication from the plurality of database validation indications, a message envelope is generated for each message target to be notified according to the first standard and at least a message in each message envelope is generated on 4. A message envelope as used herein is a special occurrence of a message that is not sent, but constitutes a repository grouping of messages from an envelope of messages. This is similar to file systems where a directory, or folder is a particular occurrence of a file grouping all the files located in the directory. The entire message envelope and its messages are also referred to herein as a message list.

Generally, the message processing engine determines the message targets which are affected by a received database validation indication and generates a message envelope for each affected message target to be notified which operates according to the first standard. All messages in a message envelope are addressed to this message target and will be sent to the message target in a well-defined order. In order to determine and ensure the sending order, dependencies at different levels are introduced, in particular the dependency of a message envelope on the level of the message envelope and a dependency of message level on the level of the message. Message envelope dependencies define an order for all message envelopes generated for a certain message target. Message dependencies define the order of a message in a certain message envelope.

Consequently, the generation of message envelopes and of messages in the message envelopes also involves a calculation of the dependencies of the message envelope between the message envelopes generated for the same message target, at 6, and the dependencies of messages between messages in each message envelope at 8.

Generally, a message envelope created for a database validation indication is calculated at 6, to be dependent on other already existing message envelopes for the same message target, i.e. than the message envelopes that have already been generated previously for this message target in response to the previous receipt of a database validation message. Therefore, message envelopes for a certain message target are ordered based on an order of receipt of database validation messages affecting said certain message target.

On the other hand, message dependencies are calculated at 8, at least on the basis of the message standard of the respective message envelope and the message functions. In particular, messages of the first standard can be classified according to different functions (also designated as “message name” below) for example: adding a message adding a record, deleting a message deleting a record, dividing messages divides a recording, and others.

A message dependency map refers to the relationships established between specific message envelopes and messages that are valid at a certain point in time. Message dependency maps are kept by the message processing engine in one or more database tables. The messages are sent to 10, by the message processor to the respective message target, in a sequence based on the message envelope dependencies and the message dependencies.

In addition to the different types of message targets, different types of database systems that generate database validation indications may be present in the distributed messaging system. One type of database system operates according to the first (new) standard and can produce indications of database validation already conforming to the first standard (and, for reasons of reverse compatibility, also indications of basic validation data compliant with the second standard). Another type of database system always operates only according to the second legacy standard and thus only produces indications of legacy database validation.

Depending on the source of a database validation message (a database system operating according to the first standard or a database system operation according to the second inherited standard) and according to the target type of message to be notified (a message target operating according to the first standard or a message target operating according to the second inherited standard) it is possible to differentiate different cases of message processing.

A first case, represented visually by FIG. 2, assumes that a database validation indication received at 11 is a first database validation indication of the plurality of database validation indications from a database system which operates in accordance with the first standard. In some embodiments, this database validation indication is signaled as a database validation indication according to the first standard, e.g. ex. by a tag, as explained elsewhere below. In response to receiving a database validation indication conforming to the first standard, the message processing engine generates a message envelope for each message target conforming to the first standard to be notified and generates at least one message in each message envelope.

Here, two sub-cases can be distinguished. For each of the message targets to be notified by implementing the first standard, briefly designated as the first message targets, a respective first message envelope is generated at 12, each of which usually includes a plurality of first interdependent messages to be relayed to the respective first message target operating according to the first standard. The plurality of first interdependent messages is specified as conforming to the first standard (which also generally includes messages conforming to the second messages conforming to the second standard for reasons of reverse compatibility already explained above). For each message target to be notified by implementing the second inherited standard, briefly designated as second message targets, a second message (one per message target) to be relayed to the second message target operating according to the second standard is generated at 13. The second message is specified as conforming to the second legacy standard.

The message processing engine then calculates, the message envelope dependencies between the first message envelope and other message envelopes already waiting for the first message target at 14. The message envelope dependencies define the message envelope order for the first message target.

The message processing engine also calculates the message dependencies between the first messages of the first message envelope based at least on the first message target and the functions of the first messages on the 15th. The message dependencies define the of messages in each message envelope.

The first messages are then sent to the first message target at 16, in a sequence based on the message envelope dependencies and the message dependencies.

Concerning the second messages generated for the message targets implementing the second inherited standard, these messages are either sent directly if there are no more messages waiting for the message target concerned or, when other messages are in waiting for the message target, a message level dependency is calculated. In the second case, the second messages are sent in a sequence according to the calculated dependency of message level.

A second case visually represented by FIG. 3 assumes that a database validation indication received at 17 is a second database validation indication of the plurality of database validation indications from a database system which operates according to the second inherited standard. In some embodiments, this database validation indication does not include a signal indicating the first standard and the message processing system interprets as well as the database validation indication is an indication according to the second standard inherited.

In response to receiving a second database validation indication of the plurality of database validation indications from a legacy database system operating according to the second standard, the processing engine messages generates at 18 a message for each message target to be notified and potentially associates the message for each message target with an existing message envelope for the respective target, provided that at least one message envelope for the message target has been generated in the past and is still pending. Generally, since the validation message of the second database conforms to the second inherited standard, only the respective messages conforming to the second standard are generated by the message processing engine. In other words, a database validation indication conforming to the legacy second standard does not cause either a generation of message envelopes or a generation of messages conforming to the first standard.

In both cases, for message targets operating according to the first standard and for message targets operating according to the second inherited standard, the message processing engine generates a message formatted according to the second standard, hereinafter referred to as the third message. . For each message target, of which it is determined at 19, that it has no message envelope and / or pending messages, the third message generated according to the second standard is sent immediately, to 20, without any dependency calculation message.

For message targets of which it is determined in 19 that it has a message waiting envelope and / or at least one message waiting, the message generated in accordance with the second inherited standard is generally associated with the message envelope in pending or, if no message envelope is pending, is included in the sequence of pending messages. In this case, the message processing engine calculates at 21 a message dependency of the third message based at least on the first message target and on the fact that the third message is a message conforming to the second inherited standard. The calculated message dependency defines the location of the third message in the sequence of other messages in the message waiting envelope for the target message target.

For example, if the intended message target operates according to the first standard, i.e. that it is a first message target, a first envelope with the first messages may already be pending. In this case, the third message is usually included in the message envelope and a message dependency is calculated linking the first messages to the third message. At 22, the first messages and the third message are sent to the first message target in a sequence based on message envelope dependencies and on message dependencies.

In special cases, p. ex. if the highest priority is given to the third message, relative to all other messages in the first message envelope, no message dependency is calculated because the third message can be sent directly.

Referring to FIG. 4, optionally, a given priority value is assigned to 24 for each of the pluralities of interdependent messages as a function at least of the standard of the message and of the type of message. The message dependency between messages with a message envelope is calculated at 25 based on the priority values assigned. An example of a table defining the priority values will also be presented later.

Optionally, a message is sent to 26 in response to the determination that the message is independent of any other message in the message envelope of the message and that the message envelope of the message is independent of any other message envelope. In addition, optionally, the message dependency of the message sent and the message dependency of the message that follows in the order of the messages in the message envelope of the message are updated to 27. As will be explained in more detail detailed below, this update could, if necessary, make the next message in the message envelope independent and therefore ready to be sent.

If the last message sent was the last message in the current message envelope, the message envelope dependency of the last message sent is updated and, likewise, the message envelope dependence of the message envelope next in the order of the message envelopes is updated. This update completes the processing of the message envelope of the last message sent and the next message envelope becomes independent and, therefore, the first message of the following message envelope also becomes independent too and therefore ready to be sent.

Optionally, the first standard complies with the new distribution capacity standard (NDC) issued by IATA.

In some embodiments, the methodologies described herein, p. ex. a GDS reservation synchronization system of legacy TT Y messages extends to a set of hybrid messages: TTY messages, XML messages and potentially other messages.

A high-level view of message processing is illustrated in FIG. 5. As an example, a “canceled-re-booked” flight segment scenario occurred in change validation indications 34 of reservation record B. Change validation indications B2 and B3 are received during a sequencing and message generation process 42 from a GDS reservation process 32. A change validation indication B2 indicates a cancellation of flight segment XX123 for the reservation record B, an indication of change validation B3 indicates the addition of a flight segment XXI23 to the reservation record B. The sequencing and message generation process 42 also receives change validations 34 for other reservation records kept by the GDS 32 reservation process, such as AO, A2 and A3 change validations for another A reservation record.

Ideally the change validation indications 34 are produced by the GDS reservation process 32 in an orderly fashion. However, this may not always be the case, as illustrated in the example for change confirmations relating to reservation record A which are sent by the reservation process GDS 32 in the order AO, A3, A2, Al. The GDS 32 reservation process may originate from two different database systems, in particular a database system operating according to the first standard (eg managing reservation record B) and a other database system operating according to the second legacy standard (eg, managing reservation record A) as explained above.

In response to the receipt of indications of change validations 34 from the exemplary flow “canceled-reserved again” concerning reservation record B (as well as other change validations 34 relating to other reservation records), the message sequencing and generation process 42 recognizes that these indications of change validations 34 of the “canceled-re-reserved” exemplary flow relating to reservation record B are change validations conforming to a leading standard such as the standard NDC (i.e., the first standard, unlike the second legacy standard). For example, the change validation indications 34 of the "canceled-re-reserved" exemplary flow relating to reservation record B contain a special indicator which identifies them as indications of change validation NDC.

In response to the recognition that a change validation indication 34 is an NDC change validation, the message sequencing and generation process 42 creates a message envelope 36 for each message target to be notified, here the target of message 49a operating according to the first standard such as NDC, and one or multiple messages 38 belonging to the message envelope 36. The message envelope groups said one or more messages relating to the recognized NDC validation indication and which must be sent to message target 49a. Furthermore, the message sequencing and generation process 42 establishes dependencies at two levels, in particular at the level of a message envelope as well as at the level of the message. The dependencies at the two levels are also referred to below as dependency maps.

The purpose of creating a message envelope 36 is to manage and determine if and when messages in this message envelope can be sent, i.e. if the messages of the message envelope 36 have no dependence on other messages 38 which are generated by other change validations 34. In this sense, from a functional point of view, a message envelope 36 constitutes a reference node for all the messages 38 belonging to this message envelope 36 (the message envelopes are therefore also abbreviated by the letter "R" below).

A new message envelope created 36 is included in a dependency map at the level of the potentially already existing message envelope if one or more other message envelopes is / are already present for the concerned message target 49a. In the example of FIG. 3, a change validation indication B2 indicating the cancellation of the flight segment XX123 is received by the message sequencing and generation process 42. The message sequencing and generation process 42 determines that the message target 49a must be notified and create an R2 message envelope and three messages

2.1 XML; 2.2 XML and 2.3 TTY belonging to the R2 message envelope.

Then, a change validation indication B3 is received. The message sequencing and generation process 42 again determines that the message target 49a is to be notified and creates another message envelope R3 with a set of messages

3.1 XML, 3.2 XML and 3.3 XML. A dependency between the R2 and R3 message envelopes is established because the R3 message envelope depends on the R2 message envelope, as indicated by the dotted arrow 37.

In addition, inside the message envelope 36, messages 38 are also arranged in order, i.e. that a message level dependency map is established. In the example of FIG. 5, the message order in the R2 message envelope is 2.1 XML, 2.2 XML and 2.3 TTY and the message order in the R3 envelope is 3.1 XML, 3.2 XML and 3.3 XML as indicated by the arrows 39. In some embodiments, the message level dependency maps are established based on the predefined priority values of the messages, so that messages with higher priority values are located upstream in the dependency map of the messages. messages compared to messages with lower priority values.

Then, the message generation and sequencing process 42 receives the change validation indication B4 always linked to the reservation record B. the change validation indication B4 comes from a legacy reservation system and the process message generation and sequencing 42 again determines that the message target 49a operating according to the first standard is to be notified. Thus, the message generation and sequencing process 42 generates a TTY message; the message 4 TTY, which it classifies in the existing dependency card in accordance with the mechanisms of the TTY context described by EP 2254046 Bl. In the example of FIG. 5, a message level dependency is calculated for the 4 TTY message so that the 4 TTY message depends on the 2.3 TTY message (for presentation reasons, it is assumed here that the 2.3 TTY message could not already have been sent , e.g. because other prior TTY messages relating to reservation record B, not shown in FIG. 5, are still pending for message target 49 a)

Dependency maps at the message envelope level and at the message level control the sequence of sending messages to message targets 49. Generally, messages for a particular message envelope 36 are only sent to message targets 49 if the particular message envelope 36 does not depend on other message envelopes 36. Therefore, in the example of FIG. 5, the messages 3.1 XML, 3.2 XML and 3.3 XML are only sent after the complete processing of the R2 envelope, i.e. after all the R2 message envelopes have been successfully sent to the message target 49a. Within a message envelope, the order in which messages are sent is determined by the message level dependency. In the example of FIG. 5, the order in which messages are sent within the R2 message envelope is the 2.1 XML message first, followed by the 2.2 XML message and lastly the 2.3 TTY message. For the R3 message envelope, the order in which the messages are sent is the 3.1 XML message first, followed by the 3.2 XML message and the 3.3 XML message last. The message 4 TTY can be sent after the message 2.3 TTY has been successfully transmitted, i.e. that the 4 TTY message is sent in parallel with the 3.1 XML message.

Change validation indications 34 received from a legacy database system are generally converted only to a message conforming to the second legacy standard, in the example of FIG. 5 in TTY messages. In the event that no previous message is pending for a given message target, these messages can be sent immediately without calculating a dependency on message envelope level and message level. In the example of FIG. 5, the reservation record A is kept in a legacy database system and the indications of change validations AO, Al, A2 and A3 are therefore only converted into TTY messages. For example, in response to receiving an AO change validation indication, the message generation and sequencing process 42 determines that the message target 49b (which is a message target operating according to the second legacy standard) must be notified and generates a 0 TTY message which is then sent immediately since there is no other message waiting for the message target 49b. Likewise, the change validation indication A1 triggers the generation of the message 1 TTY which is again sent immediately without calculation of a message level dependence, assuming that the message 0 TTY has already been successfully delivered to the message target 49b.

Generally, a message is determined to be eligible for sending and should be placed in a message sending queue in response to the determination that the message does not depend on the successful delivery of another message, in which this dependency is defined by the dependency maps at the message envelope level and at the message level. If a successful delivery of a particular message is recognized, p. ex. by receiving a confirmation of receipt response from the message target 49, the dependency of this particular message is updated by the message processing system. In response to the updating of the state of this dependency, the dependency state of other messages dependent on the particular message is then updated from "dependent to" independent "having the effect of then triggering the sending of these others messages. In response to the determination that the last message in the message level dependency map of a particular message envelope 36 has been successfully delivered to the message target 49, i.e. all messages from the particular message envelope 36 have been sent, the particular message envelope 36 is considered to be completely processed and the state of dependence on the message envelope level of the following message envelope which depends on the particular message envelope 36 is updated from “dependent” to “independent”. This makes the first message in the message level dependency map of the next message envelope ready for dispatch, and the sending of this first message in the next message envelope is triggered. The whole process continues in the same way until all messages in the message envelope have been sent to their message targets.

TTY and XML used above are examples of different types of messages conforming to different message standards. TTY is an example of an inherited standard using one or more inherited message subtypes. XML is an example of a new generation of standards using a plurality of message subtypes, e.g. ex. for different database manipulation functions. Usually, different types of messages are generated for different types of message targets, including message targets that implement the different message standards. The example of FIG. 5 shows two specific types of message targets, including TTY message targets 49b which implement only the legacy standard (not the next generation standard) and XML message targets 49 a which implement the new generation of standards such as the NDC standard (as explained above, the XML message target 49a could potentially be inversely compatible and therefore capable of also processing legacy messages).

The message processing system herein is not limited to processing messages of two message standards, but is extensible and generally suitable for processing messages conforming to one or more other standards and types for message targets 49c which implement these new standards. The concept of establishing dependencies at the message envelope and message level can be used to manage any other new standard and any other type, for example by assigning priority values to messages of the new / new standard types that define a relationship of messages from the new standard / new type to messages from existing standards / types.

Concerning the more specific part of the description, an example of a particular implementation of the general mechanisms for processing messages explained above will now be described with reference to FIGS. 6 to 14.

An exemplary architectural process for implementing the message processing engine 50 is illustrated in FIG. 6. The system architecture includes the following components which are implemented by software using dedicated and / or shared hardware resources:

- a reservation engine for a legacy global distribution system (GDS) 41 which produces indications of validation of changes to a legacy GDS;

- an NDC 40 booking engine produces NDC PNR change validation indications and marks these change validations with a beacon indicating that these change validation indications are NDC change validation indications (i.e. compliant to the first standard) and must be treated in accordance with the NDC standard, except for message targets to be notified which always operate according to the second legacy standard, such as TTY message targets.

an NDC message generation and sequencing process 42 which generates all kinds of reservation messages such as TTY messages, XML messages or other types of messages. The NDC 42 message generation and sequencing process calculates message dependency maps.

- a TTY 43 message sequencing engine which forms part of the NDC 42 message generation and sequencing process. The TTY 43 message sequencing engine calculates the dependency characteristics of TTY messages, which determines the order of sending TTY messages as described on p. ex. by EP 2254046 B1.

a message priority table 44 which stores the message priority values. The priority values of the messages are precalculated on the basis of the analysis results and can be updated if necessary or on request.

a dependency card and a message table 45 which store the dependency cards at at least two levels, in particular the dependency cards at the message envelope level for the message envelopes and the dependency chains at the message level for messages.

a state machine for sending messages 46 which represents the main process for controlling the sending of messages and for updating the dependency map at the envelope level and the dependency chains at the message level. The state message sending machine 46 includes a message queue 46a and two sub-processes, in particular

a message sending sub-process 47 which systematically removes the messages from the queue and sends them to the targets 49, and

a message response reception sub-process 48 which listens to the responses to the messages. The target response reception sub-process 48 validates the operations of the sender's queue and updates the dependency maps at the message envelopes level and the dependency chains at the message levels in order to follow changes to the dependency map and message table 45 in response to receipt of confirmation responses from message targets 49.

These system architecture components interact with each other as illustrated by the arrows connecting the blocks in FIG. 6.

The NDC 40 booking engine creates a new database record, eg. ex. in response to a new travel reservation or updates to an existing data record in response to a change to an existing travel reservation. The creation of a new database record and the updating of the existing database record respectively generate indications of change validations that the reservation engine NDC 40 publishes (arrow N01) to the sequencing process and generating NDC 42 messages. All publications from the NDC 42 reservation engine are flagged (eg, tagged) as validations of an NDC reservation change, ie. as indications of database change validations from the NDC 40 booking engine.

Similarly, the legacy GDS reservation engine 42 can create a new database record, e.g. ex. in response to a new travel reservation or updates to an existing data record in response to a change in an existing travel reservation. The creation of a new database record and the updating of an existing database record respectively generate a change validation indication which is published by the legacy GDS reservation engine 42 (arrow N02) to the process sequence and generation of NDC messages 42. However, the indications of change validations published by the legacy GDS reservation engine 40 are not signaled or marked up.

In response to receiving a change validation indication from the legacy GDS reservation engine 42, the message sequencing and generation process 42 only generates TTY messages for message targets to be notified.

In response to receipt of database change validation indications from the NDC reservation engine 40, the NDC message sequencing and generation process 42 generates message envelopes for the NDC message targets to be notified and messages associated with the respective message envelopes. For this purpose, the NDC message sequencing and generation process 42 retrieves the priority values of messages in the message priority table 44 (arrow N05 representing recovery requests and arrow N06 representing recovery responses), as well as the information retrieved concerning the current message envelopes and the associated messages from the dependency card and the message table 45, and inserts the newly generated message envelopes and the associated messages into a dependency card and in the message table messages 45 (arrow N03 representing the recovery and insertion requests and arrow N04 representing the recovery and insertion responses). The interactions of the NDC 42 message sequencing and generation process with the message priority table 44 and the dependency map and the message table 45 will be explained later on the basis of a particular example.

Furthermore, the message sequencing and generation process 42 may determine that a particular message does not depend on any other message which means that this message is ready to be sent to the message target 49. In this situation, the message sequencing and generation process 42 retrieves the particular message from the dependency card and the message board 45 via operations N03 (retrieval request) and N04 (retrieval response), generates a queue element of message representing the particular message and places the message queue element in the message queue 46a of the state machine for sending messages by an operation N07.

Subsequently, the message queue element is removed by an operation N08 from the queue by the state machine for sending messages 46 and sent (arrow N09) by the message sending subprocess. 47 to the correct message target 49. A message response (such as an acknowledgment) can be received (arrow N10) from message target 49 by the machine receiving message response 48 subprocess. state sending of messages 46.

Once the response from message target 49 has been received, i.e. that the particular message has been successfully delivered to the message target 49, the state message sending machine updates the message dependency state of the particular message in the dependency map and in the message table 45 ( Nile arrow). This update may make the following message or messages independent of any other message (ie the sending of this new message from these new messages may then be triggered. For this purpose, the message which has become independent by the successful delivery of the particular message beforehand is recovered (arrow N12) by the state sending machine 46 and placed in a queue in the message queues 46a. The operations N08, N09 and N10 are then executed in the same manner as described above.

An example of the message priority table 44 is as follows:

Message target Type of message Message name Value priority YY XML SUPR 90 YY TTY TTY 50 YY XML AJT 10 YY NEW GEN NULL ZZ XML SUPR 95 ZZ TTY TTY 90 ZZ XML AJT 70 ZZ XML DIV 0

The "Message Target" column defines the message destinations, ie. list all known message targets 49. The "Message Type" column indicates the message standards (ie, if they conform to an inherited standard such as the TTY message type or conform to a current standard such as NDC which uses XML messages. Depending on the type / standard of message, there may be messages of different subtypes which are indicated in the column "Message name". As shown in the example below above, the legacy standard may not deliver different types of messages so all TTY messages are referred to as TTY messages, however the new standard that uses XML message types may define different types of messages such as deletion of messages ("SUPR") and addition of messages ("AJT") Finally a third standard ("NEW") can define generic messages ("GEN").

The "Priority Value" column defines the message priority value of all messages of a given message type and the name of the message to be addressed to a particular message target. Therefore, priority values are used to differentiate messages at the message target, standard, and message subtype / name. In the example above, the values in the "Priority value" column have the following meanings: a priority value of 0 means that the message should not be sent. This makes sense, p. ex. in cases where messages, having a certain function, are already specified by the first standard, but are not yet supported by the currently deployed message targets. In the example in table 44 above, this is the case on p. ex. for the DIVIDED message which is already generated internally by the message processing engine 50, but is not (yet) sent due to a lack of implementation by the message targets. If no priority value is set ("NULL"), the message can be sent when there is no dependency on the message envelope. The messages in an envelope are interdependent according to their priority value, priority values of higher or lower values.

The message priority table 44 is generally static, but can be configured at any time. A new target can be added, new message types can be added for the various targets and also new message names can be added for a given message type. In addition, existing rows can be updated or deleted, e.g. when a particular target needs to be removed. Priority values can also be reconfigured.

In some embodiments, the message priority table 44 is not hosted by a database system, but is stored in the form of a cache memory file, for example. from a batch server. The cache can be synchronized with any server if necessary or appropriate. For example, changes to the message priority table 44 can be made by a content management system of the batch server and then broadcast to all of the deployed servers.

On the other hand, the dependency map and the message board 45 are very dynamic because the dependency map and the message board 45 represent the current state of the message processing system at any given time. Thus, in certain embodiments, the dependency card and the message table 45 are hosted by a database system. The message processing system described herein can operate in multiple live sessions, inserting and updating the dependency map and message table 45 in real time.

An exemplary definition of the columns of the dependency map and of the message table 5 45 is as follows:

Column name Definition ID Message ID number P Reference key identifying the associated reservation record of the NDC booking engine. 40 or the legacy GDS booking engine 41. P-Order of Key and / or chain of letters and numbers I Change validation number: P (i) represents the i ^th database change validation reservation record P J Message target RDSTAT State of dependency on the level of the envelope of messages DJSTAT State of dependency on the envelope of messages D_ID Dependency identifier indicating the message envelope or the message on which the message envelope or message depends NOT Message name TYPE Type of message Message The generated message itself represents the x ^th message to be sent to target j, generated for the change validation i of the reservation record P and the name of the message is n.

The two dependency states RDJSTAT and D_STAT can take the values "sent" (S) if the message has been sent, or "without effect" (V) if there is no message to send to the target (p eg the entry in the table represents a message envelope unlike a message), or "dependent" (D) if the message has a dependency on another message at the message level or if the message envelope of the message has a dependency on another message envelope, or "N" if there is no dependency (= ready to send) or "unknown" (U) when the dependency has not yet been identified, p. ex. a corresponding message is missing at the moment, i.e. still pending in the NDC 42 message sequencing and generation process. Table entries represent message envelopes if the RD_STAT cell is full and the DSTAT cell remains empty.

For example, the message envelope for the message list of {M ^ ' ⁿ (x)} is denoted as Rj.

In some embodiments, the message processing system 50 is deployed as a range of servers 52 with potentially multiple respective processing occurrences 54 as shown in FIG. 7. The load balancing characteristics can distribute the message processing loads between the processing cases 54 of a server 52 and / or between the servers 52 of the range of servers. Consequently, the message processing system 50 is extensible in order to adapt to a potential increase in traffic.

The message processing system 50 has at least one database server 56 (there may be additional databases for reasons of redundancy and / or performance) which keeps the dependency map and the message table 45 All the processing occurrences 54 are connected to the database servers 56. Overall, the message processing system 50 constitutes a step in an information processing chain of a larger distributed system comprising all the components. shown in FIG. 6 and other components such as travel agency customers. On the other hand, the message processing system 50 performs parallel processing, since each individual processing case 54 is capable of processing one recording envelope at a time.

As explained above, the NDC message sequencing and generation process 42 is the main process of the message processing system 50. The NDC message sequencing and generation process 42 contains the legacy TTY message sequencing engine 43 and interacts with the message priority table 44 and the dependency card and the message table 45. The operations N01 to N07 shown in FIG. 6 can be implemented by the FIG exemplary process flowchart. 8 describes below.

When an indication of change of validation of a database is received, at 602, coming either from the NDC reservation engine 40 or from the legacy GDS reservation engine 41, the NDC 42 message sequencing and generation process is constructed. first, at 604, a list of message targets 49 that are affected by the database change validation and will therefore receive one or more messages informing the target of the change in the reservation record that occurred in the NDC reservation engine 40 or in the legacy GDS reservation engine 41.

Generally, the messages for the different targets 49 have no dependency relationships (i.e., a first message to a first target can be sent regardless of the state of the second message addressed to a second target. Therefore, as explained above, the message envelope dependencies are only established between message envelopes for the same message target and, of course, the message dependencies are established only between messages in a message envelope and therefore between messages for the same message target. As illustrated in FIG 8, the NDC 42 message sequencing and generation process processes message targets 49 in the list one after the other. For a given indication of validation of database change, a message dependency map is built or enlarged either by the generation of a new the message envelope with one or more messages [right side of FIG. 8] or an inherited message [left side of FIG. 8] for each message target to be notified by the following activities shown in FIG. 8.

At 606, the NDC 42 message sequencing and generation process checks whether the end of the established list of message targets at 604 has been reached. If so, the process in FIG. 8 ends because the database change validation indication received has been processed completely. If not, the process continues with the next message target 49 in the message target list; after reading this new target at 608 the process determines if the next target operates according to the first standard [ie. NDC in this example] or according to the second legacy standard [i.e. only processing TTY messages in this example]. The process then checks at 610 whether the received database change validation indication is flagged as validation from the NDC reservation engine 40 or the legacy GDS reservation engine 41.

The two determinations of boxes 608 and 610 determine whether the current receiver is processed via the left side or via the right side of FIG. 8. In response to the determination that the database change validation indication originates from the NDC 40 reservation engine and is therefore aligned with the first standard and that the current message target operates according to the first standard, "branch yes From box 610 is selected. In all other cases, i.e. in response to the determination that the database change validation indication is from the legacy GDS reservation engine 41 through 610, and / or that the current message target operates according to the second legacy standard at 608, "branch no" from box 610 is chosen. The two branches of the process as a whole, illustrated by FIG. 8, use the dependency card and the message table 45. The left side "branch no" of the box 610 stores the dependencies at the message level as well as the messages themselves in the dependency card and in the message table 45, unless TTY messages are sent directly, because none of the messages that were waiting for the target message target are no longer waiting. The right side "branch yes" of box 610 stores the dependencies at the level of the message envelope and at the level of the message as well as the messages themselves in the dependency card and in the message table 45.

For inherited / nonNDC message targets and / or inherited change validation indications, the NDC 42 message sequencing and generation process, more specifically the TTY sequencing engine 43, generates a TTY message through activities 612 to 624 The TTY message is formatted at 612, a TTY dependency element is initialized at 614. Here, the message priority values for TTY messages are retrieved from the message priority table 44. If, at 616, it is determined that the current TTY message is the first message for the target selected in the lists in 606, i.e. if there is no previous TTY message waiting for this target, the TTY message is transmitted to the state message sending machine 46 and placed directly in the waiting list 46a. The dependency map and the message table 45 is then validated at 620 and the whole process advances to the next target on the target list, at 626. If, at 606, it is verified that the end of the list of targets are reached, the process ends.

In response to the determination at 616 that one or more other XML and / or TTY messages are still pending for the current message target selected at 606, the NDC 42 message sequencing and generation process calculates a state of message level dependency for TTY message to 622, i.e. that the parameter D_STAT is set for the TTY message. If D_STAT is calculated as "N", ie. since no dependency exists for the TTY message, the TTY message can be sent directly to the message target 49. Thus, similarly to what has been described above, the TTY message is transmitted to the state machine sending messages 46 and placed directly in the queue 46a to 618 and the process proceeds as described above. If operation 624 determines any state of dependency on the message other than "N", the dependency card and the message table 45 is then validated at 620 and the overall process advances to the next target on the target list at 626 .

Other details for processing legacy TT Y messages are described in EP 2254046 Bl, in particular in FIG. 5, FIG. 6 and FIG. 7 of EP 2254046 Bl and the description which accompanies them under paragraphs [0030] to [0034] to which reference is made herein.

For message targets 49 which implement the NDC standard, as determined in 608, and provided that the change validation indication currently being processed is tagged NDC, as determined in 610, the message sequencing and generation process NDC 42 generates one or more NDC messages by activities 612 to 624 of FIG. 8.

In 628, one or more messages are generated according to the first standard [here: on the NDC basis on XML] and / or according to the second standard [here: the message standard inherited on the TTY base]. Operations 630 and 632 are functionally similar to operations 614 and 616, but - unlike 614 and 616 - relate to a chain of dependencies at the message envelope level. In 630, a message envelope for said one or more NDC messages is created and the dependency state of the RDSTAT message envelope is initialized. The check at 632 determines whether the message envelope is the first message envelope for the current message target 49 targeted in the current loop in the message envelope dependency map stored in the dependency map and the message table. 45. In response to the determination in 632 that there is no longer an earlier message envelope for the current target 49, the newly created message envelope has no dependency and the RD STAT parameter is then set to N in accordance with 634. On the other hand, in response to the determination in 632 that one or more message envelopes for the current target 49 are already present in the dependency map and in the message table 45, the RD STAT parameter is then set in accordance with D at 636. After RD STAT is calculated at 634 or 636, process 638 is called to store the message envelope present in the dep card endances and in the message table 45.

After the successful validation of the dependency card and the message table 45 to 638, the process 640 is called upon to construct a chain of message dependencies of

ie d. message dependencies within the envelope of messages addressed to target 49 of the current loop. Operation 640 uses the message priority values predefined in the message priority table 44.

A detailed flowchart of operation 640 is illustrated in FIG. 9. Now referring to FIG. 9, the entries of operation 640 of F1G.8, as shown in FIG 702. 9, are:

i) the message envelope ii) the message list, {Mj ^ ' ⁿ (x}} and iii) the message names, types and targets of the messages in the message list.

The results are the list of dependency elements that are constructed for the inputs. The first processes, 704 and 706, aim to read the message priority table 44 and to find the priority values of the messages M ^ ' ⁿ (x) in the message list. The list of entered messages is then classified according to priority values, from the highest priority values to the lowest priority values. The list of classified messages is denoted}.

Once the messages are classified in an order, then each of the messages in the message list loops in step 708, the verification step 710 makes it possible first to determine whether the message currently envisaged has a value of valid priority defined in message priority table 44. In response to the determination that the message currently being considered at 710 has a valid priority value, the additional check at 720 is called to determine whether the message is the first message in the list messages, If so, the DID of the message Μ? ω ^{, η} [ΐ) 'is assigned to FED de R? ® at 722. At 724 a check is made to determine if the value of RDSTAT is N or V, ie d. if the message envelope is independent of other message envelopes. If this is proven, then at 726 the current message is set to be independent, i.e. that the value D_STAT for e '== N. Otherwise, at 728, the message is set to be dependent, i.e. the value

D_STAT for e -D. The process in FIG. 9 then advances to the next message in the message list at 738.

If the message processed in the current loop is no longer the first message, as determined at 720, the D_ID of the message (x) 'is assigned to the ID of the message M ^' ⁿ (x - 1) ', at 730.

Another check 732 is then performed to determine if the priority value of the message in the current loop is 0. As mentioned above, a priority value of 0 means that the message should not be sent. Consequently, if the priority value = 0 is recognized, DJSTAT of M ^ ^{, n} Çx) 'is set to V. Otherwise, D_STAT of M _/ ^ ^I ' ^{,, n} (x) 'is set to D in operations 734 and 736, respectively. The FIG process. 9 then advances to the next message in the message list, 738.

If, at 710, it is determined that the priority value of the current message should not be set, this means that the message is dependent only on the message envelope Rj ^ s. Consequently, the D_ID is always set to the ID of Rj ^ at 712 (which is identical to operation 722) and DSTAT of the message is set to D at 716 or V at 718, depending on whether RDSTAT from l The message envelope is determined to be N or V at 714. The process of FIG. 9 then advances to the next message in the message list, 738.

Now referring again to FIG. 8, after the operation 640 is concluded, the verification 642 of the RD_STAT dependency of the message envelope is called upon to determine whether the messages of the message envelope can be placed in the queue 46a for sending. If RDJSTAT = N, operation 644 is executed to place the first message in the message envelope, i.e. in queue 46a to be sent first. Then, other messages from the message envelope, Μ ^ ' ^η (χ)', whose D STAT is equal to N are also placed in the queue 46a, at 644.

If at 642 it is determined that RDJSTAT of the message envelope is not N, another check is made to determine if a TTY message is in the message dependency map for message target 49 of the current loop. If so, the message dependency map and updated to 648. More specifically, {M ^ ® ' ⁿ (x) is updated in order to link D_ID de to the TTY message of P (i - 1) or to the message envelope if no TTY is present at 648.

At this point, after operations 644, 646 and 648, respectively, have been concluded, the computation of the message list} is completed and the dependency chain for (P (i) j) is thus defined. In addition, all the messages including D_STAT = N have all been placed in the queue lists 46a for sending these messages to the message targets 49. The results are then stored in the database during the validation operation. 620. The process of FIG. 8 then advances to 626 at the next message target in the message target list.

The process of sequencing and generating NDC 42 messages can be explained further by referring by way of example to the historical updates of the message list, in the illustrative tables I and II provided by way of example which appear. below, both being examples of the dependency map and the message board 45 at a particular point in time.

In this historical update example, the validation indications with respect to the two reservation records, AAAAAA and BBBBBB, are received by the sequencing and generation process of NDC messages 42. Two message targets 49, designated as YY and ZZ, are concerned by these two reservation records and are therefore the receivers of the messages generated by the processing system 50. For the message envelope entries, only the first six columns are filled. Message entries do not include values for the fifth column RD_STAT, as this parameter refers to the dependency on the message envelope.

Table I. Dependency maps for processing of message envelopes 0 and 1

ID P I J RDSTA T D_ID D_STA T NOT TYP E Message 001 AAAAA AT 0 YY S NO The NULL NULL NULL NULL 002 BBBBBB 0 ZZ S NO The NULL NULL NULL NULL 003 AAAAA AT 0 YY NULL 001 S TTY T 004 AAAAA AT 1 ZZ NOT 001 NULL NULL NULL NULL 005 AAAAA AT 1 ZZ NULL 004 S SUPR X 006 BBBBBB 0 ZZ NULL 002 V TTY T 007 AAAAAA I ZZ NULL 005 NOT TTY T M) Y ^{, TTr} P) '

008 BBBBBB 0 ZZ NULL 006 S AJOU T X _M B (0UDD ^ ₂ y 009 BBBBBB I YY NOT 002 NULL NULL NULL NULL 010 BBBBBB 1 YY NULL 009 NOT TTY Y "Λ 011 AAAAA AT 1 YY NOT 001 NULL NULL NULL NULL 012 AAAAAA 1 JT NULL 011 NOT ADDING X j ^ y ^ AULXML

The AAAAAA (O) and BBBBBB (O) message envelopes are the first respective message envelopes of the AAAAAA and BBBBBB reservation records. Thus, the table entries with IDs 001 and 002 are each detected as "first for sequence" during check 632 in FIG. 8. AAAAAA (l) is not the first message envelope, but the first message envelope relating to the AAAAAA reservation record for which at least one message is generated for the message target ZZ. Consequently, the entry of the message envelope table »D 004 is also detected as being the« first for the sequence »during the check 632 in FIG.8. These message envelope table entries do not have the D_ID parameter set and their respective RD_STAT is set to "V" as shown in Table I, because these message envelopes do not depend on other message envelopes for their respective message targets 49. Consequently, the messages, M ^ ' ^TTY (1) and can be sent immediately once they are generated by the NDC 42 message sequencing and generation process, and their DJSTAT is updated to S. (1) 'is the first message in the message list {M% z ⁰ )' ⁿ (x)}, but it is not calculated because it does not need to be sent (for example, because this TTY message has no functional effect on the message target, or because the message target is known to be unsubscribed from the TTY message, etc., see EP 2254046 Bl, paras. [0032] and Figure 7 to which reference is made herein for more context) therefore its DSTAT is ultimately t updated to V. Then the message M ^ z ° ^ ' ^ADD [2)' is then sent and its D_STAT is updated to S. MessagesAi ^ ¹ ) ' ^771, (2)', Μ ^^ ' ^ττγ (1 ) 'and Myy ^' ^XML (iy are calculated and are ready to be placed in the message queue 46a for sending.

Triggered by other changes made to the AAAAAA and BBBBBB database records, the database change indications 2 and 10 of the AAAAAA database record and the database change validation indication 2 of BBBBBB, are received by the NDC 42 message sequencing and generation process when the processing of message envelopes and messages according to Table I is completed by the message sequencing and generation process

NDC 42 and the dependency card and message board 45 have just been validated. Messages sent to message waiting lists 46a have not yet been sent to targets 49.

In response to receiving indications of change validations 2 and 10 from the AAAAAA database record and change validation 2 from the BBBBBB database record, two other message lists, including

M ^ ^aDSL (2), and M% ^2U ' ^ur V ", are generated by the sequencing and generation process of NDC 42 messages for the indication of validation of change AAAAAA (2). In addition, a list of messages, in particular {Μγγ ¹⁰ ^ ' ^ΤΤΥ (1), M ^' ^ADD (2)}, is generated for the indication of validation of change AAAAAA (10), and a list of messages, { Μ $ ²⁾ ' ^ΤΤΥ (1), M ^' ^ADD (2), Μγ ™ '™ ¹ (3)}, is generated for the indication of validation of change BBBBBB (2). Table II represents the dependency map and the message table 45 after all of these message lists have been processed by the NDC 42 message sequencing and generation process.

Table II. Dependency cards for processing message envelopes 2 and 10

ID P I J RDJSTAT DID DJSTAT NOT TYPE Message 001 AAAAAA 0 YY S NULL NULL NULL NULL NULL 002 BBBBBB 0 zz S NULL NULL NULL NULL NULL 003 AAAAAA 0 YY NULL 001 S TTY T 004 AAAAAA 1 zz NOT 001 NULL NULL NULL NULL 005 AAAAAA 1 zz NULL 004 S SUPR X w 006 BBBBBB 0 zz NULL 002 V TTY T 007 AAAAAA 1 zz NULL 005 NOT TTY T 008 BBBBBB 0 zz NULL 006 S ADDING X _M B (0), ADD ^ ₂ y 009 BBBBBB 1 YY NOT NULL NULL NULL NULL NULL 010 BBBBBB 1 yy NULL 009 NOT TTY Y

011 AAAAAA 1 YY NOT 001 NULL NULL NULL NULL 012 AAAAAA 1 YY NULL 011 NOT ADDING X 013 BBBBBB 2 YY D NULL NULL NULL NULL NULL 014 BBBBBB 2 YY NULL 013 D SUPR X _m b (2), dei ^, 015 BBBBBB 2 YY NULL 014 D TTY T 016 AAAAAA 2 zz D 004 NULL NULL NULL NULL 017 AAAAAA 2 YY D 011 NULL NULL NULL NULL 018 AAAAAA 2 zz NULL 007 D TTY T 019 AAAAAA 2 YY NULL 017 D SUPR X _M X (2), D £ L (ip 020 BBBBBB 2 YY NULL 015 D ADDING X M $ ^2Udd (3] ' 021 AAAAAA 2 zz NULL 018 V DIV X _M A (2), _SPL , T _Ç2y 022 AAAAAA 2 YY NULL 019 D TTY T 023 AAAAAA 2 YY NULL 017 D NDC NOT 024 AAAAAA 10 YY U NULL NULL NULL NULL NULL 025 AAAAAA 10 YY NULL 024 D TTY T 026 AAAAAA 10 YY NULL 025 D ADDING X

The classified list {My® ' ⁿ (x)} is made on the basis of the definition of the priority values of the message priority table 44, derivable from the table entries having the IDs 019, 022 and 023. Their envelope of messages Ργγ ² ^ is stored as an array entry with the ID 017. The two messages and M $?) ' ^NDC (3)' have the same dependency parameter D_ID which links the two messages to Ργγ ² \ resulting from checks 710 and 720 as well as operations 712 and 722 (Fig. 9).

The message envelope R ^ / and the classified list are stored as table entries having the IDs 016, 018 and 021. M ^ ² ' ⁾ ' ^7Tr (l) 'in its dependency state D_ID linked to

M ^ ^TTY (2) 'rather than Rz / \ resulting from checks 642 and 646 as well as from operation 648 in FIG. 8. The dependency state D_ID of M ^ ² ^ ' ^{SPL / T} (2)' is calculated as 018 in operation 730 in FIG. 9), but, resulting from verification 732 and from operation 736 (FIG. 9), the state of the DSTAT message is calculated as V.

The Ryy message envelope ²⁾ and the message list {My® ^{, n} (x) '} are stored as table entries with IDs 013, 014, 015 and 020. The Ryy message envelope ¹⁰ ^ and the message list {Λί ^ ¹⁰ ^ ' ^η (χ) 7 are stored as table entries with IDs 024 to 026. The RDSTAT of the Ryy message envelope ¹⁰ - ¹ is calculated as U (Unknown), at 630 in FIG. 8 (e.g. because for some reason the change validation indication 10 has arrived at the message sequencing and generation process 42 before the change validation indication 9 and a publication context inside the change validation indication 10 only shows that there is a previous change validation indication, then the dependency of the message envelope is set to U while waiting for the arrival of the change validation indication 9. Details concerning the calculation of the unknown U state are at if explained in EP 2254046 Bl under par. And Figure 7 to which reference is made herein), and all messages have a DSTAT dependency of D, which means that they will only be queued for sending only when the dependency of the RD STAT message envelope on their message envelope is set to N.

Now referring to FIG. 10, the state message sending machine 46 is responsible for sending the messages which are queued in the message queues 46 a, by updating the dependency state D STAT of these messages. N to S and also updating the state of the message envelopes and of the messages remaining in the message envelopes contained in the dependency card and in the message table 45 after they have been sent to the target 49, c. -to-d. in response to receipt of confirmations received from the message targets, and finally by placing other messages eligible for dispatch in the message queues 46a.

The state message sending machine 46 is active whenever a message is present in the message queue 46a. The state message sending machine 46 removes the message from the queue and at 802 the sending process 47 sends the message, via an established communication chain defined for the message type to the correct message target 49 Legacy TTY messages and XML messages can be sent via different communication chains (eg asynchronously using a dedicated chain for TTY messages and synchronously using SOAP / HTTP for XML messages). Once a message is removed from the queue and sent, based on the message sending method (synchronous or asynchronous), the reception process 48 checks, at 804, whether a confirmation response from the system target (for synchronous mode) or, p. eg from an internal message delegate system (for asynchronous mode) is present, as described by EP 2693337A1. A message is reported as "Sent" (S) to 812 only when a valid confirmation response is received from message target 49 and the confirmation response does not have any error code / information. The retry sending operation which consists of operations 806, 808 and 810 is a secure method for repeating sending operations for messages that have not been delivered successfully (no valid confirmation response received within a given time interval after the message has been transmitted or a confirmation response with an error code is received), for asynchronous mode. Optionally, messages exceeding a given number of attempts are flagged and stored in the queue for retrieval as if they were ultimately not sent (not shown in FIG. 10).

When it is determined, at 804, a valid and correct response is received to the message ^ ρ (ι) η ^ ,, p £ dependency _tat dstat the message is updated to the state S (sent) 812 .

Next, operation 814 is called to check whether M ^ ' ⁿ {yY is the last message in the message list {M ^' ⁿ [x}}. In the affirmative, operation 816 updates the dependency state RDJSTAT at the level of the message envelope of Rj ^J at state S (sent) and stored in the dependency card and in the message table 45, also storing the update D STAT of operation 812. After that, at 818, the state of dependence of the following envelope of messages of the chain of dependencies at the level of the envelope of messages P (i + 1 ), if applicable, is set to RD_STAT = N (no dependency), because all the messages in the current message envelope have been sent and therefore the entire message envelope has been processed entirely. In addition, still at 818, all the messages for which D_ID is set to the ID of R? ( ^{L +} ï \ according to the dependency map and the message table 45, are updated to set their dependency state D_STAT to N. These messages are also placed in the message queue 46a for sending, to 818. Finally, the dependency card and the message table 45 are also validated once more at 822 in order to store the most recent changes in the 'next message envelope in the dependency chain at the level of the message envelope and the following list of messages {Mj ^{(l + 1), n} (x)'}, i.e. the messages of the next envelope of messages ..

If, at 814, it is determined that the current message is not the last message in the message list, operation 820 is called to select the messages eligible for sending: all messages for which D_ID is set to ID from '(i.e. all messages that depend on the current message that was successfully delivered to the target) are selected from the dependency map and message table 45, their DSTAT dependency status is set to N and these messages are placed in the message queue 46a for sending. After that, operation 822 is called to validate the dependency card and the message table 45 in order to store the most recent changes to the message lists and

The state machine for sending messages 46 can be illustrated moreover with reference to Table II already discussed above. First, the dependency maps are updated after the successful sending of (2) ',' and M $ y ^ ' ^XML [ïy as illustrated in the

FIG. 11 with Table III, representing the state of the dependency card and the message table at this stage.

When the last message in a message list, i.e. inside a message envelope R _} -, is successfully sent to the message target, the message envelope table entry in the dependency card and in the message table 45 is updated to complete the message sending processing for the current Rj® message envelope. For example, the following table entries are updated in operation 816 in FIG. 10, as shown visually by the arrows in FIG. 11:

- The successful transmission of the message with ID = 007 rule D_STAT = S which means that all messages in the message envelope with ID = 004 have been sent. Therefore, the dependency on the message envelope level can be set to "sent" too, ie. that RDSTAT of the message envelope ID = 004 is set to S.

- The message with ID = 010 is the only message in the message envelope ID = 009. Thus, when the message ID = 010 is successfully transmitted, its D_STAT is set to

S and the envelope envelope dependency can also be set to "sent", ie. that RDJSTAT of the message envelope ID = 009 is set to S.

- Similarly, the message with ID = 012 is the only message in the message envelope ID = 11. Thus, when the message ID = 12 is successfully transmitted, its ID_STAT is set to S and the dependency on the message envelope can also be set to "sent", ie. RD_STAT of the message envelope ID = 011 is set to S.

Then, the updates of the dependencies at the level of the message envelope continue with the following envelopes R ^ ^{l + 1)} which depend on the message envelopes Rj ^ which have been set to RD_STAT = S in operation 818 of the FIG. 10. Generally, the RDSTAT of the following envelope of messages R ^ ^{l + 1} ^ is updated to N each time that the message envelope R ^ on which the message envelope R depends _; ^ ^{I + 1} ^ is set to S. in the example in Table III in FIG. 11, the transitions (indicated again by the respective arrows in FIG. 11) are as follows:

- In response to the RD_STAT setting of the message envelope ID = 004 on S, the state of dependence on the level of the message envelope of the message envelope with ID = 016 depending on the message envelope ID = 004 (i.e. having D_ID = 004) is set to RD_STAT = N.

- In response to the RD STAT setting of the message envelope ID = 009 on S, the state of dependence on the level of the message envelope of the message envelope with ID = 013 depending on the message envelope ID = 009 (i.e. having D_ID = 009) is set to RD_STAT = N.

- In response to the RD STAT setting of the message envelope ID = 011 on S, the state of dependence on the level of the message envelope of the message envelope with ID = 017 depending on the message envelope ID = 011 (i.e. having D_ID = 011) is set to RD_STAT = N.

In response to these RD_STAT dependency state updates at the message envelope level, the first messages in the updated message envelopes, i.e. whose dependency is on Rj ^ ^{l + 1} \ are updated and placed in the queue, for sending, during operation 818 in FIG. 10. For example, referring again to FIG. 11, the following messages are marked as no longer dependent:

- In response to the RDSTAT setting of the message envelope ID = 013 to N, the state of dependence on the level of the message envelope of the message envelope ID = 014 being the first message in the message envelope ID = 013 (i.e. having D_ID = 013) is set to D_STAT = N and passed to message queue 46a.

- In response to the RDSTAT setting of the message envelope ID = 017 to N, the state of dependence on the level of the message envelope of the message envelope with ID = 019 and ID = 023 being both first messages in the message envelope ID = 017 (i.e. having D_ID = 13 that there is no dependency between these two messages) is set to D_STAT = N and the two messages are transmitted to the message queue 46a.

FIG operation 818. 10 also checks to see if there are any dependencies on legacy messages that need to be updated due to successful message sending and when the messages have been set to N (independent). For example, the legacy standard message ID = 108 relating to change validation indication 2 (i.e. 1 = 2) has a message level dependence on the message ID = 107 (i.e. i.e. D_ID = 007) which belonged to the message envelope ID = 004 and was sent successfully. Consequently, the state of dependency of the message ID = 018 is set to N and the message ID = 108 is also transmitted to the queue 46a for sending.

For the sake of completeness, it should be noted that the inherited message ID = 018 is a special case since it is an optional function of the message processing engine 50 to construct a direct dependency chain at the message level between TTY legacy messages for each message target for the same database record. The inherited message ID = 007 in the message envelope ID = 004 is a usual message having a dependency on the message compared to the message ID = 005 inside the message envelope ID = 004. On the other hand, the inherited message ID = 018 currently belongs to the message envelope ID = 016 and its D_ID should therefore be 016. However, since it is an inherited message, a particular process of calculating inherited dependency sets its D_ID = 007 instead of D_ID = 016 because sending the inherited message ID = 018 doing so immediately after the inherited message = 007 does not affect the sequence and dependency of any other XML messages in the message envelope (here: message ID = 021), i.e. that the message level dependency chain is kept for change validation indications reported NDC.

The dependency maps defined by the dependency map and the message table 45 after the successful sending of the first messages mentioned above (messages with IDs 014, 019, 023 and 018) are illustrated in Table IV of FIG . 12. The state of dependence on the message level of messages with IDs 014, 019, 023 and 018 is set to D_STAT = S in response to reception by the reception process 48 of the respective confirmation responses.

Next, FIG operation 820. 10 updates the dependency state at the message level of the following messages in the respective message envelopes on the basis of the chain of dependencies at the level of the message being defined by the dependency map and the message table 45. In the example of FIG. 12, the following dependency updates are made at the message level:

- In response to the successful transmission of message ID-014, the message-dependent state of message ID = 014 is set to "sent", ie. D_STAT = S. The state of dependence on the message level of the next message depending on the message ID = 0014, in particular the message ID = 015 (having D ID 014) is then set to independent, i.e. D_STAT = N, and message ID 015 is passed to the message queue 46a for dispatch.

- In the same way, in response to the successful transmission of the message ID = 019, the state of dependence on the message level of the message ID = 019 is set to "sent", ie. D_STAT = S. The state of dependence on the message level of the following message depending on the message ID = 0019, in particular the message with ID = 022 (having

D ID 019) is then set to independent, i.e. D STAT ^ N, and message ID 022 is passed to the message queue 46a for dispatch.

In addition, at the level of the message envelope, the message envelope with ID = 016 (Rzz ^} is updated to S, because the message with ID = 018 (Λί ^ ^ζ ^ ' ^ΓΤΓ (1)) was the only message in dependency chain to be sent to message target ZZ (message ID = 021 also belongs to message envelope ID = 016, but it has a canceled status [D_STAT = V] and therefore will not be sent) and the message ID = 018 has been sent.

The dependency maps defined by the dependency map and the message table 45 are shown in FIG. 13 with Table V after all of the above messages are sent. FIG. 13 also indicates the following updates to the message envelope dependencies and the message level dependencies:

After the message ID_022 has been successfully sent, its dependency on the D_STAT message is set to S. This also means that all the messages in the message envelope ID = 017 have been delivered successfully. Therefore, the dependency on the message envelope can also be set to "sent", ie. that RDSTAT of the message envelope ID = 017 is set from N to S.

- After the message ID_015 has been sent successfully, its state of dependence on the DSTAT message is set to S. The next message depending on the message ID_015 is the message ID = 020 (having D_ID = 015). Consequently, the message level dependence of the message ED = 015 is set to N and the message is transmitted to the message queue 46a for sending.

- FIG. 13 already indicates with "(S)" that the message dependency state of the message ID = 020 will later be set to "sent" in response to the receipt of a corresponding confirmation response from the message target YY.

- Then, FIG. 13 also indicates, in response to determining successful delivery of message ID_020, that the message envelope dependency of the message envelope ID = 013 will be set to "sent (S) because the message ID = 020 was the last message in this message envelope.

Finally, FIG. 14 is a schematic representation of a computer system 100 which provides the functionality of the message processing system 50 described above. The computer system 100 may include a set of instructions which cause the computer system 100 to implement any of the methods and activities of the message processing system 50 as described above. The computer system 100 includes one or more processors 101, a main memory 102 and a network interface device 103 which communicate with each other via a bus 104. Said at least one processor 101 includes at least one central processor unit , CPU, having cache program instructions for implementing the message processing methods which are described herein. Optionally, the computer system 100 can also include a static memory 105 and a disk drive unit 106. A video display 107, an alphanumeric input device 108 and a cursor control device 109 constitute a man-machine interface in order to operate the computer system 100. The network interface device 103 is a wired and / or wireless interface which connects the message processing system 50 to any number and any type of other systems, including a reservation engine NDC 40, a legacy GDS reservation engine 41 and message targets 49. Message targets 49 can be hosted on the Internet and / or any other network. The network interface device 103 uses either standard communication protocols such as HTTP / TCP / a stack of IP protocols, IEEE 802.11 and / or patented communication protocols.

A set of instructions (i.e. software) 110 representing any or all of the methods described above is hosted completely, or at least partially, in or on a computer-readable medium, p . ex. main memory 102 and / or said at least one processor 101 with said at least one CPU cache. Among others, the instructions can implement the functions of the message processing system to process the incoming database change validations and messages as well as to queue the messages sent as described in detail above. A computer-readable medium on which the software 110 and hosted can also be a non-volatile data medium 111 (eg a non-removable magnetic hard disk or a removable optical or magnetic disk) which is part of the drive unit disk 106. The software 110 can also be transmitted or received in the form of a propagated signal 112 via the Internet via the network interface device 103.

To summarize, the methods described herein facilitate the generation of a dependency chain both at the level of the message envelope and at the message level. The dependency relationships between the message envelopes and the message are configurable by (re ) defining given message priority values. Overall, a generic structure is presented which supports both legacy message flows, e.g. ex. TTY messages as well as more sophisticated hybrid message flows according to an advanced standard such as

NDC. The structure is extensible, as more sophisticated standards and message flows can be added without problem.

Although certain products and processes constructed according to the teachings of the invention have been described herein, the scope of coverage of this patent is not limited to them. On the contrary, this patent covers all the embodiments of the teachings of the invention which reasonably fall within the scope of the appended claims, either literally or in the light of the doctrine of equivalents.

Claims (3)

1. A method for processing messages in a distributed messaging system with a plurality of message targets in which at least one message target of the plurality of message targets operates according to a first standard and at least one message target of the plurality of message targets Sanctions according to a second inherited standard, the method being implemented by a message processing engine, the method comprising: - receiving a plurality of database validation indications, each database validation indication indicating a change in a database record; - in response to the receipt of a database validation indication from the plurality of database validation indications, the generation of a message envelope for each message target to be notified as functional according to the first standard and at least one message in each message envelope; - calculating the message envelope dependencies between the message envelopes generated for the same message target, the message envelope dependencies defining an order of the message envelopes for the same message target; - calculating the message dependencies between the messages in each message envelope based at least on the message standard of the respective message envelope and the message functions, the message dependencies defining an order of the messages in each envelope messages; - sending messages to the respective message target in a sequence based on message envelope dependencies and message dependencies. 2. The method according to claim 1 further comprising - in response to the reception of a first indication of validation of a database of the plurality of indications of validation of database coming from a database system which operates according to the first standard, the generation a message envelope for each message target to be notified and the generation of at least one message in each message envelope, comprising: o the generation of a first message envelope with a plurality of first interdependent messages to be relayed to a first message target which operates according to the first standard, in which the plurality of first interdependent messages is specified according to the first standard; o the generation of a second message to be relayed to a second message target which operates according to a second inherited standard, in which the second message is specified in accordance with the second inherited standard; - calculating the message envelope dependencies between the first message envelope and other message envelopes, the envelope dependencies defining the order of the message envelopes for the first message target; the calculation of each message envelope between the first messages of the first message envelope on the basis at least of the first message target and of the functions of the first messages, the message dependencies defining the order of the messages in each envelope messages; - sending the first messages to the first message target in a sequence based on the message envelope dependencies and on the message dependencies. The method according to claim 2 further comprising: - in response to the reception of a second indication of validation of a database from the plurality of indications of validation of database coming from a legacy database system which operates according to the second standard, the generation of a third message for each message target to be notified, wherein the third message is a message according to the second inherited standard, and o sending the third message without calculating a message dependency for the third message in response to the determination that there is no longer a message waiting to be sent for the message target of the third message, or o in response to the determination that at least one other message is waiting to be sent to the message target of the third message, the computation of the message dependence of the third message based at least on the message target and the function of the third message, the dependencies of the defined messages ant the order of the messages for the message target of the third message and the sending of said at least one other message and of the third message to the message target of the third message in a sequence based on the dependencies of the message envelope and on message dependencies. 4. The method according to any one of claims 1 to 3 further comprising: - the allocation, for each message envelope, of a priority value given for each of the pluralities of interdependent messages depending at least on the standard of the message and the type of message; and - the calculation of the message dependence between the messages with each message envelope on the basis of the priority values assigned. 5. The method of any of claims 1 to 4, comprising sending a message in response to determining that the message is independent of any other message in the message envelope of the message and that the The message envelope of the message is independent of any other message envelope. 6. The method according to claim 5, further comprising updating the message dependency of the message sent and, where appropriate, the message dependence of the following message, according to the order of the message in the envelope. message messages. 7. The method according to claim 5 or claim 6, further comprising updating the message envelope dependency for the message envelope of the message sent and, if necessary, updating the dependency of the envelope for the next message envelope in the order of the message envelopes in response to determining that the message sent was the last message in the order of the messages in the message envelope of the sent messages. 8. A message processing engine for processing messages in a distributed messaging system with a plurality of message targets, wherein at least one message target of the plurality of message targets operates according to a first standard and at least one message target of the plurality of message targets operates according to a second inherited standard, the message processing engine being arranged for: - receive a plurality of database validation indications, each validation indication of a database indicating a change of a record of a database; - in response to the receipt of a database validation indication of the plurality of database validation indications, generating a message envelope for each message target to be notified which operates according to the first standard and at least one message in each message envelope; - calculate the message envelope dependencies between the message envelopes generated for the same message target, the message envelope dependencies defining an order of the message envelopes for the same message target; - calculate the message dependencies between the messages in each message envelope based at least on the message standard of the respective message envelope and the message functions, the message dependencies defining an order of the messages in each envelope messages; - send the messages to the respective message target in a sequence based on the message envelope dependencies and on the message dependencies. 9. The message processing engine of claim 8 being further arranged to: - in response to receipt of a first validation indication from a first database of the plurality of database validation indications from a database system that operates according to the first standard, generate a message envelope for each message target to be notified and generate at least one message in each message envelope, comprising: o the generation of a first message envelope with a plurality of first interdependent messages to be relayed to a first message target which operates according to the first standard, in which the plurality of first interdependent messages is specified according to the first standard; o the generation of a second message to be relayed to a second message target which operates according to a second inherited standard, in which the second message is specified in accordance with the second inherited standard; - calculating the message envelope dependencies between the first message envelope and other message envelopes already waiting for the first message target, the envelope dependencies defining the order of the message envelopes for the first target message; - the calculation of the message dependencies between the first messages of the first message envelope based at least on the first message target and on the functions of the first messages, the message dependencies defining the order of the messages in each message envelope; - sending the first messages to the first message target in a sequence based on the message envelope dependencies and the message dependencies. 10. The message processing engine of claim 9 being further arranged to: - in response to receiving a second validation indication from a database of the plurality of database validation indications from a legacy database system that operates according to the second standard, generate a third message for each message target 5 to be notified, wherein the third message is a message conforming to the second legacy standard, and o send the third message without calculating a message dependency for the third message in response to the determination that there are no more message waiting to be sent for the third message target Message 10, or o in response to determining that at least one other message is waiting to be sent to the message target of the third message, calculating the message dependency of the third message based on at least the message target and the function of the third message, the dependencies 15 of message defining the order of messages for the message target of the third message and sending said at least one other message and the third message to the message target of the third message in a sequence based on the dependencies of the message envelope and on message dependencies. 11. The message processing engine according to any one of claims 8 to 10 being moreover arranged to implement the method according to any one of claims 4 to 7. 12. A computer program product for processing messages in a distributed messaging system with a plurality of message targets, wherein at least one message target of the plurality of message targets operates on a first standard and at at least one message target of the plurality of message targets operates according to a second legacy standard, the computer program product comprising 3f) program code instructions stored on a computer-readable medium for executing the steps of the method according to any one of claims 1 to 7 when said program is running on a computer.