An order cross-business system flow track and abnormal semantic analysis method

Abstract

The present application relates to the technical field of intelligent operation and maintenance, and more particularly to an order cross-business system flow track tracking and abnormal semantic analysis method, comprising: S1: each business system outputs node logs containing business name, current node number and last node number according to a unified protocol; S2: the node logs are filtered and stored by using regular matching; S3: the order link is constructed or merged based on the parent-child relationship of the node number by the analysis service, and the flow track is formed; S4: a query request is received, the node name and the number are spliced to retrieve the link, and the node state is output according to time; S5: abnormal orders are detected, logs are cleaned, and a large model is called to generate abnormal analysis combined with prompt words and a knowledge base. The present application realizes order full-link visibility and abnormal automatic positioning, and improves fault troubleshooting efficiency.

Description

Technical Field

[0001] This invention relates to the field of intelligent operation and maintenance technology, and in particular to a method for tracking the flow trajectory of orders across business systems and parsing abnormal semantics. Background Technology

[0002] With the rapid development of internet technology and distributed architecture, order processing systems are showing a significant trend towards microservices and cross-business system workflows. Against this backdrop, to ensure the traceability of order processes and the timeliness of exception handling, traditional technologies typically employ logging and tracing solutions. These solutions mainly encompass distributed logging based on general logging frameworks, centralized storage based on full logs, and tracing based on distributed tracing systems (such as Zipkin / SkyWalking).

[0003] In the order flow process, distributed logging technology results in each business system outputting logs independently, lacking a unified format and associated identifiers. When anomalies occur during cross-system order flow, manual review of logs across systems and piecing together the flow path are required, which significantly limits the real-time response capability for anomaly investigation. While centralized full-volume log storage achieves log aggregation, the lack of precise extraction and isolation mechanisms for tracking logs leads to the submersion of critical trajectory information due to the massive amount of mixed business logs. The retrieval and connection process is time-consuming and labor-intensive, affecting the real-time performance and accuracy of system monitoring. Although distributed tracing system solutions can achieve cross-system link connection, they are often limited to the underlying technical call topology level and cannot delve into business semantics (such as the flow mapping of specific business order numbers like deposits and withdrawals). Furthermore, as the number of access nodes and the amount of data increases, the system storage and computing costs rise sharply. Furthermore, the aforementioned traditional tracking systems all rely on technical call chains or single error thresholds for monitoring. When an order experiences a non-error-related implicit timeout (such as processing time exceeding the P95 threshold), the lack of an intelligent perception mechanism based on the timeliness baseline prevents the system from proactively triggering anomaly warnings, making it difficult to ensure the continuous and stable operation of order business.

[0004] However, these various business systems typically belong to different business lines, departments, and even external partners, exhibiting heterogeneous technology stacks and independent data specifications. Furthermore, due to practical constraints such as system stability and access control, it is impossible to unify their frameworks or forcibly implant global tracking identifiers. Consequently, the scattered logs from each system naturally lack a unified basis for connection, creating isolated black boxes between systems. This makes end-to-end order tracking a long-standing and unsolvable objective technical challenge that cannot be addressed through optimization within a single system. This difficulty in cross-system integration and tracing caused by uncontrollable external dependencies is an obstacle that existing technical solutions struggle to overcome fundamentally.

[0005] In real-world business scenarios, the needs for troubleshooting and analysis of various order flow anomalies differ significantly. While a few clearly reported anomalies are easily detected, it's crucial to quickly pinpoint the responsible party (customer / middle platform / channel) and the underlying root cause. Conversely, most latent timeout anomalies, though numerous and difficult to detect, have a significant impact on business timeliness. However, traditional order monitoring and anomaly handling solutions are difficult to change once their architecture is established, with all anomalies handled through a uniform manual investigation or simple rule-based alerting process. This forces business and operations personnel to adopt the most complex cross-system link investigation model, and existing systems lack the semantic parsing capability for business context, failing to automatically translate technical messages into business-understandable root causes and handling suggestions. Furthermore, traditional solutions lack knowledge accumulation and closed-loop feedback mechanisms, repeatedly relying on manual analysis for the same anomalies, leading to over-allocation of system maintenance resources and a significant increase in business operating costs, demonstrating significant shortcomings in terms of economy and intelligence. Summary of the Invention

[0006] The purpose of this invention is to overcome the shortcomings of existing technologies and provide a method for tracking the flow of orders across business systems and parsing anomalies, comprising the following steps: S1: Each business system involved in order processing outputs node logs in its internal nodes in a low-intrusion manner according to a preset unified log protocol. The node logs include at least the business name, the current node order number, and the previous node order number. S2: Collect node logs output by various business systems, identify node logs that meet the unified log protocol using preset regular expression matching rules, and centrally store the identified node logs; S3: Obtain the centrally stored node logs from the order tracking and parsing service, and based on the association between the current node order number and the previous node order number, concatenate the node logs output by different business systems into a full-link order flow trajectory; S4: Upon receiving a link query request, determine the set of link order numbers related to the target order from the order's full link flow trajectory based on the input business name and order identifier, fill in the execution status, execution time, current node and current node description of each node in chronological order, and output the order link result; S5: When an order anomaly is detected, extract the node information and associated anomaly messages in the entire order flow trajectory, combine the prompt word template corresponding to the target business and the anomaly knowledge base input model, and output the semantic parsing results containing the cause of the anomaly and handling suggestions; S6: Based on the established order end-to-end flow trajectory, automatically generate Mock service rules for each business node to support cross-system joint debugging and fault simulation.

