Enterprise digital transformation intelligent evaluation system

Abstract

The application discloses an enterprise digital transformation intelligent evaluation system and relates to the technical field of intelligent evaluation. The enterprise digital transformation intelligent evaluation system comprises a multi-source event collection module, an event chain construction module, a logical clock generation module, a passive causality verification module, a causality watermark probe injection module, a probe propagation verification module and a fusion verification output module. The passive causality verification module verifies the causality partial order of adjacent events in the directed event chain, and in combination with the asynchronous compensation-original call mapping index, identifies asynchronous compensation events and final consistency confirmation events, distinguishes the causality sequence, legal concurrency and causality loss state, and reduces the situation that asynchronous compensation, final consistency confirmation or legal concurrency are misjudged as link exceptions.

Description

Technical Field

[0001] This invention relates to the field of intelligent assessment technology, and in particular to an intelligent assessment system for enterprise digital transformation. Background Technology

[0002] As enterprises advance their digital transformation, business processes are typically distributed across business management systems, workflow approval systems, data interface systems, document collaboration systems, message middleware, and other business services. The same business object generates business logs, operation logs, interface call logs, approval workflow logs, document flow metadata, asynchronous compensation records, and consistency confirmation records across different business systems. Taking procurement as an example, a procurement request generates an approval workflow record in the workflow approval system, the approval result is synchronized to the business management system via the data interface system, related procurement attachments circulate in the document collaboration system, and asynchronous compensation records and consistency confirmation records are generated when interface calls fail or are delayed. Therefore, intelligent assessment of enterprise digital transformation no longer relies solely on system construction status or manually entered data; it also needs to identify the true flow status of business links from event data generated by multiple business systems.

[0003] Existing enterprise digital transformation assessment methods typically focus on indicator scores, system coverage, the proportion of online processes, or manual questionnaires, making it difficult to verify the true causal relationships between multiple business systems from the perspective of underlying business event chains. In multi-system collaboration scenarios, server times differ between different business systems, API calls involve asynchronous transmission, message channels experience concurrent consumption, file transfers involve bypass transmission, and asynchronous compensation and eventual consistency confirmation are required after API failures. If business chains are constructed solely based on physical time or log order, legitimate concurrency can easily be misjudged as anomalies, and events lacking true causal relationships can be incorrectly linked into the same chain. Furthermore, existing passive log analysis methods rely on existing log data and cannot proactively verify the true propagation status of target chains in API, message, data synchronization, or file transfer channels. Summary of the Invention

[0004] In situations where multiple heterogeneous business systems jointly participate in the flow of the same business object, this invention describes how to construct a directed event chain based on multi-source business events, and combine logical timestamps, asynchronous compensation records, eventual consistency confirmation records, and probe events with causal watermarks to perform passive causal verification and active propagation verification on the target link. This distinguishes between causal sequence, legitimate concurrency, existing causal anomalies, and probe propagation anomalies, and outputs event chain credibility data for intelligent assessment of enterprise digital transformation.

[0005] To achieve the above objectives, the technical solution adopted by the present invention is as follows: The enterprise digital transformation intelligent assessment system includes: The multi-source event acquisition module is used to collect business logs, operation logs, interface call logs, approval flow logs, file flow metadata, asynchronous compensation records, and consistency confirmation records generated by multiple business systems, and extract business events; the business events include at least one of ordinary business events, asynchronous compensation events, or eventual consistency confirmation events; The event chain construction module is used to construct a directed event chain for the same business object according to the business object identifier, event type, source system identifier, and cross-system call relationship; The logical clock generation module is used to maintain the vector clocks corresponding to each business system with the source system identifier as the vector dimension, generate logical timestamps when events occur within the business system, and merge the vector clocks during cross-system calls, message passing, data synchronization, or file transfer. The passive causal verification module is used to perform causal partial order verification on adjacent events in the directed event chain based on the logical timestamp, determine the causal sequence, concurrency or causal missing state, and mark the causal missing state as an existing causal anomaly. The causal watermark probe injection module is used to determine the target link and its corresponding expected propagation subgraph based on the directed event chain and the existing causal anomaly. The expected propagation subgraph includes at least the target link node set, the directed edge set, the link entry event node, and at least one link exit event node corresponding to the target link in the directed event chain. It generates probe events with causal watermark, probe identifier, target link identifier, logical timestamp, non-business impact identifier, and anomaly baseline marker, and injects the probe events into the business system interface, message channel, data synchronization channel, or file transfer channel corresponding to the target link. The probe propagation verification module is used to collect probe propagation logs generated by the probe events and generate the actual probe propagation chain based on causal watermarks and logical timestamps; the probe propagation logs are generated through an audit record channel independent of the probe event business transactions. The fusion verification output module is used to correlate and verify the actual propagation link of the probe with the expected propagation subgraph. When the two are inconsistent in the target link node, propagation direction or causal partial order relationship, the probe propagation anomaly result is output, and the probe propagation anomaly result, the existing causal anomaly and the anomaly baseline mark are written into the event chain credibility data.

[0006] As a preferred embodiment of the present invention, the multi-source event acquisition module includes an event field extraction unit and an event standardization unit. The event field extraction unit is used to extract event fields from the business logs, operation logs, interface call logs, approval flow logs, file flow metadata, asynchronous compensation records, and consistency confirmation records. The event fields include at least one of the following: business object identifier, event type, source system identifier, event time, interface call identifier, file identifier, original transaction identifier, compensation association identifier, or consistency confirmation identifier. The event standardization unit is used to generate the business event by processing the event fields according to a unified event format. The unified event format includes at least the business object identifier, event type, source system identifier, event time, event association identifier, and transaction association identifier.

[0007] As a preferred embodiment of the present invention, the event chain construction module includes an event grouping unit, a link edge generation unit, and a link direction determination unit; the event grouping unit is used to group the business events according to the business object identifier; the link edge generation unit is used to generate a link edge between two related business events according to the event type, source system identifier, and cross-system call relationship; the link direction determination unit is used to determine the direction of the link edge according to the caller and callee, sender and receiver, synchronization source and synchronization target, or file flow order.

[0008] As a preferred embodiment of the present invention, the logical clock generation module includes a vector initialization unit, an internal event update time unit, and a cross-system event merging unit. The vector initialization unit is used to establish vector dimensions based on the source system identifier and maintain the vector clocks corresponding to each business system. The internal event update time unit is used to increment the corresponding vector component when a business event occurs within the same business system and generate a logical timestamp for the business event. The cross-system event merging unit is used to take the maximum value of the sending-side logical timestamp and the receiving-side vector clock dimension by dimension when a cross-system event occurs, and increment the corresponding vector component on the receiving side to generate a logical timestamp for the receiving-side business event.

[0009] As a preferred embodiment of the present invention, the passive causal verification module includes a partial order comparison unit, a compensation mapping index unit, and a state determination unit. The partial order comparison unit is used to compare the logical timestamps of adjacent first and second business events directly connected by a link edge in the directed event chain. The compensation mapping index unit is used to establish an asynchronous compensation-original call mapping index based on the original transaction identifier, compensation association identifier, and consistency confirmation identifier. The state determination unit is used to determine whether the first and second business events are in a causal sequence state or a concurrent state based on the logical timestamps. When the link edge requires the first business event to trigger the second business event, and the first business event is not in a causal sequence state relative to the second business event, the state determination unit detects whether there is a corresponding asynchronous compensation event or an eventual consistency confirmation event based on the asynchronous compensation-original call mapping index. If not, it is determined that both are in a causal missing state.

[0010] As a preferred embodiment of the present invention, the causal watermark probe injection module includes a target link determination unit, a causal watermark generation unit, and a probe event encapsulation unit. The target link determination unit is used to determine the target link based on the directed event chain and the existing causal anomaly, and further filter or prioritize the target link based on at least one of the following: number of cross-system nodes, historical anomaly results, most recent verification time, link priority, or system load, and generate a target link identifier, an anomaly baseline marker, and an expected propagation subgraph. The expected propagation subgraph is the set of target link nodes and the set of directed edges corresponding to the target link in the directed event chain, and includes a link entry event node, at least one link exit event node, and at least one branch path. The causal watermark generation unit is used to generate a causal watermark based on the probe identifier, the target link identifier, the source system identifier, and the logical timestamp. The probe event encapsulation unit is used to encapsulate the causal watermark, the probe identifier, the target link identifier, the logical timestamp, the non-business impact identifier, and the anomaly baseline marker into the event metadata of the probe event.

