Business data processing methods, electronic devices, and storage media

Abstract

This invention discloses a business data processing method, electronic device, and storage medium. The method includes: acquiring gateway logs of a microservice gateway; determining event activity information based on the gateway logs, the event activity information including multiple events and event attribute information for each event, the event attribute information including business attributes, which characterize the attributes upon which the same event's business logic depends or the attributes upon which interactions between different events depend; generating process case information based on the event activity information, wherein the process case information is used to determine a target event set, the target event set being selected from multiple events, and the target event set collaboratively completing a target business process. This invention solves the technical problem of difficulty in identifying business process cases caused by the lack of clear start and end markers for business processes in logs of civil aviation passenger service systems.

Description

Technical Field

[0001] This invention relates to the field of big data analytics, and more specifically, to a business data processing method, electronic device, and storage medium. Background Art

[0002] As a highly interconnected global industry, the civil aviation sector involves numerous participants, including passengers, agents, airlines, and airports. The interactions among these participants create complex and diverse business scenarios. China TravelSky Holding Company Limited (hereinafter referred to as TravelSky), a leading service provider in the industry, offers its civil aviation passenger service system covering both domestic and international markets. It provides services to over 40 domestic airlines and more than 400 airlines globally, as well as comprehensive system services to over 200 domestic airports, over 80 overseas airports, and 6,000 travel agencies.

[0003] The civil aviation passenger service system not only covers the entire process of ticket sales and service, but also supports various complex civil aviation passenger business scenarios to meet the diverse needs of passengers. These business scenarios are numerous, involve cross-enterprise characteristics, affect all upstream and downstream links, involve both internal processes and interactions with external parties, and place higher demands on the system.

[0004] Traditional Business Process Management (BPM) methods, while streamlining and optimizing processes through the introduction of business process management systems, face challenges when dealing with the complexities of the civil aviation industry, including long implementation cycles and frequent scenario updates. This leads to a widening gap between actual business processes and process models, ultimately impacting accuracy and efficiency. In recent years, process mining has gained widespread attention as an emerging technology. It automatically discovers and builds business process models by analyzing event data in information systems. However, in real-world enterprise environments, especially in civil aviation passenger service systems, the complexity of log data makes it difficult to obtain complete event logs. These logs often span multiple software applications and even enterprise boundaries, resulting in a lack of necessary case information in user access records, making them unsuitable for direct use in process mining.

[0005] To address the above-mentioned problems, no effective solutions have been proposed so far. Summary of the Invention

[0006] This invention provides a business data processing method, electronic device, and storage medium to at least solve the technical problem of difficulty in identifying business process cases caused by the lack of clear business process start and end markers in the logs of the civil aviation passenger service system.

[0007] According to one aspect of the present invention, a business data processing method is provided, comprising: acquiring gateway logs of a microservice gateway; determining event activity information based on the gateway logs, wherein the event activity information includes multiple events and event attribute information of the multiple events, the event attribute information including business attributes, the business attributes being used to characterize the attributes on which the same event executes business logic or the attributes on which interaction between different events is dependent; generating process case information based on the event activity information, wherein the process case information is used to determine a target event set, the target event set being selected from multiple events, and the target event set collaboratively completing a target business process.

[0008] Furthermore, event activity information is determined based on gateway logs: multiple events are identified based on gateway logs; message information of multiple events is determined based on gateway logs, wherein the message information includes at least one of the following: request message, response message; business attributes of multiple events are determined based on message information to obtain event attribute information; multiple events and event attribute information are determined as event activity information.

[0009] Furthermore, the event attribute information also includes read and write attributes, which are used to determine whether the event's execution operation is a read operation or a write operation. Based on the event activity information, process case information is generated, including: traversing a first event set to determine a second event set. The first event set is the set of all events in the event activity information, and multiple events in the second event set have write attributes; based on the events in the second event set, traversing the first event set to determine a third event set, where the third event set includes multiple related events, and the business attributes of the related events are the same as the business attributes of the events in the second event set; and determining the third event set as process case information.

[0010] Furthermore, based on the events in the second event set, the first event set is traversed to determine the third event set, including: establishing an event activity list based on the first event set; using a sliding window to search for related events in the event activity list along a sliding path; and determining the searched related events as the third event set.

[0011] Furthermore, the event attribute information includes a time attribute, which includes the timestamp of the event. Determining the third event set as process case information includes: obtaining time filtering rules, wherein the time filtering rules are used to determine events in the third event set whose timestamp intervals with those in the second event set are within a preset time period; filtering the third event set based on the time filtering rules to obtain process case information.