[0007] Preferably, in step S1, the node log further includes at least one of the following: service name, node content, reporting time, and current sub-service name. The unified log protocol generation process includes: S11: Integrate a unified reporting component within each business system, or assemble logs in different language systems according to the same field specifications; S12: When executing at each key node of order processing, collect the application name associated with the current node, the main business name, the sub-business name, the current node order number, the previous node order number, the node description, the reporting time, and the log level; S13: Encapsulate the collected fields into structured content and combine them with thread identifiers and preset TRACE tags to generate fixed-format text logs that conform to preset formats; S14: Output the fixed-format text log to the log hosting platform of the corresponding business system to ensure that the node logs generated by different business systems have uniform recognizability and parsability.

[0008] Preferably, in step S2, the filtering and forwarding of node logs includes: S21: Configure processing rules for raw logs from business systems in the log hosting platform: 1. Configure cleaning rules in the logstore of each production log. e_keep(e search'content~="*?(TRACE.*?bizName.*? (?:distribute|inbound / vaApply).*'') e_drop(V"_container_name_") == "payout") e_ drop(V("_container_name_") == "mid-order-tracker") 2. Specify the target logstore (payment-trace) to store the cleaned trace logs. 3. Log parsing: The application subscribes to the logstore (payment-trace) to parse the logs; S22: Using a pre-defined set of regular expressions Match each entry in the original log file, with the following matching criteria: Extract the structured log body conforming to the unified log protocol and the corresponding thread information; S23: Perform field validation on successfully matched log records, at least verifying the business name, current node order number, node content, and reporting time for non-empty and integrity constraints. ; S24: Forward the node logs that pass the verification to the dedicated tracking log storage area, and retain the logs that fail the verification in the original log library or mark them as invalid data, so as to achieve separate storage of tracking logs and ordinary business logs.

[0009] Preferably, in step S3, the process of assembling the entire order flow trajectory includes: S31: The order tracking parsing service subscribes to the newly added node logs in the dedicated tracking log storage area; S32: Based on the business name in the node log, the log is routed to the corresponding business sub-table. The business log record table is used to store the complete node log content, and the business node table is used to store the node name, node order number, previous node order number, execution time and node status information. S33: Query all node records in the business node table corresponding to the target business, and extract the node name, current node order number and previous node order number for each node; S34: Using the previous node's serial number as the association basis, construct the link condition key value to determine the link relationship between the current node and the previous node; S35: When there is no link record corresponding to the link condition key value in the link relationship table, add a new link relationship record; when there is already a corresponding link record in the link relationship table, merge the current node information with the existing link information, and update the node set and node timing or status information in the link. S36: By continuously adding and merging link relationship records, a chain-like order flow path covering multiple business systems and multiple processing links is formed.

[0010] Preferably, in step S4, the link query process includes: S41: Receive a query request containing business name B and order identifier ID, wherein the order identifier is used to adapt to the master order number, payment order number, order number or cross-border message unique identifier under different business scenarios; S42: Locate the corresponding business node table based on the business name B, and query the set of node records associated with the order identifier ID; S43: Concatenate query conditions based on the node record set. ,in, For node name, Assign a node order number and retrieve the complete set of link order numbers corresponding to the target order from the link relationship table; S44: Query the log content in the corresponding business log record table based on the set of link serial numbers, and sort them in ascending order according to the execution time t, i.e., satisfying... ; S45: Map the sorted log content to the link display results, fill in the business name, order identifier, current node, current node description, and execution flag and execution time of each link node for interface or page display.

[0011] Preferably, in step S5, the process of detecting abnormal orders includes: S511: Receive information on failed or timed-out orders from the business middle platform through the exception reporting interface. The information includes at least the business name and the order identifier. S512: Alternatively, a scheduled task can be used to scan the business data tables of each business system to identify order records whose processing result is failed. S513: Alternatively, the processing time of each node can be counted according to the preset timeliness threshold of each node, and the order link exceeding the threshold can be judged as an abnormal timeout order, wherein the timeliness threshold is determined based on the statistical quantile of the historical processing time of the corresponding node. S514: Abnormal orders obtained through proactive reporting, failure scanning, or timeliness identification will be uniformly written into the abnormal order analysis set to trigger subsequent link retrieval and semantic parsing processes.

[0012] Preferably, in step S5, the process of cleaning and structuring the abnormal orders includes: S521: Query the link relationship table based on the business name and order identifier of the abnormal order to obtain the set of link order numbers corresponding to the abnormal order; S522: Extract the corresponding original link log from the log hosting platform or business log record table according to the link number set; S523: Parse the extracted raw link logs to extract node name, node content, error code, channel return message, request parameters, execution status, and execution time, and map them into structured tuples. ; S524: Sort the parsed results in ascending order of execution time, and remove duplicate nodes, empty field nodes, or invalid nodes. Complete or filter; S525: Encapsulate the cleaned node information into a unified structured input sequence. This is for use in subsequent large model calls.

[0013] Preferably, in step S5, the process of generating anomaly analysis results based on the large model includes: S531: Select the corresponding business-specific prompt word template according to the business type of the abnormal order, and set the analysis role for that business scenario in the template; S532: Input the structured end-to-end node information, node status, error codes, channel return text, and request parameters as analysis context into the prompt word template; S533: Load the exception knowledge base associated with the business type, the exception knowledge base including at least channel exception code descriptions, historical fault cases and channel announcement information; S534: Impose output constraints on large models, requiring that the output results include a business-understandable natural language description, specific abnormal nodes, attribution of responsibility, cause of abnormality, and handling suggestions; S535: When there is no matching case to handle, generate a preset fallback suggestion to prompt you to contact the middle platform operations or human support personnel for further processing.

[0014] Preferably, step S5 is followed by a result standardization and knowledge base closed-loop optimization step: The anomaly analysis content generated by the large model is structured and parsed to extract fixed output fields such as a brief description of the anomaly, the node where the anomaly occurred, the analysis of the original cause of the anomaly, and simple troubleshooting suggestions. The fixed output fields are associated with and stored in relation to the business name, order identifier, link information, and original logs of the corresponding abnormal orders. The query page displays the anomaly analysis results to business or operations personnel and receives their feedback on whether the analysis results are adopted. When the feedback result is "accepted", the corresponding cause of the anomaly, the handling plan, the relevant business type, and the link context will be written into the anomaly knowledge base. As a reference sample for subsequent similar anomaly analyses. ; By continuously receiving feedback and incrementally updating the anomaly knowledge base, the accuracy and consistency of subsequent anomaly semantic parsing are improved.

[0015] Preferably, in step S6, the process of automatically generating Mock service rules based on the order chain includes: S61: Extract the complete link template under the target business scenario from the order link relationship table. The link template includes the node sequence, the request parameter structure of each node, the response data structure, the normal processing time range, and common exception return codes. S62: For each node in the link template, extract the request parameter samples and response content samples from its historical node logs, and automatically summarize the Mock request / response data structure skeleton of the node based on field frequency and type statistics. S63: Based on the summarized data structure skeleton and combined with the preset Mock rule template, generate a dynamic response Mock rule for each node. The Mock rule includes at least: matching conditions, normal response template, abnormal response template and simulated delay interval. The matching conditions are set based on the request field, and the abnormal response template is configured according to the error code probability distribution. S64: When a joint debugging test request is received, the corresponding link template is matched according to the test business scenario, the Mock service of each node is enabled in sequence, and the upstream and downstream interactions are automatically simulated according to the timing and dependency relationship of the real link, so that the system under test can complete the full link process verification in an environment that does not rely on real external channels.

[0016] Compared with the prior art, the beneficial effects of the present invention are: This invention targets cross-organizational, heterogeneous, and uncontrollable business system cluster environments. By pre-setting a unified log, standard output node logs are output in a low-intrusion manner within each system. The log hosting platform uses pre-set regular expression matching rules to identify and forward the logs to a dedicated tracking log storage area. Thus, without modifying the internal architecture of each system or intruding on its core logic, standardized collection and separate storage of order trajectory data across black-box systems are achieved, reducing the cost of redundant log storage and retrieval. This invention subscribes to a dedicated tracking log storage area through an order tracking parsing service. Based on the business name, node logs are written into the corresponding business log record table and business node table. The order link relationship is constructed or merged based on the association between the current node order number and the previous node order number. This enables the scattered node logs to be dynamically linked in real time into a cross-business system flow trajectory for a single order. The link query request fills in the execution status and information of each node in chronological order to complete the link result reconstruction, thereby ensuring the automatic restoration and accurate presentation of the cross-business system order flow trajectory. This invention performs structured cleaning on end-to-end logs when order failures or timeouts are detected. By combining the target business's corresponding prompt word templates with an anomaly knowledge base input model, it automatically transforms complex cross-system technical logs into semantic analysis results that include a brief description of the anomaly, the node where the anomaly occurred, an analysis of the original cause of the anomaly, and troubleshooting suggestions. This ensures that specific anomaly nodes and responsible parties can be accurately located when an anomaly occurs, thereby significantly improving the efficiency of anomaly troubleshooting and the system's self-healing capabilities. It features high intelligence, high reliability, and flexibility. Attached Figure Description

[0017] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention.

[0018] Figure 1 This is a flowchart of a method for tracking the flow of orders across business systems and parsing abnormal semantics according to the present invention; Figure 2 This is a flowchart illustrating the construction process of the serial chained request path in the order cross-business system flow tracking and anomaly semantic parsing method of the present invention; Figure 3 This is a schematic diagram of the query page of this invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention. Obviously, the described embodiments are only some, not all, of the embodiments described in this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without creative effort are within the scope of protection of this application.

[0020] Those skilled in the art will understand that, unless otherwise stated, the singular forms “a” and “an” used herein, and “the”, may also include the plural forms. It should be further understood that the term “comprising” as used in this specification means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0021] First Embodiment Please see Figure 1 As shown, this embodiment provides a method for tracking the flow of orders across business systems and parsing anomalies. It generates identifiable node logs in each business system using a unified log protocol, extracts the trajectory logs from a centralized log storage using regular expression matching, and forwards them to dedicated storage. Then, a tracking and parsing service constructs a chain-like path relationship, ultimately achieving full-link visual querying and anomaly semantic parsing based on a large model. This solves the problems of fragmented trajectory and difficulty in anomaly localization during cross-system order flow, significantly improving the efficiency and automation level of order fault diagnosis. The method includes the following steps: S1: Each business system involved in order processing outputs node logs according to a preset unified log protocol. The node logs include at least the business name, the current node order number, the node content, the reporting time, the previous node order number, and the current sub-business name.