[0011] As a preferred embodiment of the present invention, the non-business impact identifier includes at least one of an isolation storage marker, a rollback transaction marker, a read-only verification marker, or a filtering marker; the non-business impact identifier is used to instruct the receiving-side business system or file transfer node to perform isolation storage, rollback, read-only verification, or filtering processing on the probe event; the probe propagation log is written through an audit record channel independent of the probe event business transaction.

[0012] As a preferred embodiment of the present invention, the probe propagation verification module includes a probe log matching unit, a propagation node determination unit, and an actual link generation unit. The probe log matching unit is used to classify probe propagation logs into the same probe event based on probe identifiers or causal watermarks. The propagation node determination unit is used to determine the propagation node of the probe event in the target link based on the source system identifier, event time, logical timestamp, and channel type. The actual link generation unit is used to generate the actual probe propagation link based on the causal watermark matching relationship between propagation nodes, the causal partial order relationship of logical timestamps, and the channel type.

[0013] As a preferred embodiment of the present invention, the fusion verification output module includes a branch coverage verification unit, a propagation direction consistency verification unit, and a causal consistency verification unit. The branch coverage verification unit is used to match the propagation nodes in the actual propagation link of the probe with the target link nodes in the expected propagation subgraph based on the target link identifier, causal watermark, source system identifier, and logical timestamp vector. The complete branch path is determined by the link entry event nodes, directed edge set, and link exit event nodes in the expected propagation subgraph. When there is no propagation node and connection relationship in the actual propagation link of the probe that matches any complete branch path in the expected propagation subgraph, a [missing information] is generated. The branch coverage anomaly result; the propagation direction consistency verification unit is used to compare the propagation direction in the actual propagation link of the probe with the propagation direction of the matched complete branch path, and generate a propagation direction anomaly result when the two are inconsistent; the causal consistency verification unit is used to verify the adjacent target link nodes on the matched complete branch path; when the causal partial order verification result of the adjacent target link node is concurrent, the corresponding causal consistency verification is skipped; when the causal partial order verification result of the adjacent target link node is causal sequential, the logical timestamp causal partial order relationship of the corresponding propagation node is compared with the causal sequential state, and a causal partial order anomaly result is generated when the two are inconsistent.

[0014] As a preferred technical solution of the present invention, the event chain credibility data includes event chain identifier, business object identifier, target link identifier, existing causal anomaly, probe propagation anomaly result, anomaly baseline marker, causal watermark matching result, logical timestamp verification result, and probe actual propagation link; the fusion verification output module is used to generate structured output records according to the event chain credibility data, and associate and store the structured output records with the corresponding directed event chains.

[0015] The present invention has the following advantages: This invention constructs a directed event chain for the same business object based on the business object identifier, event type, source system identifier, and cross-system call relationship. This associates event nodes and link edges scattered across multiple business systems into the same business flow link, avoiding link loss or incorrect connection caused by sorting based on a single system log or a single physical time.

[0016] This invention uses a passive causal verification module to perform causal partial order verification on adjacent events in a directed event chain, and combines asynchronous compensation-original call mapping index to identify asynchronous compensation events and eventual consistency confirmation events, distinguishing between causal order, legitimate concurrency and causal missing states, reducing the chance of misjudging asynchronous compensation, eventual consistency confirmation or legitimate concurrency as link anomalies.

[0017] This invention determines the target link and expected propagation subgraph based on existing causal anomalies, and generates probe events with causal watermarks, probe identifiers, target link identifiers, logical timestamps, non-business impact identifiers, and anomaly baseline markers. This combines the results of active probe verification with passive causal verification. By using anomaly baseline markers, it associates and marks existing causal anomalies before probe injection and propagation anomalies observed during probe propagation in the event chain credibility data. This provides a hierarchical basis for anomaly attribution analysis and avoids misjudging probe propagation failures caused by existing link defects as new anomalies introduced by probe injection or the propagation mechanism itself.

[0018] This invention instructs the receiving side to isolate, store, verify, filter, or roll back probe events by using a non-business impact identifier, and writes them into the probe propagation log through an audit record channel independent of the business transactions of the probe events, so that the probe events leave a traceable propagation record without changing the state of the real business object.

[0019] This invention uses a fusion verification output module to perform branch coverage verification, propagation direction consistency verification, and causal consistency verification on the actual probe propagation link and the expected propagation subgraph. This reduces misjudgments caused by differences between the serial propagation of the probe and the legitimate concurrency of the business. At the same time, the branch coverage verification independently ensures that all branches that should be covered in the concurrent scenario are touched by the actual probe propagation link, avoiding the inability to verify the integrity of the corresponding branch link due to skipping the causal verification. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings in the following description are only schematic diagrams of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort. Figure 1This is a schematic diagram of the intelligent assessment system for enterprise digital transformation used in an embodiment of the present invention. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0022] Example 1: Intelligent Assessment System for Enterprise Digital Transformation, comprising: 100. A multi-source event acquisition module is used to collect business logs, operation logs, interface call logs, approval flow logs, file flow metadata, asynchronous compensation records, and consistency confirmation records generated by multiple business systems, and extract business events; the business events include at least one of ordinary business events, asynchronous compensation events, or eventual consistency confirmation events; In this embodiment, multiple business systems include a business management system, a process approval system, a data interface system, a document collaboration system, and business middleware or interface services for recording asynchronous compensation and consistency confirmation. Taking enterprise procurement as an example, the same procurement application generates an approval flow record in the process approval system, a purchase order record in the business management system, a cross-system call record in the data interface system, flow metadata of procurement attachments or forms in the document collaboration system, and asynchronous compensation or consistency confirmation records in the interface service. The data from these different sources is collected and converted into business events, which are then used to construct a directed event chain for the same business object.

[0023] The business logs are used to describe the generation, modification, or status changes of business objects, which include at least one of the following: purchase requisitions, purchase orders, contracts, warehouse receipts, customer orders, and approval documents. The operation logs are used to describe the operations performed by users or terminals on business objects, including the operation subject, operation time, operation type, and operation terminal information. The interface call logs are used to describe the data transmission relationships between different business systems, including the caller system identifier, the callee system identifier, the interface call identifier, the call result, and the original transaction identifier. The original transaction identifier is used to establish a correspondence between subsequent asynchronous compensation records or consistency confirmation records and the original cross-system call.

[0024] The approval workflow log describes the workflow between approval nodes, including approval node identifiers, approval node order, and approval processing results. The file workflow metadata describes the flow of files or tables between different objects, without requiring the file text content as a necessary data collection object. It includes file identifiers, file structure information, flow objects, and flow time. The file structure information includes at least one of the following: field name, number of fields, table header structure, and data column type. The asynchronous compensation record describes the compensation processing triggered after cross-system call failures, timeouts, or inconsistencies, including a compensation association identifier and the corresponding original transaction identifier. The consistency confirmation record describes the confirmation result after cross-system data synchronization is completed, including a consistency confirmation identifier and the corresponding original transaction identifier.

[0025] The multi-source event acquisition module includes an event field extraction unit and an event standardization unit; The event field extraction unit is used to extract the business object identifier, business object status, and business object change fields from the business log; extract the operation subject, operation time, operation type, and operation terminal information from the operation log; extract the caller system identifier, callee system identifier, interface call identifier, call result, and original transaction identifier from the interface call log; extract the compensation association identifier and corresponding original transaction identifier from the asynchronous compensation record; extract the consistency confirmation identifier and corresponding original transaction identifier from the consistency confirmation record; extract the approval node identifier, approval node sequence, and approval processing result from the approval flow log; and extract the file identifier, file structure information, flow object, and flow time from the file flow metadata. Specifically, for business logs, the event field extraction unit uses the business object number, document number, order number, or contract number as the business object identifier; for operation logs, it uses the user account, service account, or terminal number as the operation subject or operation terminal information; for interface call logs, it uses the interface request number, message number, or transaction number as the interface call identifier or original transaction identifier; and for file flow metadata, it uses the file hash value, file number, or file ID generated by the collaboration platform as the file identifier. Thus, data from different sources has a coherent field base before entering the event standardization unit.

