A method and electronic device for issuing flight schedules

Abstract

This application provides a flight schedule publishing method and electronic device, relating to the field of message processing technology. The method includes: acquiring a flight change message, the flight change message including a change type identifier for the corresponding flight; based on the change type identifier, converting the flight change message into a standardized message using pre-processing rules; sending the standardized message to a flight schedule processing system for flight change, and receiving change result information from the flight schedule processing system; and adjusting the changed flight status data using post-processing rules based on the change type identifier and change result information to achieve flight schedule publishing. This application embodiment can be used in the field of aviation message processing, enabling differentiated and precise message processing and data adjustment for different flight change types, achieving precision and efficiency in the flight schedule publishing process.

Description

Technical Field

[0001] This application relates to the field of message processing technology, and in particular to a flight schedule publishing method and electronic device. Background Technology

[0002] When airlines make planned flight adjustments (such as adding or canceling flights, changing aircraft types, or altering flight schedules), existing technologies can achieve basic interaction between messages and systems such as flight planning and protection systems to complete flight change processing. However, they often use a generalized processing approach to meet the diverse actual business scenarios in civil aviation, making it difficult to match the business needs of different types of flight changes, resulting in insufficient adaptability of message processing to business scenarios. Summary of the Invention

[0003] The purpose of this application is to provide a flight schedule publishing method and electronic device, which aims to perform differentiated and precise message processing and data adjustment for different types of flight changes, thereby achieving precision and efficiency in the flight schedule publishing process.

[0004] Firstly, this application provides a method for publishing flight schedules, the method comprising: obtaining a flight change message, the flight change message including a change type identifier for the corresponding flight; based on the change type identifier, converting the flight change message into a standardized message through pre-processing rules, the pre-processing rules matching the change type identifier, and the standardized message conforming to the data format requirements of the flight schedule processing system; sending the standardized message to the flight schedule processing system for flight change, and receiving change result information from the flight schedule processing system, the change result information including at least the changed flight status data; and adjusting the changed flight status data through post-processing rules based on the change type identifier and the change result information to realize the publication of the flight schedule, the post-processing rules matching the change type identifier.

[0005] The flight schedule publishing method provided in this application obtains flight change messages containing change type identifiers, providing accurate business scenario identification for subsequent processing and solving the problem that generalized processing cannot distinguish between different change types. Then, based on the change type identifier, corresponding pre-processing rules are matched to convert the message into a standardized format, ensuring that various flight change information can be accurately parsed by the flight schedule processing system, avoiding data corruption or processing failures due to format incompatibility. Subsequently, the standardized message is sent to the flight schedule processing system for flight changes and the change result information is received, realizing an automated closed loop for change operations and effectively improving processing efficiency. Finally, based on the change type identifier and change result information, post-processing rules are matched to make targeted adjustments to the changed flight status data, enabling flight schedule publishing to meet the specific needs of different business scenarios such as additions, cancellations, and aircraft type adjustments, thereby enhancing the adaptability of message processing to business scenarios and achieving precision and efficiency in the flight schedule publishing process.

[0006] In conjunction with the first aspect mentioned above, in one possible implementation, when the change type identifier is a new flight identifier, the flight change message is converted into a standardized message through pre-processing rules, including: parsing the flight change message to obtain the plan information of the flight to be created, the plan information including at least flight identifier information, flight seat information, and flight lock information; if there is no flight identifier information matching the flight to be created in the flight plan processing system, a standardized message for creating the new flight is generated based on the plan information of the new flight.

[0007] In conjunction with the first aspect mentioned above, in one possible implementation, the changed flight status data is adjusted based on the change type identifier and change result information through post-processing rules, including: in response to the change result information indicating successful creation of the flight to be created, adjusting the changed flight status data based on the plan information of the flight to be created, wherein the flight status data includes at least flight reservation data and flight lock data.

[0008] In conjunction with the first aspect mentioned above, in one possible implementation, when the change type identifier is a deleted flight identifier, the flight change message is converted into a standardized message through pre-processing rules, including: parsing the flight change message to obtain the segment to be deleted for the flight to be deleted; obtaining the inventory segment that matches the flight to be deleted in the flight scheduling system; if the segment to be deleted matches the inventory segment, generating a standardized message for deleting the flight based on the segment to be deleted; if the segment to be deleted is less than the inventory segment, changing the change type identifier of the flight change message to a comprehensive change identifier, and converting the flight change message into a standardized message through pre-processing rules that match the comprehensive change identifier.

[0009] In conjunction with the first aspect mentioned above, in one possible implementation, the changed flight status data is adjusted based on the change type identifier and change result information through post-processing rules, including: in response to the change result information indicating successful deletion of the flight to be deleted, obtaining the reservation data of the flight to be deleted; and triggering protection processing for the passenger corresponding to the reservation data based on the reservation data, the protection processing being used to adjust the passenger to an alternative flight.

[0010] In conjunction with the first aspect mentioned above, in one possible implementation, when the change type identifier is a time change identifier, the flight change message is converted into a standardized message through pre-processing rules, including: parsing the flight change message to obtain the identifier information and target time information of the flight to be changed; if a target flight matching the identifier information exists in the flight planning system, obtaining the associated itinerary information of the target flight; if the associated itinerary information indicates that the time change does not affect passenger flight connections, generating a standardized message for flight time change based on the target time information; if the associated itinerary information indicates that the time change affects passenger flight connections, constructing a first flight change message and a second flight change message based on the identifier information and target time information of the flight to be changed, wherein the change type identifier of the first flight change message is a deleted flight identifier, and the change type identifier of the second flight change message is a new flight identifier.

[0011] In conjunction with the first aspect mentioned above, in one possible implementation, the changed flight status data is adjusted based on the change type identifier and change result information through post-processing rules, including: in response to the change result information indicating that the time of the target flight has been successfully updated, the changed flight status data is adjusted according to the target time information, and the flight status data includes at least flight seat reservation data and flight lock data.

[0012] In conjunction with the first aspect mentioned above, in one possible implementation, when the change type identifier is an aircraft type change identifier, the flight change message is converted into a standardized message through pre-processing rules, including: parsing the flight change message to obtain the flight identifier information and target aircraft type data of the flight to be changed; and generating a standardized message for flight type change based on the target aircraft type data when there is a target flight matching the flight identifier information in the flight planning system.

[0013] In conjunction with the first aspect mentioned above, in one possible implementation, the flight status data after the change is adjusted based on the change type identifier and change result information through post-processing rules, including: in response to the change result information indicating a successful change of the flight to be changed, obtaining the reservation data of the flight to be changed; if the aircraft type data indicates that the passenger capacity of the flight after the change is less than that of the flight before the change, triggering protection processing for the passengers corresponding to the reservation data based on the reservation data, the protection processing is at least used to adjust passengers who cannot be accommodated by the flight after the change to alternative flights.

[0014] In conjunction with the first aspect mentioned above, in one possible implementation, when the change type identifier is a comprehensive change identifier, the flight change message is converted into a standardized message through pre-processing rules, including: parsing the flight change message to obtain the identifier information, target time information, and target aircraft type data of the flight to be comprehensively changed; obtaining the inventory information of the target flight that matches the identifier information in the flight planning system; determining the change relationship between the flight to be comprehensively changed and the target flight based on the inventory information, target time information, and target aircraft type data; and determining the standardized message generation method that matches the comprehensive change identifier based on the change relationship to generate a standardized message.

[0015] In conjunction with the first aspect mentioned above, in one possible implementation, based on the change relationship, a standardized message generation method matching the comprehensive change identifier is determined to generate a standardized message. This includes: when the change relationship indicates that the flight to be comprehensively changed is a new flight, the change type identifier of the flight change message is converted to a new flight identifier, and a standardized message is generated through pre-processing rules matching the new flight identifier; when the change relationship indicates that the flight to be comprehensively changed is a segment cancellation of the target flight, and the updated segment information has no overlap with the segment information before the update, the change type identifier of the flight change message is converted to a deleted flight identifier, and a standardized message is generated through pre-processing rules matching the deleted flight identifier; when the change relationship indicates that the flight to be comprehensively changed is an update of the aircraft type and / or time of the target flight, a standardized message for updating the target flight is generated based on the target aircraft type information and target time data.

[0016] Secondly, this application provides a flight schedule publishing device, comprising: a message acquisition module, a message conversion module, a communication module, and a data adjustment module. The message acquisition module acquires flight change messages, which include a change type identifier for the corresponding flight. The message conversion module converts the flight change message into a standardized message based on the change type identifier using pre-processing rules that match the change type identifier. The standardized message conforms to the data format requirements of the flight schedule processing system. The communication module sends the standardized message to the flight schedule processing system for flight change and receives change result information from the system, including at least the changed flight status data. The data adjustment module adjusts the changed flight status data based on the change type identifier and the change result information using post-processing rules to publish the flight schedule, where the post-processing rules match the change type identifier.

[0017] In conjunction with the second aspect above, in one possible implementation, when the change type identifier is a new flight identifier, the message conversion module is specifically used to: parse the flight change message to obtain the plan information of the flight to be created, the plan information including at least flight identifier information, flight seat information and flight lock information; and, if there is no flight identifier information matching the flight to be created in the flight plan processing system, generate a standardized message for creating the new flight based on the plan information of the new flight.

[0018] In conjunction with the second aspect above, in one possible implementation, the data adjustment module is specifically used to: respond to the change result information indicating successful creation of the flight to be created, and adjust the changed flight status data based on the plan information of the flight to be created, wherein the flight status data includes at least flight reservation data and flight lock data.

