Message processing methods and apparatus, electronic equipment, storage media

Abstract

This invention discloses a message processing method, apparatus, electronic device, and storage medium. The method includes: in response to receiving a service request message, determining the service type of the service request message; obtaining a feature conversion method corresponding to the service request message based on the service type according to a preset traffic splitting rule; converting the fields contained in the service request message based on the feature conversion method to obtain a target request message; and sending the target request message to a target server, wherein the target server is used to process the service request message. This invention solves the technical problem of low accuracy in message conversion in related technologies.

Description

Technical Field

[0001] This invention relates to the field of civil aviation services, and more specifically, to a message processing method and apparatus, electronic equipment, and storage medium. Background Technology

[0002] In the development of information technology in the aviation industry, frequent Electronic Data Interchange (EDI) is required between different civil aviation systems and airlines to ensure the efficient operation of flight information, ticketing, passenger services, and other business processes. Extensible Markup Language (XML), with its customizability, scalability, and good cross-platform compatibility, is considered a superior data transmission method. XML allows airlines and their suppliers to customize data fields, enhancing data readability and understandability, and is easily accepted by airlines and their passenger service system providers.

[0003] However, the conversion of XML messages still faces challenges, especially in the process of converting from EDI to XML. Traditional conversion methods can only achieve a rough direct mapping, resulting in low conversion accuracy. This may alter the business meaning conveyed by the converted XML, ultimately affecting actual production operations.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] The present invention provides a message processing method and apparatus, electronic device, and storage medium to at least solve the technical problem of low accuracy in message conversion in related technologies.

[0006] According to one aspect of the present invention, a message processing method is provided, comprising: in response to receiving a service request message, determining the service type of the service request message; obtaining a feature conversion method corresponding to the service request message based on the service type according to a preset traffic splitting rule; converting the fields contained in the service request message based on the feature conversion method to obtain a target request message; and sending the target request message to a target server, wherein the target server is used to process the service request message.

[0007] Further, determining the business type of the business request message includes: validating the data format of the business request message to obtain a format validation result; in response to the format validation result indicating that the data format of the business request message has passed validation, performing a compliance validation on the business request message to obtain a compliance validation result, wherein the compliance validation result is used to reflect whether the business request message is secure; in response to the compliance validation result indicating that the business request message is secure, identifying the message type field contained in the business request message to obtain the business type.

[0008] Furthermore, compliance verification is performed on the business request message to obtain the compliance verification result, including: identifying the types of multiple fields contained in the business request message to obtain the field types of different fields; separating multiple fields based on the field types to obtain business fields and non-business fields; and performing compliance verification on the business request message based on the non-business fields to obtain the compliance verification result.

[0009] Furthermore, compliance verification is performed on the business request message based on non-business fields to obtain the compliance verification result, including: obtaining the initial source routing information and initial destination routing information of the business request message based on non-business fields; obtaining the target destination routing information that matches the initial source routing information from the routing configuration table; determining that the compliance verification result is that the business request message is secure if the target destination routing information is the same as the initial destination routing information; and determining that the compliance verification result is that the business request message is insecure if the target destination routing information is different from the initial destination routing information.

[0010] Furthermore, according to the preset traffic splitting rules, the feature conversion method corresponding to the business request message is obtained based on the business type, including: obtaining the microservice used to process the business request message based on the business type; obtaining the format conversion configuration parameters of the business request message based on the service identifier of the microservice, wherein the format conversion configuration parameters are used to characterize the parameters for converting the current transmission protocol used by the business request message; and obtaining the feature conversion method based on the format conversion configuration parameters.

[0011] Further, the fields contained in the business request message are transformed based on the feature transformation method to obtain the target request message, including: obtaining a business field mapping table and field transformation logic that match the feature transformation method; determining a first field and a second field from multiple fields contained in the business request message based on the business field mapping table, wherein the first field is used to represent fields that can be formatted through the business field mapping table, and the second field is used to represent fields that cannot be formatted through the business field mapping table; transforming the first field based on the business field mapping table to obtain a first target field, and transforming the second field according to the field transformation logic to obtain a second target field; reassembling the business request message based on the first target field and the second target field to obtain the target request message.

[0012] According to another aspect of the present invention, a message processing apparatus is also provided, comprising: a type acquisition module, configured to determine the service type of a service request message in response to receiving a service request message; a mode acquisition module, configured to acquire the feature conversion mode corresponding to the service request message based on the service type according to a preset traffic splitting rule; a message conversion module, configured to convert the fields contained in the service request message based on the feature conversion mode to obtain a target request message; and a message sending module, configured to send the target request message to a target server, wherein the target server is used to process the service request message.

[0013] According to another aspect of the present invention, an electronic device is also provided, comprising: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods of various embodiments of the present invention during runtime.

[0014] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is executed, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of the present invention.

[0015] According to another aspect of the present invention, a computer program product is also provided, including a computer program that, when executed by a processor, implements the methods of various embodiments of the present invention.

[0016] According to another aspect of the present invention, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods of various embodiments of the present invention.

[0017] According to another aspect of the present invention, a computer program is also provided, which, when executed by a processor, implements the methods of the various embodiments of the present invention.

[0018] In this embodiment of the invention, in response to receiving a service request message, the service type of the service request message is determined; according to a preset traffic splitting rule, the feature conversion method corresponding to the service request message is obtained based on the service type; the fields contained in the service request message are converted based on the feature conversion method to obtain the target request message; and the target request message is sent to the target server. By identifying the service type, the purpose and conversion requirements of the message can be accurately determined, and corresponding feature conversion methods can be assigned to different service types. This ensures that the converted target request message can correctly reflect the service requirements in various target formats, achieving the goal of lossless conversion of service request messages. This improves the accuracy of service request message conversion and solves the technical problem of low message conversion accuracy in related technologies. Attached Figure Description