[0026] The event standardization unit is used to generate the business event from the data extracted by the event field extraction unit according to a unified event format. The unified event format includes at least the business object identifier, event type, source system identifier, event time, event association identifier, and transaction association identifier. The event type is used to distinguish between ordinary business events, asynchronous compensation events, and eventual consistency confirmation events. Ordinary business events further include types such as creation, modification, approval, invocation, synchronization, and file transfer. Asynchronous compensation events and eventual consistency confirmation events are generated correspondingly when the asynchronous compensation record and consistency confirmation record are standardized, respectively. The source system identifier is used to distinguish whether a business event originates from a business management system, process approval system, data interface system, file collaboration system, or interface service. The event time is used to record the occurrence time of the business event or the log write time. The event association identifier is used to associate events generated by interface calls, approval nodes, or file transfers with other events under the same business object. The transaction association identifier is used to associate original interface call events, asynchronous compensation events, and eventual consistency confirmation events.

[0027] The event association identifier is extracted by the event field extraction unit from at least one of the interface call identifier, approval node identifier, or file identifier. The transaction association identifier is determined by at least one of the original transaction identifier, compensation association identifier, or consistency confirmation identifier. The asynchronous compensation record and the consistency confirmation record are respectively standardized as the asynchronous compensation event and the final consistency confirmation event.

[0028] 200. Event chain construction module, used to construct a directed event chain for the same business object according to the business object identifier, event type, source system identifier and cross-system call relationship; In this embodiment, the event chain construction module receives business events output by the multi-source event acquisition module 100, and organizes business events from different business systems into a candidate event set for the same business object, using the business object identifier as the primary association basis. The business object identifier includes at least one of the following: purchase requisition number, purchase order number, contract number, warehouse receipt number, and approval document number.

[0029] The event types describe the technical meaning of business events in business processes, including creation events, modification events, approval events, interface call events, data synchronization events, file transfer events, asynchronous compensation events, and eventual consistency confirmation events. The source system identifier distinguishes whether a business event originates from a business management system, process approval system, data interface system, file collaboration system, or interface service. For multiple events within the same source system, the event chain construction module determines their connection relationship within that system based on the event type and event time; for events between different source systems, the event chain module generates cross-system link edges based on cross-system call relationships.

[0030] The cross-system call relationship is determined by at least one of the following: interface call identifier, message passing relationship, data synchronization relationship, or file transfer relationship. The interface call identifier is derived from the interface call log and is used to associate an interface request between the calling system and the called system; the message passing relationship is derived from the message number, queue topic, or message consumption record; the data synchronization relationship is derived from the synchronization task number, synchronization batch number, or original transaction identifier; and the file transfer relationship is derived from the file identifier, transfer object, and transfer time.

[0031] The event chain construction module includes an event grouping unit, a link edge generation unit, and a link direction determination unit; The event grouping unit is used to group the business events according to the business object identifier to obtain a set of candidate events corresponding to the same business object; The event grouping unit uses the business object identifier as the basic grouping condition, and supplements the grouping results with event association identifiers and transaction association identifiers. For events directly carrying the same purchase requisition number, the event grouping unit categorizes them into the same candidate event set. For events not directly carrying a purchase requisition number but carrying an original transaction identifier, interface call identifier, or file identifier, the event grouping unit categorizes them into the candidate event set of the corresponding purchase requisition using the transaction association identifier or event association identifier. The events in the candidate event set include ordinary business events from normal business processes, as well as asynchronous compensation events and eventual consistency confirmation events.

[0032] The link edge generation unit is used to determine two related business events in the candidate event set according to the event type, source system identifier, and cross-system call relationship, and generate a link edge between the two business events; wherein, the cross-system call relationship is determined by at least one of interface call identifier, message passing relationship, data synchronization relationship, or file flow relationship; In this embodiment, a link edge represents a direct association between two business events. For events within the same business system, the link edge generation unit generates a local link edge based on the event type and event time. For events across business systems, the link edge generation unit generates a cross-system link edge based on the interface call identifier, message passing relationship, data synchronization relationship, or file flow relationship. For asynchronous compensation events, the link edge generation unit connects the asynchronous compensation event to the corresponding original interface call event or data synchronization event based on the compensation association identifier and the original transaction identifier. For eventual consistency confirmation events, the link edge generation unit connects the eventual consistency confirmation event to the corresponding data synchronization event or receiving-side state update event based on the consistency confirmation identifier and the original transaction identifier.

[0033] The link direction determination unit is used to determine the direction of the link edge based on the caller and callee, sender and receiver, synchronization source and synchronization target or file flow order in the cross-system call relationship; wherein, the directed event chain consists of business events that are determined to have an association relationship and their corresponding link edges.

[0034] In this embodiment, for interface call relationships, the link direction is from the caller to the callee; for message passing relationships, the link direction is from the message sender to the message receiver; for data synchronization relationships, the link direction is from the synchronization source to the synchronization target; and for file flow relationships, the link direction is from the file outgoing node to the file receiving node. In the directed event chain, business events serve as event nodes, and link edges represent directed connections between event nodes. For isolated events in the candidate event set that lack business object identifiers, lack event association identifiers, and cannot establish relationships with other events through transaction association identifiers, the event chain construction module does not forcibly connect them to the directed event chain. Instead, it retains their original collection records for subsequent supplementary collection or anomaly investigation.

[0035] 300. Logical clock generation module, used to maintain the vector clock corresponding to each business system with the source system identifier as the vector dimension, generate the logical timestamp of the corresponding business event when an event occurs within the business system, and merge the vector clocks during cross-system calls, message passing, data synchronization or file transfer; In this embodiment, the logical clock generation module 300 receives the directed event chain generated by the event chain construction module 200 and generates logical timestamps for the business events in the directed event chain. The logical timestamps are not based on a single physical time, but rather on vector components corresponding to each business system to represent the logical relationship between business events. Since the business management system, process approval system, data interface system, file collaboration system, and interface service in an enterprise generate logs separately, and there are inconsistencies in server time, log writing delays, asynchronous message consumption, and delayed file transfers between different systems, relying solely on event time sorting would lead to misjudgments of cross-system event relationships. Therefore, this module establishes a vector dimension based on the source system identifier and records the logical progression status of business events in different source systems using a vector clock.

[0036] The source system identifier is used to distinguish the system to which a business event belongs. For example, the business management system is denoted as source system S1, the process approval system as source system S2, the data interface system as source system S3, the file collaboration system as source system S4, and the interface service as source system S5. The above identifiers are only used to illustrate the method of distinguishing different source systems and do not limit specific naming rules. Each source system corresponds to a vector component in the vector clock, and this vector component records the logically increasing state of business events within that source system.

[0037] The logical clock generation module includes a vector initialization unit, an internal event time update unit, and a cross-system event merging unit; The vector initialization unit is used to establish vector dimensions based on the source system identifier of the already connected business systems, and maintain a corresponding vector clock for each business system; when a new business system is connected, the vector initialization unit expands the corresponding vector dimension for the new source system identifier. The vector initialization unit establishes a unified set of vector dimensions based on the source system identifier when multiple business systems are connected, and maintains a current vector clock for each business system. Initially, the vector components corresponding to each source system are set to their initial values. When a new business system is connected, the vector initialization unit adds a new vector dimension to the new source system identifier and supplements the existing vector clock with the initial value of this new dimension, ensuring that the business events generated by the new business system maintain the same vector dimension structure as the business events generated by existing business systems.

[0038] The internal event update time unit is used to increment the vector component of the source system identifier corresponding to the business event when a business event generated within the same business system is detected, and to use the incremented vector clock as the logical timestamp of the business event. In this context, business events generated within the same business system refer to those with the same source system identifier and that do not involve cross-system calls, message passing, data synchronization, or file transfer. For example, if a purchasing staff member creates a purchase request in the workflow approval system and then submits it for approval in the same workflow approval system, both the creation and submission events are considered internal events within the workflow approval system. The update time unit of internal events is sequentially incremented by the vector component corresponding to the workflow approval system, and the updated vector clock is appended to the corresponding business event, thus establishing a logical sequence relationship between events within the same business system.

