Message processing method and device, electronic equipment and storage medium

Abstract

The invention discloses a message processing method and device, electronic equipment and a storage medium. The method comprises the following steps: in response to a received service request message, determining a service type of the service request message; obtaining a feature conversion mode corresponding to the service request message based on the service type according to a preset distribution rule; converting a field contained in the service request message based on a feature conversion mode to obtain a target request message; the target request message is sent to a target server, and the target server is used for processing the service request message. According to the invention, the technical problem of low accuracy of message conversion in the prior art is solved.

Description

Technical Field

[0001] The present invention relates to the field of civil aviation services, and in particular to a message processing method and device, electronic equipment, and a storage medium. Background Art

[0002] In the information development of the aviation industry, different civil aviation systems and airlines need to frequently exchange electronic data (EDI) to ensure the efficient operation of flight information, ticket processing, passenger services and other businesses. Extensible Markup Language (XML) is considered to be a better data transmission method due to its customizability, scalability and good cross-platform compatibility. XML allows airlines and their suppliers to customize data fields, enhance the readability and comprehensibility of data, and is easily received by airlines and their passenger service system suppliers.

[0003] However, XML format message conversion still faces challenges, especially in the conversion process from EDI to XML. Traditional conversion methods can only achieve rough direct mapping, resulting in low conversion accuracy. The business meaning conveyed by the converted XML may change, ultimately affecting actual production business.

[0004] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

[0005] The embodiments of the present invention provide a message processing method and device, an electronic device, and a storage medium, so as to at least solve the technical problem of low accuracy of message conversion in the related art.

[0006] According to one aspect of an embodiment of the present invention, a message processing method is provided, including: 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 diversion 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] Furthermore, determining the business type of the business request message includes: verifying the data format of the business request message to obtain a format verification result; in response to the format verification result being that the data format verification of the business request message passes, performing a compliance verification 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 safe; in response to the compliance verification result being that the business request message is safe, identifying the message type field contained in the business request message to obtain the business type.

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

[0009] Furthermore, a compliance check is performed on the business request message based on the non-business field to obtain a compliance check result, including: based on the non-business field, obtaining the initial source routing information and the initial destination routing information of the business request message; obtaining the target destination routing information that matches the initial source routing information from the routing configuration table; in response to the target destination routing information being the same as the initial destination routing information, determining that the compliance check result is that the business request message is safe; in response to the target destination routing information being different from the initial destination routing information, determining that the compliance check result is that the business request message is unsafe.

[0010] Furthermore, according to the preset diversion rules, a feature conversion method corresponding to the business request message is obtained based on the business type, including: based on the business type, obtaining a microservice for processing the business request message; based on the service identifier of the microservice, obtaining 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 transmission protocol currently used by the business request message; and obtaining the feature conversion method based on the format conversion configuration parameters.

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

[0012] According to another aspect of an embodiment of the present invention, a message processing device is also provided, including: a type acquisition module, used to determine the business type of the business request message in response to receiving a business request message; a mode acquisition module, used to obtain the characteristic conversion mode corresponding to the business request message based on the business type according to a preset diversion rule; a message conversion module, used to convert the fields contained in the business request message based on the characteristic conversion mode to obtain a target request message; and a message sending module, used to send the target request message to a target server, wherein the target server is used to process the business request message.

[0013] According to another aspect of an embodiment of the present invention, there is further provided an electronic device, comprising: a memory storing an executable program; and a processor for running the program, wherein the method in each embodiment of the present invention is executed when the program is running.

[0014] According to another aspect of an embodiment of the present invention, a computer-readable storage medium is provided. The computer-readable storage medium includes a stored executable program, wherein when the executable program is running, the device where the computer-readable storage medium is located is controlled to execute the methods in various embodiments of the present invention.

[0015] According to another aspect of an embodiment of the present invention, a computer program product is provided, including a computer program. When the computer program is executed by a processor, the method in each embodiment of the present invention is implemented.

[0016] According to another aspect of an embodiment of the present invention, a computer program product is provided, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method in each embodiment of the present invention is implemented.

[0017] According to another aspect of the embodiments of the present invention, a computer program is further provided. When the computer program is executed by a processor, the methods in the embodiments of the present invention are implemented.

