An intelligent interface service method for an ERP system

Abstract

The application relates to the computer technical field and provides an intelligent interface service method for an ERP system, which extracts request metadata, a business feature vector and a state vector, constructs an associated topology graph based on preset business relationship rules to be disassembled into an atomic operation sequence; after the atomic operation sequence is verified, a dynamic execution mode is selected based on business requirements, an optimal execution mode is matched for different business scenarios, and the overall interface service efficiency and resource utilization are improved; after an operation exception is monitored, a process is immediately interrupted and fault-tolerant processing is started, a data flow conversion path is traced back to determine an interface quality index and locate a performance abnormal point, the basic interface is optimized in combination with the quality index, and when the performance abnormal point continuously conflicts with the business relationship rules, the business relationship rules are updated based on execution data, the whole-link management and control of abnormal tracing, root optimization and rule iteration are realized, and the stability of the interface service and the adaptability of the business rules to actual business are significantly improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an intelligent interface service method for ERP systems. Background Technology

[0002] Enterprise Resource Planning (ERP) systems, as core business management platforms, need to interface with external systems in multiple fields such as supply chain, finance, and sales. Interface services have become a key carrier for data interaction and business collaboration between systems. Early ERP interface services mostly used hard-coding to implement fixed business logic, that is, developing dedicated interfaces for specific external requests. Later, to improve versatility, standardized interface protocols were gradually introduced to achieve basic data format unification. To cope with high-concurrency scenarios, some solutions began to integrate static load balancing strategies, allocating interface call requests through preset server weights, and also trying to add simple error retry mechanisms in the interface execution phase to reduce the impact of a single call failure on business.

[0003] In recent years, to adapt to complex business processes, some technical solutions have further introduced process modeling tools, attempting to define the dependencies between interfaces through visual processes. However, the overall approach remains at the basic level of interface calls and simple fault tolerance, without forming a refined management system across the entire chain. Existing technologies often directly call preset interfaces based on external requests without refining the business logic corresponding to the requests. This makes it impossible to identify hidden conflicts between request metadata and business characteristics, which can easily lead to data inconsistencies or process interruptions during interface execution. Furthermore, there is a lack of effective tracing and resolution mechanisms after conflicts occur.

[0004] Existing interface services mostly adopt a single execution mode without dynamically selecting the mode based on business needs, which easily leads to data delays. For non-real-time batch data archiving, synchronous execution is used, which can easily consume core resources and cause other services to lag. When an interface malfunction is detected, only simple retry or degradation operations are performed, without tracing the complete data flow path to locate the root cause of the anomaly, and no correlation analysis mechanism between interface performance and business rules has been established. At the same time, interface configurations and business relationship rules are mostly statically set, which cannot be dynamically optimized based on actual execution data, resulting in the repeated occurrence of the same anomaly.

[0005] Given the shortcomings of existing technologies, the technical problem to be solved in this application is how to accurately parse external requests in order to achieve the execution stability, dynamic resource allocation and automation level of ERP system interface services. Summary of the Invention

[0006] To address the shortcomings of existing technologies, this application provides an intelligent interface service method for ERP systems. The method includes: receiving external requests and extracting request metadata, business feature vectors, and status vectors from the ERP system; parsing the request metadata and business feature vectors based on pre-set business relationship rules; and constructing an association topology graph of the external requests.

[0007] After performing conflict detection on the business semantics of nodes and the operational dependencies between nodes in the associated topology graph, the associated topology graph is mapped and decomposed into atomic operation sequences.

[0008] Once the atomic operation sequence passes verification, the execution mode is selected based on the business requirements of the atomic operation sequence. In conjunction with the state vector of the ERP system, a service instance is allocated to the basic interface corresponding to the execution mode through a dynamic load balancing algorithm. The resources of the ERP system are called to execute the atomic operation sequence and the execution data is monitored.

[0009] If an operational anomaly is detected, the process is immediately interrupted and fault tolerance processing is initiated. At the same time, the data flow path from the source system to the target system is traced back, and the quality index of each basic interface is determined based on the data flow path and execution data.

[0010] Based on data flow path analysis, performance anomalies are identified. The basic interface is optimized by combining the quality index and performance anomalies. When there is a continuous conflict between performance anomalies and business relationship rules, the business relationship rules are updated based on the execution data, and the optimization results and update results are returned to the requester.

[0011] As an optional implementation, the decomposition into a sequence of atomic operations includes:

[0012] The system detects the matching between the business semantics of each node in the associated topology graph and the business scenario parsed from the business feature vector to identify semantic conflicts, and traverses the operational dependencies between nodes to identify circular dependencies and repeated dependencies, marking conflicting nodes and conflicting dependencies.

[0013] Remove conflicting nodes and adjust conflicting dependencies to process the associated topology graph. Map the processed nodes to basic operation units according to the forward dependency path. Add serial or parallel associated execution identifiers to the basic operation units based on the operation dependencies and association strength between nodes.

[0014] Based on the resource call requirements retained after pruning and the reconstructed topology path, the basic operation unit is split into atomic operations according to the data entity identifier and operation instruction type. The atomic operations are then sorted into an atomic operation sequence according to the order constraints of the forward dependency path and the associated execution identifier.

[0015] As an optional implementation, constructing the associated topology graph includes:

[0016] Extract the business entity identifier, data entity identifier, and operation instruction type from the request metadata, and parse the process dependency, data interaction frequency, and resource call requirements from the business feature vector;

[0017] Based on pre-defined business relationship rules, initial dependencies are established between operation instruction types, data entity identifiers, and business entity identifiers to form a basic edge structure.

[0018] Calculate the semantic association between different business entity identifiers based on process dependencies and data interaction frequency, in order to determine whether to add semantic association edges and mark the association strength, and form an initial topology graph;

[0019] Calculate the semantic similarity of different nodes under the same business entity identifier, prune the initial topology graph based on resource call requirements, detect circular dependencies in the initial topology graph using a depth-first search algorithm, and cut reverse dependency edges according to the data sensitivity of the business entity identifier to reconstruct the topology path and obtain the associated topology graph.

[0020] As an optional implementation, the allocation service instance includes:

[0021] Based on the selected execution mode, the corresponding basic interfaces are defined, and the real-time resource indicators of the servers where the basic interfaces are located are extracted from the state vector of the ERP system to evaluate the resource sufficiency of each basic interface.

[0022] The allocation priority of basic interfaces is determined by combining the business requirements of atomic operation sequences. Based on the dynamic load balancing algorithm, service instances are allocated to basic interfaces by combining resource sufficiency and allocation priority.

[0023] The system invokes resources from the ERP system, executes atomic operation sequences sequentially based on the order constraints of the positive dependency path and associated execution identifiers, and monitors the execution data.

[0024] As an optional implementation method, the selected execution mode includes:

[0025] Perform integrity checks on operation dependencies, consistency checks on business semantics, rationality checks on resource calls, and compliance checks on sequence constraints on atomic operation sequences. If no anomalies are found, the checks pass.

[0026] Once the atomic operation sequence passes the verification, extract the business requirements of the atomic operation sequence, including the associated execution identifier of each atomic operation, data entity consistency, operation dependency strength, and resource call type;

[0027] Business requirements are matched with initial execution modes based on atomic operation sequences. Initial execution modes include synchronous mode, asynchronous mode, and hybrid mode.

[0028] If there are conflicting business requirements, the initial execution mode will be adjusted according to the data entity consistency priority to adapt to the resource call type and determine the final selected execution mode.

[0029] As an optional implementation, the optimized basic interface includes:

[0030] Associate the root cause interface corresponding to the performance anomaly with the quality index and role attributes of the root cause interface in order to locate the anomaly type of the root cause interface.

[0031] Based on the type of exception, select the optimization direction for the root cause exception interface, and adjust resource allocation and backup service instances in combination with role attributes, execution mode and business relationship rules to optimize the basic interface;

[0032] The optimized basic interface is incorporated into the execution flow of the atomic operation sequence, and changes in execution data and quality indices in the optimized basic interface and its upstream and downstream interfaces are monitored.

[0033] If the quality index is not less than the index threshold and the performance anomalies are eliminated, the optimized basic interface will be fixed as the default interface configuration. If there are still operational anomalies, the basic interface will be optimized again and verified again.

[0034] As an optional implementation, determining the quality index of each basic interface includes:

[0035] The execution data of the atomic operation sequence is compared with the corresponding judgment threshold, and it is determined whether the execution result between each atomic operation meets the order constraint. If any judgment condition is triggered, it indicates that the operation is abnormal.

[0036] Upon detecting an operational anomaly, the process is immediately interrupted and fault tolerance processing is initiated. Simultaneously, based on the associated execution identifiers of atomic operations and the call chain of basic interfaces, the data flow path from the source system to the target system is traced back.

[0037] Extract the role attributes and data integrity of the basic interfaces from the data flow path, extract the execution success rate and response latency of the basic interfaces from the execution data, and extract the exception recovery time of the fault tolerance processing record;

[0038] The execution success rate and response latency are correlated with execution compliance, role attributes and data integrity are correlated with workflow coordination, and the time spent on anomaly recovery is correlated with the degree of anomaly impact. The quality index of each basic interface is determined by weighted summation.

[0039] As an optional implementation, the analysis and identification of performance anomalies includes:

[0040] Basic interfaces with a quality index less than the index threshold are considered as candidate abnormal interfaces. Based on the interface connection relationship in the data flow path, the candidate abnormal interfaces and their upstream and downstream interfaces are divided into abnormal association groups.

[0041] By analyzing the synchronous fluctuation relationship between execution success rate and response latency in the basic interfaces within the anomaly association group, as well as the transmission relationship of data integrity, the association of the anomaly association group is obtained.

[0042] Based on the role attributes of the basic interfaces and the correlation of the exception association groups, analyze the direction of exception propagation and distinguish the root cause exception interfaces. Verify whether the root cause exception interfaces cause the business requirements of the atomic operation sequence to be unmet, so as to analyze and identify performance anomalies.

[0043] As an optional implementation, the updated business relationship rules include:

[0044] The frequency of conflicts between the root cause of the performance anomaly and the business relationship rules is counted. If the frequency of conflicts exceeds the preset frequency threshold and is associated with core atomic operations, it is determined that there is a continuous conflict.

[0045] Extract the clause constraints related to the root cause exception interface from the business relationship rules, compare the execution data of the root cause exception interface with the clause constraints, and locate the clause constraints corresponding to the continuous conflict.

[0046] Based on the business requirements of atomic operation sequences and the execution data of the root cause exception interface, adjust the parameters of the conflict clause constraints to update the business relationship rules.