[0039] The cross-system event merging unit is used to obtain the logical timestamp carried by the sending-side business event and the vector clock currently maintained by the receiving-side business system when a business event corresponding to a cross-system call, message passing, data synchronization or file transfer is detected. The unit then takes the maximum value of both according to the same vector dimension and increments the vector component of the source system identifier corresponding to the receiving-side business system to generate the logical timestamp of the receiving-side business event.

[0040] Taking the synchronization of procurement approval results as an example, the approval pass event in the process approval system carries its logical timestamp. After the data interface system receives the approval pass result, the cross-system event merging unit obtains the logical timestamp of the sending side and the vector clock currently maintained by the data interface system. It then takes the maximum value of both along the same vector dimension and increments the corresponding vector component of the data interface system to generate the logical timestamp of the interface call event. When the data interface system continues to synchronize the approval result to the business management system, the business management system generates the logical timestamp of the procurement order status update event in the same way. For document transfer events, asynchronous compensation events, and eventual consistency confirmation events, the logical clock generation module also generates logical timestamps according to the source system identifier and cross-system event relationship, ensuring that they have a comparable logical position in the directed event chain.

[0041] In this embodiment, logical timestamps are used to characterize the logical causal relationship between business events. For two business events, if the logical timestamp of the first business event is not greater than the logical timestamp of the second business event in any of its vector components, and at least one vector component is less than the corresponding vector component of the second business event, then the first business event is considered to be logically prior to the second business event; if the logical timestamps of the two business events do not satisfy the above relationship, then they are considered to be concurrent events. This determination is made by comparing the vector components item by item.

[0042] 400. Passive causal verification module, used to perform causal partial order verification on adjacent events in the directed event chain based on the logical timestamp, determine the causal sequence, concurrency or causal missing state between events, and mark the causal missing state as an existing causal anomaly; In this embodiment, the passive causality verification module 400 receives the directed event chain generated by the event chain construction module 200 and the logical timestamps generated by the logical clock generation module 300 for each business event. This module is used to determine whether adjacent events in the directed event chain satisfy the logical causal relationship required by the business link. When a link edge indicates the existence of a triggering relationship, but the logical timestamp does not support this triggering relationship and there is no corresponding compensation or confirmation event, the exception is marked as an existing causal exception. The existing causal exception refers to a causal exception that already exists in the directed event chain before the probe event injection.

[0043] The passive causality verification module includes a partial order comparison unit, a compensation mapping index unit, and a state determination unit. The partial order comparison unit is used to obtain the logical timestamps of adjacent first and second business events in the directed event chain, and compare the logical timestamps of the first and second business events according to the same vector dimension. In this context, two business events directly connected via a link edge are considered adjacent events. The first business event is the upstream event of the link edge, and the second business event is the downstream event of the link edge. The partial order comparison unit compares the vector components of the two logical timestamps item by item according to the same vector dimension corresponding to the source system identifier. If all vector components of the first business event are not greater than the corresponding vector component of the second business event, and at least one vector component is less than the corresponding vector component of the second business event, then the comparison result indicates that the first business event logically precedes the second business event. If the two logical timestamps do not satisfy the above relationship, then the comparison result indicates that they are in a concurrent state. A concurrent state does not directly indicate an anomaly; the state determination unit further determines whether it belongs to causal missing by combining the link edge type, cross-system call relationship, and compensation mapping index.

[0044] The compensation mapping index unit is used to establish an asynchronous compensation-original call mapping index based on the original transaction identifier, compensation association identifier, and consistency confirmation identifier; The original transaction identifier, derived from the interface call log, identifies a single original cross-system call. The compensation association identifier, derived from the asynchronous compensation record, identifies the compensation processing performed in response to original call failures, timeouts, or inconsistent states. The consistency confirmation identifier, derived from the consistency confirmation record, identifies the confirmation result after cross-system data synchronization is completed. The compensation mapping index unit establishes a mapping relationship between original transaction identifiers, compensation association identifiers, and consistency confirmation identifiers with the same or corresponding transaction relationships, forming an asynchronous compensation-original call mapping index. For example, the approval result synchronization generates an original transaction identifier T001, the synchronization timeout generates a compensation association identifier C001, and the business management system generates a consistency confirmation identifier K001 after completing the state update. The compensation mapping index unit establishes an index relationship between T001, C001, and K001.

[0045] The state determination unit is used to determine that the first business event is in a causal sequence state relative to the second business event when all vector components of the logical timestamp of the first business event are less than or equal to the corresponding vector components of the logical timestamp of the second business event, and at least one vector component is less than the corresponding vector component of the logical timestamp of the second business event. When the logical timestamp of the first business event and the logical timestamp of the second business event do not satisfy the above-mentioned causal sequence determination conditions, it is determined that the first business event and the second business event are in a concurrent state. In the directed event chain, there exists a link edge from the first business event to the second business event. The cross-system call relationship corresponding to the link edge requires the first business event to trigger the second business event. When the first business event is not in a causal order relative to the second business event, the state determination unit detects whether there is an asynchronous compensation event or an eventual consistency confirmation event corresponding to the link edge based on the asynchronous compensation-original call mapping index. Specifically, the requirement that a cross-system call relationship corresponding to a link edge triggers a second business event means that the link edge is established by an interface call identifier, a synchronization task number, a message passing relationship, or a file transfer relationship, and that this relationship in the business chain indicates that an upstream event should cause a downstream event. If an asynchronous compensation event corresponding to the link edge exists in the compensation mapping index, it indicates that compensation processing has been triggered after the original call failed, timed out, or became inconsistent in state; if a corresponding eventual consistency confirmation event exists, it indicates that cross-system data synchronization has been confirmed by the receiving side. In any of the above cases, the state determination unit does not directly mark the link as an existing causal anomaly, but retains the concurrent state or compensation confirmation state of the link for subsequent generation of event chain credibility data.

[0046] If no asynchronous compensation event or eventual consistency confirmation event corresponding to the link edge is detected, it is determined that the first service event and the second service event are in a state of causal incompleteness.

[0047] In this embodiment, a causal missing state indicates that a business triggering relationship exists in a directed event chain, but this triggering relationship is not supported by a logical timestamp and is not explained by an asynchronous compensation event or an eventual consistency confirmation event. When the existing causal anomaly is recorded, it is associated with at least the first business event, the second business event, the link edge identifier, the target business object identifier, the source system identifier, and the anomaly determination result. If the anomaly occurrence node or anomaly occurrence channel has been determined by the link edge, it is recorded together; if the anomaly occurrence channel cannot be determined by the currently collected data, it is marked as unknown in the subsequent event chain credibility data. In this way, the existing causal anomaly and the subsequent anomaly baseline marking form a corresponding relationship, avoiding confusion between probe propagation anomalies and link anomalies that existed before probe injection.

[0048] 500. Causal watermark probe injection module, used to determine the target link and its corresponding expected propagation subgraph based on the directed event chain and the existing causal anomaly, generate probe events with causal watermark, probe identifier, target link identifier, logical timestamp, non-business impact identifier and anomaly baseline marker, and inject the probe events into the business system interface, message channel, data synchronization channel or file transfer channel corresponding to the target link; In this embodiment, the causal watermark probe injection module 500 is executed after the passive causal verification module 400 completes the existing causal anomaly marking. This module does not directly modify the business status of the actual purchase application, purchase order, or approval result. Instead, it generates probe events with identification tags on the target link and propagates them in a controlled manner through business system interfaces, message channels, data synchronization channels, or file transfer channels. After the probe events propagate along the target link, a probe propagation log is formed, which is used by the probe propagation verification module 600 to reconstruct the actual probe propagation link.

[0049] The target link refers to a partial link selected from a directed event chain that requires active propagation and verification. Taking procurement as an example, the target link includes at least one of the following: approval approval event in the process approval system, approval result synchronization event in the data interface system, purchase order status update event in the business management system, and procurement attachment archiving event in the document collaboration system. The target link does not need to cover the entire procurement business process, but rather is selected around the cross-system interface, message channel, data synchronization channel, or document flow channel to be verified.