[0019] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0020] Figure 1 This is a flowchart of a message processing method according to an embodiment of the present invention;

[0021] Figure 2 This is a system architecture diagram of an optional message processing method according to an embodiment of the present invention;

[0022] Figure 3 This is a flowchart of an optional business feature extraction method according to an embodiment of the present invention;

[0023] Figure 4 This is a schematic diagram of an optional configuration center design example according to an embodiment of the present invention;

[0024] Figure 5 This is a flowchart of an optional data request processing method according to an embodiment of the present invention;

[0025] Figure 6 This is a flowchart of another optional data request processing according to an embodiment of the present invention;

[0026] Figure 7 This is a schematic diagram of a message processing apparatus according to an embodiment of the present invention. Detailed Implementation

[0027] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0028] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0029] According to an embodiment of the present invention, an embodiment of a message processing method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0030] Figure 1 This is a flowchart of a message processing method according to an embodiment of the present invention, such as... Figure 1 As shown, the method includes the following steps:

[0031] Step S102: In response to receiving a service request message, determine the service type of the service request message.

[0032] The aforementioned business request message can refer to an electronic data message sent between the civil aviation system and the airline during a business process. This message can be used to request the execution of a business operation. The aforementioned business type can be the category of the specific business operation or function requested in the business request message. For example, the aforementioned business type can include at least one or more of the following: ticketing, ticket reissue, ticket refund, ticket cancellation, etc., but is not limited to these.

[0033] In an optional embodiment, considering that different business types usually correspond to different business logic and data processing flow, when the message processing system (hereinafter referred to as the processing system) receives the above-mentioned business request message, by determining the business type of the business request message, the processing system can accurately identify the specific business operation to be performed, thereby calling the correct logic to process the business request message, avoiding data chaos and business errors caused by incorrect processing flow.

[0034] For example, in an electronic data interchange (EDI) scenario in the aviation industry, we can assume that the processing system receives a business request message in EDI format. This message may contain a `msgtype` field to indicate the business type. We can further assume that the value of the `msgtype` field is "A," indicating that the requested business type is a ticketing operation. To improve the accuracy of processing business request messages, the processing system can first parse the received message and focus on reading the `msgtype` field. After reading, the system can match the read `msgtype` field value with pre-configured business type identification rules to determine that the business type of the request message is a ticketing operation.

[0035] It should be noted that the specific values ​​of the field names used to represent business types and the field values ​​corresponding to ticketing operations are only shown as examples. Staff can configure them according to their actual needs, and there are no restrictions here.

[0036] Step S104: According to the preset traffic splitting rules, obtain the feature conversion method corresponding to the business request message based on the business type.

[0037] The aforementioned pre-defined traffic splitting rules can refer to the rules pre-set by the processing system in a microservice architecture to determine how to allocate and process business request messages among different microservices based on the business type of the received messages. The aforementioned feature conversion methods can refer to conversion strategies or algorithms used in electronic data conversion to transform business fields in business request messages into another data format. Examples of such feature conversion methods include field mapping, composite field processing, etc., but are not limited to these.

[0038] In an optional embodiment, considering that the accuracy of message data conversion may be low if a general conversion method is used when the processing system converts business request messages, the processing system can pre-set traffic splitting rules and obtain the feature conversion method corresponding to the business request message based on the business type. This allows the processing system to quickly call the conversion logic corresponding to the business type of the message when processing the business request message, thereby improving the efficiency and accuracy of message conversion.

[0039] For example, it can be assumed that the processing system pre-sets feature conversion methods corresponding to four business types: ticket issuance, ticket reissue, ticket refund, and ticket cancellation. The aforementioned pre-set traffic splitting rule can be used to split business request messages according to business type, so that the processing system can obtain the feature conversion method corresponding to the business type of the business request message. In this embodiment, it can be assumed that the processing system receives a business request message and parses it to find that the business type corresponding to the message is ticket refund. The processing system can then obtain the feature conversion method corresponding to the business request message as field mapping based on this business type.

[0040] Step S106: Based on the feature conversion method, the fields contained in the business request message are converted to obtain the target request message.

[0041] The aforementioned target request message can refer to a new message that conforms to the requirements of the target system or target data format, obtained by converting and reorganizing the fields in the original business request message (usually in EDI format) through feature conversion during the data conversion process.

[0042] In an optional embodiment, considering that directly processing EDI messages may be inefficient when the processing system is handling a large number of continuous and related business requests, and that using feature conversion to convert the fields contained in the business request messages can reduce redundant data processing and improve the conversion efficiency of the processing system, the processing system can convert the fields contained in the business request messages based on feature conversion to obtain the target request message.

[0043] For example, when processing the aforementioned business request message, the processing system can map specific fields in the EDI format to corresponding key-value pairs in the JSON (JavaScript Object Notation) format. Specifically, the processing system can first identify fields such as flight information, date, and time in the EDI message, and map these fields to corresponding key-value pairs in the JSON message. Then, the processing system can convert the data in the EDI fields into standard data types in the JSON format, thereby obtaining the aforementioned target request message.

[0044] Step S108: Send the target request message to the target server, whereby the target server is used to process the business request message.

[0045] The aforementioned target server may refer to a backend system or service that receives and processes the aforementioned target request message in the electronic data interchange or data conversion process.

[0046] In an optional embodiment, considering that the format of the target request message is designed according to the needs and processing capabilities of the target server, the processing system can send the converted message to the target server to ensure that the target server can accurately parse and understand the message content, thereby effectively executing business operations.

[0047] For example, it can be assumed that the processing system has obtained the target request message through the aforementioned steps. In order to ensure that the target request message can be sent to the target server, the processing system can establish an HTTP (Hypertext Transfer Protocol) connection with the target server and send the target request message as the data body to the target server.

