Data interface synchronization method for supply chain system

Abstract

The invention discloses a data interface synchronization method for a supply chain system, which relates to the technical field of data processing and comprises the following steps: acquiring an interface list and a call log, establishing an interface dependency relationship, forming an interface topology table and generating a unique identifier; in the data synchronization process, incremental data are collected from a source system, and a to-be-synchronized data set is generated; before the data are written into a target system, a double-water-level causal label is added to each piece of data; writing the data with the additional label into a shadow calculation account book, performing pre-checking according to consistency constraint, and submitting the data to a target system when the checking is passed; and when the check is not passed or the account and object list consistency fails, calculating a minimum cut set based on the interface topology table and the causal label, and only executing rollback on the interface nodes in the minimum cut set and generating a rollback record. According to the method, high-reliability synchronization of cross-system data interfaces can be realized in a complex supply chain scene, account, object and order consistency is improved, and large-scale rollback risks are reduced.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, specifically to a data interface synchronization method for supply chain systems. Background Technology

[0002] As the supply chain system continues to expand, various business systems, such as order management, warehouse management, transportation management, and financial settlement, operate in parallel both within and across enterprises. These systems exchange data through numerous interfaces to support core business processes such as order processing, inventory updates, transportation scheduling, and accounting. However, current technologies still face many challenges in synchronizing data interfaces.

[0003] Dependencies between interfaces often lack unified modeling, and the correspondence between different source systems and consumer systems is prone to redundancy, ambiguity, or omissions, making interface links difficult to trace and maintain. In complex scenarios, the opacity of interface dependencies introduces significant uncertainty into anomaly handling and impact scope analysis. In high-concurrency supply chain scenarios, the reliability of data synchronization is difficult to guarantee. Interface calls often result in duplicate transmissions, data loss, or out-of-order delivery, and existing methods generally lack effective idempotency control and event time management mechanisms, easily causing the target system to receive erroneous or conflicting data, thus affecting business consistency. Existing methods typically lack pre-calculation and consistency verification mechanisms during data writing, with most scenarios directly writing incremental data to the target system. When data violates business constraints, it is often only discovered during subsequent operation, leading to longer problem localization and repair cycles and increasing operational risks.

[0004] In summary, existing supply chain data interface synchronization technologies have significant shortcomings in dependency modeling, data transmission reliability, consistency verification, and anomaly handling. There is an urgent need for a new solution that can achieve highly reliable synchronization and refined anomaly handling across system data interfaces by combining interface topology modeling, causal watermarking and consistency constraints, and a minimum cut rollback mechanism based on graph theory. This would effectively improve the consistency of accounts, goods, and documents and reduce rollback costs. Summary of the Invention

[0005] Based on the shortcomings of the prior art described above, the purpose of this invention is to provide a data interface synchronization method for supply chain systems to solve the aforementioned technical problems.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a data interface synchronization method for a supply chain system, comprising: S1: Collect the interface list and call logs of each business in the supply chain system, establish interface dependency relationships based on the two dimensions of source system and consumer system, form an interface topology table, and generate a unique identifier for the interface; S2: During the data synchronization process, incremental data is collected from the source system, field mapping, anomaly filtering and idempotency processing are performed, and a dataset to be synchronized is generated. S3: Before writing the data to be synchronized in the dataset to be synchronized into the target system, attach a dual-watermark causal label to each incremental data. The dual-watermark causal label includes an event time watermark and a causal watermark. The event time watermark is used to determine the time integrity of the data arrival, and the causal watermark is used to determine the causal integrity of the data dependency. S4: Write the data to be synchronized with the attached double water level causal label into the shadow computing ledger, perform pre-consistency verification according to the preset consistency constraints, and write the data to be synchronized into the target system when the verification passes. S5: When the verification of the shadow ledger fails or the consistency verification of the target system fails, the minimum cut set that satisfies the consistency constraint is calculated based on the interface topology table and the causal edges marked with double water level causal labels. Only the interface nodes in the minimum cut set are rolled back, and rollback records are generated.

[0007] The present invention is further configured such that the collection of the interface list includes the source system identifier, the consumer system identifier, the channel type, the business object key, the event time field name, the idempotent key field, and the version field; the collection of the call log includes the called party identifier, the arrival timestamp, the result status, the delay, the tracking identifier, the event time value, the sequence location information, the count statistics, and the error type.

[0008] The present invention is further configured such that step S1 includes: Obtain the source system identifier and consumer system identifier from the interface list, and combine them with the called party identifier in the call log to normalize the correspondence between the source system and the consumer system. Establish a directed dependency relationship between the normalized source system and the consumer system to form an interface topology table; Generate a unique interface identifier in the interface topology table based on the source system identifier, consumer system identifier, and channel type.

[0009] The present invention is further configured to normalize the correspondence between the source system and the consumption system, including: Establish a system alias mapping table to map the system names and instance names in the interface list and call logs to the standard system names; When multiple mapping rules exist, the following steps are executed in sequence according to the preset priority order: explicit table-driven matching, namespace matching, service-to-system mapping, application-to-system mapping, pattern and suffix cleaning, and statistical consistency verification. After a successful match, the standardized system name is output. When the same input corresponds to multiple candidate specification system names, the best one is selected based on the frequency of occurrence in recent periodic logs. If it cannot be uniquely determined, it is marked as a conflict and enters the queue to be claimed. The system generates a confidence score and a set of evidence for the normalized results, and marks the results as pending confirmation when the confidence score is lower than a preset threshold.

[0010] The present invention is further configured such that step S2 includes: The incremental data collection method is determined based on the channel type. Field mapping processing is performed on the collected data. Field correspondence, data type unification and unit conversion are completed based on the pre-established field mapping table. The main data dictionary is called to standardize the code values ​​and convert non-standard field values ​​into standardized values. Anomaly filtering is performed on the mapped data. The data is checked according to the preset structural verification, semantic verification and master data verification rules. Data that meets the correction rules is written to the dataset to be synchronized after correction, and data that does not meet the correction rules is written to the isolation set. An idempotency identifier is generated for the data that passes the verification. The idempotency identifier is determined by the idempotency key field defined in the contract. When an idempotency identifier already exists, if the record status is "processed", the record is discarded. If the record status is "processing" or "failed", the order is compared. If the order is higher, the old record is overwritten. If the order is lower, the record is discarded. Write the data that is idempotent to the dataset to be synchronized.