[0019] In conjunction with the second aspect above, in one possible implementation, when the change type identifier is a deleted flight identifier, the message conversion module is specifically used to: parse the flight change message to obtain the segment to be deleted for the flight to be deleted; obtain the inventory segment that matches the flight to be deleted in the flight scheduling system; if the segment to be deleted matches the inventory segment, generate a standardized message for deleting the flight based on the segment to be deleted; if the segment to be deleted is less than the inventory segment, change the change type identifier of the flight change message to a comprehensive change identifier, and convert the flight change message into a standardized message through a pre-processing rule that matches the comprehensive change identifier.

[0020] In conjunction with the second aspect above, in one possible implementation, the data adjustment module is specifically used to: in response to a change result information indicating successful deletion of the flight to be deleted, obtain the reservation data of the flight to be deleted; and, based on the reservation data, trigger protection processing for the passenger corresponding to the reservation data, the protection processing being used to adjust the passenger to an alternative flight.

[0021] In conjunction with the second aspect above, in one possible implementation, when the change type identifier is a time change identifier, the message conversion module is specifically used to: parse the flight change message to obtain the identifier information and target time information of the flight to be changed; if a target flight matching the identifier information exists in the flight planning system, obtain the associated itinerary information of the target flight; if the associated itinerary information indicates that the time change does not affect passenger flight connections, generate a standardized message for flight time change based on the target time information; if the associated itinerary information indicates that the time change affects passenger flight connections, construct a first flight change message and a second flight change message based on the identifier information and target time information of the flight to be changed, wherein the change type identifier of the first flight change message is a deleted flight identifier, and the change type identifier of the second flight change message is a new flight identifier.

[0022] In conjunction with the second aspect above, in one possible implementation, the data adjustment module is specifically used to: respond to the change result information indicating that the time of the target flight has been successfully updated, and adjust the changed flight status data according to the target time information. The flight status data includes at least flight seat reservation data and flight lock data.

[0023] In conjunction with the second aspect above, in one possible implementation, when the change type identifier is an aircraft type change identifier, the message conversion module is specifically used to: parse the flight change message to obtain the flight identifier information and target aircraft type data of the flight to be changed; and, if there is a target flight in the flight planning system that matches the identifier information, generate a standardized message for flight type change based on the target aircraft type data.

[0024] In conjunction with the second aspect above, in one possible implementation, the data adjustment module is specifically used to: in response to the change result information indicating a successful change of the flight to be changed, obtain the reservation data of the flight to be changed; if the aircraft type data indicates that the passenger capacity of the changed flight is less than that of the original flight, trigger protection processing for the passengers corresponding to the reservation data based on the reservation data, and the protection processing is at least used to adjust the passengers that the changed flight cannot accommodate to alternative flights.

[0025] In conjunction with the second aspect above, in one possible implementation, when the change type identifier is a comprehensive change identifier, the message conversion module is specifically used to: parse the flight change message to obtain the identifier information, target time information, and target aircraft type data of the flight to be comprehensively changed; obtain the inventory information of the target flight matching the identifier information in the flight planning system; determine the change relationship between the flight to be comprehensively changed and the target flight based on the inventory information, target time information, and target aircraft type data; and determine the standardized message generation method matching the comprehensive change identifier based on the change relationship to generate a standardized message.

[0026] In conjunction with the second aspect above, in one possible implementation, the message conversion module is specifically used for: converting the change type identifier of the flight change message into a new flight identifier when the change relationship indicates that the flight to be comprehensively changed is a new flight, and generating a standardized message through pre-processing rules matching the new flight identifier; converting the change type identifier of the flight change message into a deleted flight identifier when the change relationship indicates that the flight to be comprehensively changed is a segment cancellation of the target flight, and the updated segment information has no overlap with the segment information before the update, and generating a standardized message through pre-processing rules matching the deleted flight identifier; and generating a standardized message for updating the target flight based on the target aircraft type information and target time data when the change relationship indicates that the flight to be comprehensively changed is an update of the aircraft type and / or time of the target flight.

[0027] Thirdly, this application provides an electronic device comprising: a processor and a memory; the memory storing processor-executable instructions; when the processor is configured to execute the instructions, the electronic device implements the method of the first aspect described above.

[0028] Fourthly, this application provides a computer-readable storage medium comprising: computer software instructions; which, when executed in an electronic device, cause the electronic device to implement the method described in the first aspect.

[0029] Fifthly, this application provides a computer program product that, when run on a computer, causes the computer to perform the steps of the relevant method described in the first aspect above, so as to implement the method of the first aspect above.

[0030] The beneficial effects of the second to fifth aspects mentioned above can be referred to the corresponding description of the first aspect, and will not be repeated here. Attached Figure Description

[0031] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0032] Figure 1 A flowchart illustrating a flight schedule publishing method provided in this application embodiment; Figure 2 A flowchart illustrating a pre-processing method for deleting flight messages provided in this application embodiment; Figure 3 A flowchart illustrating a method for post-processing the deletion of flight messages provided in this application embodiment; Figure 4 A flowchart illustrating a method for pre-processing flight schedule change messages provided in this application embodiment; Figure 5 A flowchart illustrating a pre-processing method for a comprehensive flight change message provided in this application embodiment; Figure 6 A detailed flowchart illustrating a flight schedule publishing method provided in this application embodiment; Figure 7 This is a schematic diagram illustrating the composition of a flight schedule publishing device provided in an embodiment of this application; Figure 8 This is a schematic diagram of a flight schedule publishing device provided in an embodiment of this application. Detailed Implementation

[0033] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0034] It should be noted that in the embodiments of this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplarily" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0035] In the embodiments of this application, the terms "first," "second," "third," "fourth," "fifth," and "sixth" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first," "second," "third," "fourth," "fifth," and "sixth" may explicitly or implicitly include one or more of that feature.

[0036] In embodiments of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0037] "A and / or B" includes the following three combinations: A only, B only, and a combination of A and B.

[0038] This application provides a method for publishing flight schedules. By acquiring flight change messages containing change type identifiers, it provides accurate business scenario identification for subsequent processing, thus solving the problem that generalized processing cannot distinguish between different change types. Then, based on the change type identifier, it matches the corresponding pre-processing rules to convert the message into a standardized format, ensuring that various flight change information can be accurately parsed by the flight schedule processing system, avoiding data corruption or processing failures due to format incompatibility. Subsequently, the standardized message is sent to the flight schedule processing system for flight changes and the change result information is received, realizing an automated closed loop for change operations and effectively improving processing efficiency. Finally, based on the change type identifier and change result information, it matches post-processing rules to make targeted adjustments to the changed flight status data, enabling flight schedule publishing to meet the specific needs of different business scenarios such as additions, cancellations, and aircraft type adjustments. This enhances the adaptability of message processing to business scenarios and achieves precision and efficiency in the flight schedule publishing process.

[0039] The flight schedule publishing method provided in this application can be widely applied to various business scenarios involving flight schedule formulation, adjustment, and publishing in civil aviation flight operation management. This application does not impose any restrictions on the specific application scenario's civil aviation operating entity, flight operation scale, or frequency of flight schedule changes. For example, the embodiments of this application can be applied to the core flight schedule management scenario of an airline headquarters. This addresses the business needs of daily flight adjustments (such as aircraft type changes, minor timetable adjustments, and flight additions / deletions) across the entire trunk and feeder route network, as well as large-scale seasonal flight schedule restructuring. The method provided in this application can automatically complete standardized conversion, cross-system interaction, and differentiated post-processing based on the type identifier of flight change messages. This achieves automated and standardized processing of all flight schedule changes, reduces repetitive manual work, and ensures the accuracy and timeliness of flight schedule publication across the entire network.

[0040] For example, the embodiments of this application can be applied to local flight schedule adjustments for airline branches / bases. Facing temporary flight change requests specific to the base (such as emergency flight cancellations / slot changes due to airport support or weather factors), the method provided in this application supports manually importing emergency flight change messages and assigning them priority processing permissions. Through rapid pre-rule matching and standardized conversion, it enables the rapid release of temporary flight schedules. Simultaneously, it triggers corresponding passenger protection processing procedures, adapting to the rapid response needs of unexpected scenarios in civil aviation operations.

[0041] For example, the embodiments of this application can be applied to scenarios involving the collaborative release of flight schedules by civil aviation agencies / airline alliances. Facing the collaborative needs for schedule changes in multi-airline intermodal and code-share flights, the method provided in this application can uniformly parse and process standardized flight change messages submitted by different entities. Through cross-system linkage with the flight schedule processing system and passenger protection system, it achieves synchronous release of intermodal flight schedule changes and unified push of passenger protection results. This effectively ensures the consistency of flight schedules and the continuity of passenger services in multi-entity collaborative scenarios, reducing the communication and operational costs of cross-entity flight schedule management.

[0042] The following detailed description of a flight schedule publishing method provided by this application, in conjunction with specific embodiments and accompanying drawings, provides an example of such a method.

[0043] The flight schedule publishing method provided in this application embodiment can be implemented by a flight schedule publishing system deployed on a computing device. This system can adopt a modular design to adapt to the system architecture requirements of civil aviation flight operation management, possessing full-process processing capabilities for flight change message parsing, standardized conversion, cross-system interaction, and flight status data adjustment. It can be deployed as an independent software module on the local servers or cloud computing environments of airlines and civil aviation operators. It can also be deeply integrated with existing civil aviation flight schedule processing systems, flight protection processing systems, and passenger service systems to achieve seamless connection and data linkage with existing civil aviation business systems.

[0044] This flight scheduling system can be flexibly deployed in single-machine, cluster, or cloud-native modes according to the actual deployment needs of civil aviation operations. It runs on various computing devices such as general-purpose servers and cloud computing nodes, and can interface with civil aviation industry standard network transmission protocols and data interaction interfaces to ensure stable communication with upstream and downstream systems. Meanwhile, the system's core processing modules can be flexibly expanded and adapted according to business needs, supporting targeted processing of different types of flight change messages to meet the diverse business scenarios required in civil aviation flight scheduling management.