[0018] In an embodiment of the present invention, in response to receiving a service request message, the service type of the service request message is determined; according to a preset diversion rule, a feature conversion method corresponding to the service request message is obtained based on the service type; based on the feature conversion method, the fields contained in the service request message are converted to obtain a target request message; the target request message is sent to a target server. By identifying the service type, the purpose and conversion requirements of the message can be accurately determined, and corresponding feature conversion methods are further assigned to different service types, so that the converted target request message can correctly reflect the business requirements in a variety of target formats, thereby achieving the purpose of lossless conversion of the service request message, thereby realizing the technical effect of improving the accuracy of service request message conversion, and further solving the technical problem of low accuracy of message conversion in related technologies. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:

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

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

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

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

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

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

[0026] Figure 7 It is a schematic diagram of a message processing device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0027] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work 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 and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[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 of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0030] Figure 1 is a flow chart of a message processing method according to an embodiment of the present invention. Figure 1 As shown, the method comprises the following steps:

[0031] Step S102: in response to receiving the service request message, determining the service type of the service request message.

[0032] The service request message may refer to an electronic data message sent between the civil aviation system and the airline in the service process, which can be used to request the execution of a service operation. The service type may be a category of a specific service operation or function required to be executed in the service request message, for example, the service type may include at least one or more of the following: ticket issuance, exchange, refund, invalid ticket, etc., but is not limited thereto.

[0033] In an optional embodiment, considering that different business types usually correspond to different business logics and data processing flows, when a 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 operations to be performed, thereby calling the correct logic to process the business request message, avoiding data confusion and business errors caused by incorrect processing flows.

[0034] For example, in the electronic data interchange scenario of the aviation industry, it can be assumed that the processing system receives a business request message in EDI format, which can contain a msg type field to indicate the business type. It can be further assumed that the msg type field value of the message is A, which indicates that the business type requested by the message is a ticketing operation. In order to improve the processing accuracy of the business request message, the processing system can first parse the received business request message and focus on reading the msgtype field of the message. After the reading is completed, the processing system can match the read msg type field value with the pre-configured business type identification rule, thereby determining that the business type of the above business request message is a ticketing operation.

[0035] It should be noted that the above-mentioned specific values ​​such as the field name used to indicate the business type and the field value corresponding to the ticketing operation are only for illustrative purposes. The staff can configure them according to actual needs and are not limited here.

[0036] Step S104: According to the preset diversion rule, a feature conversion method corresponding to the service request message is obtained based on the service type.

[0037] The preset diversion rules may refer to rules that are pre-set by the processing system under the microservice architecture to determine how messages are distributed and processed between different microservices according to the business type of the received business request message. The feature conversion method may refer to a conversion strategy or algorithm used to convert a business field in a business request message into another data format during the electronic data conversion process. For example, the feature conversion method may be field mapping, composite field processing, etc., but is not limited thereto.

[0038] In an optional embodiment, taking into account that when the processing system converts the business request message, if a general conversion method is used, the conversion accuracy of the message data may be low, the processing system can pre-set diversion rules and obtain the feature conversion method corresponding to the business request message based on the business type, so that when the processing system processes the business request message, it can quickly call the conversion logic corresponding to the business type of the message, thereby improving the efficiency and accuracy of the message conversion.

[0039] For example, it can be assumed that the processing system pre-sets the feature conversion methods corresponding to the four business types of ticket issuance, exchange, refund, and invalid ticket. The preset diversion rule can be to divert the business request message according to the 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 the business type corresponding to the message as refund. The processing system can obtain the feature conversion method corresponding to the business request message as field mapping based on the business type.

[0040] Step S106: convert the fields included in the service request message based on the feature conversion method to obtain a target request message.

[0041] The target request message may refer to a new message that meets 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 processing a large number of continuous and related business requests, converting the fields contained in the business request messages using a feature conversion method can reduce redundant data processing and improve the conversion efficiency of the processing system. Therefore, the processing system can convert the fields contained in the business request messages based on the feature conversion method to obtain the target request message.

[0043] For example, when processing the above-mentioned 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 the flight information, date, time and other fields in the EDI message, and map the above-mentioned fields to corresponding key-value pairs in the JSON message, and then the processing system can convert the data in the EDI field into the standard data type in the JSON format, thereby obtaining the above-mentioned target request message.

[0044] Step S108: sending the target request message to the target server, wherein the target server is used to process the service request message.

[0045] The above-mentioned target server may refer to a back-end system or service that receives and processes the above-mentioned target request message in the electronic data exchange 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 performing business operations.

[0047] For example, it can be assumed that the processing system has obtained the above-mentioned 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 a data body to the target server.