[0012] Furthermore, before determining the business attributes of multiple events based on message information, the business data processing method includes: normalizing the time format in the message information.

[0013] Furthermore, multiple events are identified based on the gateway logs, including: data extraction and processing of the gateway logs to obtain multiple events.

[0014] 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 business data processing methods of various embodiments of the present invention during runtime.

[0015] 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 running, it controls the device where the computer-readable storage medium is located to execute the business data processing method 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 computer program that, when executed by a processor, implements the business data processing methods of various embodiments of the present invention.

[0017] In this embodiment of the invention, by analyzing microservice gateway logs and extracting and standardizing business attributes from event activity information, the purpose of automatically identifying and generating civil aviation business process case information is achieved. This enables the accurate selection of target event sets from massive events to collaboratively complete specific business processes, greatly improving the efficiency and accuracy of business process identification and analysis. Furthermore, it solves the technical problem of difficulty in identifying business process cases caused by the lack of clear business process start and end markers in the logs of the civil aviation passenger service system. Attached Figure Description

[0018] 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:

[0019] Figure 1 This is a flowchart of a business data processing method according to one embodiment of the present invention;

[0020] Figure 2 This is a flowchart of a business data processing method according to one embodiment of the present invention;

[0021] Figure 3 This is a schematic diagram of the PDC service process according to an embodiment of the present invention;

[0022] Figure 4 This is a structural block diagram of a control device for a business data processing method according to one embodiment of the present invention;

[0023] Figure 5 This is a flowchart of a business data processing method according to another embodiment of the present invention. Detailed Implementation

[0024] 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.

[0025] It should be noted that the terms "first", "second", etc. in the description 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 numbers 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 clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0026] According to an embodiment of the present invention, a method embodiment for processing business data 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.

[0027] Figure 1 This is a flowchart of a business data processing method according to one embodiment of the present invention, such as... Figure 1 As shown, the method includes the following steps:

[0028] Step S10: Obtain the gateway logs of the microservice gateway;

[0029] Alternatively, obtaining gateway logs from a microservice gateway typically involves the following steps:

[0030] Log collection: As the unified entry point for all microservice requests and responses, the microservice gateway records detailed information for each service call by configuring a logging framework or using the built-in logging function. This includes, but is not limited to, timestamps, user identifiers, microservice names, detailed content of HTTP requests and responses, and key business attributes.

[0031] Log transmission: Log information needs to be transmitted from the gateway to a centralized log management system or storage system in real time or periodically. This can be achieved through log transmission tools or integration with cloud services, ensuring reliable storage and centralized management of log data.

[0032] Log parsing and standardization: The collected raw log data may vary in format. Log parsing tools are needed to parse the logs, transforming unstructured logs into standardized structured data, such as JSON format. This step requires defining parsing rules, extracting key business attributes, performing synonym disambiguation, and standardizing data format for subsequent event case identification.

[0033] Log storage and management: The parsed log data will be stored in a log management system or a dedicated log database, providing a data foundation for subsequent data analysis and process mining. Log storage needs to consider data persistence, query efficiency, and security.

[0034] Step S12: Determine event activity information based on gateway logs. The event activity information includes multiple events and event attribute information of multiple events. The event attribute information includes business attributes. Business attributes are used to characterize the attributes that the same event depends on for executing business logic or the attributes that the interaction between different events depends on.

[0035] Event activity information is a key data structure in the civil aviation microservice gateway for tracking and understanding business processes. It contains a series of events that occur within a certain period of time and their respective attribute information. Each event has its specific event attribute information, which includes, but is not limited to, timestamp, event ID, microservice name, event type (read or write), and key business attributes. Business attributes are the core component of event attribute information; they are directly related to business logic and data, and are used to characterize the key information involved in the business process.

[0036] like Figure 2 As shown, the preprocessing steps for determining event activity information based on gateway logs are as follows:

[0037] Data extraction: Extract event information from gateway logs, including basic attributes such as timestamp, event ID, and microservice name, as well as business attributes carried in request and response messages.

[0038] Normalization: The extracted business attributes are standardized and formatted to ensure consistency of the same business attributes in different microservice messages, such as differences in flight number naming and uniformity in date and time formats.