[0045] Figure 1 This is a flowchart illustrating a flight schedule publishing method provided in an embodiment of this application. For example, as shown... Figure 1 As shown, it includes the following: S101, Obtain flight change message.

[0046] The flight change message includes the change type identifier for the corresponding flight.

[0047] In this embodiment, a flight change message refers to a standardized data file used to transmit information related to changes in civil aviation flight plans. It is the core data carrier for airlines to submit flight adjustment requests to the flight planning system, enabling standardized transmission and parsing of flight change information. A change type identifier is a feature embedded in the flight change message, used to identify the type of flight plan change corresponding to the message, providing a basis for differentiated processing of subsequent messages.

[0048] In some embodiments, a flight change message may include: a change type identifier, basic flight identifier information, flight segment related data, and flight schedule time information. It may also include aircraft type data, seat configuration data, and remarks related to flight locking or seat reservation. Additionally, it will include basic attribute information of the message itself, such as message date, message source identifier, and processing priority identifier. All data is organized according to the standard format for civil aviation flight information transmission to ensure the accuracy of data parsing.

[0049] In some embodiments, the flight schedule publishing system can access a preset file transfer protocol server and retrieve flight change messages uploaded by airlines in a designated storage directory on the server. These messages contain the original message data generated by the airlines based on flight adjustment decisions. The system can also retrieve flight change messages manually created and submitted by operators in the system, thus meeting the needs for retrieving messages from different sources.

[0050] In some embodiments, the flight schedule publishing system can also: configure independent file transfer protocol server parameters for different business scenarios, including the server's IP address, access port, target directory for message storage, and message backup directory. It can also configure specific retrieval parameters for different time windows, such as flight changes within three days, flight changes beyond three days, and seasonal flight changes. Furthermore, it can configure message types to be filtered, flight number suffix filtering rules, and special flight filtering rules to pre-screen messages in the server before retrieval. Finally, it can configure email notification rules to send error messages to a specified email address when message retrieval encounters an anomaly.

[0051] In one possible implementation, the flight schedule publishing system triggers the message acquisition process at 60-second intervals via a timed scheduler. The system first establishes a connection with a preset file transfer protocol server. After verifying the connection validity, it traverses the target directory corresponding to the business scenario on the server and downloads all flight change messages in the directory to the local server for temporary storage. At the same time, the downloaded messages are marked with their source to distinguish between messages automatically obtained from the server and messages manually imported. A priority processing identifier is added to manually imported messages. After the download is completed, the acquisition time and storage path of the messages are recorded to form the basic log of message acquisition.

[0052] As shown in step S101, the standardized method for acquiring flight change messages ensures the comprehensive and timely acquisition of flight change information. It supports both automatic and manual acquisition methods, adapting to the different business needs of airlines for routine and emergency flight adjustments. Pre-emptive message filtering and independent scenario-based configuration reduce the influx of invalid messages during the acquisition process, improving the efficiency of subsequent message processing. The timed acquisition mechanism enables real-time acquisition of flight change messages, ensuring the timeliness of flight schedule change information transmission and laying a data foundation for the rapid release of subsequent flight schedules.

[0053] S102. Based on the change type identifier, convert the flight change message into a standardized message through the pre-processing rules.

[0054] Among them, the pre-processing rules are matched with the change type identifier, and the standardized messages meet the data format requirements of the flight plan processing system.

[0055] In this embodiment, the pre-processing rules refer to a set of rules preset by the flight schedule publishing system for different types of flight changes, used to parse, verify, and convert the format of flight change messages. These rules are the core basis for achieving differentiated message processing. Standardized messages refer to message data generated by the flight schedule publishing system after processing the original flight change message. These messages conform to the data format specifications of the flight schedule processing system and can be directly recognized and processed by it. They are the foundation for cross-system message interaction.

[0056] In some embodiments, the pre-processing rules may include: message parsing rules corresponding to each change type identifier, used to extract core business data from flight change messages; message validity verification rules, used to verify the message format, field integrity, and business logic rationality; message format conversion rules, used to convert the original message data into a format supported by the flight scheduling system; and flight basic information verification rules, used to confirm whether the flight in the message exists in the flight scheduling system. These rules are customized according to different change type identifiers to ensure accurate matching between the rules and the flight change type.

[0057] In some embodiments, the flight schedule publishing system can retrieve the corresponding pre-processing rules from a locally pre-set rule configuration library, within the rule category that matches the change type identifier of the current flight change message. This rule configuration library stores a complete set of pre-processing rules corresponding to all change type identifiers and supports flexible modification and updates based on business needs.

[0058] In some embodiments, the flight schedule publishing system may also: before executing pre-processing rules, prioritize flight change messages, processing messages with priority identifiers first. Simultaneously, it may perform duplicate verification on messages, checking if any messages with the same name exist in the system and are in an incomplete processing state. If such a message exists, it will not be processed temporarily. Furthermore, it may record all operation logs during the pre-processing process, including rule matching results, message parsing content, verification results, and format conversion details. If an error occurs during pre-processing, the message status can be marked as incorrect, triggering the corresponding alarm mechanism and sending an error message to a designated email address.

[0059] In one possible implementation, the flight schedule publishing system triggers a message pre-processing procedure every minute via a timed scheduler. First, all unprocessed flight change messages are retrieved from the system and sorted by priority. The change type identifier is extracted from each message, and the corresponding pre-processing rule is matched from the rule configuration library based on this identifier. The message is then parsed according to the rule to extract core data such as flight number, flight segment, scheduled time, and aircraft type. Subsequently, validity checks and flight existence verification are performed. If the verification passes, the original message is converted into a standardized message in ASM or SSM format supported by the flight schedule processing system according to the format conversion rules, and the standardized message is added to the pending transmission queue. If the verification fails, the message is marked as invalid, and the reason for invalidity is recorded. After completing the pre-processing of a single message, the next unprocessed message is processed, and so on, until all messages are processed.

[0060] As can be seen from step S102, by accurately matching the change type identifier with the pre-processing rules, differentiated pre-processing of different types of flight change messages is achieved, ensuring the relevance and rationality of message processing, converting the original message into a standardized message that meets the format requirements of the flight plan processing system, solving the problem of incompatibility between cross-system message formats, and realizing the effective transmission of flight change information.

[0061] S103. Send standardized messages to the flight planning system to make flight changes, and receive the change result information from the flight planning system.

[0062] The change result information includes at least the changed flight status data.

[0063] In this embodiment, the flight plan processing system refers to a professional system used for the formulation, adjustment, and maintenance of civil aviation flight plans. It can receive standardized flight change messages and complete corresponding flight plan change operations, and is the core system for realizing flight plan adjustments. Change result information refers to the operation result data fed back to the flight plan publishing system by the flight plan processing system after completing the flight change operation. Its core function is to reflect the execution status of the flight change and the latest flight status.

[0064] In some embodiments, the change result information may include: the changed flight status data. It may also include an execution result identifier for the flight change, indicating whether the flight change operation was successful, failed, or is in progress. It may also include the specific execution time of the flight change and details of the involved flight segment changes. It may also include remarks from the flight scheduling system regarding this change. If the change operation fails, it will also include a specific failure reason code and text description. All information is organized according to a preset interaction format between systems to ensure ease of data parsing.

[0065] In some embodiments, the flight schedule publishing system can obtain change result information fed back by the flight schedule processing system after completing the sorting of standardized messages and forming a queue to be sent through a pre-defined standardized data interaction interface with the flight schedule processing system. This interface supports the transmission of batch messages and the unified feedback of results, and can adapt to the high-frequency data interaction needs between systems.

[0066] In some embodiments, the flight schedule publishing system may also: before sending standardized messages, re-verify the messages in the unsent queue to confirm the message format and data integrity. Immediately after sending, the status of the corresponding messages is updated in batches to "processing in the flight schedule processing system," and the sending time, batch number, and corresponding interaction interface information are recorded to form a complete message sending log. If no change result information is received from the flight schedule processing system within a preset time, a resend mechanism is triggered with a limit on the number of resends. If resend still fails, a message sending anomaly is marked and an email alarm is triggered, pushing an anomaly message to a designated operations and maintenance email address.

[0067] In one possible implementation, after completing preprocessing and generating standardized messages, the flight schedule publishing system first checks if the queue to be sent is not empty. If there are standardized messages in the queue, all standardized messages in the queue are sent in batches to the flight schedule processing system through a dedicated inter-system interface. Immediately after sending, the status of these messages is updated uniformly in the local database and FLTing is received, while a sending log for each message is recorded. Subsequently, the flight schedule publishing system maintains an interface connection with the flight schedule processing system, listening in real-time and receiving change result information returned by the flight schedule processing system. Upon receiving the result, the data is parsed, extracting the changed flight status data and other execution-related information. The parsed complete change result information is associated with and stored with the corresponding flight change message, completing the message sending and result receiving process. If the queue to be sent is empty, the process ends directly.

[0068] As shown in step S103, the standardized message transmission to the flight planning system is stably achieved through the pre-defined standardized interaction interface, ensuring the effective issuance of flight change instructions. The batch sending method improves processing efficiency in multi-message scenarios. Real-time reception and storage of change result information allows for timely acquisition of the flight change execution status, providing accurate and effective data for subsequent adjustments to flight status data. Immediately updating the message status and recording a complete log after transmission enables full-process traceability of message transmission across systems. The retransmission mechanism and anomaly alarm settings effectively reduce the probability of message transmission failure, ensuring the continuity and stability of the flight change process.

[0069] S104. Based on the change type identifier and change result information, the changed flight status data is adjusted through post-processing rules to realize the release of flight plans.