[0047] After regenerating and executing the atomic operation sequence based on the updated business relationship rules, verify whether the performance anomalies have been eliminated and whether the execution data and quality index of the upstream and downstream interfaces are normal. After verifying that there are no anomalies, solidify the business relationship rules and return the optimized basic interface and the updated business relationship rules to the requester.

[0048] As an optional implementation, the immediate interruption of the process and initiation of fault tolerance processing includes: pausing unexecuted atomic operations and locking intermediate data of executed operations, and matching the corresponding fault tolerance strategy according to the exception type.

[0049] Compared with existing technologies, the beneficial effects of this application are as follows: By extracting request metadata, business feature vectors, and state vectors, and constructing an association topology graph based on pre-defined business relationship rules, the business logic is decomposed into atomic operation sequences, realizing the transformation from overall invocation to refined decomposition. This can identify and eliminate hidden conflicts in advance, avoid data inconsistencies or process interruptions during interface execution, and ensure the logical correctness of interface execution from the source. After the atomic operation sequence passes verification, synchronous, asynchronous, or hybrid execution modes are dynamically selected based on business requirements. If there are conflicts in requirements, adjustments are made based on data entity consistency. The optimal execution mode is matched for different business scenarios, which not only meets the core business requirements but also avoids the core resources being occupied by non-critical businesses, thereby improving the overall interface service efficiency and resource utilization.

[0050] Upon detecting operational anomalies, the process is immediately interrupted and fault tolerance is initiated. Furthermore, the entire data flow path is traced back to determine the interface quality index and locate performance anomalies. The basic interface is optimized in conjunction with the quality index. When anomalies continuously conflict with business relationship rules, the business relationship rules are updated based on execution data and verified and solidified. This achieves full-link control of anomaly tracing, root cause optimization, and rule iteration. It not only solves the current interface performance problem but also prevents the recurrence of similar anomalies through rule updates, significantly improving the stability of interface services and the adaptability of business relationship rules to actual business. Attached Figure Description

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

[0052] Figure 1 A flowchart illustrating a smart interface service method for an ERP system provided in this application embodiment;

[0053] Figure 2 The logic flowchart provided in the embodiments of this application is decomposed into a sequence of atomic operations;

[0054] Figure 3 The flowchart below illustrates the logic for analyzing and identifying performance anomalies in an embodiment of this application. Detailed Implementation

[0055] To make the objectives, technical solutions, and advantages of the embodiments of this application more apparent and understandable, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0056] like Figure 1 The diagram shown is a flowchart of a method for providing intelligent interface services to an ERP system according to an embodiment of this application. The method includes:

[0057] S1. Receive external requests and extract request metadata, business feature vectors, and status vectors from the ERP system. Based on preset business relationship rules, parse the request metadata and business feature vectors, construct the association topology graph of the external request, perform conflict detection on the business semantics of the nodes and the operational dependencies between nodes in the association topology graph, and map and decompose it into atomic operation sequences based on the association topology graph.

[0058] Furthermore, constructing the associated topology graph includes:

[0059] Extract the business entity identifier, data entity identifier, and operation instruction type from the request metadata, and parse the process dependency, data interaction frequency, and resource call requirements from the business feature vector;

[0060] Based on pre-defined business relationship rules, initial dependencies are established between operation instruction types, data entity identifiers, and business entity identifiers to form a basic edge structure.

[0061] Calculate the semantic association between different business entity identifiers based on process dependencies and data interaction frequency, in order to determine whether to add semantic association edges and mark the association strength, and form an initial topology graph;

[0062] Calculate the semantic similarity of different nodes under the same business entity identifier, prune the initial topology graph based on resource call requirements, detect circular dependencies in the initial topology graph using a depth-first search algorithm, and cut reverse dependency edges according to the data sensitivity of the business entity identifier to reconstruct the topology path and obtain the associated topology graph.

[0063] The raw data carried by external requests contains a large number of non-core business fields. The association topology diagram needs to be based on external requests. If this concrete information is lacking, the subsequent establishment of dependency relationships will become abstract logic and cannot match the actual business scenario of the ERP system. However, if it is directly used to construct the association topology diagram, it will introduce invalid information and cause deviations in subsequent association analysis. Based on existing structured parsing tools, the core field constraints are first defined according to the metadata template preset by the ERP system. The template clearly defines the field paths and data formats of business entity identifiers, data entity identifiers, and operation instruction types. During parsing, redundant fields are automatically filtered through the template. For example, the business entity identifiers such as enterprise code and department identifier are located from the business header of the request metadata, and the data entity identifiers such as data table name and field identifier are extracted from the data body. The operation instruction type is determined by matching the preset enumeration value of the operation type field, where the enumeration value includes create, modify, and query.

[0064] The process dependencies, data interaction frequency, and resource call requirements are analyzed from business feature vectors. Process dependencies are determined by the pre-triggered and post-related nodes of each identified business step; that is, the logic for subsequent operations can only be triggered after the completion of a preceding operation, such as generating a procurement requirement only after a work order status is confirmed. Data interaction frequency uses a combination of business entity identifier and data entity identifier as the search key, counting the number of interaction records between the two in the real-time data stream. Resource call requirements are obtained through a combination of static code analysis and dynamic call tracing. At the static level, the interface call list carried by the request is analyzed to identify the required database, caching service, and message queue resource types. At the dynamic level, application performance monitoring tools record the resource usage during historical calls to determine the priority of resource requirements. Through structured parsing and multi-dimensional extraction, the obtained key information accurately corresponds to the topology construction requirements, eliminating irrelevant data interference and providing high-quality, noise-free foundational data for subsequent dependency establishment.

[0065] The extracted fragmented elements are scattered and independent, only reflecting a single business element and failing to reflect the business relationship logic between elements. The core of the relationship topology graph is to connect nodes through an edge structure, which needs to be connected by the business relationship rules preset in the ERP system to form logical dependencies. Otherwise, the relationship topology graph will be a collection of isolated nodes and cannot reflect the sequential constraints of business flow. The preset business relationship rules are loaded, and the business is stored in the form of conditions and actions. For example, when the operation instruction type is modification and the data entity is identified as the order table, the related business entity is identified as the sales department. In the matching process, the extracted key information is first converted into fact objects that can be identified by the business relationship rules, and then the Rete algorithm is used to perform pattern matching on the fact objects to quickly locate the business relationship rules that meet the conditions.

[0066] After matching, the initial dependencies among the three are obtained. Using the business entity identifier, data entity identifier, and operation instruction type as nodes, directed edges are generated based on the matching results of the business relationship rules to form a basic edge structure. For example, the sales department node points to the modification operation node, and the modification operation node points to the order table node. At the same time, a rule number is added to each edge as a traceability attribute. If there is a conflict where the same operation matches multiple rules, it is resolved by the preset business entity function weight. For example, the weight of the finance department for modifying the order amount is higher than that of the sales department, so the finance department's association rule is selected first. In this way, the rules are used to automate and standardize the establishment of dependencies, avoiding the subjective errors of manual association. The directed edge structure clearly presents the core logic of the business entity, operation instruction, and data entity, and builds a stable skeleton for the association topology graph.