[0039] Identifying Key Business Attributes: Attributes essential for the execution of business processes are considered key business attributes. Information entropy is a statistical indicator that measures the uncertainty of attribute information. When identifying key business attributes, their importance to the business process can be assessed by calculating the information entropy of each attribute. Higher attribute information entropy generally means that the attribute varies more across different events, has a more significant impact on the business process, and is more likely to be a key business attribute. In addition to information entropy calculation, the knowledge and experience of business experts can be incorporated to assign weights to each attribute. Weights reflect the attribute's contribution to the business process; attributes with higher weights should be given higher priority in case identification. Weight settings can be based on methods such as expert review, historical data analysis, or AI model prediction.

[0040] Synonym disambiguation: Addresses the diversity of business attribute names by normalizing attributes with the same business meaning but different names through expert review or AI-assisted scoring.

[0041] Through the above preprocessing process, the raw and disorganized gateway log data can be transformed into a structured and standardized set of events, so as to more quickly determine event activity information.

[0042] In step S12, the aforementioned business attributes characterize the attributes upon which the business logic for the same event execution depends. That is, within a single business event, specific business attributes are required to ensure the correctness and validity of the operation. For example, in the "query flight inventory" event, information such as flight number, departure date, departure location, and destination is needed. This information constitutes the basic conditions for the query operation, ensuring that the relevant flight inventory data can be accurately retrieved from the database. This information (flight number, departure date, etc.) is the business attribute upon which the event execution depends. They ensure the correct execution of the business logic and avoid erroneous operations or invalid queries.

[0043] Specifically, business attributes are also used to establish connections between different events, enabling data transfer and business logic coherence by sharing certain specific attribute information. For example, when the "query flight inventory" event is followed by the "book a flight seat" event, the interaction between them requires information such as the flight number and departure date from the previous event ("query flight inventory") to ensure that the booked seat matches the queried inventory, avoiding invalid booking attempts. These attributes, which are passed between different events and used for decision-making or operations, are the business attributes upon which the interaction between events depends. They act as bridges between different business activities, enabling the entire business process to proceed smoothly and allowing various microservices to collaborate based on a common data context.

[0044] This approach allows for a more detailed analysis of the business logic of each event, identifying key business operation points. This is beneficial for optimizing call paths between microservices, reducing unnecessary service calls, and improving efficiency.

[0045] Step S14: Generate process case information based on event activity information. The process case information is used to determine the target event set, which is obtained by filtering from multiple events. The target event set collaborates to complete the target business process.

[0046] In step S14, process case information is generated based on event activity information, aiming to identify and construct a complete business process from massive event records. The target event set is a specific set of events obtained by filtering and analyzing multiple events, which together constitute a PDC business process case, that is, a complete target business process.

[0047] Through steps S10 to S14 above, in this embodiment of the invention, by analyzing microservice gateway logs and extracting and standardizing business attributes from event activity information, the purpose of automatically identifying and generating civil aviation business process case information is achieved. This enables the accurate selection of target event sets from massive events to collaboratively complete specific business processes, greatly improving the efficiency and accuracy of business process identification and analysis. Furthermore, it solves the technical problem of difficulty in identifying business process cases caused by the lack of clear business process start and end markers in the logs of the civil aviation passenger service system.

[0048] As an optional implementation, in step S12, determining the event activity information based on the gateway log includes:

[0049] Step S121: Determine multiple events based on gateway logs;

[0050] In the microservice architecture of civil aviation operations, each microservice call or operation is recorded in the gateway log. This includes the call timestamp, operation type (read / write), service name, event ID, and operator or user identity information. Assuming the log records the basic information shown in Table 1, each line of the log corresponds to an event. Therefore, four events are identified from the gateway log: Event ID1, passenger queries flight details; Event ID2, passenger purchases prepaid baggage; Event ID3, passenger processes payment; Event ID4, confirms prepaid baggage purchase result.

[0051] Table 1: Basic log information.

[0052]

[0053] Step S122: Determine message information for multiple events based on gateway logs, wherein the message information includes at least one of the following: request message, response message;

[0054] Specifically, detailed request and response information is extracted from the messages of each event. This includes request and response messages. In a microservice architecture, when a client or upstream service sends a request to a downstream service, it carries a series of business parameters and operation instructions. These parameters and instructions constitute the request message, used to start or trigger the business logic of the downstream service. After the downstream service processes the request from the upstream service, it returns a response message. The response message contains the result of the service processing, the status, and possible error information, used to inform the upstream service whether the operation was successful and its specific result. Typically, log entries will include the keywords "request" and "response," or the fields "REQ" and "RES," to distinguish between request and response messages.