[0022] Preferably, in step S1, the generation process of the unified log protocol includes: S11: Integrate a unified reporting component within each business system, or assemble logs according to the same field specifications in non-Java language systems. Specifically, in this embodiment, the reporting component, such as the tracker-sdk integrated in a Java language system, has a groupId of com.pingpongx.mid, an artifactId of tracker-sdk, and a version of 1.0.1-SNAPSHOT. In non-Java language systems (such as Python, Go, C++, etc.), logs are assembled according to the same field specifications.

[0023] S12: During each critical node of order processing (such as order creation, risk control review, channel distribution, callback notification, etc.), collect the application name (appName), main business name (bizName), sub-business name (subBizName), current node order number (orderNo), previous node order number (preOrderNo), node description (content), reporting time (logTime), and log level (logLevel) associated with the current node.

[0024] S13: Encapsulate the collected fields into structured content and combine them with the thread identifier and the preset TRACE flag to generate a fixed-format text log that conforms to the preset format. Specifically, in this embodiment, the fixed format is: [Thread Name] -- [ ] TRACE {"appName":"Application Name","bizName":"Business Name","orderNo":"Current Node Order Number","content":"Node Content","logLevel":"info","logTime":Report Time,"preOrderNo":"Previous Node Order Number","subBizName":"Current Business Name"}.