[0067] The basic edge structure only covers explicit dependencies with clearly defined business relationship rules. However, in actual ERP operations, there are high-frequency collaborative relationships where the rules are not explicitly defined. For example, after the sales department creates an order, the inventory department will actively synchronize the product inventory data for that order. If these implicit relationships are not supplemented, the relationship topology will miss key business links. Semantic encoding is performed on the descriptive text of the business entity identifiers. The descriptive text is preprocessed with word segmentation and stop word removal, and the TF-IDF weights of each term are calculated to generate fixed-dimensional semantic vectors. Then, the cosine similarity of the semantic vectors of different business entities is calculated to determine semantic association. The association standard is set as a cosine similarity greater than or equal to 0.6 to determine the existence of semantic association. Effective associations are further filtered based on data interaction frequency. If the semantic association between two business entities meets the set association standard, and the historical interaction frequency meets the business collaboration requirements, an undirected semantic association edge is added between the corresponding business entity nodes. The association strength is marked according to the comprehensive result of semantic association and data interaction frequency, including strong and weak associations. Association strength R = α × cs + β × (f n / f max In the formula, cs is the cosine similarity of semantic relevance, and f n f represents the frequency of data interaction between the two business entities. max R represents the maximum frequency of interaction among all business entities. α and β are the weighting coefficients of semantic relevance and interaction frequency, respectively. α+β=1, α=0.6, and β=0.4. When R≥0.7, it is marked as a strong association, and when R<0.7, it is marked as a weak association.

[0068] For cross-level business entities, if there is a hierarchical management relationship or cross-departmental collaboration, the set association standard should be appropriately lowered to ensure that no implicit cross-level associations are missed. Finally, based on the basic edge structure, semantic association edges are integrated to form an initial topology graph, and the calculation basis of each semantic association edge is stored. In this way, by combining semantic analysis with data interaction frequency, implicit associations between business entities can be accurately captured, and the association topology graph can be extended from rule-driven to scenario-driven, which is more in line with the actual business process of the ERP system, improves the comprehensiveness of the association topology graph, and avoids missing links due to the lag in business relationship rules.

[0069] The initial topology graph may contain redundant nodes with highly repetitive semantics or circular dependencies with closed logical loops. Redundant nodes increase the complexity of subsequent decomposition, and circular dependencies can lead to infinite loops in the operation sequence. The pruning operation is carried out from two dimensions: semantic similarity and resource call requirements. The semantic similarity of nodes under the same business entity is calculated by the edit distance algorithm, that is, the degree of functional overlap between nodes. If the semantic similarity is ≥0.85, it is determined to be functionally overlapping. Combined with the resource call requirements of the nodes, further judgment is made. Nodes with lower resource consumption and higher business priority are retained, and redundant nodes are deleted. Circular dependency detection is carried out by the depth-first search algorithm (DFS). When traversing the associated topology graph, each node is marked with three states: unvisited, being visited, and visited. If a node in the visiting state is encountered during the traversal, it is determined to be a circular dependency path, and the path information is recorded.

[0070] The topology path reconstruction is based on the data sensitivity stored in the ERP system. Data sensitivity is preset by the administrator based on business security levels, divided into high, medium, and low levels, representing a classification of the sensitivity levels of various types of data. In circular dependency paths, the data sensitivity of the data associated with nodes within the circular dependency path is compared. Forward dependencies between highly sensitive nodes are retained first, while reverse dependencies between low-sensitive nodes and highly sensitive nodes are severed. Then, a breadth-first search algorithm is used to replan the path, ensuring that the topology path complies with data security rules. Finally, graph connectivity checks are used to verify the reconstructed topology graph, ensuring that all nodes are connected and there are no isolated nodes, forming the final topology graph. Pruning operations eliminate redundant nodes, reducing the computational complexity of subsequent processes; circular dependency handling avoids the risk of execution deadlock; and data sensitivity-oriented path reconstruction ensures data security, ultimately resulting in a concise, secure, and executable topology graph.

[0071] Specifically, such as Figure 2 As shown, the decomposition into atomic operation sequences includes:

[0072] The system detects the matching between the business semantics of each node in the associated topology graph and the business scenario parsed from the business feature vector to identify semantic conflicts, and traverses the operational dependencies between nodes to identify circular dependencies and repeated dependencies, marking conflicting nodes and conflicting dependencies.

[0073] Remove conflicting nodes and adjust conflicting dependencies to process the associated topology graph. Map the processed nodes to basic operation units according to the forward dependency path. Add serial or parallel associated execution identifiers to the basic operation units based on the operation dependencies and association strength between nodes.

[0074] Based on the resource call requirements retained after pruning and the reconstructed topology path, the basic operation unit is split into atomic operations according to the data entity identifier and operation instruction type. The atomic operations are then sorted into an atomic operation sequence according to the order constraints of the forward dependency path and the associated execution identifier.

[0075] Although the association topology graph has been optimized, there are still issues with mismatches between node semantics and business scenarios, or violations of dependency relationships. If directly used for decomposition, these conflicts will lead to operation sequences that contradict actual business requirements. The association relationships between various business scenarios and their corresponding node semantics, as well as the contradictions and compatibility relationships between node semantics, are stored in a semantic database. The semantics of each node in the association topology graph are matched with the business scenario parsed from the business feature vector in the semantic database. If there is a contradiction between the node semantics and the business scenario requirements, such as a scenario requiring inventory reduction while the node semantics require inventory increase, it is marked as a semantic conflict node. Cyclic dependency detection is achieved by constructing an adjacency matrix of the association topology graph and calculating the shortest path between all nodes. If a non-zero length path exists from a node to itself, it is determined to be a residual cyclic dependency, and the complete cyclic path is marked.

[0076] Duplicate dependency detection is implemented using a hash table. The key is a combination of the source node, target node, and edge type. All edges are traversed and the occurrence of the key is counted. If the count exceeds 1, it is marked as a duplicate dependency, and the position information of the duplicate edge is recorded. All conflict information is stored in the conflict log, including conflict type, involved nodes / edges, and conflict description. This allows for the early identification of various conflicts in the associated topology graph, reducing the risk of process failure, providing a clear target for subsequent conflict handling, and improving processing efficiency.

[0077] Conflicts in the markers can hinder the normal decomposition of the operation sequence. Conflicts must be eliminated first to ensure the logical coherence of the topology graph. The node and edge structure of the associated topology graph must be transformed into executable basic operation units, and the execution order of the basic operation units must be clearly defined. Otherwise, the subsequent atomic operations will lack organizational logic. Conflicts are handled through removal and reconnection strategies. Semantically conflicting nodes are directly removed from the associated topology graph. For residual circular dependency paths, the edge with the lowest association strength is cut off. For duplicate dependencies, the earliest created edge is retained and redundant edges are deleted. After conflict handling, if a node dependency chain breaks, such as when a node's predecessor dependency node is deleted, Dijkstra's algorithm is called to find the shortest alternative dependency path among the remaining nodes and re-establish the association between nodes to ensure the connectivity of the associated topology graph. The mapping of basic operation units is implemented through a pre-built operation template library. The operation template library stores the executable operation definition corresponding to each topology node. For example, modifying the node in the order table is mapped to basic operation units such as updating the order status and adjusting the order amount. Each operation template contains information such as the operation's input parameters, output results, and resource requirements.

[0078] The addition of associated execution markers combines operation dependency and association strength analysis. By comparing the input and output parameters of basic operation units, if the input of unit B depends on the output of unit A, it is marked as serial execution; if the two units have no operation dependency and the association strength is weak, it is marked as parallel execution; if the association strength is strong but there is no operation dependency, it is marked as parallel execution with result alignment. Distributed locks ensure that the execution time of the two units is consistent. Conflict handling eliminates logical obstacles, ensures the executability of the associated topology graph and matches the business scenario. Basic operation units realize the transformation from abstract nodes to specific operations, and associated execution markers clarify the collaboration method between operations, providing intermediate results for atomic decomposition.

[0079] Basic operation units are still stage-level combined operations, which cannot directly interface with the ERP system or achieve precise execution and monitoring. They need to be broken down into indivisible atomic operations and arranged sequentially to adapt to interface calls. Following the principles of CRUD and field refinement, basic operation units are broken down by data entity and operation instructions. Each basic operation unit is further decomposed into single-field operations based on the field dimension of the data entity. For example, updating order information is broken down into atomic operations such as modifying the delivery address in the order table, modifying the amount in the order table, and modifying the status in the order table. Each atomic operation corresponds to the creation, reading, updating, or deletion of a single field and is assigned a unique operation identifier. During the decomposition process, resource dependency tags are added to each atomic operation, taking into account the resource call requirements retained after pruning. For example, if modifying the amount in the order table requires calling the financial approval interface, then the interface information is associated in the operation attributes.

[0080] First, the initial sorting order is determined based on the positive dependency paths of the associated topology graph. Then, it is adjusted in conjunction with the associated execution flags. Operations executed serially are sorted according to their dependency paths, while operations executed in parallel are placed at the same sorting level and distinguished by their sequence number suffixes. After sorting, it is verified that all pre-dependencies of atomic operations are included in the sequence to ensure that there are no residual circular dependencies, thus forming the final atomic operation sequence. The smallest granularity of atomic operations enables precise monitoring and backtracking of the execution process, and the strict sorting logic ensures the business continuity between operations. The final sequence can be directly used as the execution basis for ERP system interface calls, ensuring that the execution process is orderly and controllable, and providing a basis for subsequent selection of execution modes.

[0081] S2. After the atomic operation sequence passes the verification, the execution mode is selected according to the business requirements of the atomic operation sequence. Combined with the state vector of the ERP system, the service instance is allocated to the basic interface corresponding to the execution mode through the dynamic load balancing algorithm. The resources of the ERP system are called to execute the atomic operation sequence and the execution data is monitored.

[0082] Furthermore, the execution mode selection includes:

[0083] Perform integrity checks on operation dependencies, consistency checks on business semantics, rationality checks on resource calls, and compliance checks on sequence constraints on atomic operation sequences. If no anomalies are found, the checks pass.

[0084] Once the atomic operation sequence passes the verification, extract the business requirements of the atomic operation sequence, including the associated execution identifier of each atomic operation, data entity consistency, operation dependency strength, and resource call type;

[0085] Business requirements are matched with initial execution modes based on atomic operation sequences. Initial execution modes include synchronous mode, asynchronous mode, and hybrid mode.

[0086] If there are conflicting business requirements, the initial execution mode will be adjusted according to the data entity consistency priority to adapt to the resource call type and determine the final selected execution mode.

[0087] Although atomic operation sequences have been decomposed as described above, they may still have hidden defects, such as missing key dependencies, semantics being out of sync with the context, resource requirements exceeding capacity, or the order violating business logic, which can directly lead to execution failure. When performing integrity checks on the operational dependencies of atomic operation sequences, a directed acyclic graph is constructed based on the atomic operation dependencies. All atomic operation nodes are traversed using a topological sorting algorithm to check whether each atomic operation node has any unincluded pre-dependent nodes. For example, generating an invoice requires the completion of an order payment operation. If the order payment completion operation is missing in the sequence, it is determined to be a missing dependency. The consistency check of business semantics requires calling the semantic database constructed above to semantically map the semantic description of each atomic operation to the business scenario label. If the semantic description of inventory increase appears in the business scenario label of sales outbound, it is determined to be a semantic conflict by the strong association rules between sales outbound and inventory decrease in the semantic database.

[0088] The rationality verification of resource calls needs to be combined with the resource configuration in the state vector of the ERP system. The resource request parameters of each atomic operation, such as the number of database connections and cache space, need to be parsed and compared with the available resources of the current system. If the number of database connections requested by an operation exceeds the maximum allowed value of the system, the resource call is determined to be unreasonable. The compliance verification of sequence constraints needs to be compared with the actual order of atomic operation sequences and the aforementioned generated positive dependency paths. The path matching algorithm is used to check whether there is an operation order reversal. For example, if order shipment is placed before order review, it conflicts with the rule in the positive dependency path that shipment can only be made after review, and is determined to be a sequence violation. If no anomalies are found after the above verification, the atomic operation sequence is determined to pass the verification. Atomic operation sequences that do not conform to business logic and execution requirements are filtered in advance through multi-dimensional verification to avoid execution failure due to dependency breakage and semantic conflict, and reduce ineffective resource consumption.

[0089] The choice of execution mode must be based on the specific business characteristics of the sequence. If these characteristics cannot be clearly defined, the mode selection will lack a basis, leading to low execution efficiency or failure to achieve business goals. After the atomic operation sequence passes verification, the business requirements of the atomic operation sequence are extracted, including the associated execution identifier, data entity consistency, operation dependency strength, and resource call type of each atomic operation. When extracting the associated execution identifier, the atomic operation sequence is traversed, and the execution type field pre-set in the basic operation unit is read to directly obtain the serial or parallel identifier. For example, the serial identifier is extracted from the metadata of the order information verification operation. The extraction of data entity consistency requires comparing the data entity identifiers involved in all operations in the atomic operation sequence. An association table between data entities and operation instructions is established through hash mapping. It is checked whether there are contradictions in the field values ​​of the same data entity in different operations. For example, whether the order amount is consistent in the order creation and payment operations, thereby determining whether the data entity needs to maintain real-time consistency.

[0090] Extracting the strength of operational dependencies requires tracing back to the previously constructed relational topology graph, mapping the relational strength attributes of edges between nodes to the corresponding atomic operation dependencies. For example, a strong relational edge between order payment and order creation corresponds to high dependency strength. Extracting resource call types involves parsing the execution script of each atomic operation to identify the type of resource interface it calls, such as database CRUD interfaces, message queue interfaces, and cache interfaces. This is then categorized based on the real-time tags in the interface documentation. For example, querying inventory calls a real-time database read interface, while logging calls a non-real-time message queue interface. This transforms the abstract sequence of atomic operations into clearly describable business requirement indicators, providing a concrete basis for accurate matching of execution modes, avoiding subjectivity and blindness in execution mode selection, and preventing the initial execution mode from being unsuitable for actual resource conditions.

[0091] Different execution modes have significantly different characteristics. Synchronous mode is suitable for scenarios with high real-time requirements, while asynchronous mode is suitable for high-concurrency non-real-time scenarios. If not matched according to business needs, it will lead to low execution efficiency or waste of resources. The initial execution mode is matched based on the business needs of atomic operation sequences. The initial execution modes include synchronous mode, asynchronous mode, and hybrid mode. When matching synchronous mode, it is checked whether the business needs meet three conditions: fully serial execution, high operation dependency strength, and real-time resource call type. For example, in the atomic operation sequence of order creation, payment to confirmation, all operations are executed serially, have high dependency strength, and all call real-time database interfaces. In this case, synchronous mode is matched, and instant response and result feedback between operations are achieved through HTTP synchronous interface. On the other hand, the matching of asynchronous mode needs to meet the conditions of parallel execution, low operation dependency strength, and non-real-time resource call type. For example, in the batch material information synchronization sequence, multiple material information verification operations are executed in parallel, have low dependency strength, and call message queue interface. In this case, asynchronous mode is matched, and the operation tasks are encapsulated as messages and delivered to the queue. The consumer side processes them asynchronously and sends back the results.

[0092] Hybrid mode matching addresses needs that combine synchronous and asynchronous characteristics. For example, order status updates need to be executed serially in real time, while order data archiving can be executed in parallel but not in real time. In this case, real-time operations are bound to synchronous mode, and non-real-time operations are bound to asynchronous mode, and the execution sequence of the two modes is coordinated. Based on preset rules, the execution mode is automatically matched to ensure the basic adaptability of the initial execution mode to business requirements, reduce manual intervention, improve the efficiency of execution mode selection, and lay the foundation for subsequent adjustments.

[0093] Business requirements may inherently conflict. For example, a sequence of atomic operations may require both parallel processing and real-time data consistency, which the initial execution mode cannot simultaneously satisfy. Adjustments must be made based on priority to balance the conflict and ensure the core requirements are met. Conflict identification involves comparing the characteristics of the initial execution mode with the constraints of the business requirements. For instance, if the initially matched asynchronous mode cannot guarantee real-time data consistency due to message latency, it is determined that the initial execution mode conflicts with the business requirements. During adjustments, data entity consistency is given the highest priority. Atomic operations involving data consistency are switched from asynchronous to synchronous mode. For example, an order amount modification operation needs to be synchronized to the financial system in real time, while retaining the asynchronous execution characteristics of order log records, forming a hybrid mode. Simultaneously, resource call types are adapted, and the adjusted execution mode is checked to ensure it matches resource characteristics. For example, if the synchronous mode requires calling a real-time database, and the database is currently overloaded, temporary expansion or switching to a backup database is performed through the resource scheduling interface to ensure that resources can support execution after the mode adjustment.

[0094] Finally, the adjusted execution mode is verified through business scenario simulation. The entire process is simulated and checked to see if it meets all core requirements, such as data consistency and response time. Once confirmed to be correct, it is determined as the final execution mode. This resolves business requirement conflicts through prioritization, optimizes execution efficiency while ensuring core business needs are met, and makes the execution mode both consistent with business logic and practical, maximizing its adaptability to resource conditions and avoiding execution failures caused by rigid execution modes. The final execution mode directly determines the selection scope of basic interfaces and the allocation strategy of service instances. If the execution mode is not determined reasonably, subsequent basic interfaces and service instances will not be able to support the execution of atomic operation sequences, affecting the overall process efficiency.

[0095] Specifically, the service instances to be allocated include:

[0096] Based on the selected execution mode, the corresponding basic interfaces are defined, and the real-time resource indicators of the servers where the basic interfaces are located are extracted from the state vector of the ERP system to evaluate the resource sufficiency of each basic interface.

[0097] The allocation priority of basic interfaces is determined by combining the business requirements of atomic operation sequences. Based on the dynamic load balancing algorithm, service instances are allocated to basic interfaces by combining resource sufficiency and allocation priority.

[0098] The system invokes resources from the ERP system, executes atomic operation sequences sequentially based on the order constraints of the positive dependency path and associated execution identifiers, and monitors the execution data.

[0099] Different execution modes have different technical requirements for interfaces. If interfaces are not screened and resources are not evaluated in advance, it may lead to a mismatch between the basic interfaces and the execution mode or execution lag due to insufficient resources. When defining the suitable basic interfaces, the interfaces of the ERP system are called according to the technical requirements of the final execution mode, and the basic interfaces that meet the conditions are screened. For example, in synchronous mode, REST interfaces with response times less than or equal to a preset time threshold and supporting transactions are screened. The preset time threshold is set according to the interface type: 200ms for order creation interface, 100ms for inventory query interface, and 500ms for payment interface. Those skilled in the art can adjust it according to the performance requirements of the ERP system. In asynchronous mode, MQ interfaces with concurrent processing capabilities greater than or equal to a preset capability value and supporting message persistence are screened. In hybrid mode, two types of interfaces are screened separately and an association mapping is established. For example, the execution result of the synchronous interface is used as the trigger condition for the asynchronous interface.

[0100] When extracting real-time resource metrics of the server hosting the basic interface from the state vector, data such as CPU utilization, memory usage, network I / O, and remaining capacity of the interface connection pool are obtained through the server monitoring agent. For example, the current CPU utilization, remaining memory, and number of database connections of the server hosting the order synchronization interface. To assess resource sufficiency, real-time metrics are compared with the resource requirement threshold of the atomic operation sequence. For example, if the atomic operation sequence needs to process 100 interface calls per second, the server's current remaining processing capacity is calculated. If the remaining processing capacity is greater than or equal to the requirement, it is considered that the resources are sufficient; otherwise, it is marked as resource strained. This ensures that the defined basic interfaces match the characteristic requirements of the execution mode. At the same time, resource sufficiency assessment identifies resource bottlenecks in advance, providing a basis for resource status for subsequent service instance allocation and avoiding the allocation of operations to interfaces with insufficient resources, which could lead to execution delays and failures.

[0101] Among them, the resource sufficiency score R score =(1-CPU used )×0.4+(1-Mem used / Mem total )×0.3+(Conn remain / Conn max )×0.3, where CPU used Mem represents the current CPU utilization. used Mem is the amount of memory already used. total For total memory, Conn remain For the remaining capacity of the connection pool, Conn max The maximum capacity of the connection pool; compare real-time metrics with resource requirement thresholds for atomic operation sequences, R score A value ≥ 0.6 indicates sufficient resources, and 0.4 ≤ R indicates sufficient resources. score <0.6 indicates moderate resources that require attention. score A value less than 0.4 indicates resource scarcity; for example, if a server's CPU utilization is 40% and memory usage is 60% (Mem), then... used / Mem total =0.6), Connection pool remaining 70% (Conn) remain / Conn max =0.7), then R score =(1-0.4)×0.4+(1-0.6)×0.3+0.7×0.3=0.57, which is judged as medium resource and needs attention.

[0102] There are multiple basic interfaces to be adapted, and their importance and resource requirements vary. If they are allocated directly without prioritizing them, it will lead to insufficient resources for core business interfaces and excessive resource consumption for non-core interfaces. Based on the business requirements of atomic operation sequences, the basic interfaces are classified according to their business importance to determine the allocation priority, including core interfaces, important interfaces, and general interfaces. For example, the payment interface is a core interface, while the log interface is a general interface. At the same time, based on the resource demand intensity of the interfaces, among the basic interfaces of the same level, the basic interfaces with higher resource demand are given priority in allocation, forming the ranking result of allocation priority.

[0103] When allocating service instances based on the dynamic load balancing algorithm, the evaluation results of allocation priority and resource sufficiency are input. A weighted least-connection algorithm is then used to assign a weight to each service instance, where the weight W = γ × R. score +δ×P level In the formula R score Score the resource sufficiency of the server hosting this instance, P. level To quantify the priority allocation, core interfaces = 3, important interfaces = 2, and general interfaces = 1, with γ = 0.6 and δ = 0.4. The service instance with the highest weight W and the fewest currently active connections is selected for basic interface allocation. Service instances with sufficient resources have higher weights, and core interfaces are prioritized for creation on servers with sufficient resources to avoid concentrating multiple high-resource-demand interfaces on the same server. Important and general interfaces are allocated to their corresponding service instances according to their weights. For interfaces executed in parallel, service instances are distributed across different servers to improve concurrency. For interfaces executed serially, the network latency of the server hosting the service instance is ensured to be below a preset value to guarantee the execution order. After allocation, instance information is registered with the service discovery component and bound to the corresponding interface, generating a mapping table of interfaces and instances for querying during calls. Thus, through priority allocation and dynamic load balancing algorithms, high-priority operations are ensured to receive high-quality instance resources, while avoiding excessive load on a single instance, improving overall execution stability and efficiency.

[0104] After service instances are allocated, the execution process must be triggered according to business logic. Simultaneously, key data during execution must be monitored in real time to promptly identify anomalies and provide a basis for subsequent optimization, ensuring the execution process is controllable and traceable. When calling resources from the ERP system, based on the sequential constraints of the forward dependency path and associated execution identifiers, the service discovery component queries the mapping table between interfaces and instances to obtain the access address of the target service instance. For serial operations, instance interfaces are called sequentially according to the path order. After the previous operation succeeds, a callback function triggers the next operation; for example, after the order creation interface returns success, the order payment interface is automatically called. For parallel operations, a distributed task scheduler sends execution instructions to multiple service instances simultaneously, and a distributed lock ensures that parallel operations access the same data entity mutually exclusively.

[0105] When deploying execution data monitoring, probes are embedded in the call chain of each interface instance to obtain information such as the start time, end time, execution status, returned data content, and peak resource consumption in real time. Peak resource consumption includes CPU utilization and database latency. The obtained execution data is transmitted to the data platform through a message queue and stored in the database according to atomic operation identifiers and instance identifiers. This ensures that the atomic operation sequence is executed in an orderly manner according to the preset order constraints, while completely recording the execution process data. This provides a traceable basis for subsequent anomaly detection, performance analysis, and optimization, ensuring the reliability of business processes.

[0106] S3. If an operational anomaly is detected, immediately interrupt the process and initiate fault tolerance processing. Simultaneously, trace back the data flow path from the source system to the target system, determine the quality index of each basic interface based on the data flow path and execution data, analyze and identify performance anomalies based on the data flow path, optimize the basic interfaces by combining the quality index and performance anomalies, and update the business relationship rules based on the execution data when there is a persistent conflict between the performance anomaly and the business relationship rules, and return the optimization results and update results to the requester.

[0107] Furthermore, the quality indices for each basic interface are determined as follows:

[0108] The execution data of the atomic operation sequence is compared with the corresponding judgment threshold, and it is determined whether the execution result between each atomic operation meets the order constraint. If any judgment condition is triggered, it indicates that the operation is abnormal.

[0109] Upon detecting an operational anomaly, the process is immediately interrupted and fault tolerance processing is initiated. Simultaneously, based on the associated execution identifiers of atomic operations and the call chain of basic interfaces, the data flow path from the source system to the target system is traced back.

[0110] Extract the role attributes and data integrity of the basic interfaces from the data flow path, extract the execution success rate and response latency of the basic interfaces from the execution data, and extract the exception recovery time of the fault tolerance processing record;

[0111] The execution success rate and response latency are correlated with execution compliance, role attributes and data integrity are correlated with workflow coordination, and the time spent on anomaly recovery is correlated with the degree of anomaly impact. The quality index of each basic interface is determined by weighted summation.

[0112] During the execution of atomic operation sequences, situations may arise where the executed data exceeds the normal range or the execution order violates the sequence constraints. If these anomalies are not identified in a timely manner, they can spread to subsequent business processes. The execution data of the atomic operation sequences is extracted, including the response data and execution status of each basic interface. This execution data is then matched against preset judgment thresholds in the ERP system. These thresholds include the normal operating parameter ranges for each type of interface, i.e., the reasonable time range for interface responses and the integrity standards for data transmission. For example, the response time field in the execution data of an inventory query interface needs to be compared with the corresponding response time threshold in the judgment thresholds. If it exceeds the range of the response time threshold, it is marked as a data anomaly.

[0113] Simultaneously, based on the positive dependency path of atomic operations, the execution order between each atomic operation is verified one by one through a path matching algorithm. For example, the order review operation must be executed after the order submission operation. If the order review is detected to be completed before the order submission, it is determined to be a violation of the order constraint. As long as either data anomaly or order violation is triggered, it is determined to be an operational anomaly. Through the dual judgment of data threshold and order constraint, misjudgment caused by single data fluctuations is avoided, and hidden anomalies that are not identified due to disordered order are prevented, ensuring the accuracy of operational anomaly judgment and preventing the hidden transmission of anomalies from causing a wider range of business failures.

[0114] After confirming an anomaly, continuing subsequent operations could lead to the accumulation of erroneous data or disruption of business logic. The process must be immediately interrupted. Simultaneously, fault tolerance measures must be implemented to mitigate the impact of the anomaly on current business operations. Tracing the data flow path is fundamental for subsequent analysis of interface quality and pinpointing the root cause of the anomaly. All three must be initiated simultaneously to achieve the dual goals of timely loss mitigation and accurate source tracing. An interrupt command is sent through the ERP system to suspend unexecuted atomic operations in the atomic operation sequence, while locking intermediate data from executed operations to prevent data tampering or repeated calls. When initiating fault tolerance measures, a pre-defined fault tolerance strategy is invoked, matching the appropriate strategy based on the anomaly type. For example, if an interface is temporarily unresponsive, a retry mechanism is triggered, repeatedly calling the interface via a scheduled task until success or the maximum number of retries is reached. If a data transmission error occurs, a data rollback mechanism is initiated, restoring the data modified by the executed operations to its pre-anomaly state. If a core interface fails, a degradation strategy is triggered, and the system switches to a backup interface to continue executing critical business operations.

[0115] While handling fault tolerance, a data flow tracing graph is constructed based on the associated execution identifiers of atomic operations and the call chain of basic interfaces. Starting from the source system interface corresponding to the abnormal operation, the graph is traced layer by layer along the call chain to the target system interface. For example, starting from the payment interface corresponding to the order payment failure operation, the graph traces back to its upstream order creation interface and downstream financial accounting interface, completely restoring the entire path of data from generation to transmission, so as to obtain the data flow path from the source system to the target system. The process interruption quickly controls the scope of the abnormal spread, the fault tolerance reduces the production stoppage losses caused by the abnormal, and the backtracking of the data flow path clarifies the interface range for quality index calculation, avoiding the distortion of the index caused by missing or over-calculated interfaces.

[0116] The quality index of basic interfaces needs to comprehensively reflect their execution performance, collaborative capabilities, and anomaly recovery capabilities. Single-dimensional data cannot fully assess interface quality; therefore, multi-dimensional basic data needs to be extracted from the data flow path and execution data to support the calculation of the quality index. From the backtracked data flow path, the registration information of each basic interface is retrieved, and the role attributes of the basic interfaces are extracted. The role attributes are divided according to the functional positioning of the basic interface in the business process, including core processing interfaces, data transmission interfaces, and auxiliary verification interfaces. For example, the order payment interface is marked as a core processing interface because it directly participates in the flow of funds. At the same time, the data transmission records between basic interfaces in the data flow path are checked, and the integrity of the data received and output by each interface is confirmed through data verification logs, such as whether there are missing fields or data format errors, in order to extract data integrity.

[0117] The execution success rate and response latency of each basic interface are extracted from the execution data. The execution success rate refers to the ratio of successful executions to the total number of calls, and the response latency refers to the time interval between receiving a request and returning a result from the basic interface. From the fault tolerance processing logs, the time consumed by each basic interface after an exception occurs is extracted, that is, the time from the triggering of the exception to the restoration of normal service. For example, if an interface triggers fault tolerance processing due to a database connection failure, the recovery time is the time from the connection failure to the re-establishment of the database connection. In this way, through multi-dimensional data extraction, the core dimensions of basic interface quality assessment are covered, avoiding the distortion of the quality index due to partial data, and providing comprehensive and reliable raw data for subsequent weighted calculations.

[0118] Multi-dimensional basic data is scattered and needs to be categorized into core dimensions reflecting interface quality through reasonable correlation logic. Then, weighted summation is used to transform multi-dimensional data into a quality index for intuitive evaluation of the quality level of basic interfaces. The extracted execution success rate and response latency are correlated as a dimension of execution compliance to evaluate whether the basic interface itself is stable and smooth in execution. The higher the execution success rate and the closer the response latency meets the threshold requirements, the better the execution compliance performance. Role attributes and data integrity are correlated as a dimension of flow collaboration to evaluate the basic interface's ability to connect in cross-business flows. Core role interfaces have higher data integrity requirements. If core interfaces have missing data, the flow collaboration will be significantly reduced.

[0119] The recovery time of anomalies is correlated with the dimension of anomaly impact to assess the magnitude of the impact of basic interface anomalies on the overall process. The longer the recovery time, the wider the scope and the longer the duration of the anomaly's impact on the business, and the higher the anomaly impact. According to the ERP system's preset weighting rules, different weights are assigned to the three dimensions. For example, execution compliance has the highest weight because it directly affects the real-time business experience. The evaluation results of the three dimensions are integrated into a quality index through weighted summation. The quality index directly reflects the quality of the basic interface. Thus, through the calculation logic of dimension correlation and weighted summation, scattered data is transformed into a quantifiable quality index, which not only reflects the comprehensive performance of the basic interface but also fits the business characteristics of prioritizing cross-business flows, avoiding the disconnect between the quality index and actual business needs, and providing a clear basis for subsequent anomaly interface screening.

[0120] Quality index Q = w1 × C exec +w2×C flow +w3×C impact In the formula, C exec To implement compliance scoring, C flow For the score of circulation synergy, C impactFor the score of abnormal impact, the weights are allocated as w1=0.5, w2=0.3, and w3=0.2, reflecting the dominant role of compliance in the quality index. The sum of the three weights is 1. Those skilled in the art can adjust the weights according to the business control requirements of the ERP system; where C exec C is calculated based on a combination of execution success rate and response latency. exec =0.6×SR+0.4×T score SR represents the execution success rate, and T represents the execution success rate. score For response delay score, when response delay LR is less than or equal to the maximum allowable response delay L max Time T score =1-LR / L max When LR is greater than L max Time T score Process as 0; C flow C is determined by the product of role attribute weights (core processing interface = 1, data transmission interface = 0.8, auxiliary verification interface = 0.6) and data integrity. flow =Role w ×DI, Role w For character attribute weights, DI stands for data integrity; C impact =1-RT / RT max RT represents the time taken for abnormal recovery. max This represents the maximum allowable recovery time.

[0121] Furthermore, such as Figure 3 As shown, the analysis and identification of performance anomalies include:

[0122] Basic interfaces with a quality index less than the index threshold are considered as candidate abnormal interfaces. Based on the interface connection relationship in the data flow path, the candidate abnormal interfaces and their upstream and downstream interfaces are divided into abnormal association groups.

[0123] By analyzing the synchronous fluctuation relationship between execution success rate and response latency in the basic interfaces within the anomaly association group, as well as the transmission relationship of data integrity, the association of the anomaly association group is obtained.

[0124] Based on the role attributes of the basic interfaces and the correlation of the exception association groups, analyze the direction of exception propagation and distinguish the root cause exception interfaces. Verify whether the root cause exception interfaces cause the business requirements of the atomic operation sequence to be unmet, so as to analyze and identify performance anomalies.

[0125] Interfaces with a quality index below the index threshold are likely to have performance issues, and these candidate abnormal interfaces need to be screened out first. However, interface abnormalities are propagated; for example, an upstream interface abnormality can lead to downstream interface data abnormalities. Analyzing only candidate abnormal interfaces alone cannot uncover hidden correlation issues. An index threshold is preset according to actual requirements. The index threshold is set based on the role attributes of the basic interfaces: the index threshold for core processing interfaces is set to 0.8, the index threshold for data transmission interfaces is set to 0.7, and the index threshold for auxiliary verification interfaces is set to 0.6. Those skilled in the art can adjust this according to actual needs. The quality index of each basic interface is compared with this index threshold. If the quality index is less than the index threshold, it is marked as a candidate abnormal interface. For example, if the quality index of an order synchronization interface is less than the core interface index threshold, it is included in the candidate list. Based on the aforementioned backtracked data flow path, the upstream and downstream interface information of the candidate abnormal interfaces is extracted. Upstream and downstream interfaces are those that directly interact with the candidate abnormal interface. For example, the upstream of the candidate abnormal interface, the order payment interface, is the order review interface, and the downstream is the financial accounting interface.

[0126] Based on the interface connection relationship, each candidate abnormal interface and its upstream and downstream interfaces are divided into an independent abnormal association group. For example, the order review interface, order payment interface and financial accounting interface constitute an abnormal association group, ensuring that the group includes all relevant interfaces for abnormal transmission, and other unrelated interfaces are not included in the group. By filtering with quality index and association grouping, the scope of abnormal analysis is narrowed, which avoids irrelevant interfaces from interfering with the analysis and ensures that related interfaces are not missed, providing a focused analysis object for subsequent correlation analysis.

[0127] Interfaces within an anomaly association group exhibit a cause-and-effect transmission relationship. For example, an anomaly in one root interface can lead to anomalies in multiple downstream interfaces. Without analyzing the correlation between interfaces within the anomaly association group, it is impossible to distinguish between root anomalies and derived anomalies. Historical execution data for all interfaces within the anomaly association group should be retrieved, including time-series records of execution success rate and response latency, and data integrity. First, compare the changes in execution success rate and response latency of interfaces within the anomaly association group. If, after a decrease in the execution success rate and an increase in response latency of a certain interface, its downstream interfaces show the same trend within the same time window, it is determined that there is a synchronous fluctuation relationship between the two. For example, if the execution success rate of the order review interface decreases by 10 minutes, the execution success rate of the order payment interface will decrease synchronously, indicating a synchronous fluctuation transmission.

[0128] Simultaneously, the transmission records of data integrity within the anomaly association group are checked. If the data output by the upstream interface is missing, and the data received by the downstream interface also has the same missing data, it is determined that there is a data integrity transmission relationship between the two. For example, if the order review interface fails to transmit the customer address field, the customer address field received by the order payment interface will be empty. By combining the synchronous fluctuation relationship and the data integrity transmission relationship, the correlation of the anomaly association group is formed, and the influence and affected relationship of the interfaces within the anomaly association group is marked. Thus, through the dual analysis of time-series fluctuations and data transmission, the direction of anomaly transmission and the core cause within the anomaly association group can be accurately identified, avoiding misjudging the transmitted anomaly as the root cause anomaly, and providing a basis for subsequent accurate location of the root cause interface.

[0129] When multiple abnormal interfaces exist within an abnormal association group, it is necessary to find the root interface that triggers the chain of abnormalities. Otherwise, optimization will only target the derived abnormal interfaces and will not fundamentally solve the problem. At the same time, it is necessary to verify whether the root interface actually affects business requirements to avoid mistakenly identifying unrelated interfaces as the root cause. Combining the correlation of the abnormal association group with the role attributes of the basic interfaces, analyze the direction of abnormal propagation. Core role interfaces are more likely to become the root cause, and the direction of abnormal propagation is usually from upstream interfaces to downstream interfaces. For example, if an abnormality in the order review interface propagates to the order payment interface, then the order review interface should be given priority as a candidate root abnormality interface.

[0130] Subsequently, the business requirements of the atomic operation sequence are retrieved. For example, order processing requires accurate and real-time payment completion. It is verified whether the anomaly of the candidate root cause exception interface causes the business requirements to be unmet. If the order review interface is abnormal, causing the review to be delayed, and thus the order payment cannot be completed on time, violating the business requirement of real-time payment, then the interface is confirmed as the root cause exception interface and defined as the performance anomaly point, because it is the core anomaly source that triggers the entire anomaly association group. Thus, through the triple judgment of role attributes, association, and business requirements verification, the root cause exception interface is accurately located and the performance anomaly point is confirmed, avoiding deviation in the optimization direction and ensuring that subsequent optimizations can directly solve the core problem and avoid meaningless optimizations.

[0131] Specifically, the optimization of the basic interfaces includes:

[0132] Associate the root cause interface corresponding to the performance anomaly with the quality index and role attributes of the root cause interface in order to locate the anomaly type of the root cause interface.

[0133] Based on the type of exception, select the optimization direction for the root cause exception interface, and adjust resource allocation and backup service instances in combination with role attributes, execution mode and business relationship rules to optimize the basic interface;

[0134] The optimized basic interface is incorporated into the execution flow of the atomic operation sequence, and changes in execution data and quality indices in the optimized basic interface and its upstream and downstream interfaces are monitored.

[0135] If the quality index is not less than the index threshold and the performance anomalies are eliminated, the optimized basic interface will be fixed as the default interface configuration. If there are still operational anomalies, the basic interface will be optimized again and verified again.

[0136] The abnormal behavior of the root cause interfaces is caused by different reasons. If the type of abnormality is not clearly identified, optimization measures will lack specificity and fail to solve the actual problem. By retrieving the root cause interface corresponding to the performance anomaly, and correlating it with the quality index calculated in previous steps and the extracted role attributes, the following analysis is performed: If the root cause interface is a core processing interface, and the low quality index is mainly due to excessive response latency but normal execution success rate, combined with the ERP system's resource monitoring logs, it was found that the CPU of the server hosting the interface was consistently high, determining the anomaly type to be resource insufficiency. If the interface is a data transmission interface, the low quality index is due to poor data integrity; checking the interface's data validation logic revealed missing field validation steps, determining the anomaly type to be data validation missing. If the interface is an auxiliary validation interface, the low quality index is due to long anomaly recovery time; checking the fault tolerance strategy revealed the absence of a backup instance, determining the anomaly type to be fault tolerance insufficient. By correlating role attributes with the quality index, the core cause of the anomaly is accurately identified, and the anomaly type is determined. This avoids blindly trying optimization measures. Multi-dimensional data correlation achieves a precise mapping of anomaly behavior, cause, and type, providing a clear basis for subsequent optimization direction selection and preventing the inability to eliminate performance anomalies.

[0137] Different anomaly types require differentiated optimization strategies. Simply identifying the anomaly type without specific measures will not solve the problem. Optimization must also consider interface roles, execution modes, and business relationship rules to avoid conflicts with existing business logic after optimization. If the anomaly type is resource insufficiency, based on the role attributes and execution mode of the basic interface, increase CPU and memory quotas for the server hosting the basic interface, or migrate it to a server node with more abundant resources to ensure that resource supply matches business needs. If the anomaly type is missing data validation, based on the clauses in the business relationship rules requiring complete data transmission validation, add field integrity validation and data format validation logic to the interface code, such as adding steps for non-empty customer ID validation and order amount format validation.

[0138] If the fault tolerance mechanism is insufficient, configure backup service instances for the interface according to the execution mode. The hybrid mode needs to balance real-time performance and reliability, and bind the relationship between the primary service instance and the backup service instance. When the primary service instance fails, it will automatically switch to the backup service instance. At the same time, adjust the fault tolerance retry count and interval to adapt to the business's requirements for recovery speed. In this way, the optimization measures are accurately matched with the exception type, while taking into account the role attributes, execution mode and business relationship rules of the interface, avoiding conflicts between optimization and existing business logic, ensuring that the performance of the optimized interface is effectively improved, and avoiding misjudgments of ineffective optimization in subsequent monitoring.

[0139] The optimized basic interface needs to be actually used in the business process to verify its effectiveness. Simply configuring it without running it cannot confirm whether performance has improved. Furthermore, interface performance affects upstream and downstream interfaces. For example, if the optimized interface responds quickly, the data transmission pressure on upstream interfaces changes. Upstream and downstream data need to be monitored simultaneously to avoid missing any related impacts. The optimized basic interface should be updated to the interface corresponding to the atomic operation sequence, replacing the original abnormal interface to ensure that the execution process calls the optimized basic interface. Then, the execution of the atomic operation sequence should be retried, and execution data should be monitored simultaneously. Real-time data such as the success rate, response latency, and data integrity of the optimized interface should be obtained. The monitoring scope should be expanded to obtain the data sending efficiency of its upstream interface and the data receiving success rate of its downstream interface. For example, after optimizing the order payment interface, the order data sending speed of the upstream order review interface and the payment data receiving integrity of the downstream financial accounting interface should be monitored. The obtained multi-dimensional data should be compared in real time with the execution data before optimization and index thresholds to track performance change trends. The optimization effect should be verified in actual business scenarios, while monitoring upstream and downstream interface data to avoid negative impacts of the optimized interface on related interfaces, ensuring the overall integrity and security of the optimization.

[0140] When optimization is effective, the interface configuration should be fixed to avoid subsequent processes reverting to the original abnormal configuration. When optimization is ineffective, the problem should be re-investigated to avoid using the ineffective configuration for a long time. If the monitored execution data shows that the quality index of the optimized interface is greater than or equal to the index threshold, and the performance anomaly is completely eliminated, then the optimized resource quota, number of backup instances, and verification logic parameters should be fixed as the default configuration of the interface, and subsequent calls should automatically use this configuration. If the monitored execution data shows that the quality index is still less than the index threshold, or the performance anomaly is not eliminated, return to the step of associating the root cause of the anomaly interface to locate the anomaly type, re-analyze the cause of the anomaly, for example, if the original judgment of insufficient resources is actually due to missing database indexes, then adjust the anomaly type and reselect the optimization direction, such as supplementing the database indexes, until the optimization effect meets the standard. When optimization is effective, stabilize the interface performance and avoid repeated configuration. When it is ineffective, backtrack in time to ensure that optimization is not just a formality, forming a complete process of location, optimization, verification, and closure, providing a stable interface for the ERP system.

[0141] Specifically, updating business relationship rules includes:

[0142] The frequency of conflicts between the root cause of the performance anomaly and the business relationship rules is counted. If the frequency of conflicts exceeds the preset frequency threshold and is associated with core atomic operations, it is determined that there is a continuous conflict.

[0143] Extract the clause constraints related to the root cause exception interface from the business relationship rules, compare the execution data of the root cause exception interface with the clause constraints, and locate the clause constraints corresponding to the continuous conflict.

[0144] Based on the business requirements of atomic operation sequences and the execution data of the root cause exception interface, adjust the parameters of the conflict clause constraints to update the business relationship rules.

[0145] After regenerating and executing the atomic operation sequence based on the updated business relationship rules, verify whether the performance anomalies have been eliminated and whether the execution data and quality index of the upstream and downstream interfaces are normal. After verifying that there are no anomalies, solidify the business relationship rules and return the optimized basic interface and the updated business relationship rules to the requester.

[0146] Conflicts between root cause anomaly interfaces and business relationship rules may be accidental events, such as temporary resource fluctuations, or the business relationship rules themselves may not conform to actual business needs. Occasional conflicts do not require modification of the business relationship rules; only persistent conflicts necessitate adjustment. Extract conflict records between the root cause anomaly interface and the business relationship rules corresponding to performance anomalies, and statistically analyze the conflict frequency within a preset time range. Simultaneously, check whether the atomic operation associated with the root cause anomaly interface is a core atomic operation. Core atomic operations are those that directly affect the core ERP business, determined by the priority of business operations; for example, order payment operations are marked as core. If the conflict frequency exceeds a preset conflict frequency threshold, and the conflicting interface is associated with a core atomic operation, it is considered an anomaly. If the business relationship rules are consistently mismatched with the actual core business needs, they are considered to be in conflict. The preset conflict frequency thresholds are set based on the importance of atomic operations: the threshold for core atomic operations is 5 or more conflicts within 30 days, and the threshold for non-core atomic operations is 10 or more conflicts within 30 days. Those skilled in the art can adjust these thresholds according to business stability requirements. If the frequency does not exceed the conflict frequency thresholds or is associated with non-core atomic operations, it is considered an occasional conflict, and no update to the business relationship rules is required. This avoids erroneous changes to business relationship rules due to occasional conflicts, ensuring that updates only target fundamental conflicts that have a long-term impact on core business, thus maintaining the stability of the business relationship rules.

[0147] To determine whether persistent conflicts stem from a problem with the overall business relationship rules or a specific unreasonable clause, it's crucial to accurately pinpoint the conflicting clause constraints. Otherwise, targeted adjustments to the business relationship rules are impossible, leading to persistent vulnerabilities even after updates. Extracting clause constraints directly related to the root cause of the anomaly from the business relationship rules is essential. These constraints explicitly define the interface's operational logic, dependencies, or resource requirements. For example, the order payment interface must use a synchronous execution mode, and the order payment interface must rely on an inventory deduction interface. Comparing these extracted clause constraints with the execution data of the root cause of the anomaly reveals a conflict. If the clause constraints specify a synchronous execution mode, but the execution data shows a synchronous execution mode... If the response latency of the downstream interface far exceeds the threshold or frequently times out, it indicates a conflict between the clause constraints of the synchronous execution mode and the actual execution situation. If the clause constraints stipulate a dependency on the inventory deduction interface, but the execution data shows that the inventory deduction interface frequently malfunctions, causing the payment interface to be blocked, it indicates a conflict between the clause constraints of the dependency relationship and the actual business compatibility. By comparing them one by one, the specific clause constraints that cause the continuous conflict can be located. This avoids the need to modify the entire business relationship rules, accurately locates a single clause constraint, reduces the complexity and risk of updating business relationship rules, ensures that the adjustments are more targeted, and avoids the business relationship rule update direction deviating due to incorrect clause constraint positioning, which would prevent the resolution of the continuous conflict.

[0148] After identifying conflicting clauses, the content of the clause constraints needs to be adjusted based on actual business needs and execution data. If modifications are made solely based on subjective experience, the new clause constraints will still not conform to actual business practices. Considering the business requirements of atomic operation sequences, and using the execution data of the root cause of the anomaly as the basis for adjustment, if the conflicting clause constraint is in synchronous execution mode, and execution data shows that synchronous mode has a low success rate while hybrid mode has a high success rate and controllable response latency, then, considering the need to balance real-time performance and success rate, the conflicting clause constraint is adjusted so that the order payment interface adopts a hybrid execution mode. If the conflicting clause constraint depends on the inventory deduction interface, and execution data shows that the inventory deduction interface has a high anomaly rate, and business requirements allow for payment before inventory verification, then the conflicting clause constraint is adjusted so that the order payment interface is executed first, and the asynchronous inventory deduction interface is used for verification. After adjusting the parameters of the conflicting clause constraints, the new clause constraints are entered into the business relationship rule base, marked as pending verification, and the original conflicting clause constraints are replaced. The new clause constraints are formulated based on actual execution data and business needs, avoiding subjective assumptions, ensuring that the business relationship rules are highly adapted to actual business practices, and fundamentally resolving persistent conflicts.

[0149] The updated business relationship rules need to be verified through actual operation to avoid introducing new conflicts. Verified business relationship rules must be solidified to ensure stable use in subsequent business processes, and the results must be returned to the requester to form a complete service loop. Based on the updated business relationship rules, new atomic operation sequences are regenerated. For example, order payment-related operations are re-decomposed using a hybrid execution mode, and then the optimized basic interfaces are called to run the new atomic operation sequences. Execution data is monitored to check whether performance anomalies have been completely eliminated. Simultaneously, the execution data and quality indices of upstream and downstream interfaces are monitored to ensure they are normal. If performance anomalies completely disappear and the quality indices of all basic interfaces meet the standards, the new business relationship rules are considered effective. The pending verification status is then changed to solidified, and the effective time and version number of the business relationship rules are updated.

[0150] If any anomalies persist, the conflict resolution clauses will be revisited for readjustment. Once verified, the optimized basic interface and updated business relationship rules will be compiled into a results report and returned to the external requester through the ERP system. Verification ensures the reliability of the new business relationship rules, and the solidification operation guarantees the long-term stability of the business relationship rules. The returned results allow the requester to clearly understand the optimization results, forming a complete closed loop of anomaly handling, rule updates, and result feedback. This improves the service reliability and transparency of the ERP system. Based on the returned optimization results and new business relationship rules, the requester can directly use the optimized basic interface and business relationship rules when initiating similar external requests in the future, reducing the probability of anomalies and improving the overall operating efficiency of the ERP system.

[0151] The following is an end-to-end numerical example of receiving quality index output and rule updates from an external request:

[0152] The system receives external requests to create purchase orders, extracts request metadata (business entity identifier: purchasing department; data entity identifier: purchase order table; operation instruction type: create), and extracts business feature vectors (process dependency: approval → create → payment; data interaction frequency: 50 interactions per day between the purchasing department and the warehouse department, and 30 interactions per day between the purchasing department and the finance department; resource call requirement: database write interface). It also extracts status vectors (server A: CPU utilization 0.4, memory usage 0.6, connection pool remaining ratio 0.7; server B: CPU utilization 0.2, memory usage 0.3, connection pool remaining ratio 0.9).

[0153] A relational topology graph is constructed, and initial dependencies are established based on business relationship rules to form a basic edge structure, namely, Purchasing Department → Creation → Purchase Order Table; after semantic analysis, the cosine similarity of the description texts of the Purchasing Department and the Warehouse Department after TF-IDF vectorization is 0.75 ≥ 0.6, indicating semantic association; the data interaction frequency f n =50, f max=50, the association strength R=0.6×0.75+0.4×(50 / 50)=0.85≥0.7, is marked as strong association, and undirected semantic association edges are added; after forming the initial topology graph, pruning is performed, that is, the semantic similarity between the two nodes of creating an order and generating an order under the purchasing department is 0.92≥0.85, which is determined to be functional overlap. The node of creating an order has lower resource consumption, so the node is kept and the node of generating an order is deleted; no circular dependency was found after DFS circular dependency detection; the sensitivity of the purchasing order table is medium, so there is no need to cut the reverse dependency edges; finally, an association topology graph with 4 nodes and 5 edges is obtained.

[0154] Decomposed into atomic operation sequences, after semantic conflict detection, the semantics of all nodes match the business scenario of creating a purchase order, with no semantic conflicts; after circular dependency detection, the adjacency matrix calculation shows no non-zero paths from a node to itself; after duplicate dependency detection, there are no duplicate edges; nodes are mapped to basic operation units and associated execution identifiers are added, i.e., creating a purchase order (serial) → verifying supplier information (serial) → locking inventory (serial) → generating a record to be approved (in parallel with recording the operation log) → recording the operation log; decomposed into atomic operations by field dimension, i.e. A O1 Create purchase order master record, A O2 Verify supplier qualifications, A O3 Verify supplier credit, A O4 Lock in product inventory, A O5 Generate approval process records, A O6 Record operation audit logs, sorted by A O1 →A O2 →A O3 →A O4 →A O5 / A O6 (Parallel), a total of 6 atomic operations.

[0155] After verifying and selecting the execution mode, the topology sorting traversal is performed without missing prerequisite nodes after operation dependency integrity verification; after business semantic consistency verification, the semantics of all atomic operations match the creation of purchase order scenario tags; after resource call rationality verification, A... O1 To A O5 All operations request the database write interface, with one connection requested per operation. The current system allows a maximum of 50 connections. Six operations require a total of six connections, which is less than 50, so it is reasonable. After the order constraint compliance check, the actual order is consistent with the forward dependency path, and the check passes.

[0156] Extract business requirements, A O1 To A O4 For serial identifier, A O5 With A O6 For parallel identification; high data entity consistency requirements (purchase order table); high operational dependency (strongly related edges); AO1 To A O5 Call the real-time database interface, A O6 Call the log queue interface (non-real-time); match the initial execution mode, A O1 To A O5 Satisfies serial, high-dependency, and real-time requirements, matching synchronous mode; A O6 Satisfying the requirements of parallelism, low dependency, and non-real-time operation, matching the asynchronous mode; since there is no conflict between the two, the final execution mode is determined to be a hybrid mode (A). O1 To A O5 Synchronization, A O6 asynchronous).