[0070] Among them, the post-processing rules are matched with the change type identifier.

[0071] In this embodiment, the post-processing rules refer to a set of rules preset by the flight schedule release system for different types of flight changes, used to make targeted adjustments to flight status data based on the actual results of flight changes. These rules are the core basis for achieving adaptation between flight status data and actual change results. The changed flight status data refers to the core data reflecting the current operational status of the flight, fed back by the flight schedule processing system after completing the flight change operation. This data is the basic data carrier for the official release of the flight schedule.

[0072] In some embodiments, post-processing rules may include: flight reservation data adjustment rules corresponding to each change type identifier, used to configure flight reservation information based on the flight change result. They also include flight lock and unlock rules to determine whether a flight needs to be locked or unlocked. Additionally, they include RMK item processing rules to complete the corresponding flight service configuration based on the remarks information in the message. Passenger protection processing rules are also included to trigger the corresponding protection process when flight changes involve passenger itinerary adjustments. These rules are customized according to different change type identifiers to ensure a precise match between the rules and the flight change type and the actual change result.

[0073] In some embodiments, the flight schedule publishing system can retrieve the corresponding post-processing rules from a locally pre-set rule configuration library, within the rule category that matches the change type identifier of the current flight change message. This rule configuration library is managed in conjunction with the pre-processing rule library, supporting flexible modification, addition, and deletion of various post-processing rules according to actual civil aviation business needs.

[0074] In some embodiments, the flight schedule publishing system may also: before executing post-processing rules, re-verify the completeness and validity of the change result information; if the verification fails, suspend processing and mark the message status as abnormal; and simultaneously record the operation log of the entire post-processing process, including rule matching results, details of status data adjustment, and cross-system interaction information. If passenger protection processing is involved, the system can query the flight protection processing system for specific protection results and push passenger protection-related information to the passenger protection system based on these results. After completing the flight status data adjustment, the final processing status of the message is updated immediately. The adjusted flight status data can also be synchronized with the officially published flight schedule to relevant civil aviation business systems such as airport operation management and airline passenger services.

[0075] In one possible implementation, the flight schedule publishing system first parses the received change type identifier and the change result information fed back by the flight schedule processing system, determining whether the flight change operation indicated by the change result information was successful. If the change fails, the system records the reason for the failure in detail and marks the message status as processing failed. If the change is successful, the system accurately matches the corresponding post-processing rule from the rule configuration library based on the change type identifier, and then makes targeted adjustments to the changed flight status data according to the matched rule. After completing the adjustment of all status data, the system standardizes and encapsulates the adjusted flight status data, officially publishing the flight schedule, updating the final status of the message to processing successful, and recording all operation details of this post-processing in the system log.

[0076] As shown in step S104, by accurately matching the change type identifier with the subsequent processing rules, differentiated flight status data adjustments for different flight change types are achieved. This adapts to various business scenarios such as new flight creation, deletion, and aircraft type changes in civil aviation, ensuring the relevance and rationality of status data adjustments. Combining the change result information from the flight schedule processing system with data adjustments ensures that the adjusted flight status data is highly consistent with the actual flight change results, guaranteeing the accuracy of flight schedule publication from a data perspective.

[0077] In this embodiment, when the change type identifier is a new flight identifier, the flight schedule publishing system converts the flight change message into a standardized message using pre-processing rules as follows: First, the flight change message is parsed to obtain the schedule information of the flight to be created. Then, if there is no matching flight identifier information for the flight to be created in the flight schedule processing system, a standardized message for creating the new flight is generated based on the schedule information of the new flight.

[0078] The planning information includes at least flight identification information, flight seat information, and flight lock information.

[0079] In this embodiment, the newly created flight identifier refers to the characteristic information used to identify that the business type corresponding to the flight change message is a newly created flight. It is the core basis for the flight planning system to match the exclusive pre-processing rules for newly created flights. The plan information of the flight to be created refers to the various core business data used to create a new flight plan, parsed from the flight change message of the newly created flight type. It is the basis for generating the standardized message for newly created flights. Flight identifier information refers to the characteristic data used to uniquely identify the flight to be created, which is the key to distinguishing different flights. Flight seat information refers to the business data related to flight seats, such as the seat layout and number of seats of the flight to be created. Flight lock information refers to the relevant configuration data used to indicate whether the flight to be created needs to perform a lock operation and the lock range.

[0080] In some embodiments, the planning information for a newly created flight may include: flight identification information, flight seat information, and flight lock information. It may also include the planned start and end dates, flight schedule, service type, and aircraft type information. Additionally, it includes the origin and destination stations for each segment of the flight, the departure and arrival times and offsets for each segment, and the meal configuration information for each segment. All types of information are parsed and extracted from flight change messages for newly created flight types and structured into data according to the standards set by civil aviation flight planning.

[0081] In some embodiments, the flight schedule publishing system can obtain the schedule information of the flight to be created by invoking the dedicated message parsing rules corresponding to the new flight identifier during the parsing stage of the flight change message with the new flight identifier. These parsing rules are designed specifically for the format and data organization characteristics of new flight type messages, enabling accurate extraction and structured organization of various types of schedule information from the message.

[0082] In some embodiments, the flight scheduling system can also: perform a full-dimensional validity check on the parsed schedule information of the flights to be created, verifying the format compliance of the flight identifier information, the numerical rationality of the flight seat information, and the configuration completeness of the flight lock information. Simultaneously, it performs an automatic mapping conversion operation on the city three-letter codes in the schedule information to ensure the standardization of regional data. If the check finds missing or incorrect schedule information, it immediately marks the flight change message as invalid and records the reason for invalidity in detail. It can also completely record the parsed structured schedule information and the check results in the message processing log, providing data support for subsequent problem tracing.

[0083] In one possible implementation, the flight schedule publishing system first identifies the change type identifier in the flight change message as a new flight identifier, and then retrieves the pre-processing parsing rules that match the new flight identifier. The new flight change message is parsed segment by segment, extracting flight identifier information such as flight number, flight seat information such as aircraft layout and number of seats, and flight lock information such as RMK items related to flight lock, according to a preset parsing logic. Simultaneously, other relevant data such as flight schedule time and flight season configuration are extracted, and all extracted data is organized into structured schedule information for the new flight. Next, the system initiates a flight identifier information query request to the flight schedule processing system, sending the core identifier information of the new flight to the system to check if a matching flight identifier exists. If the flight schedule processing system reports no matching flight identifier, the system calls the format conversion rules corresponding to the new flight, encapsulates the structured schedule information of the new flight according to the ASM / SSM format requirements supported by the flight schedule processing system, supplements the necessary content such as message headers and field identifiers required for system interaction, and finally generates a standardized message for the new flight. If the flight scheduling system reports that a matching flight identifier exists, the system will skip the generation process of this standardized message and mark the status of the flight change message as invalid.

[0084] In this embodiment, by matching a specific parsing rule to the newly created flight identifier, accurate parsing of the newly created flight type message is achieved, ensuring the comprehensiveness and accuracy of the extracted flight plan information and providing compliant basic data for the generation of standardized messages. Before generating standardized messages, the uniqueness of the flight identifier information is queried and verified, effectively avoiding the problem of duplicate flight creation and ensuring the uniqueness and accuracy of flight data in the flight plan processing system. The parsed plan information is then converted into standardized messages, ensuring that the generated standardized messages can be effectively recognized and processed by the flight plan processing system, improving the standardization of flight plan formulation and laying a data foundation for the subsequent creation of new flight plans.

[0085] In this embodiment, when the change type identifier is a new flight identifier, the flight scheduling system adjusts the changed flight status data based on the change type identifier and change result information using post-processing rules as follows: In response to the change result information indicating successful creation of the flight to be created, the changed flight status data is adjusted based on the flight's schedule information.

[0086] The flight status data includes at least flight reservation data and flight lockout data.

[0087] In this embodiment, flight seat reservation data refers to business data used to characterize the seat reservation ratio, number of reserved seats, and applicable scope of each cabin class in a newly established flight, and is core information for flight seat resource allocation. Flight lockout data refers to configuration data used to indicate whether a new flight should perform a lockout operation, the scope of locked cabin classes, and the lockout duration, and is key data for ensuring the safety of flight operation management.

[0088] In some embodiments, flight status data may include: flight seat reservation data and flight lockout data, and may also include flight nature data, flight segment operational status data, flight RMK item configuration status data, and overall flight operational activation status data. These various types of data collectively constitute a complete data system characterizing the overall operational status of newly established flights, supporting the official release and implementation of flight plans.

[0089] In some embodiments, the flight scheduling system can retrieve the scheduling information of the flight to be created from the message storage directory corresponding to the local message processing database. Simultaneously, through a standardized interaction interface with the flight scheduling processing system, it can obtain change result information including a successful creation identifier after receiving feedback data from the system.

[0090] In one possible implementation, the flight scheduling system first receives the change result information from the flight scheduling processing system, parses and identifies the identifier information of the successfully created flight to be created, and confirms that the flight to be created has been completed. Then, combining the change type identifier corresponding to the flight with the new flight identifier, it retrieves the matching new flight post-processing rules from the rule configuration library. Subsequently, it retrieves the schedule information of the flight to be created from the local message processing database, and based on the seat reservation configuration requirements in the schedule information, precisely configures the flight seat reservation data in the changed flight status data, determining core information such as the number of seats reserved and the seat reservation ratio for each cabin class. Based on the flight locking configuration requirements in the schedule information, it adjusts the flight locking data, setting the flight locking type, locking range, and unlocking conditions. Simultaneously, it completes the configuration of the flight nature data and the processing of the flight RMK item according to the post-processing rules, and synchronously updates these configuration contents to the corresponding flight status data. After all flight status data has been adjusted, the system performs a full verification of the adjusted data to confirm that the data configuration is compliant and conflict-free. The adjusted flight status data is then stored in a standardized manner, completing the final adjustment of the new flight status data and providing complete and accurate status data support for the official release of flight plans.