[0055] Specifically, for the four events extracted in step S121, their message information is further analyzed: the request message of event ID1 contains flight number = 5103, departure date = 2024-08-01, departure point = PVG, and destination = AMS; the response message of event ID2 confirms that the baggage purchase was successful, including baggage quantity = 2, baggage type = standard, and purchase status = successful; the request message of event ID3 involves payment amount = 800, payment method = credit card, and the response message confirms that the payment was successful; the response message of event ID4 again confirms that the prepaid baggage purchase status = successful, and passenger ID = 123456. This message information describes the specific business operation and result of each event in more detail.

[0056] Step S123: Determine the service attributes of multiple events based on the message information to obtain event attribute information;

[0057] Specifically, attributes directly related to the business process are extracted from the message information; these attributes are called business attributes. Examples include flight number, departure date, fare, passenger ID, and seat number. From the message information in step S122, we can determine the following business attributes: Flight number: 5103; Departure date: 2024-08-01; Departure point: PVG; Destination: AMS; Passenger ID: 123456; Baggage quantity: 2; Baggage type: Standard; Purchase status: Successful; Payment amount: 800; Payment method: Credit card. These business attributes collectively constitute the event attribute information.

[0058] Step S124: Determine multiple events and event attribute information as event activity information.

[0059] Specifically, the multiple events identified in step S121, along with the detailed event attribute information parsed in step S123, are combined to form event activity information. This is typically a table (as shown in Table 2) in which each event is associated with its timestamp, operation type, service name, operator information, and business attributes.

[0060] Table 2: Event Activity Information.

[0061]

[0062]

[0063] Through the above steps, we successfully extracted event activity information from the gateway logs, which provided basic data for subsequent process case identification and business process optimization.

[0064] It needs to be further explained that, such as Figure 3The diagram illustrates a complete PDC (Plan-Do-Check-Act) business process. The overall process comprises three steps: data preparation, workflow execution, and result checking. Smaller business processes then combine to form larger processes, ultimately achieving the business objective. Therefore, a business process containing at least three phases (plan, execute, check) is defined as an atomic process, or PDC business process for short. Each PDC business process requires initial planning and data preparation. The core of this process is execution (Do), followed by a check. Read and write types of business event activities are crucial in the PDC business process. The data preparation phase involves read-type events, while the execution phase involves write-type events, and the final check phase also involves read-type events. Write-type events are the core of the entire business process. Variations exist within the PDC business process. For example, read activities can be executed multiple times. Furthermore, to provide more detailed data, the planning and check phases may consist of multiple different read activities, and the execution phase may be a combination of multiple write activities. Within a PDC business process, each event activity revolves around the same key business attribute, which could be an order number, flight number, passenger number, etc. More complex business processes consist of several sub-processes, each organized using a <read activity, write activity, read activity> pattern.

[0065] As an optional implementation, the event attribute information also includes read / write attributes, which include read attributes and write attributes. The read / write attributes are used to determine whether the event's execution operation is a read operation or a write operation. In step S14, process case information is generated based on the event activity information, including:

[0066] Step S141: Traverse the first event set and determine the second event set. The first event set is the set of all events in the event activity information. The read and write attributes of multiple events in the second event set are both write attributes.

[0067] Specifically, the first event set is the complete set of events in the event activity information, that is, it includes all events extracted from the gateway logs. In step S141, the algorithm will traverse this event set and filter out events with write attributes. These events usually represent key operations (DO execution) in the PDC business process. The filtering results will constitute the second event set, that is, the set of all events with write attributes.

[0068] Step S142: Based on the events in the second event set, traverse the first event set to determine the third event set. The third event set includes multiple related events, and the business attributes of the related events are the same as the business attributes of the events in the second event set.

[0069] Specifically, based on the established second event set, an algorithm is applied to traverse the first event set, with a sliding time window size set, to find read events whose business attributes are the same as those of events in the second event set. These read events typically occur before or after write events and are used to prepare data or verify the results of write operations; they constitute the read operation portion of the business process. The selected related read events, together with the write events in the second event set, form a third event set—that is, a set of all read and write events that share the same business attributes as write events.

[0070] Step S143: Determine the third event set as process case information.

[0071] Specifically, the third set of events constitutes a complete business process case. In this way, we can identify the various stages of the business process, such as the start, intermediate operations, and final verification.