[0157] The service instance is assigned and designated as the purchase order creation interface (core interface, P). level =3), Supplier verification interface (important interface, P) level =2), Inventory Locking Interface (Important Interface, P) level =2), Approval Generation Interface (Important Interface, P) level =2) and the logging interface (general interface, P) level =1); Server A's resource sufficiency score R score =(1-0.4)×0.4+(1-0.6)×0.3+0.7×0.3=0.57; Server B's resource sufficiency score R score =(1-0.2)×0.4+(1-0.3)×0.3+0.9×0.3=0.8.

[0158] Calculate the service instance weights: the purchase order creation interface has a weight of W=0.6×0.57+0.4×3=1.542 on server A and W=0.6×0.8+0.4×3=1.68 on server B, so server B is selected; the supplier verification interface has a weight of W=0.6×0.57+0.4×2=1.142 on server A and W=0.6×0.8+0.4×2=1.28 on server B, so server B is selected; to avoid multiple high-resource-demand interfaces being concentrated on the same server, the inventory lock interface is assigned to server A (W=1.142, server A currently has fewer active connections); the approval generation interface is assigned to server A, and the log recording interface is assigned to server B.

[0159] Execute monitoring and anomaly detection, and execute A sequentially. O1 To A O5 (Synchronous mode), A O1 Time taken 120ms (normal), A O2 Time taken 180ms (normal), A O3 Time taken 80ms (normal), A O4 Time taken: 90ms (normal), A O5It took 150ms (normal), A O6 Asynchronous message delivery queue; monitoring execution data; supplier verification interface (corresponding to A) O2 and A O3 The response latency is 350ms, which exceeds the response latency threshold of 200ms for this interface, triggering a data anomaly; at the same time, the order constraint is checked, and the execution order of all atomic operations is consistent with the forward dependency path, so the order is compliant; if any judgment condition is triggered, it is judged as an operational anomaly.