[0050] The causal watermark probe injection module includes a target link determination unit, a causal watermark generation unit, and a probe event encapsulation unit. The target link determination unit is used to determine the target link based on the directed event chain and the existing causal anomaly, and further filter or prioritize the target link based on at least one of the following: number of cross-system nodes, historical anomaly results, most recent verification time, link priority, or system load, to obtain candidate target links. During the initial verification, the historical anomaly results are empty, and the most recent verification time is an empty value or the system initial access time. Among them, the number of cross-system nodes is used to characterize the number of business systems involved in the target link; the historical anomaly results are used to characterize the situation where the link has anomalies in historical passive causal verification or probe propagation verification; the most recent verification time is used to characterize the time when the link last performed probe verification; the link priority is used to characterize the importance of the link in the enterprise business process; and the system load is used to characterize the current processing pressure of the business system or channel corresponding to the target link.

[0051] The target link determination unit is used to preferentially select candidate target links that do not have existing causal anomalies or whose number of existing causal anomalies is less than a preset threshold as the target link; when all candidate target links have existing causal anomalies and the number of existing causal anomalies is not less than the preset threshold, the target link is selected according to the anomaly level. Among them, existing causal anomalies originate from the passive causal verification module 400. The target link determination unit prioritizes links that have not been marked as having existing causal anomalies, or links with fewer than a preset threshold of existing causal anomalies, to reduce attribution confusion between probe propagation anomalies and existing link anomalies. If all candidate target links have existing causal anomalies, the target link determination unit selects target links according to the anomaly level; candidate target links with higher anomaly levels are prioritized as target links. The anomaly level is determined based on the number of business systems involved in the anomaly link, the channel through which the anomaly occurs, the number of times the anomaly is repeated, or the priority of the business link.

[0052] The target link determination unit is further configured to generate a target link identifier, an abnormal baseline marker, and a expected propagation subgraph based on the target link; wherein, the abnormal baseline marker is used to identify whether the target link is in a normal baseline state or an existing abnormal baseline state before probe injection; the expected propagation subgraph is a set of target link nodes corresponding to the target link in the directed event chain and a set of directed edges connecting the set of target link nodes, the expected propagation subgraph includes at least a link ingress event node, at least one link egress event node, a set of target link nodes, and a set of directed edges, the set of target link nodes is obtained by intercepting the service event nodes corresponding to the target link identifier in the directed event chain, and the set of directed edges is obtained by intercepting the link edges already generated between the target link nodes; the directed edges in the set of directed edges are used to form a branch path from the link ingress event node to at least one link egress event node; The target link identifier is used to uniquely identify a link to be verified. Abnormal baseline marking includes normal baseline status and existing abnormal baseline status. Normal baseline status indicates that the target link was not marked as having an existing causal anomaly before probe injection; existing abnormal baseline status indicates that the target link already had a causal missing state before probe injection. The expected propagation subgraph consists of a set of target link nodes and a set of directed edges. The set of target link nodes is obtained by intercepting the business event nodes corresponding to the target link identifier in the directed event chain, and the set of directed edges is obtained by intercepting the link edges already generated between the target link nodes. For linear links, the expected propagation subgraph represents a path from the entry node to the exit node; for message broadcasting, file distribution, or multi-system synchronization links, the expected propagation subgraph represents a directed subgraph with at least one branch path.

[0053] The causal watermark generation unit is used to generate a causal watermark based on the probe identifier, target link identifier, source system identifier, and logical timestamp. Among them, the probe identifier is used to distinguish different probe events; the target link identifier is used to identify the target link corresponding to the probe event; the source system identifier is used to record the injection source of the probe event; and the logical timestamp is used to record the logical position of the probe event at the time of injection. The logical timestamp is generated by the logical clock generation module 300 based on the injection-side source system identifier and the current vector clock when the probe event is injected at the target link inlet side, or it is obtained by incrementing the logical timestamp corresponding to the target link inlet event node by the injection-side vector component.

[0054] The causal watermark generation unit concatenates the probe identifier, target link identifier, source system identifier, and logical timestamp according to a preset field order, and generates a digest value or checksum from the concatenation result. This digest value or checksum is then used as the causal watermark. The causal watermark propagates along the target link with the probe event and is written to the probe propagation log. The causal watermark is not related to business approval opinions, purchase amounts, or supplier information, and does not participate in actual business processing.

[0055] The probe event encapsulation unit is used to encapsulate the causal watermark, probe identifier, target link identifier, logical timestamp, non-business impact identifier, and abnormal baseline marker into the event metadata of the probe event, and provide the encapsulated probe event to the business system interface, message channel, data synchronization channel, or file transfer channel corresponding to the target link.

[0056] In this embodiment, the event metadata of a probe event includes at least the probe identifier, target link identifier, causal watermark, logical timestamp, source system identifier, non-business impact identifier, and abnormal baseline marker. For business system interfaces, the probe event is sent to the receiving business system as interface request metadata with a non-business impact identifier; for message channels, the probe event is delivered with the message as a message header field or message attribute; for data synchronization channels, the probe event is transmitted as a verification record or isolation record in the synchronization task; for file transfer channels, the probe event is transmitted as file metadata, file transfer record, or collaborative platform extended attributes.

[0057] When generating the probe event, the causal watermarking probe injection module configures at least one of the following for the non-business impact identifier: an isolation storage flag, a rollback transaction flag, a read-only verification flag, or a filtering flag, based on the channel type corresponding to the target link. It should be understood that the isolation storage flag, rollback transaction flag, read-only verification flag, and filtering flag can be selected individually or used in combination depending on the actual verification scenario, to achieve flexible processing of different probe events in different receiving-side business systems or file transfer nodes. For example, in a simulated test environment, a rollback transaction flag can be used to verify link integrity without generating persistent data; in a production environment, a read-only verification flag or a filtering flag can be used to avoid affecting real business data. Those skilled in the art can determine the specific configuration method of the above-mentioned non-business impact identifier based on the channel type of the target link and verification requirements.

[0058] Among them, the isolated storage flag is used to instruct the receiving side business system to write probe events to the isolated storage area and not to store them together with real purchase applications, purchase orders or approval documents; the rollback transaction flag is used to instruct the receiving side business system to roll back the data changes corresponding to the probe events after completing the probe propagation verification; the read-only verification flag is used to instruct the receiving side business system to only parse the metadata of the probe events and generate probe propagation logs, and not to write them to the business master table; the filtering flag is used to instruct the message channel or file transfer node to stop the probe events from entering the real business processing stage after recognizing them.

[0059] When the probe event is injected through a business system interface or data synchronization channel, the non-business impact identifier is used to instruct the receiving business system to write the probe event to an isolated storage area, roll back the data changes corresponding to the probe event, or perform rollback processing after isolation storage. When the probe event is injected through a message channel or file transfer channel, the non-business impact identifier is used to instruct the receiving business system or file transfer node to perform read-only verification or filtering processing on the probe event. The probe propagation log corresponding to the probe event is written through an audit record channel independent of the probe event business transaction, so that the probe event leaves a traceable propagation record without changing the state of the real business object.

[0060] 600. Probe propagation verification module, used to collect probe propagation logs generated by the probe event in the target link, and generate the actual probe propagation link based on causal watermark and logical timestamp; wherein, the probe propagation logs are generated by the business system interface, middleware, data synchronization node or file transfer node through an audit record channel independent of the probe event business transaction; In this embodiment, the probe propagation verification module 600 receives probe propagation logs generated and injected by the causal watermarking probe injection module 500. These probe propagation logs record the process of probe events being received, parsed, forwarded, synchronized, filtered, isolated, stored, or rolled back in the target link. The probe propagation logs do not depend on changes in the business status of actual purchase requests, purchase orders, or approval documents. Instead, they are written through an audit record channel independent of the probe event's business transaction, thus retaining verifiable propagation traces even after the probe event is isolated, filtered, or rolled back.

[0061] The probe propagation logs originate from business system interfaces, middleware, data synchronization nodes, or file transfer nodes. Taking procurement as an example, the business system interface records the probe event reception time, interface call identifier, target link identifier, and causal watermark; the middleware records the message sending node, message receiving node, message subject, message consumption result, and causal watermark; the data synchronization node records the synchronization task number, synchronization source, synchronization target, synchronization result, and logical timestamp; and the file transfer node records the file identifier, transfer object, transfer time, channel type, and probe identifier.