[0072] By differentiating between read and write attributes, we can more accurately identify key operations in business processes, which has a significant effect on optimizing database access strategies, reducing data redundancy, and improving system response speed. Through the above steps, we can not only identify complete business process cases, but also understand the logical relationships and temporal sequence between events in the cases, providing valuable information for subsequent process mining and business optimization.

[0073] As an optional implementation, in step S142, based on the events in the second event set, the first event set is traversed to determine the third event set, including:

[0074] Step S1421: Establish an event activity list based on the first event set;

[0075] Specifically, all event information extracted from the gateway logs, i.e., the first event set, is further organized into an event activity list. This list is arranged in chronological order of events and includes event ID, microservice name, timestamp, type (read or write), business attributes, etc. By constructing the event activity list, we can more easily traverse and search for events. As shown in Table 3, the event activity list is built based on the first event set. It can be seen that there are 7 events in total, of which events e2, e4, and e6 are write events, which together constitute the second event set.

[0076] Table 3: List of Events and Activities.

[0077]

[0078]

[0079] Step S1422: Use the sliding window to search for related events in the event activity list according to the sliding path;

[0080] Specifically, a sliding window technique is used to search the event activity list for read operation events related to write operations in the second event set (all events with write attributes). The sliding window size can be adjusted according to business characteristics and event frequency, for example, set to 10 seconds, 60 seconds, or longer, to ensure that read operations associated with write operations can be found within a reasonable range. The sliding path is usually performed in chronological order.

[0081] Specifically, taking write event e2 (flight number 5103) as an example, we choose a sliding window size of 30 seconds. This means we will search for read events within the 30 seconds before and after write event e2 to determine the read events associated with e2. The sliding window starts 30 seconds before e2, i.e., from event e1, and then moves forward until it includes e2 and e5. The events within the sliding window are: e1, e2, e4 (ignore, this is a write event), and e5. Events e1 and e5 are determined to be associated events with event e2. For write event e4, the sliding search path also determines the associated read events e1 and e5; while for write event e6 (flight number = 5159), the sliding window determines the associated read event e7.

[0082] Step S1423: Determine that the searched related events are the third event set.

[0083] Specifically, all read events related to write events found by the sliding window are identified as the third event set. In this embodiment, events e1, e5, and e7 together constitute the third event set. The third event set is process case information used to complete the target business process (i.e., a complete PDC business process). For the PDC business process, a standard event activity file in XES format is output.

[0084] The XES standard uses a three-tiered structure of Log, Trace, and Event to represent log data, with each tier serving a specific purpose. Log: This is the highest level of the XES log structure, representing the entire log file. It can contain multiple traces, which are collections of specific paths within a business process. The Log encapsulates all log-related metadata, such as the log's creation time and description. Trace: Located below the Log level, each Trace represents a business case or a complete business process path. It can consist of multiple Events, recording all events of a specific process. For example, a passenger's complete process from querying flights and reserving seats to checking in can be considered a Trace. Event: This is the lowest level in the XES structure, representing a specific event in the log, such as a microservice call or data read / write operations. Each Event contains a set of attributes.

[0085] The structured design of the XES standard is well-suited for describing and analyzing business processes in microservice architectures, especially when it's necessary to identify a specific business process from event sequences across multiple work IDs. In business process case identification within civil aviation microservice network management, the Log contains event information for all work IDs. Through case identification algorithms, event sequences belonging to the same business process can be combined into a Trace, even if these events are executed by different work IDs. Finally, all identified Traces are converted into XES-formatted Log objects, forming an XES file that accurately represents a specific business process case.

[0086] Through the steps described above, we can not only identify read events closely related to write events, but also construct complete PDC business process cases, which is helpful for subsequent business process analysis and optimization. Each case represents a business process case centered around a specific flight number, recording in detail the sequence of read and write operations and their chronological order. This method based on sliding windows and associated event search can effectively handle complex business scenarios across microservices, improving the accuracy and efficiency of case identification.

[0087] As an optional implementation, the event attribute information includes a time attribute, which includes the timestamp of the event. Determining the third event set as process case information includes:

[0088] Obtain time filtering rules, wherein the time filtering rules are used to determine events in the third event set whose timestamp intervals with those in the second event set are within a preset time period;