[0160] An operational anomaly was detected, the process was immediately interrupted, and A was locked. O1 To A O3 The intermediate data, the supplier verification interface experienced a temporary response timeout, triggering a retry mechanism. It recovered after two retries, with an abnormal recovery time RT=15s. The data flow path is: Purchasing Department → Purchase Order Creation Interface → Supplier Verification Interface → Inventory Locking Interface → Financial System; Supplier Verification Interface (Important Interface, P) level =2) The execution success rate SR=0.95, the response latency LR=350ms, L max =200ms, LR>L max T score Process as 0; C exec =0.6×0.95+0.4×0=0.57; The character attribute is the data transmission interface, corresponding to the character attribute weight. w =0.8, In the data received and output by the supplier verification interface, only one record had an abnormal supplier contact information field format. The data integrity verification pass rate is 49 / 50 = 0.98, that is, the data integrity DI = 0.98. flow =0.8 × 0.98 = 0.784; Anomaly recovery time RT = 15s, RT max =60s; C impact =1-15 / 60=0.75, quality index Q=0.5×0.57+0.3×0.784+0.2×0.75=0.67.

[0161] Anomaly identification was performed. The index threshold for the data transmission interface was 0.7. The supplier verification interface quality index was 0.67 (<0.7), marking it as a candidate anomaly interface. The supplier verification interface, its upstream purchase order creation interface, and its downstream inventory locking interface formed an anomaly association group. Correlation analysis was performed. The purchase order creation interface quality index was 0.92 (normal), with no synchronous fluctuations. The inventory locking interface quality index was 0.85 (normal), with no synchronous fluctuations. The supplier verification interface itself had an abnormal response latency, which did not propagate to upstream or downstream; the anomaly propagation direction was self-origin. The supplier verification interface anomaly caused A... O2 and A O3The delay, which affected the business requirement of creating purchase orders, was identified as the root cause of the abnormal interface, i.e., the performance anomaly.