[0011] The present invention is further configured such that step S3 includes: Extract the event time field value from the data to be synchronized, and combine it with the arrival time to perform ordered buffering of data in the same partition. Advance the event time level according to the maximum continuous business time. When there is a late record, mark it as delayed within the tolerance time window; otherwise, write the data to be synchronized into the isolation set. Parse the business object keys defined in the data to be synchronized, extract the ordinal values ​​corresponding to the business object keys, generate version information of the object set involved in the record, and take the upper bound of each key based on the existing causal watermark to obtain the causal watermark of the current record; The event time watermark and causal watermark are combined to form a dual-watermark causal label, and a corresponding causal set summary is generated and appended to the extended field of the data to be synchronized.

[0012] The present invention is further configured such that step S4 includes: During batch loading, the data to be synchronized is aggregated according to the business object key, and the calculation order is determined according to the event time and version sequence. The data is then written to the temporary area of ​​the shadow calculation ledger in batches. In the shadow ledger, the fields contained in the data to be synchronized are incremented to update the shadow status corresponding to the business object key, and the verification is performed one by one according to the preset consistency constraints. When any constraint fails, a violation record is generated and the data to be synchronized is marked as rejected. After the batch calculation is completed, a pre-consistency check result is generated based on the violation situation. When the violation record is empty, it is determined that the check has passed. A change set is constructed and written to the target system and committed to the target system with an idempotent batch transaction. When a violation record exists, a violation details and rejection dataset are generated, recording the violated constraint rules, business object keys, states before and after the change, and causal water level requirements.

[0013] The present invention further specifies that the consistency constraints include nonnegativity constraints, conservation constraints, commitment constraints, state sequence constraints, and water level constraints.

[0014] The present invention is further configured such that step S5 includes: An interface node set is established based on the interface topology table, and causal directed edges are constructed according to the business object key and causal version recorded in the double-water level causal label, forming a causal dependency graph containing violation record nodes. In the causal dependency graph, the non-compliant nodes are aggregated into supersources, and the stable final states that satisfy the consistency constraints are aggregated into supersinks. The interface nodes are converted into edges with capacity using the point splitting method. The node capacity is calculated according to the preset weight function, and the minimum cut set is obtained by calling the maximum flow minimum cut algorithm. For the interface nodes in the minimum cut set, the rollback boundary is determined. The event time boundary is taken from the event time water level before the verification failure, the causal boundary is taken from the causal water level before the verification failure, and the rollback unit is determined according to the granularity of the combination of idempotent key or business object key and version number. Generate a rollback plan based on the rollback boundary, perform reverse rollback on the interface nodes in the minimum cut set, maintain idempotency during the rollback process, record the rollback log, and update the shadow calculus ledger and water level storage to the state before rollback; After each node rollback is completed, an immediate consistency check is performed, and the rollback is terminated when the consistency constraints are satisfied again.

[0015] The present invention further specifies that the logic for obtaining the minimum cut set is as follows: In the causal dependency graph, the non-compliant nodes are aggregated into supersources, and the stable final states that satisfy the consistency constraints are aggregated into supersinks, thus constructing a directed graph with supersources and supersinks. The interface nodes are divided into entry nodes and exit nodes using a point splitting method, and an internal edge is added between the entry nodes and the exit nodes. The capacity of the internal edge is determined by a preset capacity function. The capacity function is calculated based on error intensity, repair cost, latency pressure and business criticality. The capacity of non-revertible nodes is set to infinity. After completing the node splitting and capacity assignment, the maximum flow minimum cut algorithm is called to calculate the directed graph. When the cut set contains the internal edge of a certain interface node, the interface node is determined as a node in the minimum cut set. Perform a validity check on the interface nodes in the minimum cut set. If the node capacity is infinite, exclude the node and recalculate to obtain the minimum cut set that satisfies the consistency constraint.

[0016] This invention provides a data interface synchronization method for a supply chain system. It involves collecting the interface list and call logs of each business within the supply chain system, establishing interface dependencies based on two dimensions: the source system and the consumer system, forming an interface topology table, and generating unique identifiers for each interface. During data synchronization, incremental data is collected from the source system, and field mapping, anomaly filtering, and idempotency processing are performed to generate a dataset to be synchronized. Before writing the data to be synchronized from the dataset to the target system, a dual-watermark causal label is attached to each incremental data entry. The dual-watermark causal label includes an event time watermark and a causal watermark. The first watermark is used to determine the time integrity of data arrival, and the causal watermark is used to determine the causal integrity of data dependencies. Data to be synchronized with double-watermarked causal tags is written to the shadow ledger, and a pre-consistency check is performed based on preset consistency constraints. When the check passes, the data to be synchronized is written to the target system. When the shadow ledger check fails or the target system's ledger-to-item consistency check fails, based on the interface topology table and the causal edges marked with double-watermarked causal tags, the minimum cut set satisfying the consistency constraints is calculated. Only interface nodes in the minimum cut set are rolled back, generating rollback records. The beneficial effects include: 1. Transparent Interface Dependencies: By collecting interface lists and call logs, interface dependencies between source and consumer systems are established, forming an interface topology table and generating unique identifiers. This approach enables structured modeling of interface relationships, making interface chains clear and traceable. It solves the problems of ambiguous interface dependencies and difficulty in anomaly tracing in existing technologies, providing accurate basic data for subsequent verification and rollback. 2. Dual Consistency Guarantee: Before data is written to the target system, a dual-watermark causal label is attached to each incremental data entry. The event time watermark is used to determine the time integrity of data arrival, and the causal watermark is used to determine the causal integrity of data dependencies. This dual-watermark mechanism not only ensures the continuity of data in time sequence but also guarantees the integrity of cross-system data dependencies, overcoming the shortcomings of existing methods that only use time watermarks as a verification condition. 3. Risk Isolation Through Pre-Verification: By introducing a shadow ledger, pre-consistency verification is performed before data is officially written to the target system. The ledger virtually updates the state of business objects and verifies rules such as non-negativity constraints, conservation constraints, commitment constraints, state order constraints, and water level constraints one by one. This mechanism can identify abnormal data in advance without affecting the real business system data, preventing anomalies from directly contaminating the target system and effectively reducing potential risks. 4. Minimization and Controllability of Anomaly Rollback: When the shadow ledger verification fails or the consistency verification of ledger, physical goods, and documents fails, this invention constructs a causal dependency graph using an interface topology table and causal edges labeled with double watermarks. It then uses a point splitting and maximum flow minimum cut algorithm to calculate the minimum cut set. Rollback is only performed on interface nodes within the minimum cut set. By combining double watermarks to determine event time and causal boundaries, fine-grained reverse rollback is achieved. This method avoids the large-scale business interruption caused by a full rollback, keeps anomalies to a minimum, reduces repair costs, and improves system controllability and stability.