[0048] In an embodiment of the present invention, in response to receiving a service request message, the service type of the service request message is determined; according to a preset diversion rule, a feature conversion method corresponding to the service request message is obtained based on the service type; based on the feature conversion method, the fields contained in the service request message are converted to obtain a target request message; the target request message is sent to a target server. By identifying the service type, the purpose and conversion requirements of the message can be accurately determined, and corresponding feature conversion methods are further assigned to different service types, so that the converted target request message can correctly reflect the business requirements in a variety of target formats, thereby achieving the purpose of lossless conversion of the service request message, thereby realizing the technical effect of improving the accuracy of service request message conversion, and further solving the technical problem of low accuracy of message conversion in related technologies.

[0049] Furthermore, determining the business type of the business request message includes: verifying the data format of the business request message to obtain a format verification result; in response to the format verification result being that the data format verification of the business request message passes, performing a compliance verification 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 safe; in response to the compliance verification result being that the business request message is safe, identifying the message type field contained in the business request message to obtain the business type.

[0050] The format check result may be a result used to determine whether the message meets a predefined data format specification. The compliance check may be a check used to verify whether the service request message is safe.

[0051] In an optional embodiment, considering that the correct business request message format helps the back-end system or service to quickly parse and respond to requests, avoiding unnecessary data processing or exception processing, the processing system can first verify the data format of the business request message to obtain a format verification result to ensure the integrity and accuracy of the data during transmission. If the above format verification result shows that the data format verification of the business request message has passed, the processing system can also perform a compliance check on the business request message to obtain a compliance verification result to prevent attacks such as malicious code and SQL (Structured Query Language) injection, thereby ensuring the security of the processing system and business data. If the above compliance verification result shows that the above business request message is safe, 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 above business request message.

[0052] For example, it can be assumed that the processing system has received a business request message. In order to correctly parse out the business type corresponding to the above business request message, the processing system can first perform a data format check on the message, that is, the processing system can determine whether the message has the correct grammatical structure and whether the business-related fields are complete. After completing the above check, the processing system can obtain the format check result for the message. If the result shows that the data format of the above business request message is correct, the processing system can further perform a compliance check on the message, that is, the processing system can determine whether the source of the message is legal, whether the data is secure, and whether the business request complies with predefined rules. After the above compliance check, the processing system can obtain a compliance check result for the message. If the result shows that the above business request message is secure, the processing system can determine the business type corresponding to the message based on the msg type field contained in the business request message, so as to correctly divert the message to the corresponding business processing component.

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

[0054] The above-mentioned field type may be the application type of each field in the business request message. For example, the above-mentioned field type may include at least one or more of the following: amount type, routing information type, identity type, flight information type, time type, etc., but not limited thereto. The above-mentioned business field may refer to a data field directly related to the business logic in the business request message. For example, the above-mentioned business field may include at least one or more of the following: transaction amount, flight number, passenger information, product code, etc., but not limited thereto. The above-mentioned non-business field may refer to a field in the business request message that is not directly involved in the business logic processing but is of great significance to data transmission and system management. For example, the above-mentioned non-business field may include at least one or more of the following: routing information, EDI version information, unique identifier of the message sender, etc., but not limited thereto.

[0055] In an optional embodiment, the processing system can verify whether the data of 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 failure 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 can separate multiple fields based on the above field types to obtain the above business fields and non-business fields. Since the above non-business fields may contain information such as request ID (Identification), sender identification, timestamp, etc., the processing system can perform compliance verification on the business request message based on this information, thereby obtaining the compliance verification result for the above business request message, so that the processing system can understand the source and destination of the message, thereby ensuring the compliance and security of the message transmission.

[0056] For example, in order to accurately separate the business fields and non-business fields in the business request message, so that the processing system can perform compliance verification on the business request message, the processing system can pre-train a feature extraction model based on a deep learning algorithm, and the model can output a set of business fields and non-business fields based on the field types and field values ​​of different fields in the current business request message. Specifically, it can be assumed that the processing system receives a business request message, which contains field A, field B and field C. The processing system first identifies the field types of the above multiple fields, and the identification result can be as follows: the field type of field A is the amount class, the field type of field B is the routing information class, and the field type of field C is the flight information class. The processing system can input the above identification result and the field value of the above fields into the above feature extraction model, and the model can output the following result: the business field set includes field A and field C, and the non-business field set includes field B. Subsequently, the processing system can perform compliance verification on the above business request message based on field B, thereby obtaining the compliance verification result of the processing system for the message.