[0089] Specifically, time filtering rules typically include a preset time period Δt, used to define the time interval range between read and write events. This preset time period can be adjusted according to business characteristics and system performance. For example, in civil aviation business scenarios, considering the continuity of user operations and system response time, the preset time period may be set to anywhere from 30 seconds to 5 minutes. The purpose of setting the preset time period is to ensure the logical correlation between read and write events and to avoid mistaking unrelated events as part of the same business process.

[0090] The third event set is filtered based on time-based filtering rules to obtain process case information.

[0091] Specifically, for each write event, we search for read events within a range of Δt before and after its timestamp. Only read events whose timestamp intervals fall within a preset time period are retained and become part of the process case information. This ensures that the selected third set of events not only shares the same business attributes but is also closely related in time.

[0092] By using the above steps to filter the third event set based on time-based filtering rules, we can exclude read operations that are irrelevant in time or have excessively long time intervals. This ensures that the process case information is not only consistent in business attributes but also coherent in time sequence, avoiding interference from irrelevant events and improving the accuracy and effectiveness of process case information identification.

[0093] As an optional implementation, before determining the business attributes of multiple events based on message information, the business data processing method includes: normalizing the time format in the message information.

[0094] Specifically, normalizing the time format in message information is an important preprocessing step. It ensures that all event timestamps use a consistent format, facilitating subsequent operations such as event sorting, time interval calculation, and process case identification. The purpose of time format normalization is to eliminate format differences caused by different microservices, systems, or logging methods, converting all timestamps into a unified, easily comparable, and manipulable format.

[0095] Normalizing the time format in the message information includes the following steps:

[0096] Time format recognition: First, the algorithm needs to be able to recognize different timestamp formats in the message information. Common formats may include "YYYY-MM-DD HH:MM:SS", "YYYYMMDDHHMMSS", "HH:MM:SS YYYY-MM-DD", etc.

[0097] Parse the original time format: For each recognized time format, use the corresponding parsing function to convert the time string into a time object or timestamp format.

[0098] Convert to a uniform format: Convert the parsed time object or timestamp into a uniform format, such as "YYYY-MM-DD HH:MM:SS". The choice of uniform format should be based on the needs of subsequent processing to ensure accurate time comparison and calculation.

[0099] Format validation and exception handling: During the conversion process, the format and range of the time data need to be validated to ensure the validity and consistency of all timestamps. Appropriate mechanisms should be in place to handle unparseable time formats or abnormal timestamps, such as logging, ignoring, or setting default values.

[0100] By normalizing the event format through the above steps, the efficiency and accuracy of data processing are greatly improved, which helps in the subsequent time series analysis of the events.

[0101] As an optional implementation, in step S121, multiple events are determined based on the gateway log, including: performing data extraction processing on the gateway log to obtain multiple events.

[0102] Specifically, first, extract records containing microservice calls from the gateway logs. These records typically contain the call time, caller information, the called service name, event ID, and detailed request and response messages. Each such record is converted into an event, where the event structure should include: timestamp, service number, service name, event ID, event type (read or write), and detailed request / response message information. Using a parser or other appropriate tools, extract the business attribute information contained in the request / response messages and convert it into key-value pairs (attribute: data value). Each business attribute will correspond to a key, with its specific value serving as the value. For example, business attributes such as flight number, departure date, and cabin class will be parsed and stored as key-value pairs like {"flightNumber":"5103","departureDate":"2024-08-01","classId":"L"}. After parsing the message information, it is necessary to distinguish whether the values ​​in the key-value pairs are categorical variables or numeric variables. Categorical variables are attributes with a finite range of values, such as airline codes, cabin class, and airport codes. These attributes vary within a certain range and can be easily enumerated. Numerical variables, on the other hand, include electronic ticket numbers, order numbers, and seat numbers. These typically have a large range of values, possibly belonging to an infinite set, and are not suitable for simple enumeration. However, they can be sorted to analyze their distribution or trends.

[0103] Through the above steps, the gateway logs are processed to extract data, transforming the raw log data into structured event information. This reduces the time and complexity of data preprocessing, facilitates subsequent analysis and mining, and ensures the accuracy and efficiency of the entire identification process.

[0104] Figure 5 This is a flowchart of another business data processing method according to one embodiment of the present invention, such as... Figure 5 As shown, the method includes the following steps:

[0105] Step S501: Obtain the gateway logs of the microservice gateway;

[0106] Step S502: Determine multiple events based on gateway logs;

[0107] Step S503: Determine message information for multiple events based on gateway logs, wherein the message information includes at least one of the following: request message, response message;