[0017] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings: Figure 1 The flowchart illustrates a data interface synchronization method for a supply chain system, as shown in an exemplary embodiment of the present invention. Detailed Implementation

[0019] The embodiments of the present invention will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.

[0020] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0021] In the following description, numerous details are explored to provide a more thorough explanation of embodiments of the invention. However, it will be apparent to those skilled in the art that embodiments of the invention may be practiced without these specific details. In other embodiments, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring embodiments of the invention.

[0022] A data interface synchronization method for supply chain systems, such as Figure 1 As shown, it includes: S1: Collect the interface list and call logs of each business in the supply chain system, establish interface dependency relationships based on the two dimensions of source system and consumer system, form an interface topology table, and generate a unique identifier for the interface; S2: During the data synchronization process, incremental data is collected from the source system, field mapping, anomaly filtering and idempotency processing are performed, and a dataset to be synchronized is generated. S3: Before writing the data to be synchronized in the dataset to be synchronized into the target system, attach a dual-watermark causal label to each incremental data. The dual-watermark causal label includes an event time watermark and a causal watermark. The event time watermark is used to determine the time integrity of the data arrival, and the causal watermark is used to determine the causal integrity of the data dependency. S4: Write the data to be synchronized with the attached double water level causal label into the shadow computing ledger, perform pre-consistency verification according to the preset consistency constraints, and write the data to be synchronized into the target system when the verification passes. S5: When the verification of the shadow ledger fails or the consistency verification of the target system fails, the minimum cut set that satisfies the consistency constraint is calculated based on the interface topology table and the causal edges marked with double water level causal labels. Only the interface nodes in the minimum cut set are rolled back, and rollback records are generated.

[0023] The present invention further specifies that the interface list collection includes source system identifier, consumer system identifier, channel type, business object key, event time field name, idempotent key field, and version field; the call log collection includes called party identifier, arrival timestamp, result status, delay, tracking identifier, event time value, sequence location information, count statistics, and error type. In a specific embodiment of the present invention, the method of the present invention is applied in the data interface synchronization scenario of a supply chain system. The system includes an order management system (OMS), a warehouse management system (WMS), a transportation management system (TMS), and a financial settlement system (FMS), and the systems interact with each other through various interfaces. In order to establish the interface topology relationship and perform consistency control thereafter, the interface list and call log need to be collected first. During the system deployment phase, the interface list is generated by the interface registration module, and the collected content includes: source system identifier: refers to the initiating system of the interface call, such as OMS, WMS, TMS, or FMS. The system assigns a unique identifier code to each source system, such as "SYS_OMS" or "SYS_WMS"; consumer system identifier: refers to the receiving system of the interface call, such as WMS receiving the order placement request from OMS. This field is labeled "SYS_WMS" in the list; Channel type: indicates the interface transmission method, such as "API_REST", "MQ_KAFKA", "FTP_FILE", etc., to facilitate the determination of the data synchronization mechanism; Business object key: refers to the unique identifier field of the core business object that the interface operates on, such as order number (OrderID), delivery order number (DeliveryID), and stock batch number (StockBatchID).The interface list should explicitly record fields such as "OrderID"; the event time field name should reflect the time the data occurred, such as "event_time" or "created_at", used for subsequent calculations of event time levels; the idempotent key field should be composed of a business object key and a sequence number, such as "OrderID+LineNo+Version", used to generate idempotent identifiers to avoid duplicate consumption or out-of-order overwriting; the version field should indicate the order of data changes, such as "version" or "update_seq", used to distinguish between old and new data; during interface operation, each call will generate a call log, which is automatically recorded by the call monitoring component. The collected content includes: the called party identifier: i.e., the consumer system identifier, such as "SYS_WMS"; and the arrival timestamp: the time when the interface message arrives at the consumer system, such as "2024-08-12". 10:30:05.123; Result Status: The execution result of the interface call, such as "SUCCESS", "FAILURE", "TIMEOUT"; Delay: The time interval from when the message is sent to the consumer system for processing completion, in milliseconds; Trace Identifier: The end-to-end trace ID generated for cross-system calls, such as "TRACE_ABC12345", used for end-to-end link analysis; Event Time Value: The event time field value carried in the interface data, such as the order creation time "2024-08-12 10:29:59"; Sequence Location Information: The sequence location method under different channels. If it is a message queue, it is "partition+offset". If it is a database change log, it is "LSN" or "transaction_id"; Count Statistics: The cumulative number of interface calls, such as "batch_count=1000"; Error Type: When the result status is failure, the error category is recorded, such as "NETWORK_ERROR" or "DATA_VALIDATION_ERROR".