[0057] Furthermore, a compliance check is performed on the business request message based on the non-business field to obtain a compliance check result, including: based on the non-business field, obtaining the initial source routing information and the initial destination routing information of the business request message; obtaining the target destination routing information that matches the initial source routing information from the routing configuration table; in response to the target destination routing information being the same as the initial destination routing information, determining that the compliance check result is that the business request message is safe; in response to the target destination routing information being different from the initial destination routing information, determining that the compliance check result is that the business request message is unsafe.

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

[0059] In an optional embodiment, considering that if there is an error in the sending path of the service request message, it may cause the leakage of civil aviation service information, thereby reducing the security of the processing system, therefore, in order to ensure the accuracy of the sending path of the service request message, the processing system can pre-build a routing configuration table, which can be established based on the civil aviation business protocol and security policy, and is used to store the corresponding relationship between the source route and the destination route, so as to ensure that only the data transmission between the authorized entities is allowed. After completing the construction of the routing information table, the processing system can first parse the initial source routing information and the initial destination routing information of the service request message from the above non-business field, and can further obtain the target destination routing information matching the initial source routing information from the above routing configuration table. If the target destination routing information obtained from the routing configuration table matches the initial destination routing information declared in the service request message, it indicates that the data transmission is carried out according to the established routing rules and meets 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 that the service request message is safe. If the target destination routing information does not match the initial destination routing information declared in the message, this indicates that there may be an abnormality in the transmission process of the business request message, such as a routing error, a man-in-the-middle attack (MITM), or data tampering. At this time, the compliance check result of the processing system for the message may be that the business request message is not safe.

[0060] For example, it can be assumed that the processing system has constructed a routing configuration table, which contains a matching rule of a predetermined sending source and a sending destination, and the rule can be as follows: Entity A can send a service request message to entity C and entity D, and entity B can send a service request message to entity C. In this embodiment, it can be further assumed that the processing system has received two service request messages, recorded as message 1 and message 2, and the processing system has obtained the non-service fields of message 1 and message 2. Further, the processing system can parse out from the initial source routing information of message 1 that the message is sent by entity A, and can parse out from the initial destination routing information of message 1 that the message is 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 compliance check result of the processing system for message 1 is that message 1 is safe. Similarly, the processing system can parse out from the initial source routing information of message 2 that the message is sent by entity B, and can parse out from the initial destination routing information of message 2 that the message is 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 check result for message 2 is that message 2 is unsafe.

[0061] Furthermore, according to the preset diversion rules, a feature conversion method corresponding to the business request message is obtained based on the business type, including: based on the business type, obtaining a microservice for processing the business request message; based on the service identifier of the microservice, obtaining 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 transmission protocol currently used by the business request message; and obtaining the feature conversion method based on the format conversion configuration parameters.

[0062] The service identifier may be a label or name used to uniquely identify a microservice. The format conversion configuration parameters may be rules and standards used to convert a service request message from one transmission protocol to another protocol. The transmission protocol may be the rules and standards followed when data is transmitted on a network. For example, the transmission protocol may be EDI, XML, JSON or YAML, but is not limited thereto.

[0063] In an optional embodiment, considering that different business types may be handled by different microservices, such as query services, reservation services, ticketing services, etc., by identifying the type of business request message, the processing system can accurately call the microservice responsible for processing the type of business, thereby avoiding redundancy and confusion in data processing and improving the efficiency and accuracy of business processing. Therefore, the processing system can first determine the microservice used to process the business request message based on the business type. After determining the microservice that processes the above-mentioned business request message, further considering that different microservices may use different configuration parameters, the above-mentioned configuration parameters include how to convert the business request message from the current transmission protocol (such as EDI) to the internal protocol supported by the microservice (such as yaml, JSON), therefore, 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 keep the business meaning of the business request message consistent during the transmission process, and then ensure the integrity and accuracy of the 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 find out that the business type corresponding to the message is flight query. Then, according to the above business type, the processing system can find the corresponding microservice in the service discovery mechanism or configuration center as flight query service. The above flight query service is a microservice that specifically handles flight queries. It can be assumed that the microservice identifier of the 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 the above format conversion configuration parameters, according to the conversion logic defined in the parameters, the vehicle system can perform feature conversion on the above business request message, that is, convert the EDI message into a message in yaml format.

[0065] Specifically, in order to realize the lightweight application of EDI, the processing system can pre-deploy microservices for processing business request messages. In this embodiment, the civil aviation ticket-related business can be taken as an example. The processing system needs to first design the corresponding yaml method according to the EDI message type. The specific yaml method and the business design corresponding to the EDI message type are shown in Table 1 below:

[0066] Table 1

[0067]

[0068] Among them, the yaml method is the method name defined for civil aviation business in this embodiment, which is used to identify different business operations, such as issue, void, refund, etc. These method names will be used in the microservice architecture as references to conversion rules to achieve conversion from EDI format to yaml or other target formats. EDI type is a standard format for data transmission between civil aviation systems, used for electronic data exchange in the civil aviation industry. For example, TKTREQ 130 represents a ticket request, and TKTREQ 133 / 776 represents a void request, etc. The business description is used to describe the specific business operations represented by each EDI type message, such as issue, void, refund, exchange, etc. The business description helps to understand and locate the role of the message in the civil aviation business process, and provides a business logic basis for data conversion. In this embodiment, by pre-defining YAML methods, accurate matching and efficient conversion of common EDI message types in civil aviation business can be achieved, which not only solves the complexity and redundancy problems of traditional EDI data conversion, but also enhances the readability and flexibility of the data, so that data can be processed and transmitted in a more efficient manner in the microservice architecture, thereby better adapting to the complex needs of aviation business.

[0069] Subsequently, the processing system can design fields according to the information that must be included in the corresponding business. The field names, types, formats, descriptions, and other definitions will use the public data dictionary of the civil aviation service industry. Fields that are not found in the public data dictionary must apply to be included in the private data dictionary. Only those that pass the private dictionary review can be included in the private data dictionary. Here, civil aviation flight information can be used 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 signs bool 0 / 1 flightStatusCode Flight Status string secureFlight Safe Flight bool 0 / 1 beginFlightNumber Starting flight number int flightDate The departure date of the first leg of the flight string yyyy-mm-dd borrowMethodInd Flight seat borrowing method bool 0 / 1 flightRemark Flight Notes string segmentId Flight number string

[0072] Among them, the English name is the English identifier used to represent the data field in the civil aviation business in the yaml structure, such as flightNumber represents the flight number, and internationalInd is used to mark whether it is an international flight. The Chinese name is the Chinese explanation corresponding to the above English identifier, which is convenient for understanding the actual meaning of the field, such as the Chinese name corresponding to flightNumber is flight number, and flightSuffix is ​​flight suffix. Type is used to specify the data type of the field. For example, flightNumber is defined as int, indicating that this is an integer type used to store flight number information. The type of flightDate is string, indicating that this is a string type. Format is used to define the specific format of the data, such as the format of flightNumber is 3-4 digits, and the format of flightDate is yyyy-mm-dd, that is, the format of year-month-day. By defining the format of the data, it can be ensured that the representation of the data in yaml conforms to the preset rules, which is convenient for subsequent processing or data exchange with other systems.

[0073] Then, the processing system can define each YAML method separately according to the business characteristics. Specifically, the processing system can define the hierarchical structure and business fields of the YAML method. Here, 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 Main ticket information node, containing detailed data of the ticket 1.1ticketNumberDetails M Ticket number details node, used to provide ticket number information 1.1.1ticketNumber M Ticket Number 1.1.2conjunctionTicketTotalNumber C Total number of coupons 1.1.3dataIndicator C Data indicator 1.1.4conjunction C Coupon logo 1.2revalidationTimes C Re-authentication times 1.3International M Is it an international flight? 1.4etType M E-ticket type 1.5group M Ticket Grouping Information 1.6 coupons M Ticket Information 1.6.1couponInformation 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.2couponStatus M Ticket Status 1.6.1.1.3settlementAuthCode C Settlement authorization code

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

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

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

[0079] The above-mentioned business field mapping table may be a table for storing the mapping relationship between the fields in the source data format and the fields in the target data format. The above-mentioned field conversion logic may be a logic for processing those fields that do not have a direct mapping relationship between the source format and the target format. The above-mentioned first field may refer to a business field that can be directly format-converted through the business field mapping table. The above-mentioned second field may be a business field that cannot be directly format-converted through the business field mapping table. The above-mentioned first target field may be a field in the target format formed after the above-mentioned first field is converted through the business field mapping table. The above-mentioned second target field may be a field in the target format formed after the above-mentioned second field is converted according to the field conversion logic.