[0048] In this embodiment of the invention, in response to receiving a service request message, the service type of the service request message is determined; according to a preset traffic splitting rule, the feature conversion method corresponding to the service request message is obtained based on the service type; the fields contained in the service request message are converted based on the feature conversion method to obtain the target request message; and the target request message is sent to the target server. By identifying the service type, the purpose and conversion requirements of the message can be accurately determined, and corresponding feature conversion methods can be assigned to different service types. This ensures that the converted target request message can correctly reflect the service requirements in various target formats, achieving the goal of lossless conversion of service request messages. This improves the accuracy of service request message conversion and solves the technical problem of low message conversion accuracy in related technologies.

[0049] Further, determining the business type of the business request message includes: validating the data format of the business request message to obtain a format validation result; in response to the format validation result indicating that the data format of the business request message has passed validation, performing a compliance validation on the business request message to obtain a compliance validation result, wherein the compliance validation result is used to reflect whether the business request message is secure; in response to the compliance validation result indicating that the business request message is secure, identifying the message type field contained in the business request message to obtain the business type.

[0050] The format verification results described above can be used to determine whether a message meets a predefined data format specification. The compliance verification results described above can be used to verify whether a business request message is secure.

[0051] In one optional embodiment, considering that a correct business request message format helps the backend system or service quickly parse and respond to requests, avoiding unnecessary data processing or exception handling, the processing system can first verify the data format of the business request message to obtain a format verification result, thereby ensuring the integrity and accuracy of the data during transmission. If the above format verification result shows that the data format of the business request message passes the verification, the processing system can also perform a compliance verification on the business request message to obtain a compliance verification result, thereby preventing attacks such as malicious code and SQL (Structured Query Language) injection, and ensuring the security of the processing system and business data. If the above compliance verification result shows that the business request message is secure, the processing system can further identify the message type field contained in the business request message and finally obtain the business type corresponding to the business request message.

[0052] For example, suppose the processing system receives a business request message. To correctly parse the business type corresponding to the message, the system can first perform data format validation. That is, the system can determine whether the message has the correct syntax and whether the business-related fields are complete. After the validation, the system obtains the format validation result. If the result indicates that the data format of the message is correct, the system can further perform compliance validation. That is, the system can determine whether the message's source is legitimate, whether the data is secure, and whether the business request conforms to predefined rules. After compliance validation, the system obtains the compliance validation result. If the result indicates that the message is secure, the system can determine the business type based on the `msg type` field in the message, so as to correctly route the message to the appropriate business processing component.

[0053] Furthermore, compliance verification is performed on the business request message to obtain the compliance verification result, including: identifying the types of multiple fields contained in the business request message to obtain the field types of different fields; separating multiple fields based on the field types to obtain business fields and non-business fields; and performing compliance verification on the business request message based on the non-business fields to obtain the compliance verification result.

[0054] The aforementioned field types can be the application type of each field in the business request message. For example, the aforementioned field types can include at least one or more of the following: amount, routing information, identity identifier, flight information, time, etc., but are not limited to these. The aforementioned business fields can refer to data fields in the business request message that are directly related to business logic. For example, the aforementioned business fields can include at least one or more of the following: transaction amount, flight number, passenger information, product code, etc., but are not limited to these. The aforementioned non-business fields can refer to fields in the business request message that do not directly participate in business logic processing but are of significant importance to data transmission and system management. For example, the aforementioned non-business fields can include at least one or more of the following: routing information, EDI version information, unique identifier of the message sender, etc., but are not limited to these.

[0055] In one optional embodiment, the processing system can verify whether the data in each field conforms to the expected format by identifying the field types of multiple fields contained in the business request message, thereby preventing data parsing failures or abnormal behavior caused by type errors. After completing the above type identification, the processing system can obtain the field types of different fields and separate multiple fields based on the above field types to obtain the aforementioned business fields and non-business fields. Since the aforementioned non-business fields may contain information such as request ID (Identification), sender identifier, and timestamp, the processing system can perform compliance verification on the business request message based on this information, thereby obtaining the compliance verification result for the aforementioned business request message. This allows the processing system to understand the source and destination of the message, thereby ensuring the compliance and security of message transmission.

[0056] For example, to accurately separate business fields from non-business fields in a business request message, enabling the processing system to perform compliance verification, the processing system can pre-train a feature extraction model based on a deep learning algorithm. This model can output a set of business fields and non-business fields based on the field types and values ​​of different fields in the current business request message. Specifically, suppose the processing system receives a business request message containing fields A, B, and C. The processing system first identifies the field types of these fields, as shown below: field A is of monetary value, field B is of routing information type, and field C is of flight information type. The processing system can then input the identification results and the field values ​​into the feature extraction model. The model can output the following result: the business field set contains fields A and C, while the non-business field set contains field B. Subsequently, the processing system can perform compliance verification on the business request message based on field B, thus obtaining the compliance verification result for the message.

[0057] Furthermore, compliance verification is performed on the business request message based on non-business fields to obtain the compliance verification result, including: obtaining the initial source routing information and initial destination routing information of the business request message based on non-business fields; obtaining the target destination routing information that matches the initial source routing information from the routing configuration table; determining that the compliance verification result is that the business request message is secure if the target destination routing information is the same as the initial destination routing information; and determining that the compliance verification result is that the business request message is insecure if the target destination routing information is different from the initial destination routing information.

[0058] The initial source routing information mentioned above can be the sender information contained in the service request message, that is, which system or entity the service request message originated from. The initial destination routing information mentioned above can be the receiver information specified in the service request message, that is, the expected destination of the service request message. The target destination routing information mentioned above can be the expected receiver information that matches the initial source routing information, found in the routing configuration table mentioned above. The routing configuration table mentioned above can be a data structure or database table that stores the correspondence between source routes and destination routes, used to guide the routing logic for data transmission.