[0024] The present invention is further configured such that step S1 includes: The system retrieves the source system identifier and consumer system identifier from the interface list, and combines this with the called party identifier from the call log to normalize the correspondence between the source and consumer systems. Specifically, the interface list is stored in the configuration center and generated by the interface registration platform. Each record includes the source system identifier, consumer system identifier, channel type, business object key, event time field name, idempotent key composition, and version field. During interface calls, the call monitoring component automatically generates call logs, recording information such as the called party identifier, arrival timestamp, and tracking identifier. In actual deployments, system names may have different aliases or abbreviations; for example, "OrderSys," "OMS," and "OrderManagement" all refer to the order management system. Therefore, a system alias mapping table is established. During normalization, the system first retrieves the source and consumer system identifiers from the interface list, then combines them with the called party identifier from the call log, queries the mapping table, and uniformly maps all aliases to the standardized system names. A directed dependency relationship is established between the normalized source system and the consumer system to form an interface topology table. Specifically, after normalization, a directed dependency relationship is established between the source system and the consumer system, with the source system as the starting point and the consumer system as the ending point, to form an interface topology table. The interface topology table includes the source system, the consumer system, and the channel type. In the interface topology table, a unique identifier for each interface is generated based on the source system identifier, the consumer system identifier, and the channel type. Specifically, in the topology table, each interface dependency is generated by combining the source system identifier, the consumer system identifier, and the channel type to ensure that the interface can be uniquely referenced in the system.

[0025] The present invention is further configured to normalize the correspondence between the source system and the consumption system, including: A system alias mapping table is established to map the system names and instance names in the interface list and call logs to the standardized system names. Specifically, in a real-world operating environment, various business systems in the supply chain may have multiple names due to differences in vendors, deployment environments, or historical reasons. For example, the order management system may be called "OMS," "OrderSys," and "OrderManagement," while the warehouse system may be called "WMS," "WarehouseSystem," or "WMS_APP." Therefore, a system alias mapping table is established in the configuration center to record the correspondence between the original system names / instance names and the standardized system names. During subsequent resolution, the source and consumer system names in the interface list and call logs will first be mapped to this table to ensure that different aliases are unified to the standardized names. When multiple mapping rules exist, explicit table-driven matching, namespace matching, service-to-system mapping, application-to-system mapping, pattern and suffix cleaning, and statistical consistency verification are executed sequentially according to a preset priority order. Upon successful matching, the standardized system name is output. Specifically, in some cases, a single mapping is insufficient to cover all scenarios. For example, some system identifiers may contain prefixes, suffixes, or namespaces, requiring further matching. The system is configured with the following priority order: Explicit table-driven matching: Prioritizes searching for direct mappings in the alias mapping table; Namespace matching: Namespace resolution is performed on names with namespace prefixes (e.g., "corp.oms.service") to extract the core identifier "oms"; Service-to-system mapping: Based on service registration information, service names (e.g., "order-service") are mapped to their respective system "OMS"; Application-to-system mapping: Application names (e.g., "warehouse-app") are mapped to "WMS"; Pattern and suffix cleaning: Suffixes are removed through regularization, such as "OMS_DEV" → "OMS"; Statistical consistency verification: The frequency of occurrence of a candidate mapping is counted in the recent periodic call logs. If the proportion of a mapping result exceeds a threshold (e.g., 80%), the mapping is considered valid; For example, inputting "corp.wms-service", namespace matching extracts "wms-service", and then service mapping is normalized to "WMS"; When the same input corresponds to multiple candidate system names, the optimal one is selected based on the frequency of occurrence in recent period logs. If a unique match cannot be determined, it is marked as a conflict and added to the waiting queue. Specifically, when the same input is parsed using different rules, it may correspond to multiple candidate system names. For example, "order-app" may match both "OMS" and "ERP". In this case, the system makes a decision based on the statistical results of the call logs: if a candidate mapping result has the highest frequency in the call logs of the most recent period (e.g., 24 hours), then that result is selected as the normalized name; if two candidate results have similar frequencies and cannot be uniquely determined, they are marked as a conflict and added to the waiting queue for confirmation by manual or maintenance tools. For example, in the past 24 hours, 90% of calls to "order-app" came from "OMS" and 10% came from "ERP" → normalized to "OMS"; if "OMS" accounts for 55% and "ERP" accounts for 45%, then the input is marked as a conflict. The normalization process generates a confidence score and an evidence set for each result, marking it as pending confirmation when the confidence score falls below a preset threshold. Specifically, after normalization, a confidence score is calculated for each result, and an evidence set is stored. The confidence score is calculated based on the matching method and statistical results. For example, explicit mapping table matching assigns a confidence score of 1.0, while candidates with a statistical proportion of 90% are assigned a confidence score of 0.9. The evidence set records the basis supporting the normalization result, including the rules used, call log statistics, frequency of occurrence, and regularization rules. When the confidence score falls below a preset threshold (e.g., 0.7), the normalization result is marked as pending confirmation for manual review.