[0162] After optimizing the interface, the supplier verification interface achieved a normal success rate (0.95%) but exhibited an abnormal response latency (350ms). Resource monitoring logs revealed that the database connection pool on server B, where the interface resided, reached 90% occupancy during peak execution periods, classifying the anomaly as resource insufficiency. The optimization strategy involved configuring a database connection pool for the supplier verification interface, increasing the pool capacity from 50 to 100, and configuring a backup service instance on server A. Re-executing the atomic operation sequence reduced the supplier verification interface response latency to 120ms. Configuring a backup service instance for the optimized supplier verification interface further reduced the anomaly recovery time to RT=5s. The optimized supplier verification interface's data verification logic was enhanced, increasing the data integrity verification pass rate to 99 / 100=0.99, i.e., DI=0.99. Configuring the backup service instance reduced execution failures due to timeout retries, improving the success rate from 0.95 to 0.98. exec =0.6×0.98+0.4×(1-120 / 200)=0.748; C flow =0.8 × 0.99 = 0.792, C impact =1-5 / 60=0.917, Q=0.5×0.748+0.3×0.792+0.2×0.917=0.795, 0.795≥0.7, performance anomalies are eliminated, and the database connection pool and backup service instance with solidified configuration are established.

[0163] Perform rule verification and count the number of conflicts between the supplier verification interface and business relationship rules within 30 days. The number of conflicts is 3, which does not reach the core atomic operation conflict frequency threshold of 5. It is determined to be an occasional conflict and no business relationship rules need to be updated. The optimized basic interface configuration and operation results are returned to the requester through the ERP system.