[0025] For example, the actual log output in the number release result notification node is: [NOTIFY_BIZ-6] --[ ] TRACE {"appName":"va-center","bizName":"vaApply","orderNo":"MA260511890675983","content":"Number release result notification[bizId=MA260511890675983,status=SUCCESS]","logLevel":"info","logTime":1778463896269,"preOrderNo":"MA260511890675983","subBizName":"notifyResult"}.

[0026] S14: Output the fixed-format text log to the log hosting platform of the corresponding business system (in this embodiment, it is Alibaba Cloud Log Service SLS) to ensure that the node logs generated by different business systems have uniform identifiability and parsability.

[0027] S2: In the log hosting platform, the logs generated by various business systems are filtered, and node logs that meet the unified log protocol are identified using preset regular expression matching rules. The identified node logs are then forwarded to a dedicated tracking log storage area for centralized storage.

[0028] Preferably, in step S2, the filtering and forwarding of node logs includes: S21: Configure processing rules for the raw logs of the business system in the log hosting platform. Specifically, in this embodiment, data processing rules are configured in the logstore of each production log. Logs containing the TRACE flag and the target business name (such as distribute, inbound, vaApply) are retained by regular expression matching, non-business logs generated by specific containers are excluded, and the cleaned tracking logs are output to a dedicated target logstore (such as payment-trace). For example, the data processing function of the log service can be used to retain logs whose content matches the regular expression with e_keep, and to discard logs with container names "payout" or "mid-order-tracker" with e_drop. The results are then written to the specified logstore, and the log parsing application subscribes to the target logstore for further processing.

[0029] S22: Using a pre-defined set of regular expressions Match each entry in the original log file, with the following matching criteria: The structured log body conforming to the unified logging protocol and the corresponding thread information are extracted. Specifically, in this embodiment, the regular expression is: This regular expression can match the aforementioned fixed-format node logs and extract the thread name and JSON log body.

[0030] S23: Perform field validation on successfully matched log records, at least verifying the business name, current node order number, node content, and reporting time for non-empty and integrity constraints. Specifically, in this embodiment, the service name, current node order number, node content, and reporting time cannot be empty. Logs that fail verification are retained in the original log database or marked as invalid data and are not forwarded. S24: Forward the node logs that pass the verification to a dedicated trace log storage area (e.g., logStore named payment-trace), and retain the logs that fail the verification in the original log library or mark them as invalid data, so as to achieve separate storage of trace logs and ordinary business logs.