[0080] In an optional embodiment, considering that different business scenarios may require different conversion rules during the data format conversion process, in order to improve the accuracy of data format conversion, the processing system can predefine the business field mapping table and field conversion logic according to business requirements and target data formats, thereby ensuring that each field in the original message has a corresponding processing method in the target message. Further considering that there may be some fields in the business request message that are difficult to directly convert the format based on the business field mapping table, therefore, the processing system can determine such fields as the above-mentioned second fields, and determine the fields of the business request message that can be directly converted based on the business field mapping table as the above-mentioned first fields. After completing the division of the above-mentioned first field and the second field, 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. As for the above-mentioned 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 reorganize the first target field obtained by converting the mapping table and the second target field obtained by processing the field conversion logic to create a target request message, so that the above target request message can follow 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, and the message format of the target system may be a yaml format. The processing system may construct the above-mentioned business field mapping table in advance based on the mapping relationship between the business fields from the EDI format to the yaml format. In order to process the business fields that cannot be directly converted in format through the above-mentioned business field mapping table, the processing system may also construct the above-mentioned field conversion logic in advance. It can be assumed that the business request message received by the processing system contains fields A, B, C and D. The processing system can identify that the above-mentioned fields A and B are the first fields, and fields C and D are the second fields. At this time, the processing system can directly convert field A into yaml format based on the above-mentioned business field mapping table to obtain field a, and convert field B into yaml format to obtain field b, then the above-mentioned first target field includes field a and field b. At the same time, the processing system can convert field C into yaml format based on the above-mentioned field conversion logic to obtain field c, and convert field D into yaml format to obtain field d, then the above-mentioned second target field includes field c and field d. Finally, the processing system may combine the first target field and the second target field to obtain a target request message in a YAML format.

[0082] For ease of understanding, Figure 2 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: a namespace (Namespace), and n+1 namespaces are shown in the figure, namely Namespace'default', Namespace 1 and Namespace n, each namespace represents a different business field or functional module. Among them, the namespace Namespace'default' contains multiple service routes (only two are shown in the figure), namely service route (namespace 1) and service route (namespace n). The service route is used to control the data flow, and can guide the data to the correct service call component according to different business requirements and rules. Namespace Namespace 1 contains a service call component and multiple electronic data conversion services. Only two electronic data conversion services are shown in the figure, namely electronic data conversion service (1, 1) and electronic data conversion service (1, m1). In each structure of the above namespace Namespace 1, the service call component is responsible for calling a specific electronic data conversion service. They can select and call different service instances according to business characteristics and conversion requirements. In this application, the service call component can use the Call Service function to call, and the figure shows the calling methods of Call Service (1, k) and Call Service (n, k). The electronic data conversion service is used to implement the conversion logic from EDI to XML, JSON or other formats based on different business types. Namespace n also contains service call components and multiple electronic data conversion services. Only two electronic data conversion services are shown in the figure, namely electronic data conversion service (n, 1) and electronic data conversion service (n, mn). The functions of each structure in the above namespace n are consistent with those in namespace 1, and will not be repeated here.

[0083] Figure 3 is a flow chart of an optional business feature extraction according to an embodiment of the present invention. Figure 3 As shown, when the processing system receives an EDI request sent by an external requester, it will first check the request parameters to ensure that the request complies with the predefined EDI standards and format requirements. If the request parameter verification fails, the processing system will perform exception processing. After completing the above exception processing, the conversion ends. If the request parameter verification succeeds, the system will enter the feature extraction stage to separate the business fields and non-business fields in the EDI message. After feature extraction, the non-business fields are used to verify the route. If the verification route fails, the processing system can perform exception processing. After completing the above exception processing, the conversion ends. If the verification route succeeds, the processing system can perform business diversion and can further perform feature conversion. When the feature conversion is completed, the conversion ends.

[0084] Figure 4 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 in the center and connected to six different electronic data conversion microservice instances, including: electronic data conversion service-query instance 1, electronic data conversion service-booking instance 1, electronic data conversion service-ticket instance 1, electronic data conversion service-query instance 2, electronic data conversion service-booking instance 2, and electronic data conversion service-ticket instance 2. The responsibility of the configuration center is to manage the configuration information of these microservice instances, including but not limited to the routing information, business rules, data protocol format, etc. of the service. When the parameters of the configuration center change, the configuration center can push these changes to all related microservice instances in real time, and the changes can take effect without redeploying the service, thus realizing the dynamic separation and real-time update of the configuration. The processing system realizes dynamic configuration management of multiple microservice instances through the configuration center, which can ensure that the services can efficiently collaborate and call services according to business needs and status changes.