[0062] The probe propagation verification module includes a probe log matching unit, a propagation node determination unit, and an actual link generation unit; The probe log matching unit is used to identify log records containing the same probe identifier or the same causal watermark from the probe propagation log, and to classify the log records as belonging to the same probe event. The probe identifier is used to distinguish different probe events, while the causal watermark is used to characterize the target link to which the probe event belongs and its logical location. The probe log matching unit uses the probe identifier as the primary matching field and the causal watermark as an auxiliary matching field to aggregate probe propagation logs distributed across different business systems, interfaces, middleware, data synchronization nodes, and file transfer nodes into a single log set for the same probe event. For nodes that only retain the causal watermark and not the complete probe identifier, the probe log matching unit performs attribution matching based on the causal watermark, target link identifier, and source system identifier, avoiding the mixing of probe events injected at different times or from different target links.

[0063] The propagation node determination unit is used to determine the propagation node of the probe event in different business systems, business system interfaces, message channels, data synchronization channels or file transfer channels based on the source system identifier, event time, logical timestamp and channel type in the log record; The source system identifier is used to determine the business system or channel node to which the probe propagation log belongs; the event time is used to record the physical time when the probe propagation log was generated; the logical timestamp is used to indicate the logical position of the probe event during the propagation process; and the channel type is used to distinguish between business system interfaces, message channels, data synchronization channels, or file transfer channels. The propagation nodes include at least one of the following: interface receiving nodes, message delivery nodes, message consumption nodes, data synchronization nodes, file transfer nodes, isolated storage nodes, read-only verification nodes, filtering processing nodes, or rollback processing nodes.

[0064] The propagation node determination unit logically sorts multiple propagation logs of the same probe event based on logical timestamps. If two propagation logs belong to consecutive processing events within the same source system, their order is determined based on the increasing relationship of the vector components corresponding to that source system. If two propagation logs come from different source systems, the logical relationship between propagation nodes is determined by combining the causal partial order relationship between the causal watermark and the logical timestamp. For propagation nodes exhibiting concurrent states, the propagation node determination unit treats them as parallel branch nodes in the actual propagation link of the same probe, without forcibly merging them into a linear order.

[0065] The actual link generation unit is used to determine the connection order between the propagation nodes based on the causal watermark matching relationship between the propagation nodes, the causal partial order relationship of the logical timestamps, and the channel type corresponding to the propagation nodes, and to generate the probe actual propagation link based on the propagation nodes and the connection relationship between the propagation nodes.

[0066] Among them, the causal watermark matching relationship is used to confirm that the propagation nodes belong to the same probe event and the same target link; the causal partial order relationship of the logical timestamp is used to determine the logical sequence or concurrency relationship between propagation nodes; and the channel type is used to determine the connection method between propagation nodes. For business system interfaces, the actual link generation unit generates connection relationships according to the interface call direction; for message channels, connection relationships are generated according to the message sending node to the message receiving node; for data synchronization channels, connection relationships are generated according to the synchronization source to the synchronization target; and for file transfer channels, connection relationships are generated according to the file outflow node to the file receiving node.

[0067] In cases where probe propagation logs are missing, the actual link generation unit generates a portion of the probe's actual propagation link based on the collected propagation nodes, while retaining the missing locations. These missing locations are determined by the target link identifier, causal watermark, and channel type between adjacent propagation nodes. In cases where probe events are filtered or rolled back, the actual link generation unit does not consider filtering or rollback as missing logs. If the probe propagation log records a filtering or rollback processing node, and this processing matches a non-business impact identifier, then the filtering or rollback processing node is included in the probe's actual propagation link.

[0068] In this embodiment, the data structure of the actual probe propagation link includes probe identifier, target link identifier, causal watermark, propagation node set, connection relationship between propagation nodes, channel type, logical timestamp verification result, and log attribution result.

[0069] 700. Fusion verification output module, used to associate and verify the actual propagation link of the probe with the expected propagation subgraph. When the actual propagation link of the probe and the matching branch in the expected propagation subgraph are inconsistent in the target link node, propagation direction or causal partial order relationship, the probe propagation abnormal result is output, and the probe propagation abnormal result, the existing causal abnormality and the abnormal baseline mark are written into the corresponding event chain credibility data.

[0070] In this embodiment, the fusion verification output module 700 receives the existing causal anomaly output by the passive causal verification module 400, the expected propagation subgraph generated by the causal watermark probe injection module 500, and the actual probe propagation link generated by the probe propagation verification module 600. The fusion verification output module 700 does not directly use the complete directed event chain as the comparison object for the probe link, but instead uses the expected propagation subgraph corresponding to the target link as the comparison benchmark. Therefore, probe events are only verified within the target link range; historical event nodes before the probe injection point, side nodes unrelated to the target link, and other service nodes not selected as the target link do not participate in this fusion verification.

[0071] The fusion verification output module includes a branch coverage verification unit, a propagation direction consistency verification unit, and a causal consistency verification unit. The branch coverage verification unit is used to match the propagation nodes in the actual propagation link of the probe with the target link nodes in the expected propagation subgraph; wherein, the matching includes: determining the probe event to which the propagation node belongs based on the target link identifier and causal watermark carried by the propagation node, and locating the corresponding target link node in the expected propagation subgraph based on the source system identifier and logical timestamp vector of the propagation node; The target link identifier is used to define the link to be verified to which the propagation node belongs; the causal watermark is used to define the probe event to which the propagation node belongs; the source system identifier is used to determine the business system or channel node where the propagation node is located; and the logical timestamp vector is used to determine the logical position of the propagation node in the target link. The branch coverage verification unit first filters out propagation nodes belonging to the same probe event based on the target link identifier and the causal watermark, and then locates the propagation node to the link entry event node, link intermediate event node, or link exit event node in the expected propagation subgraph based on the source system identifier and the logical timestamp vector.

[0072] The complete branch path is determined by the link entry event node, the set of directed edges, and the link exit event node in the expected propagation subgraph; the branch coverage verification unit is used to generate a branch coverage anomaly result when there is no propagation node and connection relationship in the actual propagation link of the probe that matches any complete branch path in the expected propagation subgraph. In this embodiment, a complete branch path refers to a path that starts from the ingress event node in the expected propagation subgraph and extends along directed edges to any egress event node. For a single-path target link, a complete branch path is a link between the ingress event node and the egress event node; for target links involving message broadcasting, file distribution, or multi-system synchronization, the expected propagation subgraph includes multiple complete branch paths. A probe verification is considered successful if at least one complete branch path is covered by the actual propagation link.

[0073] The propagation direction consistency verification unit is used to compare the propagation direction in the actual propagation link of the probe with the propagation direction of the matched complete branch path in the expected propagation subgraph, and generate an abnormal propagation direction result when the upstream and downstream nodes of the two are inconsistent. The propagation direction is determined by the connections in the actual probe propagation path and the directed edges in the expected propagation subgraph. After completing branch coverage matching, the propagation direction consistency verification unit compares the propagation direction edge by edge for the matched complete branch path. An abnormal propagation direction result indicates that the probe event has reached the relevant node, but the propagation order or upstream / downstream relationship between the nodes is inconsistent with the expected propagation subgraph; this abnormality is different from the branch coverage abnormality, which focuses on the complete path coverage.

[0074] The causal consistency verification unit is used to verify adjacent target link nodes on the matched complete branch path in the expected propagation subgraph; wherein, when the causal partial order verification result of the adjacent target link node in the passive causal verification module is concurrent, the causal consistency verification corresponding to the adjacent target link node is skipped; when the causal partial order verification result of the adjacent target link node in the passive causal verification module is causal sequential, the logical timestamp causal partial order relationship of the corresponding propagation node in the actual propagation link of the probe is compared with the causal sequential state, and a causal partial order abnormal result is generated when the two are inconsistent; wherein, at least one of the branch coverage abnormal result, propagation direction abnormal result, or causal partial order abnormal result constitutes the probe propagation abnormal result.

