An Incremental Consistency Verification Method for ERP Code Recycling Based on Association Graphs

Abstract

This invention constructs an incremental consistency verification method for ERP code recycling based on an association graph. The method includes: capturing business operation events of the ERP system and incrementally updating the association status of the ERP code association graph, while simultaneously recording change logs on both sides. It obtains codes to be evaluated, performs a recyclability assessment on the ERP code association graph based on a multi-dimensional constraint model, excludes codes with indirect active dependencies or excessive residual constraints, and obtains a set of recyclable candidate codes. Based on the change logs on both sides, it performs targeted consistency verification on the recyclable candidate code set, locates missed messages, and repairs data discrepancies. It initiates a two-stage state machine protocol for the codes, including a pre-freeze phase and an observation window. After confirming no in-transit message conflicts, it performs code release and graph node clearing. This invention can ensure data reference integrity and eventual consistency in complex environments without blocking normal business operations.

Description

Technical Field

[0001] This invention relates to the field of enterprise information technology and data processing technology, and in particular to an incremental consistency verification method for ERP code recycling based on association graphs. Background Technology

[0002] In large-scale enterprise resource planning (ERP) systems, core business codes are integrated across multiple heterogeneous business modules, including finance, materials, and projects. Over time, a large number of obsolete or idle codes consume system code segment resources and impact the retrieval efficiency of the underlying database. Safely reclaiming and releasing these code resources is crucial for maintaining data integrity in large-scale systems, reducing redundant storage overhead, and ensuring the long-term stability of the system.

[0003] Existing code reclamation schemes primarily rely on performing a full scan of all business data tables involving the code within the system to check for reference conflicts when a reclamation request is initiated. This runtime global table scan operation consumes computational and memory resources and often requires strict concurrency locks on related business tables during execution. In complex environments with tens or even hundreds of millions of data points, this operation can lead to system query delays and even prolonged business-level blocking. Furthermore, due to the complex data interaction pipelines and asynchronous messaging mechanisms between modules in modern distributed systems, relying solely on instantaneous table scans makes it difficult to accurately capture changes in related data during intermediate transmission, easily leading to underlying data state collisions at the edge of reclamation.

[0004] Existing verification methods struggle to balance computational efficiency with the eventual consistency of underlying data states when dealing with massive, high-concurrency, cross-module business scenarios, potentially leading to data disconnection or system downtime. Therefore, it is necessary to research a method that can efficiently and securely manage global data reference states without blocking core business operations. Summary of the Invention

[0005] Purpose of the invention: To provide an incremental consistency verification method for ERP code recycling based on association graphs, in order to solve one of the problems mentioned above in the existing technology.

[0006] Technical solution: An incremental consistency verification method for ERP coding recovery based on association graphs, comprising:

[0007] Capture business operation events of the ERP system, and incrementally update the association status of the ERP code association graph based on the business operation events, while simultaneously recording change logs on both sides.

[0008] The code to be evaluated is obtained from the ERP system. Based on the multi-dimensional constraint model, the recyclability of the code to be evaluated is evaluated on the ERP code association graph. Codes with indirect active dependencies or excessive residual constraints are excluded to obtain a set of recyclable candidate codes.

[0009] Based on the two-sided change log, a targeted consistency check is performed on the recyclable candidate code set to locate the missing messages and repair the data differences, thus obtaining the recyclable code set that passes the consistency check.

[0010] A two-phase state machine protocol, including a pre-freeze phase and an observation window, is initiated for the recyclable code set that has passed the consistency check. After confirming that there are no in-transit message conflicts, the codes in the recyclable code set that has passed the consistency check are released in the ERP system and the nodes in the ERP code association graph are cleared.

[0011] This includes capturing business operation events from the ERP system, incrementally updating the association status of the ERP code association graph based on these events, and synchronously recording change logs on both sides, including:

[0012] Intercept business operation events involving changes in encoding reference relationships, extract the referenced encoding identifier, the referrer business object identifier, the association type and the operation timestamp, and encapsulate them into an association change message carrying a unique message identifier;

[0013] The association change message is asynchronously delivered to the graph server, and the creation, attribute update or logical deletion of the directed edge corresponding to the association change message is performed in the ERP coding association graph.

[0014] Based on the association type, synchronously refresh the strong association in-degree cache and weak association in-degree cache corresponding to the referenced encoding identifier;

[0015] When the associated change message is successfully delivered, the delivery timestamp is recorded, and when the graph update is completed on the graph server, the consumption completion timestamp is recorded, and the two-sided change logs are aggregated.

[0016] Specifically, in the process of performing a recoverability assessment on the ERP coding association graph based on a multi-dimensional constraint model, codes with indirect active dependencies are excluded. These excluded codes include:

[0017] When there are no direct active references to the code to be evaluated, extract the predecessor business object node that points to the code to be evaluated from the ERP code association graph with weak association edges.

[0018] Probe the predecessor business object node along the weakly associated edge to assess the transitivity of the upstream strong constraint code to be evaluated;

[0019] When a significant transitive constraint caused by transitivity is determined to exist, the code to be evaluated is excluded from the set of recyclable candidate codes.

[0020] This includes probing the predecessor business object node along the weakly associated edges and assessing the transitivity of the upstream strongly constrained code to be evaluated, including:

[0021] Query the strong in-degree of the preceding business object node;

[0022] If the strong in-degree of any predecessor business object node is greater than zero, it is determined that there is a significant transitive constraint and the exploration is terminated.

[0023] When the strong in-degree of all predecessor business object nodes in the current layer is zero, extract the weakly related predecessor nodes in the previous layer and continue to explore until the preset maximum exploration depth is reached.

[0024] Among these, a recoverability assessment is performed on the codes to be evaluated based on the multi-dimensional constraint model on the ERP coding association map, excluding codes with excessive residual constraint forces, including:

[0025] Extract weak association edges pointing to the code to be evaluated from the ERP code association graph, and read the association type, source module identifier and source business object identifier of the weak association edges.

[0026] The basic semantic weights are determined based on the association type, the statutory data retention period is determined based on the source module identifier, and the status factor is determined based on the source business object identifier.

[0027] The residual constraint weights of weakly related edges are calculated based on basic semantic weights, statutory data retention period, and state factors.

[0028] Obtain the maximum value of the residual constraint weights of all weakly associated edges to be evaluated, and then obtain the aggregated residual constraint weights.

[0029] When the aggregated residual constraint weight is greater than or equal to the preset recyclability threshold, the residual constraint force of the code to be evaluated is determined to be excessive, and the code to be evaluated is excluded from the set of recyclable candidate codes.

[0030] The residual constraint weights for weakly related edges, calculated based on basic semantic weights, statutory data retention period, and state factors, include:

[0031] Calculate the time decay factor based on the business creation time corresponding to the source business object identifier and the statutory data retention period;

[0032] The residual constraint weights are obtained by multiplying the basic semantic weights, the time decay factor, and the state factor.

[0033] Specifically, based on the two-sided change logs, a directed consistency check is performed on the recyclable candidate code set to locate any missed messages and repair data differences, resulting in a recyclable code set that passes the consistency check, including:

[0034] Log records for each code to be evaluated in the set of recyclable candidate codes are extracted from the business-side logs and graph-side logs contained in the dual-side change logs.

[0035] Extract the first message identifier set from the business side logs, and extract the second message identifier set from the graph side logs;

[0036] Using the first message identifier set as a reference, calculate the one-way difference set relative to the second message identifier set;

[0037] When the one-way difference set is not empty, the elements contained in the one-way difference set are positioned as the missing message identifiers of the corresponding missing messages;

[0038] Query the source association snapshot of the code to be evaluated in the business data source, compare it with the ERP code association graph and perform missing association edge filling and repair;

[0039] After the rewrite and repair are completed or the one-way difference set is empty, the corresponding code to be evaluated will be imported into the set of recyclable codes that have passed the consistency check.

[0040] In the two-phase state machine protocol that includes a pre-freeze phase and an observation window, the pre-freeze phase includes:

[0041] In the ERP coding association graph, the status of each code to be evaluated in the set of recyclable codes that have passed the consistency check is changed to the graph frozen state;

[0042] In the ERP system, a local freeze control record is written for the code to be evaluated to intercept new reference operations for the code to be evaluated.

[0043] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer program, and the computer program is configured to execute the above-described incremental consistency verification method for ERP encoding recovery based on association graphs when it is run.

[0044] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the above-described incremental consistency verification method for ERP encoding recovery based on association graph through the computer program.

[0045] Beneficial Effects: This solution employs event-driven incremental association graph construction and targeted comparison based on log set difference operations. This approach transforms time-consuming global traversal into asynchronous incremental maintenance and targeted gap repair, removing the concurrency lock restrictions on the underlying business database during the verification process. It reduces time overhead from massive traversal levels to constant-level cache reads and local incremental comparisons, resolving the system blocking and low computational efficiency issues caused by relying on full table scan verification. It ensures data reference integrity and eventual consistency in complex environments without blocking normal business operations. Attached Figure Description

[0046] Figure 1 This is a flowchart illustrating the incremental construction process of the encoded association map in this embodiment of the application.

[0047] Figure 2 This is a flowchart illustrating the steps involved in performing a recyclability assessment of the code to be evaluated on the ERP coding association graph based on a multi-dimensional constraint model, as described in this application embodiment.

[0048] Figure 3 This is a flowchart illustrating the steps involved in performing a recyclability assessment of the code to be evaluated on the ERP coding association graph based on a multi-dimensional constraint model, as described in this application embodiment.

[0049] Figure 4 This is a flowchart of the pre-freezing stage steps in an embodiment of this application. Detailed Implementation

[0050] Example 1, such as Figure 1 As shown, this embodiment elaborates on the incremental construction process of the coded association graph and the basic operating framework of the directional consistency verification mechanism based on the change log.

[0051] Step 101: Capture business operation events of the ERP system, and incrementally update the association status of the ERP code association graph based on the business operation events, while simultaneously recording change logs on both sides.

[0052] Specifically, this embodiment establishes the system's data input and underlying graph maintenance mechanism. The Enterprise Resource Planning (ERP) system encompasses multiple business modules, including finance, cost control, materials management, and equipment management. Business operation events refer to actions such as document creation, modification, cancellation, or voiding that occur within these modules. By capturing these actions, the system can perceive changes in business data in real time, driving updates to the ERP code association graph. The ERP code association graph is stored using a directed graph structure, where nodes represent codes or business documents, and directed edges represent reference relationships. Dual-sided change logs are used to anchor the data processing time nodes on both the business source side and the graph consumption side, providing a logistical record for subsequent consistency checks.

[0053] Step 101a: Capture business operation events of the ERP system, and incrementally update the association status of the ERP code association graph based on the business operation events, and synchronously record change logs on both sides. Specifically, this includes: intercepting business operation events involving changes in code reference relationships, extracting the referenced code identifier, the referrer business object identifier, the association type and operation timestamp, and encapsulating them into an association change message carrying a unique message identifier.

[0054] In this embodiment, the interception operation can be implemented by deploying enhanced code at the standard business exit of the Enterprise Resource Planning (ERP) system, such as using user exit technology or business add-in technology. When the system detects an event triggered before a database write operation, it automatically extracts fields from the context. The referenced code identifier can be a specific work breakdown structure (WBS) code, and the referrer business object identifier can be a specific purchase order number. To ensure the unique traceability of data during asynchronous transmission, the system generates a universally unique identifier as a unique message identifier and encapsulates all extracted fields into a structured associated change message. The data structure of this message can adopt Extensible Markup Language (Extreme Markup Language) format or JavaScript Object Notation (SIN) format.

[0055] Step 101b: Asynchronously deliver the association change message to the graph server, and perform the creation, attribute update, or logical deletion of the directed edge corresponding to the association change message in the ERP coded association graph.

[0056] Furthermore, the aforementioned asynchronous delivery process relies on distributed message queue middleware, such as a high-throughput distributed stream processing platform. To ensure that change operations for the same code are processed in chronological order, the system uses the referenced code identifier as the partition key for the distributed message queue. The graph server can specifically employ a streamlined graph database system. After the server consumes messages in sequence, if the business action is to add a reference, a directed edge is created from the referrer's business object node to the referenced code node; if the business action is to remove a reference, no physical deletion is performed, but the corresponding directed edge is marked as logically deleted, preserving a complete historical traceability data link.

[0057] Step 101c: Based on the association type, synchronously refresh the strong association in-degree cache and weak association in-degree cache corresponding to the referenced encoding identifier.

[0058] Specifically, the strong-association in-degree cache records the number of times the current code is referenced by core active business documents, while the weak-association in-degree cache records the number of times it is referenced by historical snapshots or loose business documents. After a directed edge is written or its state is updated, the graph server identifies whether the current change is a strong or weak association based on a predefined association type hierarchy mapping table, and increments or decrements the corresponding cache count using atomic accumulation operations. By maintaining these two types of caches in memory, the high-overhead adjacency matrix traversal calculation can be avoided during subsequent reclaimability assessments, reducing the computational time complexity to constant levels.

[0059] Step 101d: Record the delivery timestamp when the associated change message is successfully delivered, and record the consumption completion timestamp when the graph update is completed on the graph server, and collect and generate a two-sided change log.

[0060] Accordingly, the dual-side change logs specifically include business-side logs generated at the business source and graph-side logs generated by the graph server. The delivery timestamp is recorded in the business-side log, indicating that the change event has successfully entered the transmission pipeline; the consumption completion timestamp is recorded in the graph-side log, indicating that the graph node's state has reached the latest consistency. The system uses the referenced code identifier as the primary key for table creation in both logs, supporting fast targeted retrieval and processing of records by code dimension.

[0061] Step 102: Obtain the code to be evaluated from the ERP system, perform a recyclability evaluation on the ERP code association graph based on the multi-dimensional constraint model, exclude codes with indirect active dependencies or excessive residual constraints, and obtain a set of recyclable candidate codes.