[0091] In this embodiment, adjustments are made to core data such as seat reservation and locking based on the planned information of the flight to be created, ensuring a high degree of consistency between flight status data and flight plan formulation requirements, and ensuring the accuracy of the configuration of the new flight plan from a data perspective. Simultaneously, the flight nature, RMK items, and other related data are synchronized during the adjustment process, allowing the flight status data to form a complete system that supports the smooth release and operation of the new flight plan.

[0092] In this embodiment, when the change type identifier is a deleted flight identifier, the flight scheduling system converts the flight change message into a standardized message using pre-processing rules as follows: First, the flight change message is parsed to obtain the segment to be deleted for the flight to be deleted. Then, the inventory segments matching the flight to be deleted in the flight scheduling system are obtained. Subsequently, a consistency check is performed between the segment to be deleted and the inventory segments.

[0093] For example, if the segment to be deleted matches the number of segments in the inventory, a standardized message for deleting the flight is generated based on the segment to be deleted. If the number of segments to be deleted is less than the number of segments in the inventory, the change type identifier of the flight change message is changed to a comprehensive change identifier, and the flight change message is converted into a standardized message using a pre-processing rule that matches the comprehensive change identifier.

[0094] In this embodiment, the segment to be deleted refers to the flight segment information parsed from the flight change message with the deleted flight identifier, which is the core object of the flight deletion operation. The inventory segment refers to the currently valid segment data stored in the flight scheduling system that matches the flight to be deleted, and serves as the benchmark for segment consistency judgment. The comprehensive change identifier refers to the feature information used to identify a flight as undergoing multi-dimensional adjustments, and can be matched with corresponding comprehensive change-specific pre-processing rules.

[0095] In some embodiments, the segment to be deleted may include: the flight identifier of the flight to be deleted, the three-letter codes of the origin and destination stations of the segment, the execution date of the segment, and the aircraft configuration information of the segment. It may also include relevant data such as the departure and arrival times of the segment and the cabin layout of the segment. All kinds of information are parsed from the delete flight type message to form structured segment data.

[0096] In some embodiments, the inventory of flight segments may include: a flight identifier matching the flight to be deleted, the current valid execution status of the segment, and the actual operational configuration information of the segment. It also includes airport support data corresponding to the segment and passenger reservation information for the segment, representing the full set of valid flight segment data updated in real time by the flight scheduling system.

[0097] In some embodiments, the flight scheduling system can obtain the segment to be deleted by invoking the dedicated message parsing rules corresponding to the deleted flight identifier when performing a parsing operation on a flight change message with a deleted flight identifier. Simultaneously, it can initiate a query request through a standardized interaction interface with the flight scheduling processing system, and obtain the corresponding inventory segment after passing in the core identifier information of the flight to be deleted.

[0098] In some embodiments, the flight schedule publishing system may also: sort the messages of the flight type to be deleted according to priority and process them sequentially; after parsing the flight segment to be deleted, verify the integrity and format compliance of its information; and record the flight segment verification message log in detail during the flight segment comparison process. If the comprehensive change identifier is changed, the message type identifier is updated synchronously and the reason for the change is recorded. At the same time, the entire process of message processing type change is completely stored in the system log.

[0099] In one possible implementation, Figure 2 This is a flowchart illustrating a pre-processing method for deleting flight messages provided in an embodiment of this application. For example, as shown... Figure 2 As shown, after obtaining the inventory flight segments from the flight scheduling processing system, the flight scheduling publishing system first compares the flight segments in the message with the inventory flight segments. Based on the comparison result, it executes differentiated processing logic: if the flight segments in the message are fewer than the inventory flight segments, the message processing type is changed to comprehensive change, and the original delete flight message is converted into a comprehensive change message, thus performing comprehensive change message pre-processing. If the flight segments are the same, the message is converted to ASM (Automatic Segment Management), and the message generation log is recorded. Then, the ASM message is sent to the flight scheduling processing system to execute the flight deletion operation. If some flight segments in the message do not exist in the inventory or the inventory flight segments are fewer than the flight segments in the message, the message is marked as a pre-processing error and logged for subsequent problem tracing and troubleshooting.

[0100] For example, the flight scheduling system first identifies the change type identifier of the flight change message as a deleted flight identifier, sorts the message according to priority, and includes it in the processing queue. Then, it calls the matching pre-processing parsing rules to parse the message and extract the structured information of the segments to be deleted. Next, it queries the flight scheduling processing system, passing in the core identifier of the flight to be deleted to obtain the corresponding inventory segments, and then performs a consistency check between the segments to be deleted and the inventory segments. If the two information match, the system calls the format conversion rules corresponding to the deleted flight, generating a standardized message that conforms to the format requirements of the flight scheduling processing system based on the segments to be deleted. If the segments to be deleted are fewer than the inventory segments, the system modifies the change type identifier of the message to a comprehensive change identifier, calls the pre-processing rules matching the comprehensive change identifier, parses and converts the original message according to the rules, generates the corresponding standardized message, and records detailed logs of segment verification and identifier changes. If the segments to be deleted are more than the inventory segments, or some segments in the segments to be deleted do not exist in the inventory segments, the system marks the message as an error message and generates corresponding logs.

[0101] In this embodiment, flight segment consistency checks prevent erroneous flight deletions and ensure the integrity of flight plan data. When the number of flight segments to be deleted is less than the number of flight segments in the inventory, the message is converted into a comprehensive change identifier to adapt to the business scenario of partial flight segment deletion and improve message processing adaptability.

[0102] In this embodiment, when the change type identifier is a deleted flight identifier, the flight scheduling system adjusts the changed flight status data based on the change type identifier and change result information using post-processing rules as follows: In response to the change result information indicating successful deletion of the flight to be deleted, the reservation data of the flight to be deleted is obtained. Then, based on the reservation data, protection processing for the passengers corresponding to the reservation data is triggered.

[0103] Among these measures, the protective measures are used to rebook passengers onto alternative flights.

[0104] In this embodiment, reservation data refers to passenger reservation information for flights to be deleted stored in the flight scheduling system, which is the core basis for triggering passenger protection processing. Protection processing refers to flight adjustment operations carried out on passengers with reservations, with the core goal of rationally allocating passengers from deleted flights to alternative flights.

[0105] In some embodiments, reservation data may include: passenger identification information, reservation class of service, and reservation flight segment information. It may also include passenger contact information, information on accompanying persons, and reservation confirmation status data. All types of information are valid reservation data stored in real time within the flight scheduling system.

[0106] In some embodiments, the protection process may include: querying available alternative flight resources, migrating passenger reservation information to the alternative flight, and sending flight adjustment notifications to passengers. It also includes seat confirmation for the alternative flight, rescheduling of passenger itineraries, and recording the results of the protection process; all operations are carried out to ensure the smooth connection of the passenger's itinerary.

[0107] In some embodiments, the flight scheduling publishing system can obtain the reservation data of the flight to be deleted after receiving the change result information of the successful deletion of the flight through a standardized interaction interface with the flight scheduling processing system. Simultaneously, it can retrieve the corresponding basic flight information from the dedicated data storage directory of the flight to be deleted through a local message processing database.

[0108] In some embodiments, the flight schedule publishing system may also: initiate a protection result query request to the flight protection processing system to obtain the execution results of passenger protection in real time; push passenger protection-related data to the passenger protection system based on the protection results; record the entire process details of protection processing in the message post-processing log; synchronously update the status data of messages and flights to "protection processing in progress" or "protection completed"; if protection fails, record the reason for failure and trigger the corresponding email alarm mechanism.

[0109] In one possible implementation, Figure 3 This is a flowchart illustrating a method for post-processing the deletion of flight messages provided in an embodiment of this application. For example, as shown... Figure 3 As shown, after the flight scheduling system reports successful flight cancellation, the flight scheduling publishing system queries the flight protection system for passenger protection results. If the flight protection system reports that the protection results are not ready, a new query is required later. If the query result is protection successful / protection failed, the passenger protection results are pushed to the passenger protection system. If the query result shows no passengers for the flight to be deleted, it is determined that no protection result needs to be sent, and the current post-processing procedure ends directly.

[0110] For example, the flight scheduling system first parses the change result information fed back by the flight scheduling processing system, identifies the identifier of a successfully deleted flight, and, combined with the change type being a deleted flight identifier, retrieves the matching post-processing rules. Then, through the inter-system interface, it obtains the full reservation data of the flight to be deleted from the flight scheduling processing system. Based on the reservation data, it triggers the passenger protection processing flow to the flight protection processing system, continuously querying the protection results of the flight protection processing system. If a protection result is found, it is pushed to the passenger protection system to complete passenger information synchronization. If no passenger reservation information is found for the flight to be deleted, there is no need to push the protection result to the passenger protection system.

[0111] In this embodiment, passenger protection processing is precisely triggered based on reservation data, safeguarding the travel rights of passengers with reservations and enabling reasonable allocation of passengers to alternative flights. Through cross-system collaboration with flight protection processing systems, passenger protection systems, and other systems, efficient implementation of protection processing is ensured, improving the standardization of post-deletion flight processing and the quality of passenger service.

[0112] In this embodiment, when the change type identifier is a time change identifier, the flight schedule publishing system converts the flight change message into a standardized message using pre-processing rules as follows: First, the flight change message is parsed to obtain the identifier information and target time information of the flight to be changed. Then, if a target flight matching the identifier information exists in the flight schedule processing system, the associated itinerary information of the target flight is obtained. Finally, based on the associated itinerary information, the standardized message conversion process is performed.