[0075] In this embodiment, the causal consistency check does not perform mandatory checks on all edges in the expected propagation subgraph, but instead performs checks on the complete branch path matched by the actual propagation link of the probe. If the adjacent target link node on the matched complete branch path is determined to be in a concurrent state in the passive causal verification module 400, it indicates that the edge corresponds to a legitimate concurrent, broadcast branch, or asynchronous processing scenario, and the causal consistency check unit skips the causal consistency check of that edge. If the adjacent target link node is determined to be in a causal order state in the passive causal verification module 400, the logical timestamp causal partial order relationship of the corresponding propagation nodes in the actual propagation link of the probe is compared; if the probe propagation nodes do not reflect the same causal order relationship, a causal partial order anomaly result is generated.

[0076] The event chain credibility data includes event chain identifier, business object identifier, target link identifier, existing causal anomaly, probe propagation anomaly result, anomaly baseline marker, anomaly occurrence node, anomaly occurrence channel, causal watermark matching result, logical timestamp verification result, and actual probe propagation link; the fusion verification output module is used to generate structured output records according to the event chain credibility data, and associate and store the structured output records with the corresponding directed event chain; when the anomaly occurrence node and anomaly occurrence channel cannot be obtained from the existing causal anomaly, they are marked as unknown.

[0077] Among them, the event chain identifier is used to identify the directed event chain corresponding to the structured output record; the business object identifier is used to identify the corresponding purchase application, purchase order, contract or other business object; the target link identifier is used to identify the target link corresponding to this probe verification; the existing causal anomaly is used to record the causal missing state discovered by the passive causal verification module 400 before probe injection; the probe propagation anomaly result is used to record the branch coverage anomaly, propagation direction anomaly or causal partial order anomaly discovered during probe propagation; the abnormal baseline marker is used to distinguish whether the target link is in a normal baseline state or an existing abnormal baseline state before probe injection.

[0078] The anomaly occurrence node is used to record the link node corresponding to the anomaly. The anomaly occurrence channel is used to record the business system interface, message channel, data synchronization channel, or file transfer channel corresponding to the anomaly. The causal watermark matching result is used to record whether the propagation nodes in the actual probe propagation link carry a causal watermark consistent with the probe event. The logical timestamp verification result is used to record whether the propagation nodes on the matched complete branch path satisfy the corresponding causal partial order relationship, or whether the verification is skipped because the adjacent target link nodes are in a concurrent state.

[0079] In procurement operations, the structured output records generated by the fusion verification output module 700 include the procurement application number, target link identifier, abnormal baseline marker, probe actual propagation link, branch coverage result, propagation direction result, causal partial order result, and existing causal anomaly result. If the approval result synchronization link does not have any existing causal anomalies before probe injection, but the probe actual propagation link has not reached the business management system, then the existing causal anomaly in the structured output record will be empty, the probe propagation anomaly result will be a branch coverage anomaly, and the anomaly occurrence channel record will be the data synchronization channel between the data interface system and the business management system. If the target link already has existing causal anomalies before probe injection, the structured output record will record both the existing causal anomaly and the probe propagation anomaly result, and the target link will be identified as having an existing abnormal baseline state through the abnormal baseline marker.

[0080] In this embodiment, when the actual probe propagation path differs from the expected propagation subgraph, the fusion verification output module 700 associates the probe propagation anomaly result with the anomaly baseline marker. Specifically: if the anomaly baseline marker corresponding to the target path is an existing anomaly baseline state (i.e., the passive causal verification module 400 has already marked an existing causal anomaly on the target path), the fusion verification output module 700 marks this probe propagation anomaly as a propagation manifestation of an existing causal anomaly, and does not record it as a newly generated independent anomaly in the probe propagation anomaly result; if the anomaly baseline marker corresponding to the target path is a normal baseline state, the fusion verification output module 700 records the probe propagation anomaly result in the probe propagation anomaly field, and classifies it as a newly generated anomaly during the probe propagation process in the event chain credibility data. Thus, when the probe fails to complete propagation due to damage to the target path entry interface, message queue blockage, or file transfer channel malfunction, if the anomaly manifestation coincides with the location of an existing causal anomaly, the fusion verification output module 700 avoids misjudging the probe propagation failure caused by existing defects in the path as a new anomaly introduced by probe injection or the propagation mechanism itself through the anomaly baseline marker, thereby improving the accuracy of the anomaly report.

[0081] In this embodiment, when the causal consistency verification unit skips the causal consistency verification because the adjacent target link node is determined to be in a concurrent state in the passive causal verification module 400, the coverage integrity verification of the branch containing the concurrent edge is still completed independently by the branch coverage verification unit. Taking the scenario where data synchronization is initiated simultaneously to the business management system and the file collaboration system after the approval result is synchronized as an example, the approval event triggers two parallel synchronization events, and the passive causal verification module 400 determines that the two parallel edges are in a concurrent state. The causal consistency verification unit skips the causal partial order mandatory verification for these two parallel edges, but the branch coverage verification unit still verifies whether there are propagation nodes and connection relationships corresponding to the business management system branch and the file collaboration system branch respectively in the actual propagation link of the probe. If either branch is not covered by the actual propagation link of the probe, the branch coverage verification unit generates a branch coverage abnormal result and marks it as an uncovered branch in the event chain credibility data. Thus, for legitimate concurrent edges, this invention avoids false alarms by skipping the causal partial order mandatory verification, while retaining the quantitative evaluation capability of the integrity of concurrent branches through branch coverage verification, ensuring that the skipped causal verification in concurrent scenarios does not cause verification blind spots.

[0082] Example 2, see Figure 1 As shown in the figure, this embodiment provides an intelligent assessment system for enterprise digital transformation, and its specific system structure is as follows.

[0083] The system includes: a multi-source event acquisition module 100, an event chain construction module 200, a logic clock generation module 300, a passive causal verification module 400, a causal watermark probe injection module 500, a probe propagation verification module 600, and a fusion verification output module 700.

[0084] The multi-source event acquisition module 100 further includes an event field extraction unit and an event standardization unit. The event chain construction module 200 further includes an event grouping unit, a link edge generation unit, and a link direction determination unit. The logical clock generation module 300 further includes a vector initialization unit, an internal event update time unit, and a cross-system event merging unit. The passive causal verification module 400 further includes a partial order comparison unit, a compensation mapping index unit, and a state determination unit. The causal watermark probe injection module 500 further includes a target link determination unit, a causal watermark generation unit, and a probe event encapsulation unit. The probe propagation verification module 600 further includes a probe log matching unit, a propagation node determination unit, and an actual link generation unit. The fusion verification output module 700 further includes a branch coverage verification unit, a propagation direction consistency verification unit, and a causal consistency verification unit.

[0085] In terms of system connectivity and data flow, the multi-source event acquisition module 100 is connected to the event chain construction module 200 and the logical clock generation module 300, respectively, to output standardized generated business events to the event chain construction module 200 and the logical clock generation module 300. The event chain construction module 200 and the logical clock generation module 300 are connected to the passive causal verification module 400, respectively, to input directed event chains and corresponding logical timestamps to the passive causal verification module 400. The passive causal verification module 400 is connected to the causal watermark probe injection module 500, to transmit marked existing causal anomalies to the causal watermark probe injection module 500.

[0086] The causal watermark probe injection module 500 is connected to the probe propagation verification module 600 through an external target link (i.e., the business system interface, message channel, data synchronization channel, or file transfer channel), and is used to inject the generated probe events into the target link and provide the probe propagation log generated by the target link to the probe propagation verification module 600; at the same time, the causal watermark probe injection module 500 is also directly connected to the fusion verification output module 700, and is used to transmit the generated expected propagation subgraph to the fusion verification output module 700.

[0087] The probe propagation verification module 600 is connected to the fusion verification output module 700 and is used to transmit the generated probe actual propagation link to the fusion verification output module 700.

[0088] The fusion verification output module 700 is used to receive the expected propagation subgraph and the actual propagation link of the probe, and output the event chain credibility data after association and storage.