[0085] Figure 5 is a flowchart of an optional data request processing according to an embodiment of the present invention. Figure 5As shown in the figure, for multiple consecutive business-related EDI requests sent by overseas airlines, the msg type carried by the first PAOREQ request can be 44, that is, the business type carried by the request is 44. PAOREQ is a common request type in civil aviation business, mainly used for ticket query and processing. When the electronic data conversion service receives the first request, it first performs a format check on the message in the message preprocessing component to ensure that it meets the structure and grammatical requirements of the EDI message. If the check is successful, the processing system will perform feature extraction, that is, stripping the business field and non-business field in the above request, wherein the non-business field includes the requester identifier and the receiver identifier of the message, the version information of the request message, the request time and the operator information, etc. Subsequently, the electronic data conversion service can perform a routing check on the source routing and destination routing information in the above non-business field according to the routing configuration information in the configuration center, thereby ensuring the security and legitimacy of the above request. Then, the electronic data conversion service can parse the msg type of the PAOREQ message as 44 through the pre-set diversion rules, divert the business to the query interface of the electronic data conversion service, and call the corresponding feature conversion method according to the target protocol format conversion configuration in the configuration center. After completing the business diversion, the processing system can perform feature conversion on the fields in the above request according to the pre-set business mapping table and field conversion logic to ensure that the key information in the above request can be converted to the target message without loss, thereby obtaining the AirShoppingRQ message, that is, the flight query request message. After completing the above feature conversion process, the electronic data conversion service can parse whether the source route and the destination route in the non-business field match according to the routing configuration information in the configuration center. If they match, the electronic data conversion service can send the above AirShoppingRQ message to the target system, that is, the terminal query system. The msg type carried by the second request PAORE sent by the above-mentioned overseas airline can be 53. When the electronic data conversion service receives the second request, it also performs format verification, feature extraction, routing verification and feature selection on the request. Then 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 transactionID of the second request with the transactionID of the first request, that is, the transaction identifier, and detects that the transactionID is the same as 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 switch the source address and destination address of the non-business field routing information, so as to send the above-mentioned 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 format verification, feature extraction, route verification, feature selection and business diversion processes. 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 directional routing.

[0086] Figure 6 is a flowchart of another optional data request processing according to an embodiment of the present invention. Figure 6 As shown, the process is Figure 5 The process shown is similar. For multiple consecutive business-related EDI requests sent by overseas airlines, the electronic data conversion service receives the first request ITAREQ, which can be used for seat inventory query and allocation requests between airlines and travel agencies, distribution systems (GDS), etc. The request can also be processed by format verification, feature extraction, routing verification, feature selection, business diversion, feature conversion, etc., and then the business field of the message is sent to the recipient through directional routing. The electronic data conversion service receives the second request HWPREQ, which can be a request related to flight booking, passenger information processing or ticketing operations. The request can be format verified. After the verification passes, feature extraction and routing verification are performed in sequence. When the routing verification passes, the feature selection and feature extraction stage is entered. According to the value of msg type in EDI, if msg type is 56, the request will be directed to OrderCreateRQ message, that is, order creation request message. If msg type is 57, the request will be directed to OrderChangeRQ message, that is, order modification request message, and sent to the terminal reservation 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 format verification, feature extraction, route verification and feature selection processes. 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 directional routing.

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