[0113] For example, when the change in the associated itinerary information does not affect passenger flight connections, a standardized message for flight time changes is generated based on the target time information. When the change in the associated itinerary information does affect passenger flight connections, a first flight change message and a second flight change message are constructed based on the identification information of the flight to be changed and the target time information.

[0114] The change type identifier for the first flight change message is "deleted flight identifier," while the change type identifier for the second flight change message is "new flight identifier."

[0115] In this embodiment, the target time information refers to the time configuration data, such as the departure and arrival times and related offsets of the flight segment to be adjusted, which are parsed from the flight change message with a time change identifier. This is the core basis for flight time changes. Related itinerary information refers to the itinerary-related data, such as passenger transfers and connecting flight matching, stored in the flight planning system. This is crucial for determining whether time changes affect passenger itineraries.

[0116] In some embodiments, the target time information may include: the target departure time and target arrival time of each segment of the flight to be changed, as well as the corresponding time offset. It also includes relevant data such as the official effective time of the time change and the specific magnitude of the time adjustment for each segment. All types of information are structured into time data according to the civil aviation flight time configuration specifications.

[0117] In some embodiments, the associated itinerary information may include: passenger connecting flight information for the target flight, minimum connection time configuration at transit airports, and flight schedule association data for the passenger's subsequent itinerary. It also includes transit passenger booking information, segment matching relationships of connecting flights, and other related content, representing complete data reflecting the association between the target flight and the passenger's subsequent itinerary.

[0118] In some embodiments, the flight scheduling system can obtain the identification information and target time information of the flight to be changed when parsing a flight change message with a time change identifier by invoking the dedicated message parsing rules corresponding to the time change identifier. Simultaneously, it can initiate a query request through a standardized interaction interface with the flight scheduling processing system, and obtain the corresponding associated itinerary information after passing in the core identification information of the target flight.

[0119] In one possible implementation, the flight scheduling system first identifies the change type identifier of the flight change message as a time change identifier. It then calls the matching pre-processing parsing rules to parse the message, extracting the identifier information of the flight to be changed and the structured target time information. Next, it sends a query request to the flight scheduling processing system to verify if a target flight matching the identifier exists in the system. If it exists, it obtains the associated itinerary information of the target flight and analyzes it to determine if the time change affects passenger flight connections. If it does not affect connections, it calls the format conversion rules corresponding to the time change and generates a standardized message that conforms to the format requirements of the flight scheduling processing system based on the target time information. If it does affect connections, it constructs a delete flight message and a create flight message based on the identifier information of the flight to be changed and the target time information. After structurally encapsulating these two types of messages, it generates the corresponding standardized message, while recording all processing details and judgment results.

[0120] For example, Figure 4 This is a flowchart illustrating a method for pre-processing flight schedule change messages provided in an embodiment of this application. For example, as shown... Figure 4 As shown, the flight scheduling system first obtains the flight information for the time slot to be changed, and then determines whether the flight is a connecting flight. If it is determined to be a connecting flight, it further verifies the consistency across days. If the connecting flight is inconsistent across days, the message preprocessing fails; if they are consistent, the message is converted to ASM (Automatic Message Provider) and the message generation log is recorded. Then, the ASM message is sent to the flight scheduling processing system. If it is determined to be a non-connecting flight, it continues to determine whether it is a cross-purchase flight. If it is a cross-purchase flight, the flight for the time slot to be changed is canceled first, and a delete flight message and a create flight message are created in sequence, and both types of messages are included in the message queue to be processed. If it is a non-cross-purchase flight, the message is directly converted to ASM, the message generation log is recorded, and then the ASM message is sent to the flight scheduling processing system.

[0121] In this embodiment, by parsing the target time and querying related itineraries, the system accurately determines the impact of time changes on passenger itineraries, generates standardized messages as needed, or splits and creates messages for deleting and creating flights to adapt to different time change business scenarios and ensure seamless flight connections for passengers.

[0122] In this embodiment of the application, when the change type identifier is a time change identifier, the flight schedule publishing system adjusts the changed flight status data based on the change type identifier and change result information using post-processing rules as follows: In response to the change result information indicating successful update of the target flight's time, the changed flight status data is adjusted according to the target time information.

[0123] The flight status data includes at least flight reservation data and flight lockout data.

[0124] In one possible implementation, the flight schedule publishing system first parses the change result information fed back by the flight schedule processing system to identify the identifier indicating that the target flight's time slot has been successfully updated. Combining the change type identifier with the time slot change identifier, it retrieves the matching time slot change post-processing rules. Subsequently, it obtains the target time information for the target flight from the local message processing database and adjusts the flight reservation data in the updated flight status data accordingly. It synchronously updates the configuration status of the flight lock data, processes the flight RMK item according to the post-processing rules, and synchronizes the relevant configuration to the flight status data. After all adjustments are completed, the data is comprehensively verified, and the message processing status is updated to complete once no configuration conflicts are confirmed.

[0125] In this embodiment, accurately adjusting flight reservation and locking data based on target time information can ensure that the flight status is highly matched with the operational needs after the time change, adapt to the business scenario of time change, and ensure the effectiveness of the flight plan release after the time adjustment.

[0126] In this embodiment, when the change type identifier is an aircraft type change identifier, the flight scheduling system converts the flight change message into a standardized message using pre-processing rules as follows: First, the flight change message is parsed to obtain the flight identifier information and target aircraft type data of the flight to be changed. Then, if a target flight matching the flight identifier information exists in the flight scheduling system, a standardized message for flight type change is generated based on the target aircraft type data.

[0127] In this embodiment of the application, the target aircraft type data refers to the configuration information related to the aircraft type to be adjusted for the flight to be changed, which is parsed from the flight change message with the aircraft type change identifier. It is the core data basis for the flight aircraft type change operation and provides key content of the aircraft type dimension for the generation of standardized messages.

[0128] In some embodiments, target aircraft data may include: flight type code, cabin layout information corresponding to the aircraft type, and seat configuration data for each cabin class. It may also include information such as the aircraft type's passenger capacity and the operational requirements for the flight segments to which the aircraft type is compatible. All types of data are structured into aircraft configuration data according to civil aviation aircraft type operation specifications to ensure the standardization of data parsing and conversion.

[0129] In some embodiments, the flight schedule publishing system can call the dedicated message parsing rules corresponding to the aircraft type change identifier to obtain the flight identifier information and target aircraft type data of the flight to be changed when performing parsing operations on the flight change message with the aircraft type change identifier. At the same time, it can initiate a query request through the standardized interaction interface with the flight schedule processing system, and after passing in the flight identifier information, obtain feedback information on whether there is a matching target flight in the system.

[0130] In some embodiments, the flight schedule publishing system may also: sort the aircraft type change messages by priority and process them sequentially; perform format compliance and rationality checks on the parsed target aircraft type data; convert the standardized messages into a standardized format when generating standardized messages; and update the message status to "processing" and record the status change log after the message is sent.

[0131] In one possible implementation, the flight schedule publishing system first identifies the change type identifier of the flight change message as an aircraft type change identifier, sorts the message according to priority, and includes it in the processing queue. Then, it calls the matching pre-processing parsing rules to parse the message, extracting the flight identifier information of the flight to be changed and the structured target aircraft type data. Next, it sends a query request to the flight schedule processing system to verify whether a target flight matching the flight identifier information exists in the system. If it does, it calls the format conversion rules corresponding to the aircraft type change, encapsulates the target aircraft type data according to the format requirements of the flight schedule processing system, and converts it into a standardized message for flight aircraft type changes, completing the generation process of this standardized message.

[0132] In this embodiment, core data on aircraft type changes is accurately extracted through dedicated parsing rules, and pre-flight existence verification avoids changes to invalid flights, thereby enhancing the accuracy of pre-processing of aircraft type change messages.

[0133] In this embodiment, when the change type identifier is an aircraft type change identifier, the flight scheduling system adjusts the changed flight status data based on the change type identifier and change result information using post-processing rules as follows: In response to the change result information indicating successful change of the flight to be changed, the reservation data of the flight to be changed is obtained. Furthermore, if the aircraft type data indicates that the passenger capacity of the changed flight is less than that of the original flight, protection processing for the passengers corresponding to the reservation data is triggered based on the reservation data.

[0134] Among these measures, the protection process is at least used to rebook passengers who cannot be accommodated on the changed flight onto alternative flights.

[0135] In this embodiment of the application, passenger capacity refers to the maximum number of passengers that the aircraft type can carry after the flight change is adjusted. It is determined by the cabin layout and seat configuration of the aircraft type and is the core quantitative indicator for determining whether passenger protection processing is triggered.

[0136] In some embodiments, passenger capacity may include: the number of available seats in each cabin class of the modified aircraft and the actual number of passengers the aircraft can carry. It also includes capacity limit data for the flight segments adapted to the aircraft type. All types of data are derived from the target aircraft type data and are the key basis for determining the passenger protection trigger conditions.

[0137] In some embodiments, the flight scheduling system can obtain the reservation data of the flight to be changed after receiving a successful aircraft type change result message through a standardized interaction interface with the flight scheduling processing system. Simultaneously, it retrieves the target aircraft type data before and after the change from the local message processing database to determine the change in passenger capacity.

[0138] In some embodiments, the flight schedule publishing system may also: after acquiring the data, verify the integrity of the reservation data and the validity of the aircraft type data; for scenarios involving changes from a minor to a major aircraft type, it may not be necessary to trigger passenger protection and record the scenario information; when adjusting flight status data, it may simultaneously process the flight nature and RMK items; and query the protection result from the flight protection processing system. Based on the protection result, it may push relevant data to the passenger protection system.