[0108] Step S504: Determine the service attributes of multiple events based on the message information to obtain event attribute information;

[0109] Step S505: Determine multiple events and event attribute information as event activity information;

[0110] Step S506: Traverse the first event set and determine the second event set. The first event set is the set of all events in the event activity information. The read and write attributes of multiple events in the second event set are both write attributes.

[0111] Step S507: Based on the events in the second event set, traverse the first event set to determine the third event set. The third event set includes multiple related events, and the business attributes of the related events are the same as the business attributes of the events in the second event set.

[0112] Step S508: Determine the third event set as process case information;

[0113] Step S509: Establish an event activity list based on the first event set;

[0114] Step S510: Use the sliding window to search for related events in the event activity list according to the sliding path;

[0115] Step S511: Determine that the searched related events are the third event set;

[0116] Step S512: Obtain time filtering rules, wherein the time filtering rules are used to determine events in the third event set whose timestamp intervals with those in the second event set are within a preset time period;

[0117] Step S513: Filter the third event set based on the time filtering rules to obtain process case information;

[0118] Step S514: Normalize the time format in the message information;

[0119] Step S515: Extract data from the gateway logs to obtain multiple events.

[0120] Through steps S501 to S515 above, in this embodiment of the invention, by analyzing microservice gateway logs and extracting and standardizing business attributes in event activity information, the purpose of automatically identifying and generating civil aviation business process case information is achieved. This enables the accurate selection of target event sets from massive events to collaboratively complete specific business processes, greatly improving the efficiency and accuracy of business process identification and analysis. Furthermore, it solves the technical problem of difficulty in identifying business process cases caused by the lack of clear business process start and end markers in the logs of the civil aviation passenger service system.

[0121] According to an embodiment of the present invention, an apparatus embodiment of a business data processing method is provided. It should be noted that the apparatus can be used to execute the above-described business data processing method.

[0122] Figure 4 This is a structural block diagram of a control device for a business data processing method according to one embodiment of the present invention. Figure 4 As shown, the device includes:

[0123] Module 401 is used to retrieve gateway logs from the microservice gateway.

[0124] The determination module 402 is used to determine event activity information based on the gateway log. The event activity information includes multiple events and event attribute information of multiple events. The event attribute information includes business attributes, which are used to characterize the attributes on which the same event executes business logic or the attributes on which the interaction between different events depends.

[0125] The control module 403 is used to generate process case information based on event activity information. The process case information is used to determine the target event set, which is obtained by filtering multiple events. The target event set collaborates to complete the target business process.

[0126] Optionally, the determining module 402 is further configured to determine multiple events based on the gateway logs; determine the message information of the multiple events based on the gateway logs, wherein the message information includes at least one of the following: request message, response message; determine the business attributes of the multiple events based on the message information to obtain event attribute information; and determine the multiple events and event attribute information as event activity information.

[0127] Optionally, the event attribute information also includes read and write attributes, which include read attributes and write attributes. The read and write attributes are used to determine whether the execution operation of the event is a read operation or a write operation. The control module 403 is also used to generate process case information based on the event activity information, including: traversing the first event set to determine the second event set, where the first event set is the set of all events in the event activity information, and the read and write attributes of multiple events in the second event set are both write attributes; based on the events in the second event set, traversing the first event set to determine the third event set, where the third event set includes multiple related events, and the business attributes of the related events are the same as the business attributes of the events in the second event set; and determining the third event set as process case information.

[0128] Furthermore, the control module 403 is also used to establish an event activity list based on the first event set; search for related events in the event activity list using a sliding window along a sliding path; and determine that the searched related events are the third event set.

[0129] Furthermore, the event attribute information includes time attributes, which include the timestamp of the event. The third event set is determined to be process case information. The determining module 402 is also used to obtain time filtering rules, wherein the time filtering rules are used to determine events in the third event set whose timestamp interval with the events in the second event set is within a preset time period. The third event set is filtered based on the time filtering rules to obtain process case information.

[0130] Furthermore, the acquisition module 401 is also used to normalize the time format in the message information.

[0131] Furthermore, the acquisition module 401 is also used to extract and process data from the gateway logs to obtain multiple events.

[0132] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0133] 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.

[0134] Optionally, in this embodiment, the processor can be configured to perform the following steps via a computer program:

[0135] Step S10: Obtain the gateway logs of the microservice gateway;