[0059] In an optional embodiment, considering that errors in the sending path of the service request message may lead to the leakage of civil aviation service information, thereby reducing the security of the processing system, the processing system can pre-build a routing configuration table to ensure the accuracy of the service request message sending path. This routing configuration table can be established based on civil aviation business protocols and security policies to store the correspondence between source routes and destination routes, thereby ensuring that data transmission between authorized entities is only permitted. After completing the construction of the routing information table, the processing system can first parse the initial source route information and initial destination route information of the service request message from the aforementioned non-business fields, and can further obtain the target destination route information that matches the initial source route information from the aforementioned routing configuration table. If the target destination route information obtained from the routing configuration table matches the initial destination route information declared in the service request message, it indicates that the data transmission is carried out according to the established routing rules and complies with the requirements of the business protocol and security policy. At this time, the compliance verification result of the processing system for the message can be considered as proof of the security of the service request message. If the destination routing information does not match the initial destination routing information declared in the message, it indicates that there may be an anomaly in the transmission process of the service request message, such as routing errors, man-in-the-middle (MITM) attacks, or data tampering. In this case, the compliance verification result of the processing system for the message can be that the service request message is insecure.

[0060] For example, it can be assumed that the processing system constructs a routing configuration table containing predefined matching rules for sending sources and sending destinations. These rules might be as follows: Entity A can send service request messages to entities C and D, and entity B can send service request messages to entity C. In this embodiment, it can be further assumed that the processing system receives two service request messages, denoted as message 1 and message 2, and that the processing system has already obtained the non-service fields of message 1 and message 2. Furthermore, the processing system can parse the initial source routing information of message 1 to determine that the message was sent by entity A, and can parse the initial destination routing information of message 1 to determine that the message was sent to entity C. Since the initial destination routing information of message 1 is consistent with the target destination routing information recorded in the routing configuration table, the processing system's compliance verification result for message 1 is that message 1 is secure. Similarly, the processing system can deduce from the initial source routing information of message 2 that the message was sent by entity B, and from the initial destination routing information of message 2 that the message was sent to entity D. Since the initial destination routing information of message 2 is inconsistent with the target destination routing information recorded in the routing configuration table, the processing system's compliance verification result for message 2 is that message 2 is insecure.

[0061] Furthermore, according to the preset traffic splitting rules, the feature conversion method corresponding to the business request message is obtained based on the business type, including: obtaining the microservice used to process the business request message based on the business type; obtaining the format conversion configuration parameters of the business request message based on the service identifier of the microservice, wherein the format conversion configuration parameters are used to characterize the parameters for converting the current transmission protocol used by the business request message; and obtaining the feature conversion method based on the format conversion configuration parameters.

[0062] The service identifier mentioned above can be a label or name used to uniquely identify a microservice. The format conversion configuration parameters mentioned above can be the rules and standards used to convert business request messages from one transport protocol to another. The transport protocol mentioned above can be the rules and standards followed when data is transmitted over the network; for example, the transport protocol can be EDI, XML, JSON, or YAML, but is not limited to these.

[0063] In an optional embodiment, considering that different business types may be handled by different microservices, such as query services, reservation services, and ticketing services, by identifying the type of business request message, the processing system can accurately call the microservice responsible for handling that type of business, thereby avoiding data redundancy and confusion and improving the efficiency and accuracy of business processing. Therefore, the processing system can first determine the microservice used to handle the business request message based on the business type. After determining the microservice for handling the above-mentioned business request message, further considering that different microservices may use different configuration parameters, including how to convert the business request message from the current transport protocol (such as EDI) to the internal protocol supported by the microservice (such as YAML, JSON), the processing system can also obtain the format conversion configuration parameters of the business request message based on the service identifier of the microservice. In order to ensure that the business meaning of the business request message remains consistent during transmission, and thus ensure the integrity and accuracy of business information during the conversion process, the processing system can obtain the feature conversion method based on the format conversion configuration parameters.

[0064] For example, after receiving a business request message, the processing system can parse the message to determine that the corresponding business type is flight query. Then, based on this business type, the system can search for the corresponding microservice, flight query service, in the service discovery mechanism or configuration center. This flight query service is a microservice specifically for handling flight queries. Let's assume the microservice identifier for flight query service is `flight-query-service`. The processing system can further obtain format conversion configuration parameters from the configuration center based on the service identifier of `flight-query-service`. After obtaining these format conversion configuration parameters, according to the conversion logic defined in these parameters, the vehicle system can perform feature conversion on the aforementioned business request message, that is, convert the EDI message into a YAML format message.

[0065] Specifically, to achieve lightweight EDI applications, the processing system can pre-deploy microservices for processing business request messages. In this embodiment, taking civil aviation ticket-related business as an example, the processing system needs to first design corresponding YAML methods based on the EDI message type. The specific YAML methods and corresponding business designs for EDI message types are shown in Table 1 below:

[0066] Table 1

[0067]

[0068] In this embodiment, YAML methods are method names defined for civil aviation business, used to identify different business operations, such as issuing, voiding, and refunding tickets. These method names will be used in the microservice architecture as references for conversion rules to achieve conversion from EDI format to YAML or other target formats. EDI types are standard formats for data transmission between civil aviation systems, used for electronic data interchange in the civil aviation industry. For example, TKTREQ 130 represents a ticketing request, and TKTREQ 133 / 776 represents a voiding request. The business description describes the specific business operation represented by each EDI type message, such as issuing, voiding, refunding, and reissuing. The business description helps to understand and locate the role of the message in the civil aviation business process, providing a business logic basis for data conversion. In this embodiment, by pre-defining the YAML method, accurate matching and efficient conversion of common EDI message types in civil aviation business can be achieved. This not only solves the problems of complexity and redundancy in traditional EDI data conversion, but also enhances the readability and flexibility of the data, enabling the data to be processed and transmitted in a more efficient way in a microservice architecture, thereby better adapting to the complex needs of aviation business.