[0139] In one possible implementation, the flight scheduling system first parses the change result information fed back by the flight scheduling processing system to identify the identifier indicating a successful aircraft type change for the flight to be changed. Combining the change type identifier with the aircraft type change identifier, it retrieves the matching aircraft type change post-processing rules. Then, it obtains the reservation data of the flight to be changed through an interactive interface, retrieves the target aircraft type data before and after the change from the local database, and calculates the corresponding passenger capacity. It determines whether the passenger capacity of the changed aircraft type is less than that before the change. If it's a minor change to a major change, it only processes the flight nature and RMK items according to the rules and adjusts the flight status data synchronously. If the capacity decreases, it triggers passenger protection processing based on the reservation data, continuously queries the protection results and pushes them to the passenger protection system, synchronously updates the protection results to the flight status data, records the entire operation details, and finally updates the processing status of the message.

[0140] In this embodiment, passenger protection processing is triggered as needed based on changes in passenger capacity, adapting to different business scenarios such as small-to-large and large-to-small aircraft model modifications, and can accurately protect passengers' travel rights.

[0141] In this embodiment, when the change type identifier is a comprehensive change identifier, the flight schedule publishing system converts the flight change message into a standardized message using pre-processing rules as follows: First, the flight change message is parsed to obtain the identifier information, target time information, and target aircraft type data of the flight to be comprehensively changed. Then, the inventory information of the target flight matching the identifier information is obtained from the flight schedule processing system. Subsequently, based on the inventory information, target time information, and target aircraft type data, the change relationship between the flight to be comprehensively changed and the target flight is determined. Finally, based on the change relationship, a standardized message generation method matching the comprehensive change identifier is determined to generate a standardized message.

[0142] For example, when the change relationship indicates that the flight to be comprehensively changed is a new flight, the change type identifier of the flight change message is converted into a new flight identifier, and a standardized message is generated through the pre-processing rules that match the new flight identifier.

[0143] When the change relationship represents the cancellation of a segment of the target flight, and the updated segment information has no overlap with the previous segment information, the change type identifier of the flight change message is converted into a deleted flight identifier, and a standardized message is generated through the pre-processing rules that match the deleted flight identifier.

[0144] The change relationship characterizes the flight to be comprehensively changed as updating the aircraft type and / or time of the target flight. Based on the target aircraft type information and target time data, a standardized message for updating the target flight is generated.

[0145] In this embodiment, inventory information refers to the currently valid full operational data matching the target flight stored in the flight scheduling system, which is the core benchmark for determining the comprehensive change relationship. The change relationship refers to the specific adjustment type and association attributes of the flight to be comprehensively changed relative to the target flight, determined by comparing the inventory information with the target data to be comprehensively changed, and is a key basis for selecting the standardized message generation method.

[0146] In some embodiments, inventory information may include: segment configuration information for the target flight, current aircraft type data, and real-time operating schedule information. It also includes cabin layout, seat resource allocation, segment execution status, and basic operational data associated with the flight; all types of data are valid business data updated in real time within the flight planning system.

[0147] In some embodiments, the change relationships may include: new relationships for flights to be comprehensively changed into new flights, and deletion relationships for completely canceling target flight segments. Update relationships may also include adjustments to the target flight's aircraft type and / or time. All types of relationships are derived from multi-dimensional comparative analysis of inventory information and data to be comprehensively changed.

[0148] In one possible implementation, the flight schedule publishing system first identifies the change type identifier of the flight change message as a comprehensive change identifier. It then calls the matching pre-processing parsing rules to parse the message, extracting the identifier information, target time information, and target aircraft type data of the flight to be comprehensively changed. Subsequently, it sends a query request to the flight schedule processing system to obtain the inventory information of the matching target flights. Based on the inventory information and the aforementioned target data, it performs a multi-dimensional comparative analysis to determine the change relationship between the two. If it is a new addition relationship, the message identifier is converted to a new flight identifier, and its pre-processing rules are reused to generate a standardized message. If it is a deletion relationship involving the complete cancellation of a flight segment, it is converted to a deleted flight identifier, and its pre-processing rules are reused to generate a standardized message. If it is an update relationship involving aircraft type and / or time, a corresponding updated standardized message is directly generated based on the target aircraft type and time information, while simultaneously recording all processing details and judgment results.

[0149] Furthermore, the flight schedule publishing system can reuse its post-processing rules to adjust the changed flight status data based on the change type identifier corresponding to the standardized message generated by the pre-processing results.

[0150] For example, Figure 5 This is a flowchart illustrating a method for pre-processing flight comprehensive change messages provided in an embodiment of this application. For example, as shown... Figure 5 As shown, the flight scheduling system first retrieves inventory flight information and determines whether the inventory flight exists. If the inventory flight does not exist, the message processing type is changed to "Create Flight," the original comprehensive change message is converted into a "Create Flight" message, and preprocessing is performed. If the inventory flight exists, the system further checks for canceled segments. If all segments are canceled, the message processing type is changed to "Delete Flight," the original comprehensive change message is converted into a "Delete Flight" message, and preprocessing is performed. If only some segments are canceled, the system first verifies that the canceled segments exist in the inventory, then proceeds to cross-day segment consistency verification. If no canceled segments exist, the system directly proceeds to cross-day segment consistency verification. After completing the cross-day segment consistency verification, the message is converted to ASM (Automatic Segment Management) and the message generation log is recorded. Finally, the ASM message is sent to the flight scheduling system for further processing.

[0151] In this embodiment, the relationship between comprehensive changes is accurately determined by multi-dimensional analysis and comparison with inventory information. The identifier is converted or the message is generated directly as needed. Existing pre-processing rules are reused to adapt to various scenarios of comprehensive changes, thereby improving the efficiency and adaptability of pre-processing of comprehensive change messages.

[0152] In summary, Figure 6 This is a detailed flowchart illustrating a flight schedule publishing method provided in an embodiment of this application. For example, as shown... Figure 6As shown, the flight schedule publishing system first configures message import parameters, including configuration file server parameters to distinguish between messages from three days ago, messages from within three days, and seasonal messages; configures message processing rules to achieve message type filtering, flight selection, and city three-letter code conversion; and configures notification rules to set email notification on / off and corresponding notification email addresses. Then, it reads the configured message import parameters and periodically accesses the file server to retrieve message files. Next, it filters flight change messages from the retrieved message files for preprocessing. For new flight messages, deleted flight messages, time slot change messages, aircraft type change messages, and comprehensive change messages, corresponding preprocessing logic is executed. After preprocessing, various standardized messages are sent to the flight schedule processing system to execute flight change operations. After the flight schedule processing system completes its processing of standardized messages, the flight schedule publishing system receives the returned results and performs post-processing. For new flight messages, deleted flight messages, time slot change messages, aircraft type change messages, and comprehensive change messages, corresponding post-processing logic is executed. Finally, update the final flight schedule data to release the flight schedule and complete its official release.

[0153] The flight schedule publishing method provided in this application solves the problem of generalized processing failing to distinguish between different change types by acquiring flight change messages containing change type identifiers, thus providing accurate business scenario identification for subsequent processing. Furthermore, based on the change type identifier, corresponding pre-processing rules are matched to convert the message into a standardized format, ensuring that various flight change information can be accurately parsed by the flight schedule processing system, avoiding data corruption or processing failures due to format incompatibility. The standardized message is then sent to the flight schedule processing system for flight changes and the change result information is received, achieving an automated closed loop for change operations and effectively improving processing efficiency. Finally, based on the change type identifier and change result information, post-processing rules are matched to make targeted adjustments to the changed flight status data, enabling flight schedule publishing to meet the specific needs of different business scenarios such as additions, cancellations, and aircraft type adjustments. This enhances the adaptability of message processing to business scenarios and achieves precision and efficiency in the flight schedule publishing process.

[0154] In an exemplary embodiment, Figure 7 This is a schematic diagram illustrating the composition of a flight schedule publishing device provided in an embodiment of this application. Figure 7As shown, the flight plan publishing device includes: a message acquisition module 701, a message conversion module 702, a communication module 703, and a data adjustment module 704. Specifically, the message acquisition module 701 acquires flight change messages, which include a change type identifier for the corresponding flight; the message conversion module 702 converts the flight change message into a standardized message based on the change type identifier using pre-processing rules that match the change type identifier, and the standardized message conforms to the data format requirements of the flight plan processing system; the communication module 703 sends the standardized message to the flight plan processing system for flight change and receives change result information from the system, including at least the changed flight status data; and the data adjustment module 704 adjusts the changed flight status data based on the change type identifier and change result information using post-processing rules to publish the flight plan, where the post-processing rules match the change type identifier.

[0155] In this embodiment of the application, when the change type identifier is a new flight identifier, the message conversion module 702 is specifically used to: parse the flight change message to obtain the plan information of the flight to be created, the plan information including at least flight identifier information, flight seat information and flight lock information; and generate a standardized message for creating a new flight based on the plan information of the flight to be added, in the case that there is no flight identifier information matching the flight to be created in the flight plan processing system.

[0156] In this embodiment of the application, the data adjustment module 704 is specifically used to: in response to the change result information indicating that the flight to be created has been successfully created, adjust the changed flight status data based on the plan information of the flight to be created, wherein the flight status data includes at least flight reservation data and flight lock data.

[0157] In this embodiment, when the change type identifier is a deleted flight identifier, the message conversion module 702 is specifically used to: parse the flight change message to obtain the segment to be deleted of the flight to be deleted; obtain the inventory segment that matches the flight to be deleted in the flight planning system; if the segment to be deleted matches the inventory segment, generate a standardized message for deleting the flight based on the segment to be deleted; if the segment to be deleted is less than the inventory segment, change the change type identifier of the flight change message to a comprehensive change identifier, and convert the flight change message into a standardized message through a pre-processing rule that matches the comprehensive change identifier.