[0089] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. An intelligent assessment system for enterprise digital transformation, characterized in that: include: The multi-source event acquisition module is used to collect business logs, operation logs, interface call logs, approval flow logs, file flow metadata, asynchronous compensation records, and consistency confirmation records generated by multiple business systems, and extract business events; the business events include at least one of ordinary business events, asynchronous compensation events, or eventual consistency confirmation events; The event chain construction module is used to construct a directed event chain for the same business object according to the business object identifier, event type, source system identifier, and cross-system call relationship; The logical clock generation module is used to maintain the vector clocks corresponding to each business system with the source system identifier as the vector dimension, generate logical timestamps when events occur within the business system, and merge the vector clocks during cross-system calls, message passing, data synchronization, or file transfer. The passive causal verification module is used to perform causal partial order verification on adjacent events in the directed event chain based on the logical timestamp, determine the causal sequence, concurrency or causal missing state, and mark the causal missing state as an existing causal anomaly. The causal watermark probe injection module is used to determine the target link and the corresponding expected propagation subgraph based on the directed event chain and the existing causal anomaly. The expected propagation subgraph includes at least the target link node set, the directed edge set, the link entry event node and at least one link exit event node corresponding to the target link in the directed event chain. Generate probe events with causal watermarks, probe identifiers, target link identifiers, logical timestamps, non-business impact identifiers, and abnormal baseline markers, and inject the probe events into the business system interface, message channel, data synchronization channel, or file transfer channel corresponding to the target link; The probe propagation verification module is used to collect probe propagation logs generated by the probe events and generate the actual probe propagation chain based on causal watermarks and logical timestamps; the probe propagation logs are generated through an audit record channel independent of the probe event business transactions. The fusion verification output module is used to correlate and verify the actual propagation link of the probe with the expected propagation subgraph. When the two are inconsistent in the target link node, propagation direction or causal partial order relationship, the probe propagation anomaly result is output, and the probe propagation anomaly result, the existing causal anomaly and the anomaly baseline mark are written into the event chain credibility data.

2. The intelligent assessment system for enterprise digital transformation according to claim 1, characterized in that, The multi-source event acquisition module includes an event field extraction unit and an event standardization unit. The event field extraction unit is used to extract event fields from the business logs, operation logs, interface call logs, approval flow logs, file flow metadata, asynchronous compensation records, and consistency confirmation records. The event fields include at least one of the following: business object identifier, event type, source system identifier, event time, interface call identifier, file identifier, original transaction identifier, compensation association identifier, or consistency confirmation identifier. The event standardization unit is used to generate the business event by processing the event fields according to a unified event format. The unified event format includes at least the business object identifier, event type, source system identifier, event time, event association identifier, and transaction association identifier.

3. The intelligent assessment system for enterprise digital transformation according to claim 2, characterized in that, The event chain construction module includes an event grouping unit, a link edge generation unit, and a link direction determination unit. The event grouping unit is used to group the business events according to the business object identifier. The link edge generation unit is used to generate a link edge between two related business events based on the event type, source system identifier, and cross-system call relationship. The link direction determination unit is used to determine the direction of the link edge based on the caller and callee, sender and receiver, synchronization source and synchronization target, or file flow order.

4. The intelligent assessment system for enterprise digital transformation according to claim 1, characterized in that, The logical clock generation module includes a vector initialization unit, an internal event update time unit, and a cross-system event merging unit. The vector initialization unit is used to establish vector dimensions based on the source system identifier and maintain the vector clocks corresponding to each business system. The internal event update time unit is used to increment the corresponding vector component when a business event occurs within the same business system and generate a logical timestamp for that business event. The cross-system event merging unit is used to take the maximum value of the sending-side logical timestamp and the receiving-side vector clock dimension by dimension when a cross-system event occurs, and increment the corresponding vector component on the receiving side to generate a logical timestamp for the receiving-side business event.

5. The intelligent assessment system for enterprise digital transformation according to claim 1, characterized in that, The passive causal verification module includes a partial order comparison unit, a compensation mapping index unit, and a state determination unit; the partial order comparison unit is used to compare the logical timestamps of adjacent first and second business events that are directly connected by a link edge in the directed event chain. The compensation mapping index unit is used to establish an asynchronous compensation-original call mapping index based on the original transaction identifier, compensation association identifier, and consistency confirmation identifier; The state determination unit is used to determine whether the first business event and the second business event are in a causal sequence state or a concurrent state based on the logical timestamp; when the link edge requires the first business event to trigger the second business event, and the first business event is not in a causal sequence state relative to the second business event, the state determination unit detects whether there is a corresponding asynchronous compensation event or an eventual consistency confirmation event based on the asynchronous compensation-original call mapping index. If it does not exist, then it is determined that the two are in a state of causal absence.

6. The intelligent assessment system for enterprise digital transformation according to claim 1, characterized in that, The causal watermark probe injection module includes a target link determination unit, a causal watermark generation unit, and a probe event encapsulation unit. The target link determination unit is used to determine the target link based on the directed event chain and the existing causal anomaly, and further filter or prioritize the target link based on at least one of the following: number of cross-system nodes, historical anomaly results, most recent verification time, link priority, or system load, and generate a target link identifier, anomaly baseline marker, and expected propagation subgraph. The expected propagation subgraph is the set of target link nodes and the set of directed edges corresponding to the target link in the directed event chain, and includes a link entry event node, at least one link exit event node, and at least one branch path. The causal watermark generation unit is used to generate a causal watermark based on the probe identifier, target link identifier, source system identifier, and logical timestamp; the probe event encapsulation unit is used to encapsulate the causal watermark, probe identifier, target link identifier, logical timestamp, non-business impact identifier, and abnormal baseline marker into the event metadata of the probe event.

7. The intelligent assessment system for enterprise digital transformation according to claim 6, characterized in that, The non-business impact identifier includes at least one of the following: isolation storage marker, rollback transaction marker, read-only verification marker, or filtering marker; the non-business impact identifier is used to instruct the receiving side business system or file transfer node to perform isolation storage, rollback, read-only verification, or filtering processing on the probe event; the probe propagation log is written through an audit record channel independent of the probe event business transaction.

8. The intelligent assessment system for enterprise digital transformation according to claim 1, characterized in that, The probe propagation verification module includes a probe log matching unit, a propagation node determination unit, and an actual link generation unit; the probe log matching unit is used to classify probe propagation logs into the same probe event based on probe identifiers or causal watermarks. The propagation node determination unit is used to determine the propagation node of the probe event in the target link based on the source system identifier, event time, logical timestamp, and channel type; the actual link generation unit is used to generate the actual propagation link of the probe based on the causal watermark matching relationship between propagation nodes, the causal partial order relationship of logical timestamps, and the channel type.

9. The intelligent assessment system for enterprise digital transformation according to claim 6, characterized in that, The fusion verification output module includes a branch coverage verification unit, a propagation direction consistency verification unit, and a causal consistency verification unit. The branch coverage verification unit is used to match the propagation nodes in the actual propagation link of the probe with the target link nodes in the expected propagation subgraph based on the target link identifier, causal watermark, source system identifier, and logical timestamp vector. The complete branch path is determined by the link entry event node, the set of directed edges, and the link exit event node in the expected propagation subgraph. When there is no propagation node and connection relationship in the actual propagation link of the probe that matches any complete branch path in the expected propagation subgraph, a branch coverage anomaly result is generated. The propagation direction consistency verification unit is used to compare the propagation direction in the actual propagation link of the probe with the propagation direction of the matched complete branch path, and generate a propagation direction anomaly result when the two are inconsistent. The causal consistency verification unit is used to verify the adjacent target link nodes on the matched complete branch path. When the causal partial order verification result of the adjacent target link node is concurrent, the corresponding causal consistency verification is skipped. When the causal partial order verification result of the adjacent target link node is causal sequential, the logical timestamp causal partial order relationship of the corresponding propagation node is compared with the causal sequential state, and a causal partial order anomaly result is generated when the two are inconsistent.

10. The intelligent assessment system for enterprise digital transformation according to claim 1, characterized in that, The event chain credibility data includes event chain identifier, business object identifier, target link identifier, existing causal anomaly, probe propagation anomaly result, anomaly baseline marker, causal watermark matching result, logical timestamp verification result, and probe actual propagation link; the fusion verification output module is used to generate structured output records according to the event chain credibility data, and associate and store the structured output records with the corresponding directed event chain.

Images