[0069] Subsequently, the processing system can design fields based on the information required for the corresponding business. The field names, types, formats, and descriptions will be defined using a publicly available data dictionary for the civil aviation service industry. Fields not found in the public data dictionary must apply to be added to a private data dictionary; only those approved by the private dictionary can be included. Taking civil aviation flight information as an example, some of the data dictionaries used are shown in Table 2 below:

[0070] Table 2

[0071] English name Chinese name type Format flightNumber Flight number int 3-4 digits flightSuffix Flight suffix string a internationalInd International flight sign bool 0 / 1 flightStatusCode Flight status string secureFlight Safe flight bool 0 / 1 beginFlightNumber Origin Flight Number int flightDate Departure date of the first flight segment string yyyy-mm-dd borrowMethodInd Flight borrowing method bool 0 / 1 flightRemark Flight Notes string segmentId Flight number string

[0072] In the YAML structure, the English name is used to represent the English identifier of the data field in civil aviation operations. For example, flightNumber represents the flight number, and internationalInd indicates whether it is an international flight. The Chinese name is the Chinese explanation of the above English identifier, which makes it easier to understand the actual meaning of the field. For example, flightNumber corresponds to flight number, and flightSuffix is ​​the flight suffix. The type is used to specify the data type of the field. For example, flightNumber is defined as int, indicating that it is an integer type used to store flight number information. The type of flightDate is string, indicating that it is a string type. The format is used to define the specific format of the data. For example, the format of flightNumber is 3-4 digits, and the format of flightDate is yyyy-mm-dd, that is, the year-month-day format. By defining the data format, it can be ensured that the data is represented in YAML according to preset rules, which facilitates subsequent processing or data exchange with other systems.

[0073] Then, the processing system can define each YAML method individually according to business characteristics. Specifically, the processing system can define the hierarchical structure and business fields of the YAML methods. Taking the ticket information in the ticketing method as an example, the YAML method definition is shown in Table 3 below:

[0074] Table 3

[0075] Node Name level illustrate 1ticket M The master ticket information node contains detailed data about the ticket. 1.1 ticketNumberDetails M The ticket number details node is used to provide ticket number information. 1.1.1 ticketNumber M Ticket number 1.1.2conjunctionTicketTotalNumber C Total number of joint tickets 1.1.3 dataIndicator C Data indicator 1.1.4 connection C Joint ticket logo 1.2 revalidationTimes C Number of re-verifications 1.3 International M Is it an international segment? 1.4etType M Electronic ticket type 1.5 groups M Ticket grouping information 1.6 coupons M Ticket Information 1.6.1 coupon Information M Ticket details node 1.6.1.1 couponInfos M Ticket Information 1.6.1.1.1 couponNumber M Ticket Number 1.6.1.1.2 couponStatus M Ticket status 1.6.1.1.3 settlementAuthCode C Settlement authorization code

[0076] In this YAML structure, `ticket` is the top-level node representing the main ticket information, marking the beginning of the entire ticketing data record. Its level `M` (Mandatory) indicates that this node is mandatory, meaning it must exist in any YAML representation of ticketing information. `ticketNumberDetails`, a direct subordinate of `ticket`, is also mandatory. It encapsulates detailed information related to the ticket number, including the ticket number, total number of tickets in a row, data indicator, row identifier, and number of re-verification attempts. `ticketNumber`, a subordinate node of `ticketNumberDetails`, represents the unique identifier of the ticket, used to identify a specific ticket record; it is also mandatory. `conjunctionTicketTotalNumber` represents the total number of tickets in a row. As a subordinate node of `ticketNumberDetails`, it indicates the total number of other tickets associated with the current ticket; its level `C` (Conditional) indicates that this node is optional. `dataIndicator`, a subordinate node of `ticketNumberDetails`, is a data indicator used to mark the nature of specific data, such as whether it is test data; it is also optional. `conjunction` is a combined ticket identifier, a sub-node of the `ticketNumberDetails` node, indicating whether a ticket is part of a combined ticket; it is also an optional field. `revalidationTimes` is the number of times the ticket has been revalidated, a direct sub-node of the `ticket` node, used to track ticket status; it is an optional node. `International` indicates whether it is an international flight, a direct sub-node of the `ticket` node, and is mandatory for ticketing processing, used to distinguish between domestic and international flights; it is a mandatory node. `etType` is the electronic type of the ticket, a direct sub-node of the `ticket` node, used to determine the specific category of the ticket, such as paper ticket or electronic ticket; it is a mandatory node. `group` is ticket grouping information, a direct sub-node of the `ticket` node, used to organize and manage ticket series; it is a mandatory node. `coupons` is a ticket information node, a direct sub-node of the `ticket` node, used to encapsulate ticket data related to the ticket; it is a mandatory node. `couponInformation` is a detailed ticket information node, a sub-node of the `coupons` node, used to describe the common attributes or management information of multiple tickets; it is a mandatory node. couponInfos is a collection of specific coupon information. As a subordinate node of the couponInformation node, each couponInfo represents the data of a coupon and is a required node.`couponNumber` is the unique ID of the ticket, used for identification and verification. It is a required node, a child of the `couponInfos` node. `couponStatus` indicates the current status of the ticket, such as whether it is valid, used, or expired. It is also a required node, a child of the `couponInfos` node. `settlementAuthCode` is the settlement authorization code, used for security verification during the settlement process. It is an optional node, a child of the `couponInfos` node. Through a combination of required and optional fields, and a multi-layered node design, the processing system can completely and accurately represent complex and ever-changing civil aviation ticketing data. The clear hierarchical structure and field definitions shown in Table 3 not only help ensure the accuracy and consistency of electronic data conversion but also facilitate data exchange and processing between different microservice components, thereby improving the overall operational efficiency and business flexibility of the processing system.

[0077] After completing the above deployment, the processing system can call the electronic data conversion service through the interface to realize message protocol conversion.