[0062] In this embodiment, the codes to be evaluated are typically imported in batches by the system administrator or generated by a system scheduled task. The multi-dimensional constraint model, by analyzing the well-maintained strong-association in-degree cache and weak-association in-degree cache, combined with predecessor node path exploration in the graph, can identify codes that appear to have no business attachments but are actually indirectly locked by complex business chains. After filtering out such codes that do not meet the conditions for safe reclamation, the remaining safe codes constitute the set of reclaimable candidate codes, which proceed to the next data comparison stage. The specific calculation formulas and attenuation evaluation algorithms of the multi-dimensional constraint model will be explained in detail in subsequent specific embodiments.

[0063] Step 103: Perform a directed consistency check on the recyclable candidate code set based on the two-sided change logs, locate the missing messages and repair the data differences, and obtain the recyclable code set that has passed the consistency check.

[0064] Optionally, this embodiment eliminates asynchronous data inconsistencies caused by network transmission delays or middleware queue congestion. Instead of performing a full table scan of the underlying business tables, the system uses an established index to selectively extract the processing pipeline records at both ends of the transmission pipeline for codes that have entered the candidate set. By comparing the pipeline records on both sides, lost or stalled data update instructions are identified, and targeted repairs are performed within the independent local scope of the code, resulting in a recyclable code set that has passed the final, confirmed, and secure consistency check.

[0065] Optionally, a targeted consistency check is performed on the recyclable candidate code set based on the two-sided change logs to locate any missed messages and repair data differences, resulting in a recyclable code set that passes the consistency check, specifically including:

[0066] Step 103a: Extract the log records of each code to be evaluated from the set of recyclable candidate codes contained in the business-side logs and the graph-side logs.

[0067] Specifically, for any code to be evaluated in the recyclable candidate code set, the system uses its corresponding identifier as the search keyword. It queries all transmission records under that identifier in the business-side logs and simultaneously queries the consumption records under that identifier in the graph-side logs. This on-demand, targeted extraction method reduces memory usage and input / output overhead in the verification process.

[0068] Step 103b: Extract the first message identifier set from the business side logs and extract the second message identifier set from the graph side logs.

[0069] The first message identifier set represents the complete set of unique IDs for all change instructions actually generated by the business operation, while the second message identifier set represents the set of unique IDs for change instructions executed by the graph database. All elements in the sets are universally unique identifiers.

[0070] Step 103c: Using the first message identifier set as a reference, calculate the one-way difference set relative to the second message identifier set.

[0071] In this embodiment, the physical meaning of a one-way difference set is the set of elements that exist in the first message identifier set but are missing from the second message identifier set. In an optional implementation, a hash table mapping algorithm can be used to perform the difference set calculation. For example, assuming that the first message identifier set contains 3 identifiers and the second message identifier set contains only 2 of them, the remaining 1 message identifier that was not successfully consumed by the graph end can be obtained through the one-way difference set operation.

[0072] Step 103d: When the one-way difference set is not empty, locate the elements contained in the one-way difference set as the missing message identifiers of the corresponding missing messages.

[0073] The one-way difference set is non-empty, meaning that an entity change occurred on the business side, but the change instruction was lost or has not yet arrived during the asynchronous process. Based on this, the system extracts the element that caused the inconsistency and marks it as a missed message identifier, providing a unique target credential for subsequent source tracing and targeted repair.

[0074] Step 103e: Query the source association snapshot of the code to be evaluated in the business data source, compare it with the ERP code association graph and perform missing association edge filling and repair.

[0075] Furthermore, based on the aforementioned missing message identifier, the system initiates a relational query to the underlying database to obtain the current set of all reference relationship states for the code to be evaluated, i.e., the source association snapshot. This source association snapshot is then compared line by line with the node association edge information stored in the graph server. If a reference edge exists in the source association snapshot but is missing in the graph, an incremental write operation is triggered in the graph, and the count values ​​of the strong and weak association in-degree caches are simultaneously corrected, thereby achieving consistency between the business foundation and the graph appearance.

[0076] Step 103f: After the rewrite and repair are completed or the one-way difference set is empty, the corresponding code to be evaluated is imported into the set of recyclable codes that have passed the consistency check.

[0077] Based on this, if the one-way difference set is empty, it indicates that the asynchronous data link of the encoding is synchronized without omissions, and the data is allowed to pass. If a rewrite repair has been performed, the system will allow the data to pass again after confirming that the map data has been successfully updated. The encoding set collected through this funnel mechanism ensures that the map's recyclable state is a data mapping with no delay before entering the physical release phase.

[0078] Step 104: Start a two-stage state machine protocol, which includes a pre-freeze phase and an observation window, for the recyclable code set that has passed the consistency check. After confirming that there are no in-transit message conflicts, release the codes in the recyclable code set that has passed the consistency check in the ERP system and clear the nodes in the ERP code association graph.

[0079] In this embodiment, the two-phase state machine protocol prevents collisions between the moment the code is physically reclaimed and concurrently generated new business operations. The pre-freeze phase cuts off the source of new business variables from the time dimension by setting control barriers at both ends of the system to prevent the establishment of new references. The observation window provides a time buffer for computation, specifically for waiting for and processing in-transit instructions that were issued before the freeze barrier took effect but are queued in the message pipeline. After double security isolation filtering, the system finally releases the code segment in the master data dictionary and physically erases the corresponding graph node on the graph side. The calculation method for the underlying freeze timing and time buffer of the two-phase state machine protocol will be described in detail in subsequent specific embodiments.

[0080] Example 2: This example details how, during multi-dimensional constraint evaluation, indirect active dependencies are identified through backward probing along the graph. Optionally, as... Figure 2 As shown, in the process of performing a recoverability assessment on the ERP coding association graph based on a multi-dimensional constraint model, codes with indirect active dependencies are excluded. Specifically, the excluded codes include:

[0081] Step 201: When there is no direct active reference to the code to be evaluated, extract the predecessor business object node from the ERP code association graph that points to the code to be evaluated with weak association edges.

[0082] Specifically, "no direct active references" refers to a state where the system reads the strong association in-degree cache and determines that the strong association in-degree of the target code is zero. In this state, although the target code is not occupied by active documents such as executing purchase orders or outstanding financial vouchers, indirect dependencies may still exist due to the chain structure of business documents in the system architecture. A predecessor business object node refers to a business entity upstream of the target code node in the directed graph structure. By parsing the directed edge attributes, which include the start node, end node, and association type, the system can locate all upstream sources that have weak references to the code to be evaluated.

[0083] In some alternative implementations, the extraction of predecessor business object nodes can rely on the local adjacency list query mechanism of the graph database. The system queries all incoming edges using the unique identifier of the code to be evaluated as an index, and filters out connections that do not belong to the weak association type according to a predefined dictionary, generating a first-level predecessor set containing several predecessor node identifiers.

[0084] Step 202: Probe the predecessor business object node in reverse along the weakly associated edge to assess the transitivity of the upstream strong constraint code to be evaluated.