[0158] In this embodiment of the application, the data adjustment module 704 is specifically used to: in response to the change result information indicating successful deletion of the flight to be deleted, obtain the reservation data of the flight to be deleted; and based on the reservation data, trigger protection processing for the passenger corresponding to the reservation data, the protection processing being used to adjust the passenger to an alternative flight.

[0159] In this embodiment, when the change type identifier is a time change identifier, the message conversion module 702 is specifically used to: parse the flight change message to obtain the identifier information and target time information of the flight to be changed; if a target flight matching the identifier information exists in the flight planning system, obtain the associated itinerary information of the target flight; if the associated itinerary information indicates that the time change does not affect passenger flight connections, generate a standardized message for flight time change based on the target time information; if the associated itinerary information indicates that the time change affects passenger flight connections, construct a first flight change message and a second flight change message based on the identifier information and target time information of the flight to be changed, wherein the change type identifier of the first flight change message is a deleted flight identifier, and the change type identifier of the second flight change message is a new flight identifier.

[0160] In this embodiment of the application, the data adjustment module 704 is specifically used to: in response to the change result information indicating that the time of the target flight has been successfully updated, adjust the changed flight status data according to the target time information, wherein the flight status data includes at least flight seat reservation data and flight lock data.

[0161] In this embodiment of the application, when the change type identifier is an aircraft type change identifier, the message conversion module 702 is specifically used to: parse the flight change message to obtain the flight identifier information and target aircraft type data of the flight to be changed; and, if there is a target flight in the flight planning processing system that matches the identifier information, generate a standardized message for flight type change based on the target aircraft type data.

[0162] In this embodiment of the application, the data adjustment module 704 is specifically used to: in response to the change result information indicating that the flight to be changed has been successfully changed, obtain the reservation data of the flight to be changed; when the aircraft type data indicates that the passenger capacity of the changed flight is less than that of the original flight, trigger the protection processing for the passengers corresponding to the reservation data according to the reservation data, and the protection processing is at least used to adjust the passengers that the changed flight cannot carry to the alternative flight.

[0163] In this embodiment of the application, when the change type identifier is a comprehensive change identifier, the message conversion module 702 is specifically used to: parse the flight change message to obtain the identifier information, target time information, and target aircraft type data of the flight to be comprehensively changed; obtain the inventory information of the target flight that matches the identifier information in the flight planning processing system; determine the change relationship between the flight to be comprehensively changed and the target flight based on the inventory information, target time information, and target aircraft type data; and determine the standardized message generation method that matches the comprehensive change identifier based on the change relationship to generate a standardized message.

[0164] In this embodiment, the message conversion module 702 is specifically used for: when the change relationship indicates that the flight to be comprehensively changed is a new flight, converting the change type identifier of the flight change message into a new flight identifier, and generating a standardized message through a pre-processing rule matching the new flight identifier; when the change relationship indicates that the flight to be comprehensively changed is a segment cancellation of the target flight, and the updated segment information has no overlap with the segment information before the update, converting the change type identifier of the flight change message into a deleted flight identifier, and generating a standardized message through a pre-processing rule matching the deleted flight identifier; when the change relationship indicates that the flight to be comprehensively changed is an update of the aircraft type and / or time of the target flight, generating a standardized message for updating the target flight based on the target aircraft type information and target time data.

[0165] In an exemplary embodiment, this application also provides an electronic device, which may be the flight schedule publishing device in the above method embodiments. Figure 8 This is a schematic diagram of a flight schedule publishing device provided in an embodiment of this application. Figure 8 As shown, the flight schedule publishing device may include: a processor 801 and a memory 802; the memory 802 stores instructions executable by the processor 801; when the processor 801 is configured to execute instructions, it causes an electronic device or network device or manager to perform the system functions described in the foregoing method embodiments.

[0166] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0167] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0168] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0169] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0170] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0171] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for publishing flight schedules, characterized in that, The method includes: Obtain a flight change message, wherein the flight change message includes a change type identifier for the corresponding flight; Based on the change type identifier, the flight change message is converted into a standardized message through pre-processing rules. The pre-processing rules match the change type identifier, and the standardized message conforms to the data format requirements of the flight planning system. The standardized message is sent to the flight planning system to make flight changes, and the change result information from the flight planning system is received. The change result information includes at least the changed flight status data. Based on the change type identifier and the change result information, the changed flight status data is adjusted through post-processing rules to realize the release of flight plans. The post-processing rules are matched with the change type identifier.

2. The method according to claim 1, characterized in that, When the change type identifier is a new flight identifier, the step of converting the flight change message into a standardized message through pre-processing rules includes: The flight change message is parsed to obtain the plan information of the flight to be created. The plan information includes at least flight identification information, flight seat information, and flight lock information. If no flight identifier information matching the flight to be created exists in the flight planning processing system, a standardized message for creating the new flight is generated based on the planning information of the flight to be created.

3. The method according to claim 2, characterized in that, The step of adjusting the changed flight status data based on the change type identifier and the change result information using post-processing rules includes: In response to the change result information indicating successful creation of the flight to be created, the flight status data is adjusted based on the planning information of the flight to be created. The flight status data includes at least flight reservation data and flight lock data.

4. The method according to claim 1, characterized in that, When the change type identifier is a deleted flight identifier, the step of converting the flight change message into a standardized message through pre-processing rules includes: Parse the flight change message to obtain the flight segment to be deleted for the flight to be deleted; Obtain the inventory flight segments in the flight scheduling system that match the flight to be deleted; If the segment to be deleted matches the segment in the inventory, a standardized message for deleting the flight is generated based on the segment to be deleted. If the number of flight segments to be deleted is less than the number of flight segments in the inventory, the change type identifier of the flight change message is changed to a comprehensive change identifier, and the flight change message is converted into a standardized message through a pre-processing rule that matches the comprehensive change identifier.

5. The method according to claim 4, characterized in that, The step of adjusting the changed flight status data based on the change type identifier and the change result information using post-processing rules includes: In response to the change result information indicating successful deletion of the flight to be deleted, the booking data of the flight to be deleted is obtained; Based on the reservation data, a protection process is triggered for the passenger corresponding to the reservation data, which is used to reassign the passenger to an alternative flight.

6. The method according to claim 1, characterized in that, When the change type identifier is a time change identifier, the step of converting the flight change message into a standardized message through preprocessing rules includes: The flight change message is parsed to obtain the identification information and target time information of the flight to be changed; If a target flight matching the identification information exists in the flight planning processing system, the associated itinerary information of the target flight is obtained; If the associated itinerary information indicates that the time change does not affect the passenger's flight connection, a standardized message for flight time change is generated based on the target time information; When the associated itinerary information indicates that the time change affects the passenger's flight connection, a first flight change message and a second flight change message are formed based on the identification information of the flight to be changed and the target time information. The change type identifier of the first flight change message is a deleted flight identifier, and the change type identifier of the second flight change message is a new flight identifier.

7. The method according to claim 6, characterized in that, The step of adjusting the changed flight status data based on the change type identifier and the change result information using post-processing rules includes: In response to the change result information indicating that the time of the target flight has been successfully updated, the flight status data is adjusted according to the target time information. The flight status data includes at least flight reservation data and flight lock data.

8. The method according to claim 1, characterized in that, When the change type identifier is an aircraft type change identifier, the step of converting the flight change message into a standardized message through pre-processing rules includes: Parse the flight change message to obtain the flight identification information and target aircraft type data of the flight to be changed; If a target flight matching the flight identification information exists in the flight planning processing system, a standardized message for flight type change is generated based on the target aircraft type data.

9. The method according to claim 8, characterized in that, The step of adjusting the changed flight status data based on the change type identifier and the change result information using post-processing rules includes: In response to the change result information indicating that the flight to be changed has been successfully changed, the reservation data of the flight to be changed is obtained; If the passenger capacity of a flight after the aircraft type data change is less than that of the flight before the change, the reservation data will trigger a protection process for the passengers corresponding to the reservation data. The protection process is at least used to adjust the passengers who cannot be accommodated by the changed flight to alternative flights.

10. The method according to claim 1, characterized in that, When the change type identifier is a comprehensive change identifier, the step of converting the flight change message into a standardized message through pre-processing rules includes: The flight change message is parsed to obtain the identification information, target time information, and target aircraft type data of the flight to be comprehensively changed; Obtain the inventory information of the target flight that matches the identification information in the flight planning system; Based on the inventory information, target time information, and target aircraft type data, the change relationship between the flight to be comprehensively changed and the target flight is determined; Based on the change relationship, a standardized message generation method matching the comprehensive change identifier is determined to generate a standardized message.

11. The method according to claim 10, characterized in that, The step of determining a standardized message generation method that matches the comprehensive change identifier based on the change relationship, in order to generate a standardized message, includes: When the change relationship indicates that the flight to be comprehensively changed is a new flight, the change type identifier of the flight change message is converted into a new flight identifier, and a standardized message is generated by using the pre-processing rules that match the new flight identifier; When the change relationship indicates that the flight to be comprehensively changed is a segment cancellation of the target flight, and the updated segment information has no overlap with the segment information before the update, the change type identifier of the flight change message is converted into a deleted flight identifier, and a standardized message is generated through the preprocessing rules that match the deleted flight identifier. The change relationship indicates that the flight to be comprehensively changed is to update the aircraft type and / or time of the target flight. Based on the target aircraft type information and target time data, a standardized message for updating the target flight is generated.

12. An electronic device, characterized in that, The electronic device includes: a processor and a memory; The memory stores instructions that the processor can execute; When the processor is configured to execute the instructions, it causes the electronic device to implement the method as described in any one of claims 1-11.

Images