[0078] Further, the fields contained in the business request message are transformed based on the feature transformation method to obtain the target request message, including: obtaining a business field mapping table and field transformation logic that match the feature transformation method; determining a first field and a second field from multiple fields contained in the business request message based on the business field mapping table, wherein the first field is used to represent fields that can be formatted through the business field mapping table, and the second field is used to represent fields that cannot be formatted through the business field mapping table; transforming the first field based on the business field mapping table to obtain a first target field, and transforming the second field according to the field transformation logic to obtain a second target field; reassembling the business request message based on the first target field and the second target field to obtain the target request message.

[0079] The aforementioned business field mapping table can be a table used to store the mapping relationship between fields in the source data format and fields in the target data format. The aforementioned field conversion logic can be logic used to handle fields that do not have a direct mapping relationship between the source and target formats. The aforementioned first field can refer to a business field that can be directly format-converted through the business field mapping table. The aforementioned second field can be a business field that cannot be directly format-converted through the business field mapping table. The aforementioned first target field can be a field in the target format formed after the aforementioned first field is converted through the business field mapping table. The aforementioned second target field can be a field formed in the target format after the aforementioned second field is converted according to the field conversion logic.

[0080] In one optional embodiment, considering that different business scenarios may require different conversion rules during data format conversion, to improve the accuracy of data format conversion, the processing system can predefine a business field mapping table and field conversion logic based on business requirements and the target data format, thereby ensuring that each field in the original message has a corresponding processing method in the target message. Further considering that some fields in the business request message may be difficult to convert directly based on the business field mapping table, the processing system can identify these fields as the aforementioned second field, and identify the fields in the business request message that can be directly converted based on the business field mapping table as the aforementioned first field. After completing the division of the first and second fields, the processing system can use the business field mapping table to map the value of the first field in the original message to the corresponding field in the target message to obtain the first target field. For the aforementioned second field, the processing system can perform a conversion operation according to the predefined field conversion logic to obtain the second target field. Finally, the processing system can reassemble the first target field obtained through the mapping table and the second target field obtained through the field conversion logic to create a target request message. This allows the target request message to conform to the data format and structure of the target system and contain complete business information.

[0081] For example, the business request message received by the processing system may be an EDI message, while the message format of the target system may be YAML format. The processing system can pre-construct the aforementioned business field mapping table based on the mapping relationship between business fields from EDI format to YAML format. To process business fields that cannot be directly converted through the aforementioned business field mapping table, the processing system can also pre-construct the aforementioned field conversion logic. Assuming that the business request message received by the processing system contains fields A, B, C, and D, the processing system can identify fields A and B as the first field, and fields C and D as the second field. In this case, the processing system can directly convert field A to YAML format (field a) and field B to YAML format (field b) based on the aforementioned business field mapping table. Therefore, the aforementioned first target field includes fields a and b. Simultaneously, the processing system can convert field C to YAML format (field c) and field D to YAML format (field d) based on the aforementioned field conversion logic. Therefore, the aforementioned second target field includes fields c and d. Finally, the processing system can combine the first target field and the second target field to obtain a target request message in YAML format.

[0082] For ease of understanding, Figure 2 This is a system architecture diagram of an optional message processing method according to an embodiment of the present invention, such as... Figure 2As shown, the architecture includes namespaces, with n+1 namespaces illustrated in the diagram: Namespace 'default', Namespace 1, and Namespace n. Each namespace represents a different business domain or functional module. Namespace 'default' contains multiple service routes (only two are shown in the diagram): Service Route (namespace 1) and Service Route (namespace n). Service routes are used for data flow control, directing data to the correct service invocation component based on different business needs and rules. Namespace 1 contains service invocation components and multiple electronic data conversion services. Only two electronic data conversion services are shown in the diagram: Electronic Data Conversion Service (1, 1) and Electronic Data Conversion Service (1, m1). Within each structure of Namespace 1, the service invocation components are responsible for invoking specific electronic data conversion services. They can select and invoke different service instances based on business characteristics and conversion requirements. In this application, the service invocation components can use Call Service function calls. The diagram illustrates the invocation methods of Call Service (1, k) and Call Service (n, k). The Electronic Data Conversion (EDI) service implements conversion logic from EDI to XML, JSON, or other formats based on different business types. Namespace n also contains service call components and multiple EDI services. The diagram only shows two EDI services: EDI service (n, 1) and EDI service (n, mn). The functions of the structures in namespace n are consistent with those in namespace 1, and will not be repeated here.

[0083] Figure 3 This is a flowchart of an optional business feature extraction method according to an embodiment of the present invention, such as... Figure 3 As shown, when the processing system receives an EDI request from an external requester, it first verifies the request parameters to ensure that the request conforms to predefined EDI standards and format requirements. If the request parameter verification fails, the processing system performs exception handling; after completing the exception handling, the conversion ends. If the request parameter verification succeeds, the system enters the feature extraction stage to separate business fields and non-business fields in the EDI message. After feature extraction, the non-business fields are used to verify routes. If route verification fails, the processing system can perform exception handling; after completing the exception handling, the conversion ends. If route verification succeeds, the processing system can perform business traffic splitting and further feature conversion; once the feature conversion is complete, the conversion ends.

[0084] Figure 4 This is a schematic diagram of an optional configuration center design example according to an embodiment of the present invention, such as... Figure 4 As shown, the configuration center is located centrally and connected to six different electronic data conversion (EDC) microservice instances. These instances include: EDC Query Instance 1, EDC Reservation Instance 1, EDC Ticketing Instance 1, EDC Query Instance 2, EDC Reservation Instance 2, and EDC Ticketing Instance 2. The configuration center is responsible for managing the configuration information of these microservice instances, including but not limited to service routing information, business rules, and data protocol formats. When the parameters in the configuration center change, it can push these changes to all associated microservice instances in real time, taking effect without redeploying the services. This achieves dynamic separation and real-time updates of the configuration. The processing system uses the configuration center to dynamically manage the configurations of multiple microservice instances, ensuring efficient collaboration and service calls between services based on business needs and status changes.