[0136] Step S12: Determine event activity information based on gateway logs. The event activity information includes multiple events and event attribute information of multiple events. The event attribute information includes business attributes. Business attributes are used to characterize the attributes that the same event depends on for executing business logic or the attributes that the interaction between different events depends on.

[0137] Step S14: Generate process case information based on event activity information. The process case information is used to determine the target event set, which is obtained by filtering from multiple events. The target event set collaborates to complete the target business process.

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

[0139] Optionally, in this embodiment, the storage medium may be configured to store a computer program for performing the following steps:

[0140] Step S10: Obtain the gateway logs of the microservice gateway;

[0141] Step S12: Determine event activity information based on gateway logs. The event activity information includes multiple events and event attribute information of multiple events. The event attribute information includes business attributes. Business attributes are used to characterize the attributes that the same event depends on for executing business logic or the attributes that the interaction between different events depends on.

[0142] Step S14: Generate process case information based on event activity information. The process case information is used to determine the target event set, which is obtained by filtering from multiple events. The target event set collaborates to complete the target business process.

[0143] 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.

[0144] Optionally, in this embodiment, the above-mentioned computer program product can be configured as a computer program that performs the following steps:

[0145] Step S10: Obtain the gateway logs of the microservice gateway;

[0146] Step S12: Determine event activity information based on gateway logs. The event activity information includes multiple events and event attribute information of multiple events. The event attribute information includes business attributes. Business attributes are used to characterize the attributes that the same event depends on for executing business logic or the attributes that the interaction between different events depends on.

[0147] Step S14: Generate process case information based on event activity information. The process case information is used to determine the target event set, which is obtained by filtering from multiple events. The target event set collaborates to complete the target business process.

[0148] In the above embodiments of the present invention, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0149] 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 example, 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 couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between units or modules may be electrical or other forms.

[0150] The units described as separate components may or may not be physically separate. Similarly, the components shown as units may or may not be physical units; 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, depending on actual needs.

[0151] In addition, the functional units in the various embodiments of the present invention may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0152] 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 of 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.

[0153] The above are merely preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications 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 business data processing method, characterized in that, include: Retrieve gateway logs from the microservice gateway; Based on the gateway logs, event activity information is determined. The event activity information includes multiple events and event attribute information of the multiple events. The event attribute information includes business attributes, which are used to characterize the attributes on which the same event executes business logic or the attributes on which interaction between different events depends. Process case information is generated based on the event activity information, wherein the process case information is used to determine a target event set, the target event set is selected from the plurality of events, and the target event set collaboratively completes the target business process; The event attribute information also includes read / write attributes, which include read attributes and write attributes. These read / write attributes are used to determine whether the event's execution operation is a read operation or a write operation. Based on the event activity information, process case information is generated, including: Traverse the first event set to determine the second event set. The first event set is the set of all events in the event activity information. The read and write attributes of multiple events in the second event set are both write attributes. Based on the events in the second event set, the first event set is traversed to determine the third event set, wherein the third event set includes multiple associated events, the business attributes of the associated events are the same as the business attributes of the events in the second event set, and the associated events include read events and write events; The third event set is determined to be the process case information; Based on the events in the second event set, traverse the first event set to determine the third event set, including: Create an event activity list based on the first event set; Use a sliding window to search for the associated event in the event activity list according to the chronological order; The searched related events are identified as the third event set.

2. The business data processing method according to claim 1, characterized in that, Determine event activity information based on the gateway logs: The multiple events are determined based on the gateway logs; The message information of the multiple events is determined based on the gateway logs, wherein the message information includes at least one of the following: request message, response message; Based on the message information, the service attributes of the multiple events are determined to obtain the event attribute information; The plurality of events and the event attribute information are identified as the event activity information.

3. The business data processing method according to claim 1, characterized in that, The event attribute information includes a time attribute, which includes the event's timestamp. Determining the third event set as the process case information includes: Obtain time filtering rules, wherein the time filtering rules are used to determine events in the third event set whose timestamp intervals with those in the second event set are within a preset time period; The process case information is obtained by filtering the third event set based on the time filtering rules.

4. The business data processing method according to claim 2, characterized in that, Before determining the service attributes of the plurality of events based on the message information, the service data processing method includes: The time format in the message information is normalized.

5. The business data processing method according to claim 2, characterized in that, The multiple events are determined based on the gateway logs, including: The gateway logs are processed to extract data and obtain the multiple events.

6. 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.

7. 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.

8. 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