[0026] The present invention is further configured such that step S2 includes: The incremental data collection method is determined based on the channel type. Field mapping processing is performed on the collected data, ensuring field correspondence, data type unification, and unit conversion based on a pre-established field mapping table. The master data dictionary is then used to standardize code values, converting non-standardized field values ​​into standardized values. Specifically, the supply chain system has multiple interface transmission channels: When the channel type is an API interface, incremental data is retrieved paginated via REST API, using the last_event_time or last_id in the request parameters for incremental retrieval; when the channel type is a message queue (MQ), consumers consume unprocessed messages sequentially based on partition number and offset, such as Kafka's partition + offset; when the channel type is a file transfer (FTP / SFTP), incremental data extracts newly added files using file batch number or timestamp as boundaries; when the channel type is a database change log (CDC), unprocessed change records are collected based on the previously saved log sequence number (such as binlogLSN or transaction ID). For example, OMS sends new orders to WMS via API, with the API call including `last_event_time=2024-08-12 10:00:00`. WMS only returns order data after this time. A field mapping table is pre-established to clearly define the field correspondences between different systems. The field mapping table's attributes include source fields, consumption fields, data types, and unit conversion rules. Within the field mapping table, field correspondence rules are established for each interface between the source and consumption systems. These rules clarify the one-to-one correspondence between data fields in the source system and the data fields the consumption system expects to receive, enabling field renaming and unification during data synchronization. The field mapping table contains data type information for type conversion during synchronization. For example, numeric fields in the source system may require string representation in the consumption system, or the source system may use floating-point numbers while the consumption system uses fixed-point numbers, requiring conversion before transmission. The field mapping table also specifies unit conversion rules for sensitive fields such as measurements or currencies. For example, when the source system records values ​​in larger units and the consumer system receives them in smaller units, the data should be standardized according to a preset conversion ratio during synchronization to ensure semantic consistency of values ​​across systems. For fields with enumerated or code values, the mapping table, combined with the master data dictionary, defines the correspondence between code values ​​and standardized values ​​across different systems. For instance, if the source system uses localized business status descriptions while the consumer system uses unified standard codes, the master data dictionary needs to be called during field mapping to convert the code values. Through the rule definition of the above field mapping table, the consistency of data across systems in terms of name, type, unit, and code can be guaranteed, thus providing reliable input for subsequent data cleaning, idempotency control, and consistency verification. The mapped data undergoes anomaly filtering, performing checks according to preset structural, semantic, and master data validation rules. Data that meets the correction rules is written to the dataset to be synchronized after correction; data that does not meet the correction rules is written to the isolation set. Specifically, anomaly detection is performed on the mapped data, with rules including: structural validation: field completeness and data type correctness. For example, order numbers cannot be empty, and amount fields must be positive numbers; semantic validation: logical rationality. For example, order amounts must be greater than zero, and delivery times cannot be earlier than order creation times; master data validation: referenced warehouses, materials, and customers must exist in the master data dictionary. The processing logic includes: for data that meets the correction rules (e.g., missing decimal places in the amount field can be padded with "00"), the system writes it to the dataset to be synchronized after correction; for data that does not meet the correction rules (e.g., invalid warehouse codes, empty order numbers), it is written to the isolation set, and the error type is recorded in the log. An idempotency identifier is generated for data that passes verification. This identifier is determined by the idempotency key field defined in the contract. If an idempotency identifier already exists, the record is discarded if its status is "processed." If the record's status is "processing" or "failed," the sequence number is compared; the record with the higher sequence number overwrites the old record, and the record with the lower sequence number is discarded. Specifically, the system generates the idempotency identifier based on the idempotency key field defined in the contract document. For example, the idempotency key is defined as {OrderID+LineNo+Version}. For data with order number ORD123, line number 001, and version number V3, the idempotency identifier is "ORD123-001-V3". Processing logic: If the idempotency identifier already exists and the record's status is "processed," the current data is discarded. If the status is "processing" or "failed," the version sequence number is compared: if the new data version number is higher than the old version number, the new data overwrites the old data; if the new data version number is lower than the old version number, the record is discarded. Write the data that is idempotent to the dataset to be synchronized.

[0027] The present invention is further configured such that step S3 includes: The system extracts the event time field value from the data to be synchronized and performs ordered buffering of data within the same partition based on the arrival time. The event time level is advanced according to the maximum continuous business time. If a late record exists, it is marked as delayed within a tolerance time window; otherwise, the data to be synchronized is written to the isolation set. Specifically, each record in the dataset to be synchronized contains an event time field value generated by the source system, and the message arrival time is recorded during the synchronization process. The system performs ordered buffering of the data to be synchronized within each partition. Ordered buffering: Data is stored in order of event time and compared with the arrival time. When event times are continuous and there are no breaks, the event time level advances. Late data processing: If a record's event time is detected to be earlier than the current level but still within a preset tolerance time window (e.g., 5 minutes), the record is marked as "delayed" and allowed to be filled within the window. If the record exceeds the tolerance time window, it is considered severely late and directly written to the isolation set to avoid affecting the continuity of the level. For example: if the current water level advances to 10:30:00, and a new record with an event time of 10:28:30 arrives, it is marked as delayed within a 5-minute window, and isolated after the window expires; The system parses the business object keys defined in the data to be synchronized, extracts the ordinal values ​​corresponding to the business object keys, generates version information for the object set involved in the record, and takes the upper bound of each key based on the existing causal watermark to obtain the causal watermark for the current record. Specifically, each piece of data to be synchronized contains a business object key, such as an order number, line number, or inventory batch number. The system extracts the corresponding ordinal values ​​based on the object key to calculate the causal watermark. Object set version information generation: The system extracts the version number of the current object from the object key and version field of the record to form the object set version information. For example, if the version number of order number ORD123 is V3, then the version information is {ORD123:V3}. Causal watermark update: The system maintains the causal watermark as a version vector, recording the highest version number of each object key. For a newly arrived record, the version number of the object key is compared key-by-key with the existing causal watermark, and the upper bound is taken as the updated causal watermark. For example: If the existing causal watermark is {ORD123:V2,ORD124:V5}, and the new record is {ORD123:V3}, then the updated causal watermark will be {ORD123:V3,ORD124:V5}. The system combines the event time watermark and the causal watermark to form a dual-watermark causal label, and generates a corresponding causal set summary, which is then appended to the extended fields of the data to be synchronized. Specifically, after obtaining the event time watermark and the causal watermark, the system combines them to form a dual-watermark causal label. The dual-watermark causal label generation process is as follows: Event time watermark: reflects the longest consecutive event time of the data processed in the current partition; Causal watermark: reflects the highest version number set of the object set. The system generates a causal set summary based on the causal watermark for rapid verification. For example, a hash function is used to calculate the summary of the version vector, generating a concise identifier. The event time watermark, causal watermark, and causal set summary are appended as extended fields to the data record to be synchronized for use in subsequent shadow ledger and consistency verification steps.