[0031] S3: The order tracking parsing service subscribes to the node logs in the dedicated tracking log storage area. Based on the business name, the node logs are written to the corresponding business log record table and business node table. The order link relationship is constructed or merged based on the association between the current node order number and the previous node order number, forming a cross-business system flow trajectory for a single order.

[0032] Preferably, in step S3, the process of writing data to the business log table and the business node table according to the business name includes: S311: New node logs in the dedicated trace log storage area (payment-trace logStore) of the order trace parsing service subscription; S312: Based on the business name B (i.e., bizName) in the node log, the log is routed to the corresponding business sub-table. The business log record table is used to store the complete node log content (such as log_vaApply_record), and the business node table (such as log_vaApply_node) is used to store the node name, node order number, previous node order number, execution time and node status information for subsequent link splicing. S313: If the business log record table does not contain records that meet the combined conditions If the record is not found, a new log record is added; otherwise, a deduplication or update operation is performed (for example, when the same node reports repeatedly, the last one is taken as the standard). Specifically, in this embodiment, the composite condition is (bizName, orderNo, subBizName, logTime). S314: If the corresponding node information (node ​​name + node order number) does not exist in the business node table, a new node record will be created; if the corresponding node information already exists, it will be merged and updated according to time or status to ensure the accuracy of node status and consistency of time sequence.

[0033] Preferably, in step S3, the process of constructing or merging order link relationships includes: S321: Query all node records in the business node table corresponding to the target business, and extract the node name of each node. Current node order number and the previous node's order number ; S322: Construct link condition key-value pairs based on the previous node's serial number of the current node. Determine the link relationship between the current node and its predecessor node; S323: When the key does not exist in the link relationship table When a corresponding link record is created, a new link relationship record is added. S324: When the key already exists in the link relationship table When recording the corresponding link, the current node information is merged with the existing link information, and the set of nodes in the link is updated. And node timing or status information; S325: By continuously adding and merging link relationship records, a chain-like order flow path covering multiple business systems and multiple processing links is formed. Specifically, in this embodiment, for a deposit order, its link may be: order creation -> risk control review -> channel order placement -> channel callback -> result notification. Each link forms a directed edge through the order number of the previous node and the order number of the current node.

[0034] Please see Figure 2 As shown, the process of constructing or merging order link relationships is as follows: When a new business log is parsed, the business name, the current node order number, and the previous node order number are extracted; first, they are saved to the log_record table, and it is determined whether the current business node exists. If it does not exist, it is added; then, the link relationship table is queried based on the previous node order number. If no link relationship exists, a new link relationship is directly added, that is, a directed edge is established between "previous node order number → current business node order number"; if a link relationship exists, a merge operation is performed, and the current node is appended to the end of the existing link. For example, if the existing link is customerApply:A000100132->preRoute:B00000121->confirmOrder:C0001988->submitChannel:MA260511890675983, when the notifyResult node log is received, it is appended and the link is updated to customerApply:A000100132->...->submitChannel:MA260511890675983->notifyResult:MA260511890675983.

[0035] Preferably, the splicing of the entire order flow trajectory further includes: Determine whether there are any breakpoints in the entire order flow trajectory due to missing structured logs; If there is a breakpoint in the link, the entire link flow trajectory of the order will be marked as incomplete, and the location of the breakpoint and the missing range will be marked and prompted in the link display results.

[0036] S4: Upon receiving a link query request, query the node set corresponding to the business based on the input business name and order identifier, concatenate the query conditions of node name and node order number, determine the link order number set related to the target order from the link relationship table, query the corresponding log records based on the link order number set, fill in the execution status, execution time, current node and current node description of each node in chronological order, and output the order link result.

[0037] Preferably, in step S4, the link query process includes: S41: Receive a query request containing the business name B and the order identifier ID, wherein the order identifier is used to adapt the master order number, payment order number, order number or cross-border message unique identifier under different business scenarios. Specifically, in this embodiment, the business name is bizName, the order identifier is orderNo, the deposit link supports the top-up order number or GPI UETR, and the withdrawal link supports the order ID or payment order number.

[0038] S42: Locate the corresponding business node table (e.g., log_vaApply_node) based on the business name B, and query the set of node records associated with the order identifier ID.

[0039] S43: Query conditions based on concatenating node record sets ,in, For node name, The node order number is used to retrieve the complete set of link order numbers corresponding to the target order from the link relationship table.

[0040] For example, for the vaApply business, the query conditions could be (node_name='orderCreate'ANDnode_id='MA260511890675983') OR (node_name='riskCheck'ANDnode_id='...'), etc.

[0041] S44: Query the log content in the corresponding business log record table (e.g., log_vaApply_record) based on the link single number set, and sort them in ascending order according to the execution time t, i.e., satisfying... .

[0042] S45: Map the sorted log content to the link display results, fill in the business name, order identifier, current node, current node description, and execution flag (executeFlag: true indicates execution, false indicates non-execution) and execution time of each link node for interface or page display.