[0085] In this embodiment, backward probing is a bottom-up graph traversal operation. Transitivity is used to describe cascading dependencies in business logic. For example, an archived sales order references a material code via a weakly linked edge, and this sales order is referenced by an active after-sales service order via a strongly linked edge. In this type of structure, the business constraints carried by the active after-sales service order will be passed downstream along the document traceability link to the material code. Evaluating transitivity involves calculating or determining whether such indirect constraints spanning multiple network nodes have the effect of preventing code retrieval.

[0086] Step 203: When it is determined that there is a significant transitive constraint caused by transitivity, the code to be evaluated is excluded from the set of recyclable candidate codes.

[0087] Specifically, a significant transitive constraint indicates that the strength of the constraint signal transmitted from upstream exceeds the system's allowable tolerance boundary. Removing this code from the candidate set can prevent upstream document access anomalies caused by missing related objects in the data base.

[0088] As a basic implementation of the above steps, the system provides a binary decision mechanism based on breadth-first traversal. Optionally, it explores the predecessor business object node along weakly related edges to evaluate the transitivity of the upstream strongly constrained code to be evaluated, specifically including:

[0089] Optionally, query the strong in-degree of the predecessor business object node.

[0090] Specifically, at each layer of the reverse probing, the system sends a request to the cache interface maintained in memory to obtain the strong in-degree value of all predecessor business object nodes in the current layer. This value reflects the number of active business operations carried by the corresponding node at the current moment.

[0091] Optionally, if the strong in-degree of any predecessor business object node is greater than zero, it is determined that there is a significant transitive constraint and the exploration is terminated.

[0092] In this embodiment, the system outputs a Boolean value of true as soon as any node with a strong in-degree correlation is found on the traversal path. This decision logic has low computational overhead and is suitable for simple resource planning systems with strict requirements for business integrity and short correlation links.

[0093] Optionally, when the strong in-degree of all predecessor business object nodes in the current layer is zero, the weakly related predecessor nodes in the previous layer are extracted and explored until the preset maximum exploration depth is reached.

[0094] The preset maximum exploration depth is a hard protection mechanism for the system's computing resources, used to prevent infinite loops caused by loops or excessively long links in the graph structure. In a conventional enterprise resource planning system, the preset maximum exploration depth is set to 3 in this embodiment. Once the traversal level reaches this upper limit, the system will stop extracting nodes from the previous level and output a conservative judgment indicating the existence of significant transitive constraints.

[0095] This embodiment provides a preferred implementation based on a computational propagation model, which involves probing the predecessor business object node along weakly associated edges to evaluate the transitivity of the upstream strongly constrained code to be evaluated. This is achieved through the following method:

[0096] Optionally, based on the association type of the weakly associated edge, a pre-configured constraint transmission coefficient is obtained, and the cumulative path transmission coefficient from the predecessor business object node to the code to be evaluated is calculated based on the constraint transmission coefficient.

[0097] Specifically, different types of weakly correlated edges have varying propagation capabilities for constraint signals. The system maintains a mapping table that maps semantically tight association types, such as cross-module reference associations, to higher propagation coefficients, for example, a value of 0.8; and semantically loose association types, such as historical snapshot associations, to lower propagation coefficients, for example, a value of 0.2. For a propagation path traversing multiple consecutive weakly correlated edges, the system multiplies the constraint propagation coefficients of each edge along the path to obtain the cumulative propagation coefficient, which is used to calculate the signal attenuation level along that specific path.

[0098] Optionally, the strong correlation in-degree of the predecessor business object node is queried, and the strong correlation in-degree is saturated and mapped using a preset normalization constant to obtain the strength factor, where the strength factor is the ratio of the strong correlation in-degree to the sum of the strong correlation in-degree and the normalization constant.

[0099] In this embodiment, using strong correlation in-degree can lead to excessively large numerical differences. Using saturation mapping can unify and converge them to a dimensionless interval between 0 and 1. The specific calculation formula is as follows:

[0100] F strength =N strong / (N strong +K norm );

[0101] Among them, F strength N is the intensity factor. strong K represents the strong in-degree of the predecessor business object node. norm This is a preset normalization constant.

[0102] Specifically, a preset normalization constant is used to control the saturation rate of the mapping curve. In this embodiment, the preset normalization constant is set to 3. When the strong correlation in-degree is 1, substituting the normalization constant of 3, the calculated intensity factor is 0.25; when the strong correlation in-degree approaches infinity, the intensity factor approaches 1.0. Through this fractional calculation, the dimensional conflict between source intensity and path attenuation is decoupled.

[0103] Optionally, the intensity factor can be multiplied by the path cumulative transmission coefficient to obtain the constraint influence of the predecessor business object node on the predecessor node to be evaluated.

[0104] Specifically, the system uses the intensity factor calculated above as the initial constraint force source, multiplies it by the path cumulative transmission coefficient representing the attenuation ratio, and calculates the degree of residual constraint influence of a single reverse reachable path on the target encoding.

[0105] Optionally, the maximum value of the constraint influence of the predecessor node on all reachable paths can be obtained as the global propagated constraint influence.

[0106] Furthermore, when there are multiple reverse reachable paths to the target code, the system does not use a summation method, but instead extracts the maximum value among all path calculation results as a global metric, which conforms to the objective law in business that the strongest constraint path dominates the judgment result.

[0107] Optionally, a significant transitive constraint is determined to exist when the global transitive constraint influence is greater than or equal to a preset transitive constraint significance threshold.

[0108] The preset transitive constraint significance threshold is a tolerance parameter that can be adjusted by business personnel. In this embodiment, the preset transitive constraint significance threshold is set to 0.15. To provide a simplified dimensionless normalized example, assume that a predecessor node is currently being explored, with a strong correlation in-degree of 2 and a preset normalization constant of 3. The current path consists of a weakly correlated edge with a transmission coefficient of 0.5. The strength factor is calculated to be 2 / (2+3)=0.4. Multiplying this by the transmission coefficient, the influence of the predecessor node constraint is 0.4*0.5=0.2. If the preset transitive constraint significance threshold is 0.15, since 0.2≥0.15, the system can trigger a judgment after comparison, outputting the result of significant transitive constraint, and preventing unsafe recycling actions.

[0109] Building upon this, to avoid computational overload caused by the propagation model in large-scale dense graphs, an adaptive propagation pruning mechanism is provided. After calculating the cumulative propagation coefficient of the path from the predecessor business object node to the code to be evaluated based on the constraint propagation coefficient, it also includes:

[0110] Optionally, the path cumulative conduction coefficient can be compared with a preset minimum effective conduction threshold.

[0111] Specifically, during the process of extracting predecessor nodes layer by layer and calculating the cumulative product, the system monitors the attenuation of the path cumulative conduction coefficient in real time. The preset minimum effective conduction threshold characterizes the physical boundary at which the system considers the constraint signal to have dissipated. In this embodiment, the preset minimum effective conduction threshold is set to 0.02.

[0112] Optionally, when the cumulative path propagation coefficient is less than the minimum effective propagation threshold, a propagation pruning mechanism is triggered to terminate the continued exploration operation along the current direction and prevent the previous layer node in the current direction from being added to the next layer of the inspection set.