Claims

1. A method for providing intelligent interface services for ERP systems, characterized in that: include: Receive external requests and extract request metadata, business feature vectors, and status vectors from the ERP system. Based on pre-defined business relationship rules, parse the request metadata and business feature vectors to construct an association topology graph of the external requests. After performing conflict detection on the business semantics of nodes and the operational dependencies between nodes in the associated topology graph, the associated topology graph is mapped and decomposed into atomic operation sequences. Once the atomic operation sequence passes verification, the execution mode is selected based on the business requirements of the atomic operation sequence. In conjunction with the state vector of the ERP system, a service instance is allocated to the basic interface corresponding to the execution mode through a dynamic load balancing algorithm. The resources of the ERP system are called to execute the atomic operation sequence and the execution data is monitored. If an operational anomaly is detected, the process is immediately interrupted and fault tolerance processing is initiated. At the same time, the data flow path from the source system to the target system is traced back, and the quality index of each basic interface is determined based on the data flow path and execution data. Based on data flow path analysis, performance anomalies are identified. The basic interface is optimized by combining the quality index and performance anomalies. When there is a continuous conflict between performance anomalies and business relationship rules, the business relationship rules are updated based on the execution data, and the optimization results and update results are returned to the requester.

2. The intelligent interface service method for ERP systems as described in claim 1, characterized in that, The decomposition into atomic operation sequences includes: The system detects the matching between the business semantics of each node in the associated topology graph and the business scenario parsed from the business feature vector to identify semantic conflicts, and traverses the operational dependencies between nodes to identify circular dependencies and repeated dependencies, marking conflicting nodes and conflicting dependencies. Remove conflicting nodes and adjust conflicting dependencies to process the associated topology graph. Map the processed nodes to basic operation units according to the positive dependency path. Add serial or parallel associated execution identifiers to the basic operation units based on the operation dependencies and association strength between nodes. Based on the resource call requirements retained after pruning and the reconstructed topology path, the basic operation unit is split into atomic operations according to the data entity identifier and operation instruction type. The atomic operations are then sorted into an atomic operation sequence according to the order constraints of the forward dependency path and the associated execution identifier.