[0085] Figure 5 This is a flowchart of an optional data request processing method according to an embodiment of the present invention, such as... Figure 5As shown, for multiple consecutive business-related EDI requests sent by overseas airlines, the first request, PAOREQ, can carry a message type of 44, indicating that the business type of the request is 44. PAOREQ is a common request type in civil aviation, mainly used for ticketing inquiries and processing. When the electronic data conversion service receives the first request, it first performs format validation on the message within the message preprocessing component to ensure it conforms to the structure and syntax requirements of EDI messages. If the validation is successful, the processing system will perform feature extraction, that is, separating the business fields and non-business fields from the request. The non-business fields include the requester and recipient identifiers, the version information of this request message, the request time, and operator information. Subsequently, the electronic data conversion service can perform route validation on the source and destination route information in the non-business fields based on the routing configuration information in the configuration center, thereby ensuring the security and legitimacy of the request. Then, the Electronic Data Conversion Service (EDC) can parse the PAOREQ message's msg type as 44 according to pre-defined routing rules, redirecting the business to the EDC's query interface, and calling the corresponding feature conversion method based on the target protocol format conversion configuration in the configuration center. After completing the business routing, the processing system can perform feature conversion on the fields in the above request according to the pre-defined business mapping table and field conversion logic to ensure that the key information in the above request can be losslessly converted into the target message, thereby obtaining the AirShoppingRQ message, i.e., the flight query request message. After completing the above feature conversion process, the EDC can parse whether the source route and destination route in the non-business fields match according to the routing configuration information in the configuration center. If they match, the EDC can send the above AirShoppingRQ message to the target system, i.e., the terminal query system. The second request PAORE sent by the overseas airline can carry a message type of 53. When the electronic data conversion service receives the second request, it also performs format verification, feature extraction, route verification, and feature selection on the request. Subsequently, the electronic data conversion service can perform feature conversion on the request. At this time, according to the pre-set business rules, the electronic data conversion service compares the transaction ID (transaction identifier) ​​of the second request with that of the first request. It detects that the transaction ID is the same as that of the previous request. Therefore, the electronic data conversion service can directly use the business field content in the shared memory to generate the corresponding response AirShoppingRQ message, and swap the source address and destination address of the non-business field routing information, thereby sending the above response AirShoppingRQ message back to the overseas airline to achieve the response.For the nth request of other types sent by overseas airlines, the electronic data conversion service can process the request through the above-mentioned process of format verification, feature extraction, route verification, feature selection and business diversion. Subsequently, the electronic data conversion service can call the interface of the electronic data conversion service corresponding to the current request to process the request, and finally send the message converted based on the request to the corresponding terminal system through directed routing.

[0086] Figure 6 This is a flowchart of another optional data request processing according to an embodiment of the present invention, such as... Figure 6 As shown, this process is similar to Figure 5 The process is similar. For multiple consecutive business-related EDI requests sent by overseas airlines, the Electronic Data Conversion Service receives the first request, ITAREQ. This request can be used for seat inventory query and allocation requests between airlines and travel agencies, Global Distribution Systems (GDS), etc. This request can also undergo format validation, feature extraction, route validation, feature selection, business routing, and feature conversion. Subsequently, the business fields of the message are directed to the recipient via redirected routing. The Electronic Data Conversion Service receives the second request, HWPREQ. This request can be related to flight booking, passenger information processing, or ticketing operations. This request undergoes format validation. After successful validation, feature extraction and route validation are performed sequentially. If the route validation passes, the feature selection and feature extraction stage begins. Based on the value of the msg type in the EDI, if the msg type is 56, the request will be redirected to an OrderCreateRQ message, i.e., an order creation request message. If the msg type is 57, the request will be redirected to an OrderChangeRQ message, i.e., an order modification request message, and sent to the terminal booking system. For the nth request of other types sent by overseas airlines, the electronic data conversion service can process the request through the above-mentioned process of format verification, feature extraction, route verification and feature selection. Subsequently, the electronic data conversion service can call the interface of the electronic data conversion service corresponding to the current request to process the request, and finally send the message converted based on the request to the corresponding terminal system through directed routing.

[0087] According to an embodiment of the present invention, a message processing apparatus is provided. It should be noted that this apparatus can be used to execute the above-described message processing method. The specific implementation and application scenarios are the same as those in the above embodiment, and will not be repeated here. Figure 7 This is a schematic diagram of a message processing apparatus according to an embodiment of the present invention, such as... Figure 7 As shown, the device includes:

[0088] The type acquisition module 702 is used to determine the service type of the service request message in response to receiving the service request message.

[0089] The method acquisition module 704 is used to obtain the feature conversion method corresponding to the business request message based on the business type according to the preset traffic distribution rules.

[0090] The message conversion module 706 is used to convert the fields contained in the business request message based on the feature conversion method to obtain the target request message.

[0091] The message sending module 708 is used to send the target request message to the target server, whereby the target server is used to process the business request message.

[0092] Furthermore, the type acquisition module is also used to: validate the data format of the business request message and obtain a format validation result; in response to the format validation result indicating that the data format of the business request message has passed the validation, perform compliance validation on the business request message and obtain a compliance validation result, wherein the compliance validation result is used to reflect whether the business request message is secure; in response to the compliance validation result indicating that the business request message is secure, identify the message type field contained in the business request message and obtain the business type.

[0093] Furthermore, the type acquisition module is also used to: identify the types of multiple fields contained in the business request message to obtain the field types of different fields; separate multiple fields based on the field types to obtain business fields and non-business fields; and perform compliance verification on the business request message based on the non-business fields to obtain the compliance verification results.