[0043] Specifically, the request parameters for this link query API interface include the business name (supporting either deposit or withdrawal links) and the order identifier (deposit links support the top-up order number or GPI's UETR, while withdrawal links support the order ID and payment order number). The returned response message body includes the business name, order identifier, current node, current node description, and a list of business links. Each node in the link list includes a node identifier, node name, execution flag, and execution time. Please refer to Table 1 below for the request parameters of this link query API interface, and Table 2 below for the returned response message body.

[0044] Table 1: Request Parameters

[0045] Table 2: Return Response

[0046] S5: When an order failure or timeout is detected, the system performs structured cleaning of the full-link log based on the link relationship and time sorting of the target order. It also combines the prompt word template corresponding to the target business with the input model of the anomaly knowledge base to output a brief description of the anomaly, the node where the anomaly occurred, the analysis of the original cause of the anomaly, and troubleshooting suggestions, so as to realize the automated location and semantic analysis of order anomalies across business systems.

[0047] Preferably, in step S5, the process of detecting abnormal orders includes: S511: Receive information on failed or timed-out orders from the business middle platform through the exception reporting interface. The information includes at least the business name and order identifier. The middle platform is the only entry point for all business lines to issue business instructions and is also the first object to detect abnormal orders. When an order fails or times out, it actively calls the exception reporting interface of the order tracking service.

[0048] S512: Alternatively, a scheduled task can be used to scan the business data tables of each business system to identify order records whose processing result is failed (e.g., the order status field is FAILED or TIMEOUT). S513: Alternatively, the processing time of each node can be calculated based on the preset timeliness threshold for each node. and will meet the conditions The order chain was determined to be an abnormal order that timed out. It represents the 95th percentile of the processing time for the corresponding node. For example, if the P95 of the historical processing time for a certain node is 500 milliseconds, then anything exceeding 1000 milliseconds is considered a timeout exception. S514: Abnormal orders obtained through proactive reporting, failure scanning, or timeliness identification will be uniformly written into the abnormal order analysis set to trigger subsequent link retrieval and semantic parsing processes.

[0049] Preferably, in step S5, the process of cleaning and structuring the abnormal orders includes: S521: Query the link relationship table based on the business name and order identifier of the abnormal order to obtain the set of link order numbers corresponding to the abnormal order (i.e., all node order numbers that the order passes through). S522: Extract the corresponding original link logs from the Log Hosting Platform (SLS) or the business log record table based on the link log number set; S523: Parse the extracted raw link logs to extract node name, node content, error code, channel return message, request parameters, execution status, and execution time, and map them into structured tuples. ; S524: Sort the parsed results in ascending order of execution time, and remove duplicate nodes, empty field nodes, or invalid nodes. Complete or filter; S525: Encapsulate the cleaned node information into a unified structured input sequence. This is for use in subsequent large model calls.

[0050] Preferably, in step S5, the process of generating anomaly analysis results based on the large model includes: S531: Select the corresponding business-specific prompt word template according to the business type of the abnormal order (such as cross-border payment deposit, withdrawal, etc.), and set the analysis role for this business scenario in the template, such as "Cross-border payment channel abnormal message analysis expert"; S532: Input the structured end-to-end node information, node status, error codes, channel return text, and request parameters as analysis context into the prompt word template; S533: Load the exception knowledge base associated with the business type. The exception knowledge base shall include at least the channel exception code description, historical failure cases and channel announcement information. S534: Impose output constraints on the large model, requiring the output results to include a natural language description that the business can understand (e.g., "This order was rejected by the channel due to insufficient balance"), the specific abnormal node (e.g., "Channel order placement node"), the responsible party (customer / middle platform / channel), the reason for the abnormality (e.g., "The channel returned error code 2001, corresponding to insufficient balance"), and handling suggestions (e.g., "Please ask the customer to recharge and try again"). S535: When there is no matching case, generate a preset fallback suggestion (e.g., "Please contact the middle platform operations team for manual handling") to prompt you to contact the middle platform operations or human support personnel for further handling.

[0051] Please see Figure 3The diagram illustrates the abnormal order chain and semantic analysis in this embodiment. For a withdrawal order, the normal workflow should include: generating a payment order (PO231201...) → routing to the channel (PD231201...) → inquiring about foreign exchange settlement → preparing to submit to the channel → processing the payment result. However, an anomaly is detected at the "payment failure" node. The large model performs semantic analysis based on this chain context, combined with the common problems library at the bottom of the interface (such as "the applicant's customer number cannot be empty" and "the customer's account opening status is abnormal"), accurately locating the anomaly in the customer account status verification stage on the channel side: the order was submitted to the channel on December 1st, but only returned a failure on December 4th, indicating that the problem lies on the channel side rather than the system process itself.

[0052] Preferably, step S5 is followed by result standardization and knowledge base closed-loop optimization steps: The anomaly analysis content generated by the large model is structured and parsed to extract fixed output fields such as a brief description of the anomaly, the node where the anomaly occurred, the analysis of the original cause of the anomaly, and simple troubleshooting suggestions. Example of parsing results: { "briefDesc": "Channel returned a rejection because the receiving account information is incorrect", "errorNode": "Channel delivery node", "rawReason": "Channel return code R102, the corresponding field account_number has an incorrect format". "suggestion": "Please verify the recipient's account number and ensure it matches the bank's record before re-initiating the payment." The fixed output fields are associated with and stored in relation to the business name, order identifier, link information, and original logs of the corresponding abnormal orders.

[0053] The query page displays the anomaly analysis results to business or operations personnel and receives their feedback on whether the analysis results are adopted (e.g., "satisfied" / "unsatisfied").

[0054] When the feedback result is "accepted", the corresponding cause of the anomaly, the handling plan, the relevant business type, and the link context will be written into the anomaly knowledge base. As a reference sample for subsequent similar anomaly analyses. .

[0055] By continuously receiving feedback and incrementally updating the anomaly knowledge base, the accuracy and consistency of subsequent anomaly semantic parsing are improved.

[0056] Second Embodiment Based on the same concept, the present invention also provides a computer device, including a memory and a processor, wherein the memory stores computer-readable instructions, and when the computer-readable instructions are executed by the processor, the processor causes the processor to perform the steps of an order cross-business system flow trajectory tracking and anomaly semantic parsing method as described in the embodiments.

[0057] Based on the same concept, the present invention also provides a storage medium storing computer-readable instructions, characterized in that, when the computer-readable instructions are executed by one or more processors, the one or more processors cause the one or more processors to perform the steps of an order cross-business system flow trajectory tracking and anomaly semantic parsing method as described in any one of the embodiments.

[0058] It is understood that, for the aforementioned method of tracking order flow across business systems and parsing anomalies, if all of them are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this 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 a network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, optical disks, and other media capable of storing program code.

[0059] Computer-readable storage media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable storage medium may also be any readable medium other than a readable storage medium that can transmit, propagate, or transfer a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0060] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

[0061] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A method for tracking the flow of orders across business systems and parsing anomalies, characterized in that, Includes the following steps: S1: Each business system involved in order processing outputs node logs in its internal nodes in a low-intrusion manner according to a preset unified log protocol. The node logs include at least the business name, the current node order number, and the previous node order number. S2: Collect node logs output by various business systems, identify node logs that meet the unified log protocol using preset regular expression matching rules, and centrally store the identified node logs; S3: Obtain the centrally stored node logs from the order tracking and parsing service, and based on the association between the current node order number and the previous node order number, concatenate the node logs output by different business systems into a full-link order flow trajectory; S4: Upon receiving a link query request, determine the set of link order numbers related to the target order from the order's full link flow trajectory based on the input business name and order identifier, fill in the execution status, execution time, current node and current node description of each node in chronological order, and output the order link result; S5: When an order anomaly is detected, extract the node information and associated anomaly messages in the entire order flow trajectory, combine the prompt word template corresponding to the target business and the anomaly knowledge base input model, and output the semantic parsing result containing the cause of the anomaly and handling suggestions.

2. The method for tracking order flow trajectory across business systems and parsing abnormal semantics according to claim 1, characterized in that, In step S1, the node log also includes at least one of the following: service name, node content, reporting time, and current sub-service name. The generation process of the unified log protocol includes: S11: Integrate a unified reporting component within each business system, or assemble logs in different language systems according to the same field specifications; S12: When executing at each key node of order processing, collect the application name associated with the current node, the main business name, the sub-business name, the current node order number, the previous node order number, the node description, the reporting time, and the log level; S13: Encapsulate the collected fields into structured content and combine them with thread identifiers and preset TRACE tags to generate fixed-format text logs that conform to preset formats; S14: Output the fixed-format text log to the log hosting platform of the corresponding business system to ensure that the node logs generated by different business systems have uniform recognizability and parsability.

3. The method for tracking order flow trajectory across business systems and parsing abnormal semantics according to claim 1, characterized in that, In step S2, the filtering and forwarding of node logs includes: S21: Configure processing rules for the raw logs of the business system in the log hosting platform; S22: Using a pre-defined set of regular expressions Match each entry in the original log file, with the following matching criteria: Extract the structured log body conforming to the unified log protocol and the corresponding thread information; S23: Perform field validation on successfully matched log records, at least verifying the business name, current node order number, node content, and reporting time for non-empty and integrity constraints. ; S24: Forward the node logs that pass the verification to the dedicated tracking log storage area, and retain the logs that fail the verification in the original log library or mark them as invalid data, so as to achieve separate storage of tracking logs and ordinary business logs.

4. The method for tracking order flow trajectory across business systems and parsing abnormal semantics according to claim 1, characterized in that, In step S3, the process of assembling the entire order flow trajectory includes: S31: The order tracking parsing service subscribes to the newly added node logs in the dedicated tracking log storage area; S32: Based on the business name in the node log, the log is routed to the corresponding business sub-table. The business log record table is used to store the complete node log content, and the business node table is used to store the node name, node order number, previous node order number, execution time and node status information. S33: If the business log record table does not contain records that meet the combined conditions If the record is not found, a new log record will be added; otherwise, a deduplication or update operation will be performed. S34: If the corresponding node information does not exist in the business node table, a new node record is created; if the corresponding node information already exists, it is merged and updated according to time or status to ensure the accuracy of node status and consistency of time sequence. S35: When there is no link record corresponding to the link condition key value in the link relationship table, add a new link relationship record; when there is already a corresponding link record in the link relationship table, merge the current node information with the existing link information, and update the node set and node timing or status information in the link. S36: By continuously adding and merging link relationship records, a chain-like order flow path covering multiple business systems and multiple processing links is formed.

5. The method for tracking order flow trajectory across business systems and parsing abnormal semantics according to claim 1, characterized in that, In step S4, the link query process includes: S41: Receive a query request containing business name B and order identifier ID, wherein the order identifier is used to adapt to the master order number, payment order number, order number or cross-border message unique identifier under different business scenarios; S42: Locate the corresponding business node table based on the business name B, and query the set of node records associated with the order identifier ID; S43: Concatenate query conditions based on the node record set. ,in, For node name, Assign a node order number and retrieve the complete set of link order numbers corresponding to the target order from the link relationship table; S44: Query the log content in the corresponding business log record table based on the set of link serial numbers, and sort them in ascending order according to the execution time t, i.e., satisfying... ; S45: Map the sorted log content to the link display results, fill in the business name, order identifier, current node, current node description, and execution flag and execution time of each link node for interface or page display.

6. The method for tracking order flow trajectory across business systems and parsing abnormal semantics according to claim 1, characterized in that, In step S5, the process of detecting abnormal orders includes: S511: Receive information on failed or timed-out orders from the business middle platform through the exception reporting interface. The information includes at least the business name and the order identifier. S512: Alternatively, a scheduled task can be used to scan the business data tables of each business system to identify order records whose processing result is failed. S513: Alternatively, the processing time of each node can be counted according to the preset timeliness threshold of each node, and the order link exceeding the threshold can be judged as an abnormal timeout order, wherein the timeliness threshold is determined based on the statistical quantile of the historical processing time of the corresponding node. S514: Abnormal orders obtained through proactive reporting, failure scanning, or timeliness identification will be uniformly written into the abnormal order analysis set to trigger subsequent link retrieval and semantic parsing processes.

7. The method for tracking order flow trajectory across business systems and parsing abnormal semantics according to claim 1, characterized in that, Step S5 involves data cleaning and structured organization of abnormal orders, including: S521: Query the link relationship table based on the business name and order identifier of the abnormal order to obtain the set of link order numbers corresponding to the abnormal order; S522: Extract the corresponding original link log from the log hosting platform or business log record table according to the link number set; S523: Parse the extracted raw link logs to extract node name, node content, error code, channel return message, request parameters, execution status, and execution time, and map them into structured tuples. ; S524: Sort the parsed results in ascending order of execution time, and remove duplicate nodes, empty field nodes, or invalid nodes. Complete or filter; S525: Encapsulate the cleaned node information into a unified structured input sequence. This is for use in subsequent large model calls.

8. The method for tracking order flow trajectory across business systems and parsing abnormal semantics according to claim 1, characterized in that, In step S5, the process of generating anomaly analysis results based on the large model includes: S531: Select the corresponding business-specific prompt word template according to the business type of the abnormal order, and set the analysis role for that business scenario in the template; S532: Input the structured end-to-end node information, node status, error codes, channel return text, and request parameters as analysis context into the prompt word template; S533: Load the exception knowledge base associated with the business type, the exception knowledge base including at least channel exception code descriptions, historical fault cases and channel announcement information; S534: Impose output constraints on large models, requiring that the output results include a business-understandable natural language description, specific abnormal nodes, attribution of responsibility, cause of abnormality, and handling suggestions; S535: When there is no matching case to handle, generate a preset fallback suggestion to prompt you to contact the middle platform operations or human support personnel for further processing.

9. The method for tracking order flow trajectory across business systems and parsing abnormal semantics according to claim 1, characterized in that, Following step S5, the process also includes result standardization and knowledge base closed-loop optimization steps: The anomaly analysis content generated by the large model is structured and parsed to extract fixed output fields such as a brief description of the anomaly, the node where the anomaly occurred, the analysis of the original cause of the anomaly, and simple troubleshooting suggestions. The fixed output fields are associated with and stored in relation to the business name, order identifier, link information, and original logs of the corresponding abnormal orders. The query page displays the anomaly analysis results to business or operations personnel and receives their feedback on whether the analysis results are adopted. When the feedback result is "accepted", the corresponding cause of the anomaly, the handling plan, the relevant business type, and the link context will be written into the anomaly knowledge base. As a reference sample for subsequent similar anomaly analyses. ; By continuously receiving feedback and incrementally updating the anomaly knowledge base, the accuracy and consistency of subsequent anomaly semantic parsing are improved.

Images