[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 mode acquisition module 704 is used to acquire the feature conversion mode corresponding to the service request message based on the service type according to the preset diversion rule.

[0090] The message conversion module 706 is used to convert the fields included in the service 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, wherein the target server is used to process the service request message.

[0092] Furthermore, the type acquisition module is also used to: verify the data format of the business request message to obtain a format verification result; in response to the format verification result being that the data format verification of the business request message passes, perform a compliance check 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 safe; in response to the compliance verification result being that the business request message is safe, identify the message type field contained in the business request message to 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 field types of different fields; separate multiple fields based on the field type to obtain business fields and non-business fields; perform compliance verification on the business request message based on the non-business field to obtain a compliance verification result.

[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; in response to the target destination routing information being the same as the initial destination routing information, determine that the compliance verification result is that the business request message is safe; in response to the target destination routing information being different from the initial destination routing information, determine that the compliance verification result is that the business request message is unsafe.

[0095] Furthermore, the method acquisition module is also used to: 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 transmission protocol currently used by the business request message; based on the format conversion configuration parameters, obtain the feature conversion method.

[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 a field that can be formatted through the business field mapping table, and the second field is used to represent a field that cannot be formatted through the business field mapping table; based on the business field mapping table, convert the first field to obtain a first target field, and convert the second field according to the field conversion logic to obtain a second target field; based on the first target field and the second target field, reorganize the business request message to obtain a target request message.

[0097] An embodiment of the present application further provides an electronic device, comprising: 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 when running.

[0098] An embodiment of the present application further provides a computer-readable storage medium, which includes a stored executable program, wherein when the executable program is running, the device where the computer-readable storage medium is located is controlled to execute the methods in various embodiments of the present invention.

[0099] An embodiment of the present application further provides a computer program product, including a computer program, which implements the methods in various embodiments of the present invention when executed by a processor.

[0100] An embodiment of the present application further provides a computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium is used to store a computer program, and when the computer program is executed by a processor, the method in each embodiment of the present invention is implemented.

[0101] The embodiments of the present application further provide a computer program, which implements the methods in the above-mentioned embodiments of the present invention when executed by a processor.

[0102] In the above embodiments of the present invention, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made 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. Among them, the device embodiments described above are only schematic. For example, the division of the units can be a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

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

[0105] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0106] If the integrated unit is implemented in the form of 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, and the computer software product is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, a server or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, magnetic disk or optical disk and other media that can store program codes.

[0107] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principle of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A message processing method, characterized in that: include: In response to receiving a service request message, determining a service type of the service request message; According to the preset diversion rules, obtaining the feature conversion mode corresponding to the service request message based on the service type; Converting the fields included in the service request message based on the feature conversion method to obtain a target request message; The target request message is sent to a target server, wherein the target server is used to process the service request message.

2. The method according to claim 1, characterized in that: Determining the service type of the service request message includes: Verifying the data format of the service request message to obtain a format verification result; In response to the format verification result being that the data format verification of the service request message passes, performing a compliance verification on the service request message to obtain a compliance verification result, wherein the compliance verification result is used to reflect whether the service request message is safe; In response to the compliance check result indicating that the service request message is safe, a message type field included in the service request message is identified to obtain the service type.

3. The method according to claim 2, characterized in that Performing compliance check on the service request message to obtain compliance check results, including: Identify the types of multiple fields included in the service request message to obtain field types of different fields; Separating the multiple fields based on the field type to obtain business fields and non-business fields; A compliance check is performed on the service request message based on the non-service field to obtain the compliance check result.

4. The method according to claim 3, characterized in that: Performing compliance verification on the service request message based on the non-service field to obtain the compliance verification result includes: Based on the non-business field, obtaining initial source routing information and initial destination routing information of the business request message; Acquire target destination routing information matching the initial source routing information from the routing configuration table; In response to the target destination routing information being the same as the initial destination routing information, determining that the compliance verification result is that the service request message is safe; In response to the target destination routing information being different from the initial destination routing information, it is determined that the compliance check result is that the service request message is unsafe.

5. The method according to claim 1, characterized in that According to the preset diversion rule, obtaining the feature conversion mode corresponding to the service request message based on the service type includes: Based on the business type, obtain a microservice for processing the business request message; Based on the service identifier of the microservice, obtain a format conversion configuration parameter of the business request message, wherein the format conversion configuration parameter is used to represent a parameter for converting a transmission protocol currently used by the business request message; The feature conversion mode is obtained based on the format conversion configuration parameters.

6. The method according to claim 1, characterized in that The fields included in the service request message are converted based on the feature conversion method to obtain a target request message, including: Obtaining 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 included in the business request message, wherein the first field is used to represent a field that can be formatted through the business field mapping table, and the second field is used to represent a field that cannot be formatted through the business field mapping table; The first field is converted based on the business field mapping table to obtain a first target field, and the second field is converted according to the field conversion logic to obtain a second target field; the business request message is reorganized based on the first target field and the second target field to obtain the target request message.

7. A message processing device, characterized in that: include: A type acquisition module, configured to determine the service type of the service request message in response to receiving the service request message; A mode acquisition module, used to acquire a feature conversion mode corresponding to the service request message based on the service type according to a preset diversion rule; A message conversion module, used for converting the fields included in the service request message based on the feature conversion method to obtain a target request message; The 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.

8. An electronic device, characterized in that: include: A memory storing an executable program; A processor, configured to run the program, wherein the program executes the method according to any one of claims 1 to 6 when running.

9. 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, the device where the storage medium is located is controlled to execute the method according to any one of claims 1 to 6.

10. A computer program product, characterized in that The invention comprises a computer program which, when executed by a processor, implements the method according to any one of claims 1 to 6.

Images