3. The intelligent interface service method for ERP systems as described in claim 2, characterized in that, Constructing the associated topology graph includes: Extract the business entity identifier, data entity identifier, and operation instruction type from the request metadata, and parse the process dependency, data interaction frequency, and resource call requirements from the business feature vector; Based on pre-defined business relationship rules, initial dependencies are established between operation instruction types, data entity identifiers, and business entity identifiers to form a basic edge structure. Calculate the semantic association between different business entity identifiers based on process dependencies and data interaction frequency, in order to determine whether to add semantic association edges and mark the association strength, and form an initial topology graph; Calculate the semantic similarity of different nodes under the same business entity identifier, prune the initial topology graph based on resource call requirements, detect circular dependencies in the initial topology graph using a depth-first search algorithm, and cut reverse dependency edges according to the data sensitivity of the business entity identifier to reconstruct the topology path and obtain the associated topology graph.

4. The intelligent interface service method for ERP systems as described in claim 3, characterized in that, The allocation service instance includes: Based on the selected execution mode, the corresponding basic interfaces are defined, and the real-time resource indicators of the servers where the basic interfaces are located are extracted from the state vector of the ERP system to evaluate the resource sufficiency of each basic interface. The allocation priority of basic interfaces is determined by combining the business requirements of atomic operation sequences. Based on the dynamic load balancing algorithm, service instances are allocated to basic interfaces by combining resource sufficiency and allocation priority. The system invokes resources from the ERP system, executes atomic operation sequences sequentially based on the order constraints of the positive dependency path and associated execution identifiers, and monitors the execution data.

5. The intelligent interface service method for ERP systems as described in claim 4, characterized in that, The selected execution mode includes: Perform integrity checks on operation dependencies, consistency checks on business semantics, rationality checks on resource calls, and compliance checks on sequence constraints on atomic operation sequences. If no anomalies are found, the checks pass. Once the atomic operation sequence passes the verification, extract the business requirements of the atomic operation sequence, including the associated execution identifier of each atomic operation, data entity consistency, operation dependency strength, and resource call type. Business requirements are matched with initial execution modes based on atomic operation sequences. Initial execution modes include synchronous mode, asynchronous mode, and hybrid mode. If there are conflicting business requirements, the initial execution mode will be adjusted according to the data entity consistency priority to adapt to the resource call type and determine the final selected execution mode.

6. The intelligent interface service method for ERP systems as described in claim 5, characterized in that, The optimized basic interface includes: Associate the root cause interface corresponding to the performance anomaly with the quality index and role attributes of the root cause interface in order to locate the anomaly type of the root cause interface. Based on the type of exception, select the optimization direction for the root cause exception interface, and adjust resource allocation and backup service instances in combination with role attributes, execution mode and business relationship rules to optimize the basic interface; The optimized basic interface is incorporated into the execution flow of the atomic operation sequence, and changes in execution data and quality indices in the optimized basic interface and its upstream and downstream interfaces are monitored. If the quality index is not less than the index threshold and the performance anomalies are eliminated, the optimized basic interface will be fixed as the default interface configuration. If there are still operational anomalies, the basic interface will be optimized again and verified again.

7. The intelligent interface service method for ERP systems as described in claim 6, characterized in that, The determination of the quality index for each basic interface includes: The execution data of the atomic operation sequence is compared with the corresponding judgment threshold, and it is determined whether the execution result between each atomic operation meets the order constraint. If any judgment condition is triggered, it indicates that the operation is abnormal. Upon detecting an operational anomaly, the process is immediately interrupted and fault tolerance processing is initiated. Simultaneously, based on the associated execution identifiers of atomic operations and the call chain of basic interfaces, the data flow path from the source system to the target system is traced back. Extract the role attributes and data integrity of the basic interfaces from the data flow path, extract the execution success rate and response latency of the basic interfaces from the execution data, and extract the exception recovery time of the fault tolerance processing record; The execution success rate and response latency are correlated with execution compliance, role attributes and data integrity are correlated with workflow coordination, and the time spent on anomaly recovery is correlated with the degree of anomaly impact. A weighted sum is used to determine the quality index of each basic interface.

8. The intelligent interface service method for ERP systems as described in claim 7, characterized in that, The analysis identifies performance anomalies including: Basic interfaces with a quality index less than the index threshold are considered as candidate abnormal interfaces. Based on the interface connection relationship in the data flow path, the candidate abnormal interfaces and their upstream and downstream interfaces are divided into abnormal association groups. By analyzing the synchronous fluctuation relationship between execution success rate and response latency in the basic interfaces within the anomaly association group, as well as the transmission relationship of data integrity, the association of the anomaly association group is obtained. Based on the role attributes of the basic interfaces and the correlation of the exception association groups, analyze the direction of exception propagation and distinguish the root cause exception interfaces. Verify whether the root cause exception interfaces cause the business requirements of the atomic operation sequence to be unmet, so as to analyze and identify performance anomalies.

9. The intelligent interface service method for ERP systems as described in claim 8, characterized in that, The updated business relationship rules include: The frequency of conflicts between the root cause of the performance anomaly and the business relationship rules is counted. If the frequency of conflicts exceeds the preset frequency threshold and is associated with core atomic operations, it is determined that there is a continuous conflict. Extract the clause constraints related to the root cause exception interface from the business relationship rules, compare the execution data of the root cause exception interface with the clause constraints, and locate the clause constraints corresponding to the continuous conflict. Based on the business requirements of atomic operation sequences and the execution data of the root cause exception interface, adjust the parameters of the conflict clause constraints to update the business relationship rules. After regenerating and executing the atomic operation sequence based on the updated business relationship rules, verify whether the performance anomalies have been eliminated and whether the execution data and quality index of the upstream and downstream interfaces are normal. After verifying that there are no anomalies, solidify the business relationship rules and return the optimized basic interface and the updated business relationship rules to the requester.

10. The intelligent interface service method for ERP systems as described in claim 1, characterized in that, The immediate interruption of the process and initiation of fault tolerance processing includes: pausing unexecuted atomic operations and locking intermediate data of executed operations, and matching the corresponding fault tolerance strategy according to the exception type.

Images