[0028] The present invention is further configured such that step S4 includes: During batch loading, the data to be synchronized is aggregated according to the business object key, and the calculation order is determined based on the event time and version sequence. The data is then written to the temporary area of ​​the shadow ledger in batches. Specifically, during data synchronization, the system divides the dataset to be synchronized generated in the S3 phase into batches. Each batch contains data records within the same time window, such as 2024-08-12 10:00:00 to 2024-08-12 11:00:00. The system aggregates the data within a batch according to the business object key (such as order number, outbound order number), merging multiple incremental records belonging to the same object key. Subsequently, the system determines the calculation order based on the event time and version sequence: if the object keys are the same, they are sorted from earliest to latest according to the event time; if the event times are the same, they are sorted from highest to lowest according to the version number, ensuring that newer versions cover older versions. After sorting, the data is written to the temporary area of ​​the shadow ledger as input for virtual state updates. In the shadow ledger, the incremental fields of the data to be synchronized are applied to update the shadow status corresponding to the business object key. Verification is performed line by line according to preset consistency constraints. When any constraint fails, a violation record is generated, and the data to be synchronized is marked as rejected. Specifically, the system maintains a shadow status (such as order status, inventory quantity) for each business object key. When incremental data is written, only the incremental fields it contains are applied to update the shadow status, without directly modifying the target system. For example, if the order status changes from "created" to "shipped," the status change of the object key is recorded in the shadow ledger, while the real order system retains its original value until verification passes. During the shadow ledger update process, verification is performed line by line according to preset consistency constraints. When any constraint is not met, the system immediately generates a violation record and marks the data to be synchronized as "rejected," preventing it from participating in subsequent batches of calculations. The invention further specifies that the consistency constraints include non-negativity constraints, conservation constraints, commitment constraints, state order constraints, and water level constraints. Specifically, the constraints are as follows: Non-negativity constraint: Inventory quantity cannot be negative; Conservation constraint: The total quantity of goods received and goods shipped should remain constant; Commitment constraint: Inventory for pre-sale orders must be frozen before delivery; Status sequence constraint: Order status must progress in the order of "Created → Approved → Shipped"; Water level constraint: The new data version number must not be lower than the current causal water level requirement. After batch calculation is completed, a pre-consistency check result is generated based on the violations. If no violation record is found, the check is considered passed, and a change set is constructed and written to the target system, then committed to the target system as an idempotent batch transaction. Specifically, after batch calculation, the system summarizes the check results: if there are no violation records in the entire batch, the batch is considered to have passed the check. The system constructs the shadow state change set of this batch into an idempotent transaction set and commits it to the target system. The commit process uses batch-level idempotency control to ensure that transactions with the same batch number are not applied repeatedly. If a violation record exists, the check is considered to have failed, the batch is not committed to the target system, and instead enters the exception handling process. When violations are recorded, a violation details list and a rejection dataset are generated, recording the violated constraint rules, business object keys, pre- and post-change states, and causal watermark requirements. Specifically, when violations are recorded in a batch, the system generates a violation details list and a rejection dataset for all abnormal data: the violation details list records the violated constraint rules, the corresponding business object keys, the shadow states before and after the data change, and the causal watermark requirements; the rejection dataset contains all rejected data to be synchronized, for subsequent isolation analysis or manual intervention.

[0029] The present invention is further configured such that step S5 includes: A set of interface nodes is established based on the interface topology table. Causal directed edges are constructed according to the business object keys and causal versions recorded in the double-watermark causal labels, forming a causal dependency graph containing violation record nodes. Specifically, if a violation record is found, such as an inventory update record violating the "non-negativity constraint," the system treats this record as a violation node. First, a set of interface nodes is established based on the interface topology table, with each interface node corresponding to an interface relationship between the source system and the consumer system. Then, causal directed edges are constructed according to the business object keys and causal versions recorded in the double-watermark causal labels to describe the data dependencies between interfaces. For example, the Order Management System (OMS) issues orders to the Warehouse Management System (WMS), and after WMS issues orders, it synchronizes them to the Finance Management System (FMS). If an outbound record in WMS triggers an anomaly, the dependency graph contains causal edges from OMS to WMS and from WMS to FMS, and the anomaly node is marked as a violation. In the causal dependency graph, non-compliant nodes are aggregated into supersources, and stable final states satisfying consistency constraints are aggregated into supersinks. Interface nodes are transformed into edges with capacity using a point splitting method. Node capacity is calculated based on a preset weight function, and the minimum cut set is obtained by calling the maximum flow minimum cut algorithm. The invention further specifies that the logic for obtaining the minimum cut set is as follows: In the causal dependency graph, violating nodes are aggregated into supersources, and stable final states satisfying consistency constraints are aggregated into supersinks, constructing a directed graph with supersources and supersinks. Specifically, in the preceding steps, if the shadow ledger verification finds that an inventory update record violates the nonnegativity constraint, the interface node corresponding to that record is marked as a violating node. First, an interface node set is established based on the interface topology table, with each node representing a data interface between the source system and the consumer system. Based on the double-watermark causal labels, the object key and causal version are extracted, and causal directed edges between interfaces are constructed to form a causal dependency graph. In this dependency graph: all violating nodes are aggregated into a supersource node, representing the starting point of the anomaly; all stable final state nodes satisfying consistency constraints are aggregated into supersink nodes, representing the system state that is expected to remain unchanged; for example, when OMS issues an order to WMS, and WMS outbound data is synchronized to FMS, if the WMS node is abnormal, the supersource includes the WMS node, and the supersink includes the FMS node. The interface nodes are divided into entry and exit nodes using a point-split approach, with an internal edge added between them. The capacity of this internal edge is determined by a preset capacity function, which is weighted based on error intensity, repair cost, latency pressure, and business criticality. The capacity of nodes that cannot be rolled back is set to infinity. Specifically, to ensure the algorithm can perform minimum cut judgments on nodes, each interface node employs point-split technology: the original node is split into an entry and exit node; an internal edge is added between the entry and exit points to represent the cost of cutting off the node. Dependency edges point from the exit of a node to the entry of a downstream node, maintaining the directionality of causal relationships. For example, the edge OMS→WMS is represented after point-split as: OMS exit → WMS entry. The capacity of the internal edge of the WMS node represents the cost required to cut off the node. Furthermore, the capacity of each internal edge is calculated by a preset capacity function, and the capacity value reflects the "cost" required to roll back the node. The capacity function is calculated based on a weighted average of the following factors: Error intensity: the cumulative number or severity of violations generated by the node; Repair cost: the computational cost required to roll back the node's data; Latency pressure: the impact of rolling back the node's data on business timeliness; Business criticality: the importance of the node in the supply chain process. For example, if an interface node is a critical accounting node, its capacity is assigned a larger value due to its high business criticality; for nodes that cannot be rolled back (such as the final financial settlement node), the capacity is set to infinity to ensure that the node is not selected during minimum cut calculation. After completing the node splitting and capacity assignment, the maximum flow minimum cut algorithm is called to calculate the directed graph. When the cut set contains an internal edge of a certain interface node, that interface node is determined as a node in the minimum cut set. Specifically, after the node splitting and capacity assignment are completed, the system calls the maximum flow minimum cut algorithm (such as the Dinic or Edmonds-Karp algorithm) to calculate the minimum cut from the supersource to the supersink: when the cut set contains an internal edge of a certain node, it means that cutting that node minimizes the abnormal propagation path, and then that node is determined as a member of the minimum cut set; the minimum cut set represents the minimum range of interfaces that need to be rolled back; for example, in the OMS→WMS→FMS link, if the WMS node has the smallest capacity, the algorithm will select the internal edge of the WMS node into the minimum cut, and the minimum cut set is {WMS node}. The system performs a validity check on the interface nodes in the minimum cut set. If a node has an infinite capacity, it is excluded and the algorithm is recalculated to obtain a minimum cut set that satisfies the consistency constraint. Specifically, after obtaining the minimum cut set, the system performs a validity check on each node in the set: if a node has an infinite capacity (a non-retrograde node), it is excluded. After excluding the node, the minimum cut algorithm is rerun until a minimum cut set that does not contain non-retrograde nodes is obtained. This avoids cutting off critical accounting nodes or other non-retrograde final state nodes and ensures that the rollback range is reasonable and executable.