[0113] In this embodiment, once a path passes through multiple semantically loose edges with a propagation coefficient of 0.2, its cumulative product will rapidly decay to below the minimum effective propagation threshold. After the condition is met, the system discards the exploration task on that branch and no longer generates database query operations.

[0114] Example 3: This example details how, during the recyclability assessment phase, for codes to be evaluated that lack indirect active dependencies, the residual constraint force of weakly associated edges is calculated using a multi-factor decay model. Optionally, as... Figure 3 As shown, based on a multi-dimensional constraint model, a recoverability assessment is performed on the codes to be evaluated on the ERP coding association map, excluding codes with excessive residual constraints. Specifically, this includes:

[0115] Step 301: Extract weak association edges pointing to the code to be evaluated from the ERP code association graph, and read the association type, source module identifier and source business object identifier of the weak association edges.

[0116] Specifically, weakly related edges refer to directed edges in an Enterprise Resource Planning (ERP) system that represent non-core or completed business relationships. The system traverses the ERP coding relationship graph, locates all incoming edges with the node to be evaluated as its terminal node, and uses a pre-defined attribute filter to remove strongly related edges, retaining the target edge set. The system analyzes the edge attribute fields stored in the graph database to obtain the relationship type (characterizing the connection nature), the source module identifier (for tracing the business origin), and the source business object identifier (for locating specific documents). These three fields constitute the input feature tuple for subsequent calculation of the attenuation weight.

[0117] Step 302: Determine the basic semantic weight based on the association type, determine the statutory data retention period based on the source module identifier, and determine the status factor based on the source business object identifier.

[0118] In this embodiment, the system completes the aforementioned feature transformation by querying a pre-configured mapping table. The basic semantic weight reflects the inherent constraint strength of different association types in business logic. The basic semantic weight corresponding to cross-module reference associations is higher than that corresponding to historical snapshot associations.

[0119] In one optional implementation, when the associated type read by the system fails to match any record in the mapping table, the system executes a missing data degradation strategy, forcibly setting the basic semantic weight to the maximum allowed value of 1.0 within the mapping table, and outputting a type missing alarm log to prevent the constraint of unknown associated types from being incorrectly underestimated. The statutory data retention period is set according to the compliance requirements of each business module, representing the minimum time for data to be fully retained in the system. The status factor reflects the degree to which the source business document is currently out of active processes.

[0120] Step 303: Calculate the residual constraint weights of weakly related edges based on basic semantic weights, statutory data retention period, and state factors.

[0121] Specifically, the above calculation process integrates discrete attribute features into continuous computational metrics. The residual constraint weights reflect the degree to which the weakly correlated edge maintains its business binding to the target encoding after considering time decay and state evolution.

[0122] Step 304: Obtain the maximum value of the residual constraint weights of all weakly related edges to be evaluated, and obtain the aggregated residual constraint weights.

[0123] Furthermore, the system collects the residual constraint weights of all weakly related edges pointing to the same code to be evaluated and performs a maximum value operation, rather than a summation or average operation. This operation logic follows the principle of strongest constraint determination, that is, as long as there is a weakly related edge with residual constraint weights, the overall unrecoverability of the code is established. In addition, if no weakly related edges are extracted after traversal of a code to be evaluated, the system will import the code to be evaluated into the pass-through set, bypassing the current maximum value calculation step to prevent program exceptions caused by executing the value function on the empty set. The codes to be evaluated in the pass-through set have no residual constraints because they do not have weakly related edges, and are merged into the set of recoverable candidate codes. They are then merged with the codes that are determined to be recoverable after comparison with residual constraint weights and enter the subsequent directional consistency verification stage.

[0124] Step 305: When the aggregated residual constraint weight is greater than or equal to the preset recyclability threshold, it is determined that the residual constraint force of the code to be evaluated exceeds the limit, and the code to be evaluated is excluded from the recyclable candidate code set.

[0125] In this embodiment, the preset recyclability threshold is set to 0.15. The system compares the calculated aggregate residual constraint weight with the preset recyclability threshold. If the value is greater than or equal to the preset recyclability threshold, it indicates that the code is still subject to non-negligible business restrictions. Based on the determination result, the system generates an exclusion instruction, cutting off its path to subsequent data comparison and physical release processes.

[0126] As a basic implementation of the above steps, the system provides residual constraint weights for weakly related edges based on basic semantic weights, statutory data retention periods, and state factors, specifically including:

[0127] Optionally, a time decay factor is calculated based on the business creation time corresponding to the source business object identifier and the statutory data retention period.

[0128] In this basic scheme, the system queries the underlying business data table to obtain the system timestamp of the original business object when it was initially created. By calculating the time difference between the current system time and the business creation time, and then combining this with a linear decay function, a time decay factor is derived. Specifically, the time decay factor decreases linearly as the difference between the current system time and the business creation time increases. Those skilled in the art can use the legally mandated data retention period as a time benchmark and employ a conventional linear decay function to determine the specific value of the time decay factor.

[0129] Optionally, the residual constraint weights can be obtained by multiplying the basic semantic weights, the time decay factor, and the state factor.

[0130] The system performs a multiplication operation on the above three factors to obtain the residual constraint weights. To further strengthen the binding guarantee capability of the statutory data retention period on the evaluation results, this embodiment provides a preferred implementation method based on the compliance-gated segmented decay model. The residual constraint weights of weakly correlated edges are calculated based on the basic semantic weights, the statutory data retention period, and the state factor, which is achieved in the following way:

[0131] Optionally, obtain the time interval since the business object corresponding to the source business object identifier left the inactive state until now.

[0132] The system retrieves the timestamp of the last business state change for the source business object using its identifier; this timestamp is the deactivation timestamp. The deactivation time interval is obtained by subtracting this timestamp from the current time. Using the deactivation time interval instead of the business creation time ensures that the starting point of the decay calculation is strictly aligned with the end of the business lifecycle.

[0133] Optionally, when the deactivation interval is less than or equal to the statutory data retention period, a compliance lockout phase is triggered, and the residual constraint weight is set to be equal to the basic semantic weight.

[0134] In this embodiment, the statutory data retention period acts as a hard gating condition. When the comparison determines that the source business object has not yet expired, the system cuts off the intervention paths of the state factor and time decay factor on the final calculation result. At this time, the residual constraint weights inherit the values ​​of the basic semantic weights. Since the values ​​of the basic semantic weights are all much greater than the preset recyclability threshold, this compliance locking mechanism can prevent the misjudgment and reclamation of non-expired data from the underlying algorithm structure.

[0135] Optionally, when the deactivation interval is greater than the statutory data retention period, a multi-factor decay stage is triggered. The proportion of the deactivation interval exceeding the statutory data retention period is used as the independent variable. The time decay factor is calculated using a pre-configured decay rate constant according to a negative exponential law. The basic semantic weight, the time decay factor, and the state factor are multiplied to obtain the residual constraint weight.

[0136] Once the legally mandated data retention period is exceeded, compliance protection gating is activated, and the system introduces a non-linear accelerated decay calculation. The specific calculation formula is as follows:

[0137] α=exp(-λ*max(0,(Δt-T ret ) / T ret Where α is the time decay factor, λ is the pre-configured decay rate constant, Δt is the deactivation time interval, and T is the time interval. ret The statutory data retention period is defined as exp, which is an exponential function with the natural constant as its base, and max is a function that takes the maximum value.

[0138] To prevent temporary business modules without configured retention periods from triggering program exceptions during operation, the system adds protection rules to the pre-judgment logic. ret When the value equals 0, the ratio term in the formula is set to its maximum value, causing the time decay factor to converge to 0. At the instant the gating is activated, the state factor re-enters the system through multiplication, resulting in discontinuous numerical jumps in the final output residual constraint weights, reflecting the instantaneous presentation of the actual decay state of the business after the compliance protection is lifted.

[0139] Optionally, regarding the specific value mapping method for the state factors introduced by the product operation, the state factors are determined based on the source business object identifier, specifically including:

[0140] Optionally, query the current lifecycle status of the business document corresponding to the source business object identifier.

[0141] The system reads the status indicator field from the business master data table to identify whether the document is in an in-process state that can be modified or in a read-only completed state.

[0142] Optionally, based on a preset state decay mapping relationship, when the lifecycle state is an active state, the state factor is set to a constant 1.

[0143] A constant value of 1 indicates that no reduction in the binding force is applied. An active status indicates that the business document is still generating business impact, and the associated signals it emits have full binding force.

[0144] Optionally, when the lifecycle state is archived, the state factor is set to a preset first decay coefficient.

[0145] Optionally, when the lifecycle state is closed, the state factor is set to a preset second attenuation coefficient, wherein the constant 1, the first attenuation coefficient, and the second attenuation coefficient are monotonically decreasing.

[0146] To demonstrate the data flow of multi-factor composite calculations, a simplified dimensionless example is provided. Assume the basic semantic weight is 0.8, the statutory data retention period is 5, and the deactivation interval is 10. The current state is archived. The preset first decay coefficient is 0.5, the preset second decay coefficient is 0.1, and the decay rate constant is 0.1. Calculate the overdue ratio, obtaining (10-5) / 5=1.0. Substituting into the formula, the time decay factor is exp(-0.1*1.0)≈0.90. Based on the monotonically decreasing relationship constraint 1.0>0.5>0.1>0, the current state factor takes the first decay coefficient of 0.5. The system performs a multiplication operation 0.8*0.90*0.5, finally obtaining a residual constraint weight of 0.36. Since 0.36 is greater than the recyclability threshold of 0.15, it is determined that the weakly related edge still has a constraint, and the encoded node is retained.

[0147] Example 4: This example details a two-phase state machine protocol for isolating concurrent business writes and processing in-transit messages in an asynchronous data architecture. Optionally, as... Figure 4 As shown, in the two-phase state machine protocol that includes a pre-freeze phase and an observation window, the pre-freeze phase includes:

[0148] Step 401: In the ERP coding association graph, change the status of each code to be evaluated in the set of recyclable codes that have passed the consistency check to the graph frozen state.

[0149] Step 402: In the ERP system, write the local freeze control record for the code to be evaluated to intercept new reference operations for the code to be evaluated.

[0150] Specifically, the above steps construct a distributed consistency barrier across the system. Due to physical isolation and network transmission latency between the Enterprise Resource Planning (ERP) system and the graph server, data collisions may occur when new associations are created on the business side during the execution of physical deletion of codes. The system separates the normal business write sequence and the background recycling and release sequence on the timeline by registering freeze flags at both ends. When a business operation attempts to reference a code within the coverage of a freeze control record in a document row, the pre-validation logic will prevent the operation and return an interrupt signal.

[0151] Furthermore, when the graph consumer receives an association change message pointing to a node in the graph's frozen state, it does not perform the usual edge write operation. Instead, it completely transfers the message to the frozen period arrival message temporary storage table and marks it as temporary in the graph-side change log for subsequent reading and verification during the observation window.

[0152] Optionally, as a basic implementation of double-end freezing, the system provides a graph-first freezing sequence, and the pre-freezing phase is performed in the following manner:

[0153] Optionally, the map freeze status can be updated in the ERP coding association map, and the map freeze timestamp can be recorded.

[0154] Optionally, a freeze control record can be written to the ERP system, and the timestamp of the control record being written can be obtained.

[0155] Optionally, in the business-side logs, retrieve the time window between the map freeze timestamp and the control record write timestamp.

[0156] Optionally, if a new associated change message involving the code to be evaluated exists within the time window, roll back the map freeze status and freeze control records.

[0157] In this embodiment, since the freezing operation of the graph node occurs before the writing operation of the business-side control record, business operations can still freely create new references to the code during the time gap between the completion of the graph freezing and the effective business interception. Because the timestamp of such new references is later than the graph freezing timestamp, they cannot be captured by subsequent regular in-transit message detection logic. Therefore, the system performs gap message supplementation by retrieving business-side logs. If a missing new association change message is found within the time window, the system determines that the atomicity of the double-ended freezing has been violated and immediately triggers a state rollback instruction, reverting the code to be evaluated to the next evaluation cycle.

[0158] Alternatively, as an alternative to the above-mentioned basic solution, a preferred source-first double-end freezing implementation method is provided to cut off gap vulnerabilities from the physical and logical level. The pre-freezing stage is performed in the following manner:

[0159] Optionally, a freeze control record is written to the ERP system to activate the interception logic for new reference operations on the code to be evaluated, and the timestamp of the control record being written is recorded.

[0160] Optionally, the status of the code to be evaluated can be changed to the map frozen status based on the condition update mechanism in the ERP code association map, and the map frozen timestamp can be recorded.

[0161] Optionally, if the map freeze status update fails, the freeze control record in the ERP system can be revoked.

[0162] Specifically, this reverse order operation shifts the time gap from the change-generating source to the change-consuming end. The business system's pre-verification is activated the instant the record control record is written to the timestamp, cutting off the path to subsequent new references. During this gap, since the source is cut off, the graph consumer only processes legitimate historical messages generated before the freeze. A conditional update mechanism ensures concurrency safety, allowing the overwrite of the graph's frozen state only when the graph node is in a normal active state. If the graph write fails, the system performs a one-way rollback, updating the record status in the enterprise resource planning system to "revoked."

[0163] Optionally, after completing any of the above-mentioned double-ended pre-freezing, the system enters an observation window period for digesting the data remaining in the asynchronous pipeline, and initiates a two-phase state machine protocol that includes the pre-freezing phase and the observation window period. The observation window period includes:

[0164] Optionally, the pre-configured maximum message production latency, maximum message queue retention time, maximum message consumption processing latency, and safety margin are obtained. The maximum message production latency, maximum message queue retention time, maximum message consumption processing latency, and safety margin are added together to obtain the duration of the observation window.

[0165] In this step, the duration of the observation window is determined by the superposition of the extreme values ​​of various physical transmission delay parameters in the system. The specific calculation formula is as follows:

[0166] T obs =T prod +T queue +T consume +T margin ;

[0167] Among them, T obs To observe the duration of the window, T prod For the maximum delay in message production, T queue T represents the maximum retention time of the message queue. consume T represents the maximum processing latency for message consumption. marginFor safety margin, by accumulating the longest end-to-end time of the system, the system can calculate a deterministic time boundary.

[0168] Optionally, during the duration of the observation window, unconsumed change messages involving codes to be evaluated and whose operation timestamps are earlier than the freeze timestamps recorded in the pre-freeze phase are continuously monitored, and the monitored unconsumed change messages are determined to be messages in transit.

[0169] Specifically, the system scans the message queue and the consumption logs of the graph server at fixed polling intervals. Unconsumed change messages must simultaneously meet three criteria: the target field carried in the message body matches the code to be evaluated; the operation timestamp is earlier than the freeze timestamp recorded in the pre-freeze phase; the corresponding control record write timestamp exists in the source-first scheme; the corresponding graph freeze timestamp exists in the graph-first scheme; and there is no corresponding consumption completion timestamp on the graph side. When all three conditions are met, the message is defined as an in-transit message, indicating that the graph data has not yet converged to the business state at the time of freeze.

[0170] Optionally, if no messages in transit are detected for an extended period of time during the observation window, and it is confirmed that there are no conflicts in transit messages, the steps of releasing the codes in the recyclable code set that have passed the consistency check in the ERP system and clearing the nodes in the ERP code association graph are triggered.

[0171] When the system runtime exceeds the boundary time calculated by the formula, and the above three monitoring conditions are not triggered simultaneously, the system obtains a final convergence confirmation command, proving that all historical commands belonging to the code to be evaluated within the pipeline have been cleared. The code identifier is modified to a recycled status in the master data table of the business database, and the node and its attached edges are deleted from the graph database.

[0172] Optionally, when a message in transit is detected, the recycling process can be withdrawn and a freeze rollback can be performed.

[0173] If a message meeting the conditions is captured during the observation window, it indicates that the safety premise for recycling has been lost. The system suspends subsequent release actions and enters the exception recovery branch.

[0174] Optionally, to ensure concurrent consistency during the anomaly recovery process, the system employs a reverse rollback protocol to execute the withdrawal operation. The withdrawal and recovery process, along with the freeze rollback, is executed via the reverse rollback protocol, specifically including:

[0175] Optionally, an operation can be performed in the ERP code association graph to restore the frozen state of the graph corresponding to the code to be evaluated to the normal receiving state, thereby restoring the ability of the ERP code association graph to receive the corresponding messages.

[0176] Optionally, after the map freeze state is successfully restored, an operation is then performed in the ERP system to update the freeze control record corresponding to the code to be evaluated to the revoked state, and release the interception logic for new reference operations for the code to be evaluated.

[0177] In this embodiment, the reverse rollback protocol follows the execution order of graph side first, then business source side. If the order is reversed, causing the business source to be unblocked first, the business system will generate a new associated message for that encoding. When this new message flows to the graph server, because the graph node is still in the graph frozen state, it may cause the message to be rejected or incorrectly stored, resulting in a failure where the business layer establishes a connection but the graph layer experiences a topology disconnection. By requiring the graph node to restore to the normal receiving state first, the concurrent conflict point is intercepted, ensuring that new data generated after the business source ban is lifted can be synchronously consumed and written to disk by the graph.

[0178] Example 5: This example details the construction of the initial baseline of the association graph during the initial deployment phase of the system through a lossless smooth migration mechanism. Optionally, before capturing business operation events of the ERP system and incrementally updating the association status of the ERP code association graph based on these business operation events, the example also includes initializing the ERP code association graph, specifically including:

[0179] Optionally, start an event listener and temporarily store the associated change messages generated in real time, and record the initialization start timestamp.

[0180] Specifically, when the consistency verification module is deployed for the first time in the Enterprise Resource Planning (ERP) system, the system faces constraints such as a massive amount of existing data and the inability to halt business operations. To ensure no data loss during the transition period, the system adopts a "first-open, first-close" strategy to initiate the initialization process. The system activates the event listening components deployed in each business module and begins to capture all real-time related change messages. At this moment, the graph server does not perform regular edge write operations but instead forwards the received related change messages to a pre-configured temporary storage queue for temporary storage. Simultaneously, the system obtains and records the system time when the event listening components are started, marking this time as the initialization start timestamp. Recording the initialization start timestamp provides a time anchor for subsequent data comparisons and identifies real-time messages that overlap or conflict with historical existing data.

[0181] In some alternative implementations, the aforementioned temporary queue can be implemented using an independent topic channel of a high-throughput message middleware, or it can be buffered in a memory-based key-value database to cope with the large-scale concurrent message writing that may occur during peak business periods.

[0182] Optionally, the existing data tables of the ERP system are traversed, the existing code reference relationships are converted into graph edges and written into the ERP code association graph to construct the initial baseline.

[0183] In this embodiment, after enabling the real-time data interception pipeline, the system initiates a background full scan task. The full scan task reads the existing data tables at the underlying level of each business module in the Enterprise Resource Planning (ERP) system in batches by executing structured query statements. The system extracts each historically generated and currently valid coded reference relationship, converts the table structure data into vertices and edges in a graph network, and appends the corresponding association type and time attributes, writing them in batches into the ERP coded association graph. Simultaneously with writing the graph edges, the system synchronously calculates and initializes the initial count values ​​of the strong association in-degree cache and weak association in-degree cache for each coded node. When all existing data tables have been traversed and written, the system constructs an initial baseline in the graph database reflecting the full historical association status.

[0184] Furthermore, considering that the data volume of enterprise resource planning systems typically reaches hundreds of millions, the full scan task can specifically adopt multi-threaded sharding concurrent reading technology based on a distributed computing framework to divide the data table into multiple data blocks for parallel processing, thereby compressing the initial baseline construction cycle.

[0185] Optionally, after the initial baseline is built, the temporarily stored association change messages are processed, and an overwrite update or skip operation is performed by comparing the timestamp carried in the association change messages with the timestamp of the graph edge being written.

[0186] Specifically, after the initial baseline construction command is executed, the system officially enters the catch-up phase. The graph consumer switches its reading source from the regular queue to the aforementioned temporary queue and begins to extract and process the temporarily stored association change messages sequentially. Since the business system continues to run during the full scan, some messages in the temporary queue may contain secondary modification operations on the same encoded reference relationship. To resolve state conflicts caused by concurrent writes, the system extracts the operation timestamp carried in the temporary messages and compares it with the last scan write timestamp of the corresponding graph edge record in the initial baseline.

[0187] The specific logic for the system to perform the above comparison is as follows: if the message timestamp is greater than the scan write timestamp, it indicates that the temporary message represents a business action that is more up-to-date than the existing scan results. The system performs an overwrite update operation on the corresponding graph edge based on the attributes of the message. Conversely, if the message timestamp is less than or equal to the scan write timestamp, it indicates that the change status of the temporary message record has been included and solidified by a later full scan task. The system discards the message and performs a skip operation.

[0188] Through the aforementioned strict timestamp and timing arbitration mechanism, the system can ensure a smooth handover between old and new data sources without interrupting front-end business operations, guaranteeing no data state rollback during the transition period. After all historical backlog messages in the temporary queue are cleared, the graph consumer automatically switches back to normal listening to the real-time message queue, signifying the complete completion of the initial baseline construction and catch-up strategy.

[0189] This invention introduces a computational transitive constraint propagation model and a compliance-gated segmented decay model. By decoupling source strength and path decay for adaptive graph exploration pruning, and using a statutory retention period as a hard gate combined with negative exponential state weighting, it achieves the calculation of indirect constraints and residual constraints while adhering to the bottom line of data compliance. This releases coding resources that have been locked ineffectively for a long time by historical formal associations, and solves the problems of data chain breakage and compliance risks caused by implicit dependencies and coarse-grained judgments in complex business chains.

[0190] Furthermore, a source-priority dual-end pre-freezing and dynamic observation window collaborative mechanism was designed. By prioritizing the cutting off of incremental business sources through reverse-order operations and calculating the convergence waiting time based on the maximum physical delay of the pipeline link, in-transit messages in the asynchronous communication pipeline are processed without introducing a global distributed lock, ensuring the eventual consistency between the reclamation and release operations and the underlying business reality.

[0191] The preferred embodiments of the present invention have been described in detail above. However, the present invention is not limited to the specific details in the above embodiments. Within the scope of the technical concept of the present invention, various equivalent transformations can be made to the technical solutions of the present invention, and these equivalent transformations all fall within the protection scope of the present invention.

Claims

1. A method for incremental consistency verification of ERP coding based on association graphs, characterized in that, include: Capture business operation events of the ERP system, and incrementally update the association status of the ERP code association graph based on the business operation events, while simultaneously recording change logs on both sides. The code to be evaluated is obtained from the ERP system. Based on the multi-dimensional constraint model, the recyclability of the code to be evaluated is evaluated on the ERP code association graph. Codes with indirect active dependencies or excessive residual constraints are excluded to obtain a set of recyclable candidate codes. Based on the two-sided change log, a targeted consistency check is performed on the recyclable candidate code set to locate the missing messages and repair the data differences, thus obtaining the recyclable code set that passes the consistency check. A two-phase state machine protocol, including a pre-freeze phase and an observation window, is initiated for the recyclable code set that has passed the consistency check. After confirming that there are no conflicts in transit messages, the codes in the recyclable code set that have passed the consistency check are released in the ERP system and the nodes in the ERP code association graph are cleared. In performing a recoverability assessment of the codes to be evaluated on the ERP coding association graph based on a multi-dimensional constraint model, codes with indirect active dependencies are excluded. These excluded codes include: When there are no direct active references to the code to be evaluated, extract the predecessor business object node that points to the code to be evaluated from the ERP code association graph with weak association edges. Probe the predecessor business object node along the weakly associated edge to assess the transitivity of the upstream strong constraint code to be evaluated; When a significant transitive constraint caused by transitivity is determined to exist, the code to be evaluated is excluded from the set of recyclable candidate codes; Based on a multi-dimensional constraint model, a recoverability assessment is performed on the codes to be evaluated on the ERP coding association map, excluding codes with excessive residual constraints, including: Extract weak association edges pointing to the code to be evaluated from the ERP code association graph, and read the association type, source module identifier and source business object identifier of the weak association edges; The basic semantic weights are determined based on the association type, the statutory data retention period is determined based on the source module identifier, and the status factor is determined based on the source business object identifier. The residual constraint weights of weakly related edges are calculated based on basic semantic weights, statutory data retention period, and state factors. Obtain the maximum value of the residual constraint weights of all weakly associated edges to be evaluated, and then obtain the aggregated residual constraint weights. When the aggregated residual constraint weight is greater than or equal to the preset recyclability threshold, the residual constraint force of the code to be evaluated is determined to be excessive, and the code to be evaluated is excluded from the set of recyclable candidate codes.

2. The method of claim 1, wherein, Capture business operation events from the ERP system, incrementally update the association status of the ERP code association graph based on these events, and synchronously record change logs on both sides, including: Intercept business operation events involving changes in encoding reference relationships, extract the referenced encoding identifier, the referrer business object identifier, the association type and the operation timestamp, and encapsulate them into an association change message carrying a unique message identifier; The association change message is asynchronously delivered to the graph server, and the creation, attribute update or logical deletion of the directed edge corresponding to the association change message is performed in the ERP coding association graph. Based on the association type, synchronously refresh the strong association in-degree cache and weak association in-degree cache corresponding to the referenced encoding identifier; When the associated change message is successfully delivered, the delivery timestamp is recorded, and when the graph update is completed on the graph server, the consumption completion timestamp is recorded, and the two-sided change logs are aggregated.

3. The method of claim 1, wherein, Probe backward along weakly related edges to identify predecessor business object nodes and assess the transitivity of upstream strong constraints on the code to be evaluated, including: Query the strong in-degree of the preceding business object node; If the strong in-degree of any predecessor business object node is greater than zero, it is determined that there is a significant transitive constraint and the exploration is terminated. When the strong in-degree of all predecessor business object nodes in the current layer is zero, extract the weakly related predecessor nodes in the previous layer and continue to explore until the preset maximum exploration depth is reached.

4. The method of claim 1, wherein, The residual constraint weights of weakly related edges are calculated based on basic semantic weights, statutory data retention period, and state factors, including: Calculate the time decay factor based on the business creation time corresponding to the source business object identifier and the statutory data retention period; The residual constraint weights are obtained by multiplying the basic semantic weights, the time decay factor, and the state factor.

5. The method of claim 1, wherein, Based on the two-sided change logs, a directed consistency check is performed on the recyclable candidate code set to locate any missed messages and repair data differences, resulting in a recyclable code set that passes the consistency check, including: Log records for each code to be evaluated in the set of recyclable candidate codes are extracted from the business-side logs and graph-side logs contained in the dual-side change logs. Extract the first message identifier set from the business side logs, and extract the second message identifier set from the graph side logs; Using the first message identifier set as a reference, calculate the one-way difference set relative to the second message identifier set; When the one-way difference set is not empty, the elements contained in the one-way difference set are positioned as the missing message identifiers of the corresponding missing messages; Query the source association snapshot of the code to be evaluated in the business data source, compare it with the ERP code association graph and perform missing association edge filling and repair; After the rewrite and repair are completed or the one-way difference set is empty, the corresponding code to be evaluated will be imported into the set of recyclable codes that have passed the consistency check.

6. The method of claim 1, wherein, In a two-phase state machine protocol that includes a pre-freeze phase and an observation window, the pre-freeze phase includes: In the ERP coding association graph, the status of each code to be evaluated in the set of recyclable codes that have passed the consistency check is changed to the graph frozen state; In the ERP system, a local freeze control record is written for the code to be evaluated to intercept new reference operations for the code to be evaluated.

7. A computer readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein the program, when executed, performs the method of any one of claims 1 to 6. 8.An electronic device comprising a memory and a processor, the electronic device comprising: The memory stores a computer program, and the processor is configured to execute the method of any one of claims 1 to 6 via the computer program.

Images