[0094] Furthermore, the type acquisition module is also used to: obtain the initial source routing information and initial destination routing information of the business request message based on non-business fields; obtain the target destination routing information that matches the initial source routing information from the routing configuration table; determine that the compliance verification result is that the business request message is secure if the target destination routing information is the same as the initial destination routing information; and determine that the compliance verification result is that the business request message is insecure if the target destination routing information is different from the initial destination routing information.

[0095] Furthermore, the method acquisition module is also used to: acquire the microservice used to process the business request message based on the business type; acquire the format conversion configuration parameters of the business request message based on the service identifier of the microservice, wherein the format conversion configuration parameters are used to characterize the parameters for converting the current transport protocol used by the business request message; and acquire the feature conversion method based on the format conversion configuration parameters.

[0096] Furthermore, the message conversion module is also used to: obtain a business field mapping table and field conversion logic that match the feature conversion method; based on the business field mapping table, determine a first field and a second field from multiple fields contained in the business request message, wherein the first field is used to represent fields that can be format converted through the business field mapping table, and the second field is used to represent fields that cannot be format converted through the business field mapping table; convert the first field based on the business field mapping table to obtain a first target field, and convert the second field according to the field conversion logic to obtain a second target field; reassemble the business request message based on the first target field and the second target field to obtain a target request message.

[0097] Embodiments of this application also provide an electronic device, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods in various embodiments of the present invention during runtime.

[0098] Embodiments of this application also provide a computer-readable storage medium including a stored executable program, wherein, when the executable program is executed, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of the present invention.

[0099] Embodiments of this application also provide a computer program product, including a computer program that, when executed by a processor, implements the methods of various embodiments of the present invention.

[0100] Embodiments of this application also provide a computer program product, including a non-volatile computer-readable storage medium for storing a computer program that, when executed by a processor, implements the methods in various embodiments of the present invention.

[0101] Embodiments of this application also provide a computer program that, when executed by a processor, implements the methods described in the various embodiments of the present invention.

[0102] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

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

[0104] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0105] Furthermore, the functional units in the various embodiments of the present invention 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.

[0106] 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 computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0107] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A message processing method, characterized in that, include: Upon receiving a service request message, determine the service type of the service request message; According to the preset traffic splitting rules, the feature conversion method corresponding to the service request message is obtained based on the service type; Based on the aforementioned feature conversion method, the fields contained in the business request message are converted to obtain the target request message; The target request message is sent to the target server, wherein the target server is used to process the service request message; The process of converting fields contained in the service request message based on the feature conversion method to obtain a target request message includes: obtaining a service field mapping table and field conversion logic matching the feature conversion method; determining a first field and a second field from multiple fields contained in the service request message based on the service field mapping table, wherein the first field is used to characterize fields that can be format converted through the service field mapping table, and the second field is used to characterize fields that cannot be format converted through the service field mapping table; converting the first field based on the service field mapping table to obtain a first target field, and converting the second field according to the field conversion logic to obtain a second target field; and reassembling the service request message based on the first target field and the second target field to obtain the target request message.

2. The method according to claim 1, characterized in that, Determining the service type of the service request message includes: The data format of the service request message is validated to obtain the format validation result; In response to the format verification result indicating that the data format of the business request message has passed the verification, a compliance verification is performed on the business request message to obtain a compliance verification result, wherein the compliance verification result is used to reflect whether the business request message is secure; In response to the compliance verification result indicating that the business request message is secure, the message type field contained in the business request message is identified to obtain the business type.

3. The method according to claim 2, characterized in that, The compliance verification of the business request message is performed to obtain the compliance verification result, including: The types of multiple fields contained in the service request message are identified to obtain the field types of different fields; Based on the field type, the multiple fields are separated to obtain business fields and non-business fields; The compliance verification of the business request message is performed based on the non-business fields to obtain the compliance verification result.

4. The method according to claim 3, characterized in that, Based on the non-business fields, the business request message is subjected to compliance verification to obtain the compliance verification result, including: Based on the non-business fields, obtain the initial source routing information and initial destination routing information of the business request message; Retrieve the target destination routing information that matches the initial source routing information from the routing configuration table; In response to the fact that the target destination routing information is the same as the initial destination routing information, the compliance verification result is determined to be secure for the service request message; In response to the discrepancy between the target destination routing information and the initial destination routing information, the compliance verification result is determined to be that the service request message is insecure.

5. The method according to claim 1, characterized in that, According to preset traffic splitting rules, the feature conversion method corresponding to the service request message is obtained based on the service type, including: Based on the business type, obtain the microservice used to process the business request message; Based on the service identifier of the microservice, obtain the format conversion configuration parameters of the business request message, wherein the format conversion configuration parameters are used to characterize the parameters for converting the current transmission protocol used by the business request message; The feature conversion method is obtained based on the format conversion configuration parameters.

6. A message processing apparatus, characterized in that, include: The type acquisition module is used to determine the service type of the received service request message in response to the received service request message; The method acquisition module is used to obtain the feature conversion method corresponding to the service request message based on the service type according to the preset traffic splitting rules. The message conversion module is used to convert the fields contained in the service request message based on the feature conversion method to obtain the target request message; A message sending module is used to send the target request message to the target server, wherein the target server is used to process the service request message; The message conversion module is further configured to: obtain a service field mapping table and field conversion logic matching the feature conversion method; determine a first field and a second field from multiple fields contained in the service request message based on the service field mapping table, wherein the first field is used to characterize fields that can be format converted through the service field mapping table, and the second field is used to characterize fields that cannot be format converted through the service field mapping table; convert the first field based on the service field mapping table to obtain a first target field, and convert the second field according to the field conversion logic to obtain a second target field; and reassemble the service request message based on the first target field and the second target field to obtain the target request message.

7. An electronic device, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program, when running, performs the method according to any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored executable program, wherein, when the executable program is executed, it controls the device on which the storage medium is located to perform the method according to any one of claims 1 to 5.

9. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method according to any one of claims 1 to 5.

Images