[0030] For the interface nodes in the minimum cut set, determine the rollback boundaries. The event time boundary is taken from the event time water level before the verification failure, and the causal boundary is taken from the causal water level before the verification failure. The rollback unit is determined according to the granularity of an idempotent key or a combination of a business object key and a version number. Specifically, the event time boundary is taken from the event time water level before the verification failure; the causal boundary is taken from the causal water level before the verification failure. The rollback operation uses an idempotent key or a combination of "business object key + version number" as the granularity to ensure that the minimum rollback unit is a deterministic and replayable record. Generate a rollback plan file, recording the nodes to be rolled back, the rollback units, the boundary conditions, and the rollback method (logical rollback or physical rollback). A rollback plan is generated based on the rollback boundary. Reverse rollback is performed on the interface nodes in the minimum cut set, maintaining idempotency throughout the rollback process. Rollback logs are recorded, and the shadow ledger and watermark storage are updated to their pre-rollback states. Specifically, the system performs rollback according to the reverse dependency relationship of the interface topology: first rollback downstream nodes, then rollback upstream nodes to avoid data dependency breaks. Idempotency is maintained during the rollback process, meaning repeated rollbacks do not change the result. After the rollback operation is completed, rollback logs are recorded, including the rollback node, number of rollback entries, rollback boundary, and timestamp. Simultaneously, the shadow ledger and watermark storage are updated to their pre-rollback states to ensure system consistency after the rollback. After each node rollback is completed, an immediate consistency check is performed, and the rollback terminates when the consistency constraints are satisfied again. Specifically, after each node rollback is completed, the system performs an immediate consistency check: if all constraints are satisfied again, the rollback terminates and the system returns to a consistent state; if violations still exist, the rollback of the next node continues, or the minimum cut set is expanded, until consistency is restored. For example, if the inventory quantity returns to a non-negative value after the WMS node rollback, the system stops further rollbacks; if the anomaly still exists, it may be necessary to continue rolling back the OMS node.

[0031] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for data interface synchronization for a supply chain system, characterized in that, Comprise: S1: Collect the interface list and call log of each business of the supply chain system, establish the interface dependency relationship according to the two dimensions of source system and consumer system, form the interface topology table, and generate the interface unique identifier; S2: In the data synchronization process, collect incremental data from the source system, perform field mapping, abnormal filtering and idempotent processing, and generate a set of to-be-synchronized data; S3: Before writing the to-be-synchronized data in the to-be-synchronized data set into the target system, a double-water-level causal label is attached to each incremental data, the double-water-level causal label includes event time water level and causal water level, the event time water level is used to judge the time integrity of the data arrival, and the causal water level is used to judge the causal integrity of the data dependency relationship; S4: Write the to-be-synchronized data with the double-water-level causal label into the shadow calculus ledger, and perform pre-consistency check according to the preset consistency constraint, and when the check passes, write the to-be-synchronized data into the target system; S5: When the check of the shadow calculus ledger fails or the consistency check of the target system account fails, calculate the minimum cut set that satisfies the consistency constraint based on the interface topology table and the causal edge marked by the double-water-level causal label, and only execute rollback on the interface nodes in the minimum cut set to generate a rollback record.

2. The method for data interface synchronization for a supply chain system of claim 1, wherein, The collection of the interface list includes source system identifier, consumer system identifier, channel type, business object key, event time field name, idempotent key field and version field; The collection of the call log includes the identifier of the called party, the arrival timestamp, the result status, the delay, the tracking identifier, the event time value, the sequential positioning information, the count statistics and the error type.

3. The method for data interface synchronization of a supply chain system according to claim 2, wherein, Step S1 comprises: Obtain the source system identifier and the consumer system identifier from the interface list, and normalize the correspondence between the source system and the consumer system in combination with the called party identifier in the call log; Establish a directed dependency relationship between the normalized source system and the consumer system to form an interface topology table; Generate an interface unique identifier according to the source system identifier, the consumer system identifier and the channel type in the interface topology table.

4. The method for data interface synchronization for a supply chain system of claim 1, wherein, The normalization of the correspondence between the source system and the consumer system comprises: Establish a system alias mapping table to map the system name, instance name and standard system name in the interface list and the call log; When there are multiple mapping rules, perform explicit table-driven matching, namespace matching, service-to-system mapping, application-to-system mapping, pattern and suffix cleaning and statistical consistency check in the order of the preset priority, and output the standard system name after successful matching; When the same input corresponds to multiple candidate standard system names, select the optimal one according to the frequency of occurrence in the near-period log, and mark it as a conflict and enter the to-be-claimed queue when it cannot be uniquely determined; Generate a confidence value and an evidence set for the normalized result, and mark it as a to-be-confirmed state when the confidence value is lower than the preset threshold.

5. The method for data interface synchronization of a supply chain system according to claim 2, wherein, Step S2 comprises: Determine the collection method of incremental data according to the channel type, perform field mapping processing on the collected data, complete field correspondence, data type unification and unit conversion according to the pre-established field mapping table, and call the master data dictionary to complete code value standardization, and convert non-standardized field values into standard values; The abnormality filtering processing is performed on the mapped data, and detection is performed according to preset structure verification, semantic verification and main data verification rules; data meeting the correction rules is written into the to-be-synchronized data set after correction, and data not meeting the correction rules is written into the isolation set; An idempotent identifier is generated for the data passing the verification, and the idempotent identifier is determined by an idempotent key field defined in the contract; when the idempotent identifier already exists, if the record state is processed, the record is discarded, if the record state is processing or failed, the sequence position is compared, the old record is overwritten when the sequence position is higher, and the record is discarded when the sequence position is lower; The data passing the idempotent control is written into the to-be-synchronized data set.

6. The method for data interface synchronization for a supply chain system of claim 1, wherein, Step S3 comprises: The event time field value in the to-be-synchronized data is extracted, and the data in the same partition is sequentially buffered in combination with the arrival time; the event time water level is advanced according to the maximum continuous business time; when there is a late record, it is marked as delayed within the tolerance time window; otherwise, the to-be-synchronized data is written into the isolation set; The business object key in the to-be-synchronized data is parsed, the sequence position value corresponding to the business object key is extracted, the object set version information involved in the record is generated, and the upper bound of each key is taken on the basis of the existing causal water level to obtain the causal water level of the current record; The event time water level and the causal water level are combined to form a double-water-level causal tag, and a corresponding causal set digest is generated and attached to the extension field of the to-be-synchronized data.

7. The method for data interface synchronization for a supply chain system of claim 1, wherein, Step S4 comprises: The to-be-synchronized data is aggregated according to the business object key during batch loading, and the calculation order is determined according to the event time and the version sequence, and the data is written into the temporary area of the shadow calculation ledger by batch; The fields contained in the to-be-synchronized data are applied to update the shadow state corresponding to the business object key in the shadow calculation ledger, and the pre-set consistency constraints are executed sequentially to check when any constraint fails, a violation record is generated and the to-be-synchronized data is marked as rejected; After the batch calculation is completed, a pre-consistency check result is generated according to the violation, and when the violation record is empty, it is determined that the check passes, a change set is constructed and written into the target system, and an idempotent batch transaction is submitted to the target system; When there is a violation record, a violation detail and a rejected data set are generated, and the violated constraint rule, business object key, state before and after change, and causal water level requirement are recorded.

8. The method for data interface synchronization of a supply chain system according to claim 7, wherein, The consistency constraints include non-negative constraints, conservation constraints, commitment constraints, state sequence constraints and water level constraints.

9. The method for data interface synchronization for a supply chain system of claim 1, wherein, Step S5 comprises: An interface node set is established based on an interface topology table, and a causal directed edge is constructed according to the business object key and the causal version recorded in the double-water-level causal tag, forming a causal dependency graph containing the violation record node; In the causal dependency graph, the violation nodes are converged into a super source, the stable terminal state meeting the consistency constraints is converged into a super sink, the interface nodes are converted into edges with capacity by point splitting, the node capacity is calculated according to a pre-set weight function, and the maximum flow minimum cut algorithm is called to obtain the minimum cut set; The interface nodes in the minimum cut set are determined to have a rollback boundary, wherein the event time boundary is taken from the event time water level before the check fails, the causal boundary is taken from the causal water level before the check fails, and the rollback unit is determined according to the combination granularity of the idempotent key or the business object key and the version number; According to the rollback boundary, a rollback plan is generated, reverse sequence rollback is performed on the interface nodes in the minimum cut set, idempotency is maintained during the rollback, rollback logs are recorded, and the shadow calculation ledger and water level are updated to the state before rollback; After the rollback of each node is completed, immediate consistency check is performed, and the rollback is terminated when the consistency constraint is re-satisfied.

10. The method for data interface synchronization for a supply chain system of claim 1, wherein, The acquisition logic of the minimum cut set is as follows: In the causal dependency graph, the illegal nodes are aggregated into a super source, and the stable terminal state satisfying the consistency constraint is aggregated into a super sink, and a directed graph with a super source and a super sink is constructed; The interface nodes are divided into entry nodes and exit nodes by point splitting, and internal edges are added between the entry nodes and the exit nodes, the capacity of the internal edges is determined by a preset capacity function, the capacity function is weighted calculation based on error intensity, repair cost, delay pressure and business criticality, and the capacity of the non-rollback nodes is set to infinity; After point splitting and capacity assignment are completed, the maximum flow minimum cut algorithm is called to calculate the directed graph, when the internal edge of a certain interface node is included in the cut set, the interface node is determined as the node in the minimum cut set; The interface nodes in the minimum cut set are subjected to legality check, if the node capacity is infinite, the node is excluded and re-calculated, and the minimum cut set satisfying the consistency constraint is obtained.

Images