Enterprise informatization management integration platform based on big data

Abstract

The invention belongs to the technical field of enterprise informatization management and big data integration, and particularly relates to an enterprise informatization management integration platform based on big data. Comprising an auditing element unified structured acquisition module, a main body unique identifier analysis and failure closed loop module, a caliber version and field mapping version joint locking module and an evidence index binding and consistency verification packaging module. The platform reads interface and field mapping from a service system log according to a configuration table, normalizes the interface and field mapping and writes the interface and field mapping into an event account book collocation state; executing main body gating on the original entry record to generate a main body identifier and writing back the main body identifier; when failure occurs, the reason code is written and blocked, and the failure evidence index is returned; performing node analysis on the aperture script and generating an aperture chain fingerprint; and serializing the event segments, calculating abstracts, constructing batch abstract roots, positioning first inconsistent serial numbers when recalculation is inconsistent, and scheduling and supplementary collection, so as to output a recheckable audit evidence packet. According to the invention, aperture consistency and evidence traceability can be realized.

Description

Technical Field

[0001] This invention belongs to the field of enterprise information management and big data integration technology, specifically relating to an enterprise information management integration platform based on big data. Background Technology

[0002] The Chinese patent application (CN202411785976.4) discloses an integrated enterprise information management platform based on big data. This invention is built upon the Hadoop distributed computing framework, integrating technologies such as MapReduce parallel processing, Spark real-time computing, and HDFS distributed storage. It achieves parallel data processing through swarm intelligence algorithms and pheromone transfer mechanisms, utilizes hierarchical autoencoder networks for heterogeneous data mapping, combines biological cell division mechanisms and entropy balance mechanisms to achieve dynamic resource scheduling, employs adaptive grid partitioning and data temperature stratification technologies to optimize storage management, and builds multi-scale feature fusion and knowledge reasoning based on SparkMLlib to support decision analysis.

[0003] Although this invention overcomes the problems of low data processing efficiency, limited system expansion, and difficulty in data sharing in traditional enterprise information management technology, and provides reliable technical support for enterprise digital transformation, in the scenario of cross-system data caliber and access link integration for personal information protection compliance audit, enterprises deploy multiple business systems in the process of operation and management. These multiple business systems continuously generate operation logs and data processing records during operation. This will lead to the need for enterprises to form verifiable audit materials and traceable links for audit elements and processing links when conducting compliance audits of personal information processing activities. To address the aforementioned issues, existing technologies employ enterprise information management integration platforms that interface with business systems to perform field mapping and data synchronization, writing multi-system data into a data warehouse or data lake. These platforms also deploy unified identity directories and single sign-on to link system accounts with personnel files; deploy log collection components to collect operation logs and generate audit lists according to sampling rules; and deploy data directories and lineage management tools to register caliber information and export reports to form audit materials. However, in compliance audit scenarios, the following problems exist: First, the association between accounts and entities relies on static binding or a single rule, making it difficult to generate a unique entity identifier for the same event. Second, different systems have inconsistent recording standards for processing purposes, processing objects, and sensitive tags, making it difficult to form a unified structured record for audit elements. Third, the lack of joint constraints between caliber versions and field mapping versions makes it difficult to reproduce historical caliber calculation paths. Fourth, audit materials are mainly exported and packaged, lacking structured indexes, consistency checks, and cross-system association rules, making it difficult to perform consistency verification of event sets, caliber information, and entity links.

[0004] To address the aforementioned issues, this invention proposes an integrated enterprise information management platform based on big data. This platform standardizes and normalizes field mapping of operation logs from various enterprise business systems, generating unified, structured audit event records and writing them into an event ledger. It generates entity identifiers and establishes a closed-loop traceability system by parsing and gating the original entry records to uniquely identify the entities involved. Furthermore, it generates a caliber lineage version chain and blocks encapsulated inputs in case of conflicts by performing node-based parsing, rule standardization, and version joint locking on indicator scripts. Finally, it generates verifiable audit evidence packages and identifies the minimum supplementary collection boundary in case of inconsistencies by performing deterministic serialization, digest calculation, and consistency recalculation verification on event fragments. Summary of the Invention

[0005] In view of the aforementioned existing problems, the present invention is proposed.

[0006] This invention provides an integrated enterprise information management platform based on big data. The purpose is to solve the problems of inconsistent audit log element definitions leading to difficulty in associating events, inconsistent identification of the same subject in different systems leading to instability in merging subjects, lack of joint locking of indicator definitions and field mapping versions leading to audit definition drift, and lack of consistency verification and failure location closed loop for evidence encapsulation leading to difficulty in reviewing evidence packages and uncertainty in the boundaries of supplementary collection.

[0007] To solve the above-mentioned technical problems, the present invention provides the following technical solution: A big data-based enterprise information management integration platform includes: Module M1, Unified Structured Audit Element Collection Module: Standardizes the elements of operation logs generated by various business systems of the enterprise, generates unified structured audit event records and writes them into the event ledger, and sets the processing status identifier to the original entry. Module M2, Subject Unique Identifier Resolution and Failure Closed-Loop Module: Based on structured audit event records, it uses identity gating to process records in the event ledger whose processing status is marked as original entry, generates a unique subject identifier, and writes it back to the event ledger; Module M3, Joint Locking Module for Calibration Version and Field Mapping Version: Based on a unique entity identifier, it performs caliber locking processing on the enterprise indicator caliber and field mapping, generates a caliber lineage version chain and writes it into the caliber lineage database; Module M4, Evidence Index Binding and Consistency Verification Encapsulation Module: Based on the caliber lineage version chain, it performs evidence solidification processing on the event ledger records passed by the subject and the caliber lineage version chain passed by the caliber, generates a verifiable audit evidence package and outputs it.

[0008] As a preferred implementation method, the specific steps of the unified structured data collection module for audit elements are as follows: The configuration reading unit generates a data source access parameter set by reading the data source configuration records; the interface call and authentication unit generates an original operation log record set by initiating an interface call to the interface address and performing authentication verification on the authentication credential; when the interface returns a success status code, the interface call and authentication unit writes the original operation log record set into the unmapped cache area to generate an unmapped cache record; when the interface returns a failure status code, the data source identifier, failure time, and failure reason code are written into the collection exception record, and the data source identifier is written into the retry queue to generate an exception handling record; and when the retry count reaches the retry limit, the data source is... The identifier is written to the skip queue to generate a skipped processing record; the field mapping and value normalization unit performs unified field renaming and enumeration value fixed mapping table conversion on the cache record to be mapped according to the field mapping version number to generate a unified structured audit event record set; when the audit event record is missing operation time or missing operation account, the field mapping and value normalization unit writes the record to the rejection list and writes the missing field reason code to generate a rejection list record; the event ledger writing and status setting unit only performs writing to the event ledger on audit event records that have not been written to the rejection list and sets the processing status identifier to original entry to generate an original entry record.

[0009] As a preferred implementation method, the specific steps of the unified structured data collection module for audit elements are as follows: The event unique identifier generation unit generates an event fragment string by performing deterministic serialization on a unified structured set of audit event records in a fixed field order; it generates a unique string input by connecting adjacent fields with a fixed delimiter and writing fixed placeholders for null fields; and it generates an event unique identifier by performing secure hash calculation on the event fragment string. When an audit event record is marked as a rejection list record, the event unique identifier generation unit does not generate an event unique identifier, but retains the reason code for the missing field to generate a traceable rejection list record and blocks the record from entering the event ledger writing and status setting process and the subsequent subject parsing process.

[0010] As a preferred implementation, the specific steps of the subject unique identifier resolution and failure closure module are as follows: The directory equivalence matching unit reads the operation account of the record with the processing status marked as "original entry" in the event ledger and performs an equivalence comparison with the account index of the unified identity directory to generate a matching hit flag and a first candidate subject flag. When the matching hit flag is "missed", the hash consistency feature generation unit reads the mobile phone number field, email field, and employee number field in the event ledger record and performs normalization processing to generate an event-side identity element set. The hash consistency feature generation unit performs a search on the unified identity directory according to the event-side identity element set to generate a directory-side candidate identity element set. It performs secure hash calculation and equivalence comparison on the event-side identity elements and the directory-side candidate identity elements respectively to generate a mobile phone number consistency flag, an email consistency flag, and an employee number consistency flag. The subject matching score calculation unit performs a weighted summation on the consistency flags according to the weight coefficient to generate a subject matching score and writes it into the matching score field of the event ledger record. The threshold reading and gating judgment unit reads the threshold configuration record to generate an identity mapping threshold and performs a numerical comparison between the subject matching score and the identity mapping threshold to generate a gating judgment result and a failure reason code.

[0011] As a preferred implementation, the specific steps of the subject unique identifier resolution and failure closure module are as follows: When the gating result is "pass" and the matching hit flag is "hit", the subject write-back unit writes the first candidate subject identifier into the subject identifier field of the event ledger record and updates the processing status flag to "subject pass", thus generating a subject pass event ledger record. When the gating result is "pass" and the matching hit flag is "miss", the subject write-back unit sorts the candidate subject identifier set in descending order by subject matching score and selects the candidate subject identifier with the first number to generate a second candidate subject identifier. The second candidate subject identifier is then written into the subject identifier field of the event ledger record, and the processing status flag is updated to "subject pass", thus generating a subject pass event ledger record. When the gating result is "fail", the failure evidence storage unit writes the event unique identifier, subject matching score, failure reason code, data source identifier, and recording time into the evidence index to generate a subject failure evidence record and updates the processing status flag of the event ledger record to "subject failure". When the processing status flag is "subject failure", the encapsulation allow flag is set to "prohibit" and the event unique identifier is written into the encapsulation exclusion list to generate a blocking result.

[0012] As a preferred implementation, the specific steps of the joint locking module for the caliber version and field mapping version are as follows: The caliber script acquisition unit reads the unique entity identifier from the event ledger record of the subject, and uses the unique entity identifier as the search key to read the audit task configuration record to obtain the audit task identifier, indicator identifier, caliber version number, and caliber script text bound to the unique entity identifier. It also generates the caliber script text and field mapping rule set by reading the indicator identifier and caliber version number registered in the audit task configuration, and reading the field mapping version number and field mapping rule set registered in the data source configuration, and writes them to the parsing cache. The node parsing unit generates a caliber node set and a topologically ordered node sequence by performing mark sequence generation and bracket pairing verification on the caliber script text. When the bracket pairing verification fails or there are unrecognizable character segments, the node parsing unit writes the failure reason code and script text location information into the evidence index, sets the caliber processing status identifier to caliber failure, and sets the caliber encapsulation allow flag to prohibit. The rule normalization and serialization unit replaces field names with unified field names according to the field mapping rule set, sorts commutative operation operands in lexicographical order, and normalizes numerical constants and time constants. The format of configuration record registration is fixed, generating a standardized rule string. A node fingerprint string is generated by deterministic serialization according to the field order of the serialized configuration record registration, fixed delimiters, and null placeholders. The upstream node identifier set is sorted lexicographically, and the node identifier, node type, and sorted upstream node identifier set are concatenated with the standardized rule string according to the field order of the serialized configuration record registration. During concatenation, the fixed delimiters of the serialized configuration record registration are used, and null values ​​are written into fixed placeholders, thereby generating the node fingerprint string and writing it into the fingerprint cache. When the field mapping rule set cannot match a field name, the rule normalization serialization unit writes the missing field reason code into the evidence index, sets the caliber processing status flag to caliber failure, and sets the caliber encapsulation allow flag to prohibit. A caliber lineage deterministic fingerprint generation algorithm is used to perform rule normalization processing on the node rule text and deterministic serialization processing on the normalization result, thereby generating a standardized rule string and a node fingerprint string, which are then written into the fingerprint cache. The formula for the caliber lineage deterministic fingerprint generation algorithm executed by the rule normalization serialization unit is as follows: , in Let S be the node fingerprint string of the i-th node, where S is the node fingerprint string and i is the index of the caliber node. For deterministic serialization functions, Let i be the node identifier of the i-th node. Let i be the node type of the i-th node. This represents the result after sorting the upstream node identifier set in lexicographical order. The result after lexicographical sorting. The set of upstream node identifiers of the i-th node. Let be the normalized rule string of the i-th node. Configure for serialization.

[0013] As a preferred implementation, the specific steps of the joint locking module for the caliber version and field mapping version are as follows: The transformation digest generation unit generates node transformation digest values ​​by performing secure hash calculation on the node fingerprint string, and generates a caliber lineage version chain fingerprint by performing chain aggregation on the node transformation digest values ​​according to the topologically ordered node sequence, and writes it into the caliber lineage database. The version conflict verification unit generates a historical chain fingerprint set by retrieving the caliber lineage database using a joint key composed of the indicator identifier, caliber version number, and field mapping version number, and generates a conflict determination result by performing an equivalence comparison between the current caliber lineage version chain fingerprint and the historical chain fingerprint set. When the conflict determination result is no conflict, the caliber blocking and evidence output unit sets the caliber processing status flag to caliber pass and sets the caliber encapsulation allow flag to allow, and outputs the caliber lineage version chain as subsequent encapsulation input. When the conflict determination result is conflict, the caliber blocking and evidence output unit sets the caliber processing status flag to caliber failure, writes the joint key, caliber lineage version chain fingerprint, and conflict reason code into the evidence index, and sets the caliber encapsulation allow flag to prohibit entry into the subsequent encapsulation input set.

[0014] As a preferred embodiment, the specific steps of the evidence index binding and consistency verification encapsulation module are as follows: The event fragment serialization unit obtains the event unique identifier, subject unique identifier, indicator identifier, operation timestamp, operation type, object identifier, and processing purpose by reading the event ledger records passed by the subject, and obtains the caliber version number, field mapping version number, and caliber caliber version chain fingerprint by reading the caliber caliber lineage version chain passed by the caliber, thereby generating an event fragment field set; the event fragment serialization unit performs deterministic serialization on the event fragment field set according to the field order registered in the encapsulation configuration table to generate an event fragment string; the fragment digest calculation unit performs secure hash calculation on the event fragment string according to the hash algorithm type registered in the hash algorithm configuration item to generate a fragment digest value; the evidence index binding unit generates an evidence index record by writing the event unique identifier, fragment digest value, caliber caliber version chain fingerprint, indicator identifier, subject unique identifier, and operation timestamp into the evidence index, and writes the evidence index identifier back to the evidence index field of the event ledger record to establish a searchable binding relationship.

[0015] As a preferred implementation, the specific steps of the evidence index binding and consistency verification encapsulation module are as follows: The batch grouping unit reads the batch window duration from the encapsulation configuration table and limits the batch window duration to five to sixty minutes. It then groups the evidence index records according to the operation timestamp, generating a batch set and writing the batch identifier, window start time, and window end time to generate batch index records. The intra-batch sorting unit sorts the evidence index records within the same batch in ascending order by operation timestamp and, if timestamps are the same, in lexicographical order by event unique identifier, thus generating an intra-batch ordered record sequence. The preceding digest chain generation unit performs a secure hash calculation on the batch identifier and window start time to generate a chain start digest. It then iteratively aggregates the preceding digest value and the current fragment digest value in ascending order of the intra-batch ordered record sequence to generate a preceding digest chain value sequence. The preceding digest chain value corresponding to the evidence index record is written into the preceding digest chain field of the evidence index record to generate the chain value storage result; the digest tree construction unit aggregates the fragment digest values ​​layer by layer until a single digest root is obtained by concatenating adjacent pairs and performing secure hash calculation to generate the batch digest root. When the number of fragment digest values ​​is even, the digest tree construction unit generates the batch digest root by aggregating adjacent pairs. When the number of fragment digest values ​​is odd, the digest tree construction unit generates the batch digest root by copying the last fragment digest value to make it even and then aggregating adjacent pairs; the digest root signature unit generates the digest root signature value by reading the signature key identifier and signature algorithm type in the key configuration table and performing signature operation on the batch digest root, and writes it into the signature field of the batch index record.

[0016] As a preferred embodiment, the specific steps of the evidence index binding and consistency verification encapsulation module are as follows: The consistency recalculation verification unit rereads the event fragment string one by one within the ordered record sequence of the batch and recalculates the fragment digest value, the preceding digest chain value, and the batch digest root to generate a recalculated digest root. It then performs an equivalence comparison between the recalculated digest root and the batch digest root in the batch index record to generate a consistency verification result. When the consistency verification result is successful, the consistency recalculation verification unit sets the batch status identifier to "encapsulation passed," triggering the evidence package generation unit to generate a verifiable auditable evidence package. When the consistency verification result is unsuccessful, the consistency recalculation verification unit sets the batch status identifier to "encapsulation failed," writes a failure reason code, generates the first inconsistency position number, and writes it into the failure location field to generate minimum resampling location information. It then performs an equivalence comparison one by one between the preceding digest chain field of the evidence index record and the preceding digest chain value recalculated by the consistency recalculation verification unit. Upon the first inconsistency, it determines the first inconsistency position number and writes it into the failure location field to generate minimum resampling location information. The formula for the evidence inconsistency location algorithm is as follows: , in The consistency recalculation verification unit recalculates the preorder summary chain value obtained from the j-th evidence index record. Let j be the index of the preorder summary chain obtained by recalculation, and j be the index of the ordered record sequence within the batch. For secure hash calculation functions, The fragment digest value is obtained by the consistency recalculation verification unit from the event fragment string corresponding to the j-th evidence index record. It is a hash algorithm type; The failure re-sampling scheduling unit calculates the re-sampling start boundary and re-sampling end boundary by reading the operation timestamp of the record corresponding to the failure location field and combining it with the re-sampling time extension registered in the encapsulation configuration table, thereby generating a supplementary sampling task. The re-sampling time extension is limited to ten seconds to three hundred seconds. The batch identifier, re-sampling start time, re-sampling end time, failure reason code and data source identifier are written into the re-sampling queue to trigger the acquisition side to supplement sampling according to the re-sampling time boundary and re-enter the event fragment serialization processing flow.

[0017] Beneficial effects 1. By applying a processing flow of "rule normalization, deterministic serialization and chained summary solidification under field mapping version number constraints" to the script text of the caliber, a caliber lineage version chain fingerprint is generated and locked with the indicator identifier, caliber version number and field mapping version number as a joint key. This ensures that the same joint key corresponds to only one set of verifiable caliber implementation, avoiding caliber drift and inconsistency in audit evidence due to the same indicator being from different business system sources, different field aliases and different script expressions.

[0018] 2. By performing joint conflict verification on the caliber chain fingerprint, and setting the caliber encapsulation allow flag to be prohibited under the condition of conflict or caliber failure, and writing the joint key, chain fingerprint and cause code into the evidence index, a deterministic closed loop of "conflict is blocked and failure is traced" is generated, so that the evidence encapsulation module only receives input records that are both caliber and subject to the test, reducing the risk of multiple calibers being mixed into the same evidence package and cross-batch evidence being difficult to verify.

[0019] 3. By performing deterministic serialization, preorder digest chain generation, and consistency recalculation verification on event fragments within the evidence encapsulation batch, and locating the first inconsistency position and outputting the minimum re-sampling location information when consistency fails, the failed re-sampling scheduling unit is driven to generate supplementary sampling tasks according to the minimum boundary. This enables the evidence package to maintain verifiable consistency under abnormal conditions such as supplementary sampling and write-back, repeated push, or write retry, and avoids the expansion of the re-sampling scope and scheduling congestion caused by batch re-sampling. Attached Figure Description

[0020] Figure 1 This is a system module diagram of the present invention.

[0021] Figure 2This is a comparison chart of the technical effects of the present invention, in which the black bars represent the present invention and the gray bars represent the prior art. Detailed Implementation

[0022] To make the technical means, creative features, and achieved objectives and effects of this invention easier to understand, the invention is further described below with reference to specific embodiments. However, the following embodiments are merely preferred embodiments of this invention and not all of them. Other embodiments obtained by those skilled in the art based on the embodiments described herein without creative effort are all within the protection scope of this invention. Unless otherwise specified, the experimental methods in the following embodiments are conventional methods, and the materials and reagents used in the following embodiments are commercially available unless otherwise specified.

[0023] Example 1 combined Figure 1 The diagram shown is a module diagram of an enterprise information management integration platform based on big data. The specific implementation steps are as follows: Module M1, Unified Structured Audit Element Collection Module: Standardizes the elements of operation logs generated by various business systems of the enterprise, generates unified structured audit event records and writes them into the event ledger, and sets the processing status identifier to the original entry. Module M2, Subject Unique Identifier Resolution and Failure Closed-Loop Module: Based on structured audit event records, it uses identity gating to process records in the event ledger whose processing status is marked as original entry, generates a unique subject identifier, and writes it back to the event ledger; Module M3, Joint Locking Module for Calibration Version and Field Mapping Version: Based on a unique entity identifier, it performs caliber locking processing on the enterprise indicator caliber and field mapping, generates a caliber lineage version chain and writes it into the caliber lineage database; Module M4, Evidence Index Binding and Consistency Verification Encapsulation Module: Based on the caliber lineage version chain, it performs evidence solidification processing on the event ledger records passed by the subject and the caliber lineage version chain passed by the caliber, generates a verifiable audit evidence package and outputs it; Combination Figure 2 The image shows a comparison of the technical effects of an enterprise information management integration platform based on big data. The black bars represent the technical effects of the present invention, while the gray bars represent the technical effects of existing technologies. Figure 2 It can be seen that the technical effect of the present invention is superior to that of the existing technology.

[0024] Example 2, this example is an explanation of Example 1. The unified structured acquisition module for audit elements includes: a configuration reading unit, an interface call and authentication unit, a field mapping and value range normalization unit, an event unique identifier generation unit, and an event ledger writing and status setting unit; wherein: The configuration reading unit is used to read the data source configuration record. The configuration reading unit generates the data source access parameter set by writing the data source access parameter set into the acquisition task context. The data source access parameter set includes interface address, authentication credential, data source identifier, field mapping version number, timestamp field name, account field name, operation type field name, object identifier field name, processing destination field name, and sensitive tag field name; The sensitive label is a classification identifier used to characterize the sensitivity of personal information in the data fields involved in the operation log. The classification identifier is stored in the form of enumeration values ​​and used for subsequent audit sampling and evidence encapsulation gating. The interface call and authentication unit is used to perform interface calls and credential injection on the interface address and authentication credentials in the collection task context. The interface call and authentication unit obtains the operation log data returned by the business system and parses it into a raw operation log record set, thereby generating a raw operation log record set. When the interface returns a success status code, the interface call and authentication unit writes the raw operation log record set into the unmapped cache area. When the interface returns a failure status code, the interface call and authentication unit writes the data source identifier, failure time and failure reason code into the collection exception record and writes the data source identifier into the retry queue or skip queue. The aforementioned business systems are data source systems deployed by enterprises during their operation and management processes, capable of generating and providing operation logs externally. Examples include: human resource management systems, financial shared service systems, enterprise resource planning systems, customer relationship management systems, collaborative office systems, contract management systems, procurement management systems, warehouse management systems, project management systems, and data analysis systems. Each business system is configured to generate operation log records containing operation time, operation account, operation type, object identifier, and processing purpose during its business processing, and output the operation log records to the integration platform through corresponding data interfaces. The field mapping and value normalization unit is used to perform field mapping and value normalization on the original operation log record set in the unmapping cache. The field mapping and value normalization unit renames the account field name, operation type field name, object identifier field name, processing destination field name, sensitive label field name, and timestamp field name according to the field mapping version number, and performs fixed mapping table conversion on the operation type enumeration value and sensitive label enumeration value to generate a unified structured audit event record set. When the unified structured audit event record is missing operation time or missing operation account, the field mapping and value normalization unit writes the record into the rejection list and writes the missing field reason code. The event unique identifier generation unit is used to perform deterministic serialization and secure hash calculation on a unified structured set of audit event records. The event unique identifier generation unit generates an event fragment string by serializing and concatenating the data source identifier, operation account, operation type, object identifier, processing purpose, sensitive tag, and operation time according to a fixed field order, and performs a secure hash operation on the event fragment string to generate an event unique identifier. When the audit event record is marked as a rejection list record, the event unique identifier generation unit does not generate an event unique identifier and retains the reason code of the missing field, thereby generating a traceable record of the rejection list and blocking the audit event record from entering the event ledger and subsequent subject parsing process. The deterministic serialization is a process of forming a unique string input from the fields in the unified structured audit event record in a fixed manner. The process is executed as follows: the system reads the data source identifier, operation account, operation type, object identifier, processing purpose, sensitive tags, and operation time in sequence, and concatenates them according to the field order registered in the data source configuration; the system uses a fixed delimiter to connect adjacent fields and writes a fixed placeholder for null fields, thereby generating an event fragment string; wherein, both the fixed delimiter and the fixed placeholder are registered in the configuration items and are consistent across all data sources; The secure hash calculation is a process of performing secure hash calculation on the event fragment string to obtain a fixed-length digest value. The process is performed as follows: the event fragment string is encoded using a unified character encoding, and the encoded byte sequence is used as input to call a secure hash algorithm function to calculate the digest value; the digest value is written into the event unique identifier field; when an audit event record is marked as a rejection list record, the system does not perform the secure hash calculation and does not write the event unique identifier, and writes the missing field reason code into the rejection list storage area; The event ledger writing and status setting unit is used to perform entry writing on the unique event identifier and the unified structured field set. The event ledger writing and status setting unit generates an event ledger record by writing the unique event identifier, operation time, operation account, operation type, object identifier, processing purpose and sensitive tags into the event ledger. When the event ledger record is generated, the event ledger writing and status setting unit sets the processing status identifier to the original entry. When the audit event record belongs to the rejection list record, the event ledger writing and status setting unit writes the rejection reason code and data source identifier into the rejection list storage area. The audit reviewers and the collection scheduling unit review and supplement the data, so that the rejection list record can form a closed loop processing of traceable missing reasons, locatable responsible data source, definite supplementary collection scope, and re-entry of supplementary collection results, avoiding the inability to perform subsequent subject parsing and evidence encapsulation due to missing audit elements.

[0025] Example 3 is an explanation of Example 1. The subject unique identifier parsing and failure closed-loop module takes the event ledger record written to the event ledger in Example 2 with the processing status identifier as the original entry as input, thereby generating event ledger records of subject success or evidence records of subject failure. The subject unique identifier parsing and failure closed-loop module includes: a directory equivalence matching unit, a hash consistency feature generation unit, a subject matching score calculation unit, a threshold reading and gating judgment unit, a subject write-back unit, a failure evidence storage unit, and an input blocking unit; wherein: The directory equivalence matching unit is used to perform equivalence matching between the operation account in the event ledger record and the account index in the unified identity directory. The directory equivalence matching unit generates equivalence matching results by outputting a matching hit flag and a first candidate subject identifier. When the equivalence matching hit flag is hit, the directory equivalence matching unit writes the first candidate subject identifier into the subject candidate field. When the equivalence matching hit flag is not hit, the directory equivalence matching unit writes a not hit flag into the subject candidate field and triggers the subsequent consistency feature generation process. The aforementioned equality matching is a matching method based on determining the equality relationship of key values. The equality matching is performed as follows: The account key value is obtained by reading the operation account field in the event ledger record, and the index key value is obtained by reading the account index field in the unified identity directory; the account key value and the index key value are normalized under the same character encoding rule, the normalization process including removing leading and trailing spaces and unifying capitalization; an index key value that is exactly the same as the account key value is searched in the unified identity directory; when an exactly the same index key value is found, a match hit flag is output and the subject identifier associated with the index key value is output as the first candidate subject identifier; when no exactly the same index key value is found, a miss flag is output and the hash consistency feature generation process begins. The hash consistency feature generation unit is used to generate hash consistency features for identity elements associated with the unified identity directory and event ledger records when the equality match miss flag is met. The hash consistency feature generation unit reads the mobile phone number, email, and employee ID fields from the event ledger records and performs normalization processing on the read strings. This normalization processing includes removing leading and trailing spaces and standardizing case. It also reads the mobile phone number, email, and employee ID fields associated with the operation account in the unified identity directory and performs the same normalization processing on the read strings. Secure hash calculations are then performed on the normalized event-side string and directory-side string to obtain event-side digest values ​​and directory-side digest values. Finally, the event-side digest value and directory-side digest value are compared for equality. When the summaries on both sides are exactly the same, the corresponding consistency flag is set to 1; when the summaries on both sides are different, the corresponding consistency flag is set to 0; when any field on one side is empty or missing, the corresponding consistency flag is set to 0 and a missing field reason code is written. Through the above processing, a mobile phone number consistency flag, an email consistency flag, and an employee ID consistency flag are generated, and the consistency flags are written into the flag field of the event ledger record, so that the subject matching score calculation unit can read and calculate the subject matching score. When the hash consistency feature generation unit fails to find the target, it uses one of the mobile phone number, email address, and employee ID in the event ledger record as the directory retrieval key, and specifies the retrieval order and missing handling. For example, the employee ID index is used to search the directory first, and if it is not found, the mobile phone number index is used, and then the email address index is used. Each step generates a hit flag and a candidate subject identifier. The subject matching score calculation unit is used to perform weighted calculations on the mobile phone number consistency flag, email consistency flag, and employee ID consistency flag. The subject matching score calculation unit generates a subject matching score by weighting and summing the three consistency flags according to weight coefficients. The weight coefficients satisfy the condition that the sum of the weights is 1. The weight coefficients are registered and determined by a weight configuration table, which includes: mobile phone number weight, email weight, and employee ID weight, and the sum of the three is 1. When the task starts, the weight configuration table is read and the weight coefficients are loaded into the subject matching score calculation unit. The subject matching score calculation unit writes the subject matching score into the matching score field of the event ledger record, thereby generating a verifiable gating input and supporting repeated calculations in the subsequent threshold comparison process. The threshold reading and gating judgment unit is used to read the threshold configuration and perform gating judgment on the subject matching score. The threshold reading and gating judgment unit reads the subject matching score field of the event ledger record to obtain the subject matching score, and reads the threshold configuration record to obtain the identity mapping threshold. The subject matching score is compared with the identity mapping threshold. When the subject matching score is greater than or equal to the identity mapping threshold, the gating judgment result is output as "pass" and the subject passes the flag is output. When the subject matching score is less than the identity mapping threshold, the gating judgment result is output as "fail" and the subject fails the flag and the failure reason code is output. By writing the gating judgment result, the subject matching score and the identity mapping threshold into the judgment field of the event ledger record, a verifiable judgment basis is generated. The subject write-back unit writes back the subject identifier and updates the processing status identifier to "subject passes" when the subject passes, and the failure evidence storage unit writes failure evidence and updates the processing status identifier to "subject fails" when the subject fails, thereby generating the gating judgment result. The subject write-back unit is used to write a unique subject identifier into the event ledger record when the subject pass flag is established. The subject write-back unit generates an event ledger record for subject pass by writing the first candidate subject identifier or the second candidate subject identifier into the subject identifier field and updating the processing status identifier from the original entry to subject pass. The second candidate subject identifier is determined by the matching subject record corresponding to the subject matching score. The subject matching score calculation unit takes the set of matched candidate subjects as input, sorts them in descending order of matching score, and takes the subject identifier of the first record as the second candidate subject identifier. When the candidate set is empty, the subject is directly set to fail. The failure evidence storage unit is used to write failure evidence into the evidence index when the subject failure flag is set. The failure evidence storage unit generates a subject failure evidence record by writing the event unique identifier, subject matching score, failure reason code, data source identifier and recording time, and updates the processing status identifier of the event ledger record from the original entry to subject failure. The encapsulation input blocking unit is used to block the event from entering the subsequent evidence encapsulation input set when the processing status is identified as subject failure. The encapsulation input blocking unit generates a blocking result by setting the encapsulation allow flag to prohibit on the event ledger record or writing the unique identifier of the event into the encapsulation exclusion list, so that the subsequent evidence index binding and consistency verification encapsulation module only executes on the event ledger record whose processing status is identified as subject success.

[0026] Example 4, this example is an explanation of Example 1. The joint locking module for caliber version and field mapping version uses the audit task identifier associated with the main body through the event ledger record output in Example 3 as the trigger condition, and uses the indicator identifier, caliber version number, and field mapping version number registered in the audit task configuration as inputs to generate a caliber lineage version chain and write it into the caliber lineage database. When a conflict is established, it outputs conflict evidence and blocks entry into the subsequent evidence encapsulation input set. The joint locking module for caliber version and field mapping version includes: a caliber script acquisition unit, a node parsing unit, a rule normalization and serialization unit, a transformation summary generation unit, a version joint registration unit, a version conflict verification unit, and a caliber blocking and evidence output unit; wherein: The aforementioned caliber script acquisition unit is used to load caliber script text and field mapping rules into the parsing cache. By reading the indicator identifier of the event ledger record and the caliber version number of the audit task configuration record, it can locate and read the caliber script text corresponding to the indicator identifier and the caliber version number. By reading the field mapping version number of the data source configuration record and the set of field mapping relationships corresponding to the field mapping version number, it obtains the field mapping rule set and writes the caliber script text and the field mapping rule set into the parsing cache for subsequent processing by the node-based parsing unit. When the caliber script text is missing, the caliber script acquisition unit writes the indicator identifier, caliber version number, and missing reason code into the evidence index, sets the caliber processing status identifier to caliber failure, and sets the caliber encapsulation allow flag to prohibit. The node-based parsing unit converts the script text into a processable set of script nodes and a topologically ordered sequence of nodes. It reads the script text from the parsing buffer and reads characters segment by segment from left to right, identifying consecutive character segments as field identifiers, numeric constants, string constants, operators, and parentheses, thus generating a tag sequence. It performs parenthesis pairing checks on the tag sequence and reduces it according to the order of multiplication / division priority, addition / subtraction priority, comparison priority, and logical priority, thereby generating a set of syntax nodes. It assigns a node identifier to each syntax node and registers the field identifier or upstream node identifier referenced by that syntax node in the upstream node identifier set, thus generating... The process involves creating a caliber node set that includes node identifiers, node types, a set of upstream node identifiers, and node rule text. The node parsing unit outputs nodes round by round, starting with nodes whose upstream node identifier sets are empty, and deletes references to already output nodes, thereby generating a topologically ordered node sequence and writing it into the parsing buffer. During bracket pairing verification, if brackets are not paired, quotation marks are not paired, there are unrecognizable character segments, or the number of nodes in the topologically ordered node sequence is less than the number of nodes in the caliber node set, the node parsing unit writes the failure reason code and script text location information into the evidence index, sets the caliber processing status flag to caliber failure, and sets the caliber encapsulation allow flag to prohibit. The bracket pairing verification is performed by scanning the marked sequence in positional order and using a stack-based matching rule to check the pairing of left brackets pushed onto the stack and right brackets popped from the stack, thereby generating a bracket pairing verification result flag. When the verification passes, the node parsing unit enters syntax reduction to generate a caliber node set. When the verification fails, the node parsing unit writes the failure reason code and failure location index and sets the caliber processing status flag to caliber failure, thereby blocking subsequent processing. The rule normalization and serialization unit is used to solidify the node rule text into a deterministic node fingerprint string for subsequent secure hash calculation. It reads the node rule text node by node from the parsing buffer according to the topologically ordered node sequence, and replaces the field names in the node rule text with uniform field names according to the field mapping rule set. Simultaneously, it sorts the operands of addition and multiplication operations lexicographically, outputs numerical constants in a fixed format according to the decimal places recorded in the normalization configuration record, outputs time constants in the time format recorded in the normalization configuration record, and removes redundant whitespace characters, thereby generating a normalized rule string. The rule normalization and serialization unit further sorts the upstream node identifier set lexicographically and, according to the field order recorded in the serialization configuration record, stores the node identifier, node type, and sorting... The upstream node identifier set is concatenated with the normalized rule string. During concatenation, a fixed delimiter is used to record the serialization configuration and a fixed placeholder is written for null values, thereby generating a node fingerprint string and writing it into the fingerprint cache. When the field mapping rule set cannot match the field name, the rule normalization serialization unit writes the missing field reason code into the evidence index, sets the caliber processing status flag to caliber failure, and sets the caliber encapsulation allow flag to prohibit. By using the caliber lineage deterministic fingerprint generation algorithm, rule normalization processing is performed on the node rule text, and deterministic serialization processing is performed on the normalization result, thereby generating a normalized rule string and a node fingerprint string and writing them into the fingerprint cache. The formula of the caliber lineage deterministic fingerprint generation algorithm executed by the rule normalization serialization unit is as follows: , in Let S be the node fingerprint string of the i-th node, where S is the node fingerprint string and i is the index of the caliber node. For deterministic serialization functions, Let i be the node identifier of the i-th node. Let i be the node type of the i-th node. This represents the result after sorting the upstream node identifier set in lexicographical order. The result after lexicographical sorting. The set of upstream node identifiers of the i-th node. Let be the normalized rule string of the i-th node. Configure for serialization; In one embodiment, in the indicator auditing scenario of an enterprise information management integration platform, the same indicator of an enterprise may have differences in field aliases, script text formats, and node arrangements in different business systems. This may cause the platform to fall into two inconsistent implementations even under the condition that "the version number of the standard is consistent and the version number of the field mapping is consistent". As a result, when reviewing audit evidence, there is a practical problem that "the same batch of evidence corresponds to multiple calculation standards and it is impossible to determine which standard to use". To address the aforementioned practical problems, the rule normalization and serialization unit in the joint locking module for caliber version and field mapping version performs unified field name processing on each caliber node rule text output by the node parsing unit. This unified field name processing is achieved by the rule normalization and serialization unit reading the mapping reference from the field mapping relationship set according to the field mapping version number, and replacing the source field names appearing in the node rule text with unified field names. The rule normalization and serialization unit further rearranges the operands of addition and multiplication operations in the node rule text in lexicographical order, and uniformly formats constants according to the numerical and time formats recorded in the normalized configuration records, while deleting redundant whitespace characters, thereby converting caliber rules with the same semantics but different expressions into the same normalized rule string. After obtaining the normalized rule string, the rule normalization and serialization unit sorts the upstream node identifier set of the caliber node in lexicographical order, and concatenates the node identifier, node type, and sorted upstream node identifier set with the normalized rule string according to the field order registered in the serialization configuration record, fixed separator and null placeholder, thereby generating a deterministic node fingerprint string and writing it into the fingerprint cache area, so that the same caliber node can still obtain the same node fingerprint string under different system sources, different script writing methods and different node output orders. Subsequently, the transformation digest generation unit performs secure hash calculation on the node fingerprint string to obtain the node digest value, and performs chain aggregation on the node digest value according to the topologically ordered node sequence to generate the caliber lineage version chain fingerprint and writes it into the caliber chain fingerprint field; the version conflict verification unit uses the indicator identifier, caliber version number and field mapping version number to form a joint key to retrieve the historical chain fingerprint set, and compares the current caliber chain fingerprint with the historical chain fingerprints one by one: when the comparison is consistent, the version conflict verification unit sets the caliber processing status identifier to caliber passed and sets the caliber encapsulation allow flag to allow, so that the evidence encapsulation module can only encapsulate the unique caliber implementation consistent with the joint key; when the comparison is inconsistent, the version conflict verification unit sets the caliber processing status identifier to caliber failed and writes the conflict reason code, and at the same time writes the joint key, caliber chain fingerprint and conflict reason code into the evidence index and sets the caliber encapsulation allow flag to prohibit, thereby preventing multiple calibers from being mixed into the same audit evidence package and providing traceable basis for subsequent review and location; The aforementioned transformation digest generation unit is used to generate node transformation digest values ​​from node fingerprint strings and generate caliber lineage version chain fingerprints. It generates node transformation digest values ​​by reading node fingerprint strings one by one from the fingerprint cache and performing secure hash calculations. The node transformation digest values ​​are then concatenated according to the topologically ordered node sequence and secure hash calculations are performed again to generate caliber lineage version chain fingerprints. The node transformation digest values ​​are written into the node digest field, and the caliber lineage version chain fingerprints are written into the caliber chain fingerprint field, so that they can be read by the version joint registration unit and the version conflict verification unit. The aforementioned version joint registration unit is used to form a joint registration record by combining the caliber version number and the field mapping version number. It generates a lineage registration record to be verified by writing the indicator identifier, caliber version number, field mapping version number, topological ordered node sequence, node summary field and caliber chain fingerprint field into the caliber lineage database and setting the caliber processing status identifier to caliber entry. The record to be verified is then written into the record field to be verified in the caliber version index table with a joint key, so that the version conflict verification unit can read the set of historical chain fingerprint records under the same joint key. The version conflict verification unit is used to verify the consistency of calibers under the same composite key. It retrieves the caliber version index table by composite key, reads the historical chain fingerprint record set corresponding to the composite key, and performs an equality comparison between the current caliber chain fingerprint field and each of the historical chain fingerprints to generate a conflict determination result. Specifically, when the historical chain fingerprint record set is empty, the conflict determination result is set to non-conflict and the caliber processing status is updated to caliber passed. When the historical chain fingerprint record set is not empty and any historical chain fingerprint is not equal to the current caliber chain fingerprint, the version conflict verification unit sets the conflict determination result to conflict, generates a conflict reason code, and updates the caliber processing status to caliber failed. The version conflict verification unit writes the conflict determination result and conflict reason code into the verification field of the caliber lineage database to generate a verifiable verification record. The aforementioned caliber blocking and evidence output unit is used to select the subsequent path based on the caliber processing status identifier. When the caliber processing status identifier indicates caliber failure, the caliber blocking and evidence output unit writes the indicator identifier, caliber version number, field mapping version number, current caliber chain fingerprint field, and conflict reason code into the evidence index, thereby generating a caliber conflict evidence record, and sets the caliber encapsulation allow flag to prohibit, thereby blocking entry into the subsequent evidence encapsulation input set. When the caliber processing status identifier indicates caliber passage, the caliber blocking and evidence output unit sets the caliber encapsulation allow flag to allow and outputs the caliber lineage version chain as the input of the subsequent module.

[0027] Example 5, this example is an explanation of Example 1. The evidence index binding and consistency verification encapsulation module uses the event ledger record passed by the subject in Example 3 and the caliber encapsulation permission flag and the caliber lineage version chain passed in Example 4 as encapsulation input. Through deterministic serialization, digest calculation, batch encapsulation and consistency verification of the encapsulation input, a verifiable auditable evidence package is generated and output. When the consistency verification fails, the module generates failed evidence and triggers a re-sampling scheduling closed loop. The evidence index binding and consistency verification encapsulation module includes: an event fragment serialization unit, a fragment digest calculation unit, an evidence index binding unit, a batch grouping unit, an intra-batch sorting unit, a preceding digest chain generation unit, a digest tree construction unit, a digest root signature unit, a consistency recalculation verification unit, an evidence package generation unit, and a failed re-sampling scheduling unit; wherein: The event fragment serialization unit is used to generate deterministic event fragments from the encapsulated input. The unit reads the unique identifier, subject unique identifier, indicator identifier, operation timestamp, operation type, object identifier, and processing purpose from the event ledger, and reads the caliber version number, field mapping version number, and caliber chain fingerprint field from the caliber lineage version chain to obtain the event fragment field set. The unit then performs deterministic serialization of the event fragment field set according to the field order registered in the encapsulation configuration table and writes it to the fragment buffer to generate an event fragment string. The field order is as follows: unique event identifier, subject unique identifier, indicator identifier, caliber version number, field mapping version number, caliber chain fingerprint field, operation timestamp, operation type, object identifier, and processing purpose. The encapsulation configuration table simultaneously registers a fixed separator and a null placeholder. The event fragment serialization unit uses the fixed separator and null placeholder to generate the same event fragment string from the same field set. The fragment digest calculation unit is used to generate fragment digest values ​​for event fragment strings. The fragment digest calculation unit generates fragment digest values ​​and writes them into the fragment digest field by reading event fragment strings one by one from the fragment buffer and performing secure hash calculation according to the hash algorithm type registered in the hash algorithm configuration item. The evidence index binding unit is used to bind event ledger records and fragment summary values ​​into a searchable evidence index. By writing the event unique identifier, fragment summary value, caliber chain fingerprint field, indicator identifier, subject unique identifier and operation timestamp into the evidence index, an evidence index record is generated. The index identifier of the evidence index record is written back to the evidence index field of the event ledger record, so that the subsequent evidence package generation unit can retrieve evidence elements according to the evidence index field. The batch grouping unit is used to divide the evidence index records into batch sets. The batch grouping unit generates batch sets by reading the batch window duration from the encapsulation configuration table and grouping the evidence index records by operation timestamps. The batch window duration is limited to five to sixty minutes and is registered by the platform administrator in the encapsulation configuration table. The batch grouping unit generates batch index records by writing a batch identifier, window start time, and window end time to each batch.

[0028] The batch sorting unit is used to form a deterministic order within a batch. The batch sorting unit sorts the evidence index records within the same batch in ascending order by operation timestamp and in lexicographical order by event unique identifier under the condition that the timestamps are the same, thereby generating an ordered sequence of records within the batch and writing it into the sorting field of the batch index record. The aforementioned preorder summary chain generation unit is used to generate a traceable preorder summary chain for an ordered record sequence within a batch. It generates a chain start summary by performing a secure hash calculation on the batch identifier and the batch window start time. Then, it concatenates the preorder summary value and the current segment summary value in ascending order from the first record to the last record within the batch, performs a secure hash calculation, and writes it back as the preorder summary value of the next record, thereby generating a preorder summary chain. The preorder summary chain value corresponding to each record is written into the preorder summary field of the evidence index record, so that it can be used by the consistency recalculation verification unit for recalculation and comparison. The summary tree construction unit is used to construct a summary tree from the summary values ​​of fragments within a batch and obtain the summary root. It extracts a list of fragment summary values ​​from the ordered record sequence within the batch and aggregates them layer by layer by concatenating adjacent values ​​and then performing secure hash calculation until a single summary root is obtained. This generates the batch summary root and writes it into the summary root field of the batch index record. Specifically, when the number of fragment summary values ​​is even, it directly aggregates them layer by layer by concatenating adjacent values ​​and then performing secure hash calculation until a single summary root is obtained. When the number of fragment summary values ​​is odd, the summary tree construction unit copies the last fragment summary value to make it even and then aggregates them by concatenating adjacent values ​​and then performing secure hash calculation until a single summary root is obtained. The digest root signature unit is used to generate a signature on the batch digest root to solidify batch evidence. It reads the signature key identifier and signature algorithm type from the key configuration table, performs a signature operation on the batch digest root to generate a digest root signature value, and writes the digest root signature value, signature key identifier, and signature algorithm type into the signature field of the batch index record for verification by the consistency recalculation verification unit. When the signature operation fails, the digest root signature unit writes the failure reason code into the evidence index and sets the batch status identifier to encapsulation failure. The consistency recalculation verification unit is used to perform recalculation consistency verification on batch evidence. The unit rereads the event fragment string from the evidence index record and recalculates the fragment digest value, preceding digest chain, and batch digest root to obtain the recalculated digest root. It then performs an equality comparison between the recalculated digest root and the digest root field in the batch index record to generate a consistency verification result. When the consistency verification result is successful, the unit sets the batch status identifier to "encapsulation successful" and outputs the batch identifier for the evidence package generation unit to continue processing. When the consistency verification result is unsuccessful, the unit sets the batch status identifier to "encapsulation failed" and writes a failure reason code. It then executes an evidence inconsistency location algorithm to compare the preceding digest chain value in the batch index record with the preceding digest chain value recalculated by the consistency recalculation verification unit, generating the first inconsistency position number and writing it into the failure location field of the batch index record. This allows the failure re-sampling scheduling unit to determine the minimum re-sampling start boundary and generate a re-sampling task based on the corresponding record timestamp. The formula for the evidence inconsistency location algorithm is: , in The consistency recalculation verification unit recalculates the preorder summary chain value obtained from the j-th evidence index record. Let j be the index of the preorder summary chain obtained by recalculation, and j be the index of the ordered record sequence within the batch. For secure hash calculation functions, The fragment digest value is obtained by the consistency recalculation verification unit from the event fragment string corresponding to the j-th evidence index record. It is a hash algorithm type; In one embodiment, in the audit evidence encapsulation scenario of the enterprise information management integration platform, the evidence index binding and consistency verification encapsulation module generates event fragment strings and calculates fragment summary values ​​for event ledger records within the same batch, and then generates a preceding summary chain value and a batch summary root based on the ordered record sequence within the batch. When the event fragment strings of individual records within the same batch change due to upstream supplementary collection and write-back, repeated push of data sources, missing event fragment fields, abnormal sorting fields within the batch, or storage write failure retry, the platform will encounter the actual problem that "the preceding summary chain value saved in the batch index record is inconsistent with the preceding summary chain value recalculated by the consistency recalculation verification unit". If only the result "batch failed" is given at this time, the failed re-collection scheduling unit cannot determine from which record to start supplementary collection, which is likely to trigger the entire batch re-collection and cause the re-collection range to be too large and the scheduling congestion to occur. To address the aforementioned practical problems, when the consistency recalculation verification unit determines that the consistency verification result is unsuccessful, it first reads the ordered record sequence within the batch index records, and then sequentially reads the event fragment strings corresponding to the evidence index records from the first record to the last record according to the record order of the sequence. Subsequently, the consistency recalculation verification unit performs digest recalculation on each event fragment string according to the same hashing rule as the fragment digest calculation unit, thereby obtaining a recalculated fragment digest value sequence that corresponds one-to-one with the ordered record sequence within the batch. After obtaining the recalculated fragment digest value sequence, the consistency recalculation verification unit uses the chain start digest corresponding to the batch identifier and the window start time as the initial chain value, and aggregates the recalculated fragment digest values ​​one by one in ascending order of the ordered record sequence within the batch, thereby generating a recalculated pre-sequence digest chain value sequence one by one. The consistency recalculation verification unit then... While generating the recalculated preceding summary chain value, the recalculated preceding summary chain value at the same sequence number position is compared with the preceding summary chain value already saved in the batch index record. When the comparison result is not equal for the first time, the consistency recalculation verification unit determines the sequence number position as the first inconsistent position and writes it into the failure location field of the batch index record. At the same time, the operation timestamp of the record corresponding to the first inconsistent position is written into the resampling location field, thereby generating the minimum resampling location information. The failure resampling scheduling unit generates a resampling task by reading the failure location field and the resampling location field, and triggers the acquisition side to supplement and recalculate with the resampling location time point as the resampling start boundary. This enables the platform to locate the inconsistency start point with the smallest range and complete the supplementary acquisition closed loop when consistency fails, avoiding the expansion of the resampling range and scheduling congestion caused by the whole batch resampling. The evidence package generation unit is used to generate a verifiable and auditable evidence package under the condition that the encapsulation is passed. It generates evidence package metadata by reading the batch identifier, window start and end time, digest root field, digest root signature field and signature key identifier from the batch index record, and by reading the evidence index field list from the evidence index record. It generates evidence package file identifier by encapsulating the evidence package metadata and evidence index field list according to the field order registered in the encapsulation configuration table and writing them into the evidence package storage area. It then writes the evidence package file identifier back to the evidence package field of the batch index record, so that the external review end can pull the evidence package according to the batch identifier and review the digest root and signature. The aforementioned failure re-sampling scheduling unit is used to trigger a re-sampling closed loop under the condition of encapsulation failure. The failure re-sampling scheduling unit reads the failure location field from the batch index record and reads the operation timestamp of the evidence index record of the failure location field as the re-sampling location time point. The failure re-sampling scheduling unit reads the re-sampling time extension from the encapsulation configuration table and calculates the re-sampling time boundary to generate a re-sampling task. The re-sampling time extension is limited to ten seconds to three hundred seconds, and the re-sampling time extension is registered by the platform in the encapsulation configuration table. The failure re-sampling scheduling unit writes the batch identifier, re-sampling start time, re-sampling end time, failure reason code and data source identifier into the re-sampling queue, thereby triggering the acquisition side to supplement the event ledger record according to the re-sampling time boundary and re-enter the event fragment serialization unit of this embodiment.

[0029] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely preferred examples and are not intended to limit the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of the present invention is defined by the appended claims and their equivalents.

Claims

1. A big data-based enterprise information management integration platform, characterized in that: Module M1, Unified Structured Audit Element Collection Module: Standardizes the elements of operation logs generated by various business systems of the enterprise, generates unified structured audit event records and writes them into the event ledger, and sets the processing status identifier to the original entry. Module M2, Subject Unique Identifier Resolution and Failure Closed-Loop Module: Based on structured audit event records, it uses identity gating to process records in the event ledger whose processing status is marked as original entry, generates a unique subject identifier, and writes it back to the event ledger; Module M3, Joint Locking Module for Calibration Version and Field Mapping Version: Based on a unique entity identifier, it performs caliber locking processing on the enterprise indicator caliber and field mapping, generates a caliber lineage version chain and writes it into the caliber lineage database; Module M4, Evidence Index Binding and Consistency Verification Encapsulation Module: Based on the caliber lineage version chain, it performs evidence solidification processing on the event ledger records passed by the subject and the caliber lineage version chain passed by the caliber, generates a verifiable audit evidence package and outputs it.

2. The enterprise information management integration platform based on big data according to claim 1, characterized in that: The specific steps of the unified structured data collection module for audit elements are as follows: The configuration reading unit generates a data source access parameter set by reading the data source configuration records; the interface call and authentication unit generates an original operation log record set by initiating an interface call to the interface address and performing authentication verification on the authentication credential; when the interface returns a success status code, the interface call and authentication unit writes the original operation log record set into the unmapped cache area to generate an unmapped cache record; when the interface returns a failure status code, the data source identifier, failure time, and failure reason code are written into the collection exception record, and the data source identifier is written into the retry queue to generate an exception handling record; and when the retry count reaches the retry limit, the data source is... The identifier is written to the skip queue to generate a skipped processing record; the field mapping and value normalization unit performs unified field renaming and enumeration value fixed mapping table conversion on the cache record to be mapped according to the field mapping version number to generate a unified structured audit event record set; when the audit event record is missing operation time or missing operation account, the field mapping and value normalization unit writes the record to the rejection list and writes the missing field reason code to generate a rejection list record; the event ledger writing and status setting unit only performs writing to the event ledger on audit event records that have not been written to the rejection list and sets the processing status identifier to original entry to generate an original entry record.

3. The enterprise information management integration platform based on big data according to claim 1, characterized in that: The specific steps of the unified structured data collection module for audit elements are as follows: The event unique identifier generation unit generates an event fragment string by performing deterministic serialization on a unified structured set of audit event records in a fixed field order; it generates a unique string input by connecting adjacent fields with a fixed delimiter and writing fixed placeholders for null fields; and it generates a unique event identifier by performing secure hash calculation on the event fragment string. The event unique identifier generation unit does not generate an event unique identifier when an audit event record is marked as a rejection list record, but retains the missing field reason code to generate a rejection list traceable record and blocks the record from entering the event ledger writing and status setting process as well as the subsequent subject parsing process.

4. The enterprise information management integration platform based on big data according to claim 1, characterized in that: The specific steps of the subject unique identifier resolution and failure closed-loop module are as follows: The directory equivalence matching unit reads the operation account from the event ledger for records with the processing status marked as "original entry" and performs an equivalence comparison with the account index in the unified identity directory to generate a matching hit flag and the first candidate subject identifier; hashing. When the matching hit flag is not found, the consistency feature generation unit reads the mobile phone number field, email field, and employee number field in the event ledger record and performs normalization processing to generate an event-side identity element set. The hash consistency feature generation unit performs a retrieval on the unified identity directory according to the event-side identity element set to generate a directory-side candidate identity element set. The unit performs secure hash calculation and equal value comparison on the event-side identity elements and the directory-side candidate identity elements respectively to generate mobile phone number consistency flag, email consistency flag, and employee number consistency flag. The subject matching score calculation unit generates a subject matching score by performing a weighted summation on the consistency flag according to the weight coefficient and writes it into the matching score field of the event ledger record; the threshold reading and gating judgment unit generates an identity mapping threshold by reading the threshold configuration record, and generates a gating judgment result and failure reason code by comparing the subject matching score with the identity mapping threshold.

5. The enterprise information management integration platform based on big data according to claim 1, characterized in that: The specific steps of the subject unique identifier resolution and failure closed-loop module are as follows: When the gating result is "pass" and the matching hit flag is "hit", the subject write-back unit writes the first candidate subject identifier into the subject identifier field of the event ledger record and updates the processing status flag to "subject pass", thus generating a subject pass event ledger record. When the gating result is "pass" and the matching hit flag is "miss", the subject write-back unit sorts the candidate subject identifier set in descending order by subject matching score and selects the candidate subject identifier with the first number to generate a second candidate subject identifier. The second candidate subject identifier is then written into the subject identifier field of the event ledger record, and the processing status flag is updated to "subject pass", thus generating a subject pass event ledger record. When the gating result is "fail", the failure evidence storage unit writes the event unique identifier, subject matching score, failure reason code, data source identifier, and recording time into the evidence index to generate a subject failure evidence record and updates the processing status flag of the event ledger record to "subject failure". When the processing status flag is "subject failure", the encapsulation allow flag is set to "prohibit" and the event unique identifier is written into the encapsulation exclusion list to generate a blocking result.

6. The enterprise information management integration platform based on big data according to claim 1, characterized in that: The specific steps of the joint locking module for the caliber version and field mapping version are as follows: The caliber script acquisition unit reads the unique entity identifier from the event ledger record of the subject, and uses the unique entity identifier as the search key to read the audit task configuration record to obtain the audit task identifier, indicator identifier, caliber version number, and caliber script text bound to the unique entity identifier. It also generates the caliber script text and field mapping rule set by reading the indicator identifier and caliber version number registered in the audit task configuration, and reading the field mapping version number and field mapping rule set registered in the data source configuration, and writes them to the parsing cache. The node parsing unit generates a caliber node set and a topologically ordered node sequence by performing mark sequence generation and bracket pairing verification on the caliber script text. When the bracket pairing verification fails or there are unrecognizable character segments, the node parsing unit writes the failure reason code and script text location information into the evidence index, sets the caliber processing status identifier to caliber failure, and sets the caliber encapsulation allow flag to prohibit. The rule normalization and serialization unit replaces field names with unified field names according to the field mapping rule set, sorts commutative operation operands in lexicographical order, and normalizes numerical constants and time constants. The format of configuration record registration is fixed, generating a standardized rule string. A node fingerprint string is generated by deterministic serialization according to the field order of the serialized configuration record registration, fixed delimiters, and null placeholders. The upstream node identifier set is sorted lexicographically, and the node identifier, node type, and sorted upstream node identifier set are concatenated with the standardized rule string according to the field order of the serialized configuration record registration. During concatenation, the fixed delimiters of the serialized configuration record registration are used, and null values ​​are written into fixed placeholders, thereby generating the node fingerprint string and writing it into the fingerprint cache. When the field mapping rule set cannot match a field name, the rule normalization serialization unit writes the missing field reason code into the evidence index, sets the caliber processing status flag to caliber failure, and sets the caliber encapsulation allow flag to prohibit. A caliber lineage deterministic fingerprint generation algorithm is used to perform rule normalization processing on the node rule text and deterministic serialization processing on the normalization result, thereby generating a standardized rule string and a node fingerprint string, which are then written into the fingerprint cache. The formula for the caliber lineage deterministic fingerprint generation algorithm executed by the rule normalization serialization unit is as follows: ， in Let S be the node fingerprint string of the i-th node, where S is the node fingerprint string and i is the index of the caliber node. For deterministic serialization functions, Let i be the node identifier of the i-th node. Let i be the node type of the i-th node. This represents the result after sorting the upstream node identifier set in lexicographical order. The result after lexicographical sorting. The set of upstream node identifiers of the i-th node. Let be the normalized rule string of the i-th node. Configure for serialization.

7. The enterprise information management integration platform based on big data according to claim 1, characterized in that: The specific steps of the joint locking module for the caliber version and field mapping version are as follows: The transformation digest generation unit generates node transformation digest values ​​by performing secure hash calculation on the node fingerprint string, and generates a caliber lineage version chain fingerprint by performing chain aggregation on the node transformation digest values ​​according to the topologically ordered node sequence, and writes it into the caliber lineage database. The version conflict verification unit generates a historical chain fingerprint set by retrieving the caliber lineage database using a joint key composed of the indicator identifier, caliber version number, and field mapping version number, and generates a conflict determination result by performing an equivalence comparison between the current caliber lineage version chain fingerprint and the historical chain fingerprint set. When the conflict determination result is no conflict, the caliber blocking and evidence output unit sets the caliber processing status flag to caliber pass and sets the caliber encapsulation allow flag to allow, and outputs the caliber lineage version chain as subsequent encapsulation input. When the conflict determination result is conflict, the caliber blocking and evidence output unit sets the caliber processing status flag to caliber failure, writes the joint key, caliber lineage version chain fingerprint, and conflict reason code into the evidence index, and sets the caliber encapsulation allow flag to prohibit entry into the subsequent encapsulation input set.

8. The enterprise information management integration platform based on big data according to claim 1, characterized in that: The specific steps of the evidence index binding and consistency verification encapsulation module are as follows: The event fragment serialization unit obtains the unique event identifier, unique subject identifier, indicator identifier, operation timestamp, operation type, object identifier, and processing purpose by reading the event ledger records passed by the subject, and obtains the caliber version number, field mapping version number, and caliber caliber version chain fingerprint by reading the caliber's caliber lineage version chain, thereby generating an event fragment field set; the event fragment serialization unit generates an event fragment string by performing deterministic serialization on the event fragment field set according to the field order registered in the encapsulation configuration table; The fragment digest calculation unit generates a fragment digest value by performing secure hash calculation on the event fragment string according to the hash algorithm type registered in the hash algorithm configuration item; the evidence index binding unit generates an evidence index record by writing the event unique identifier, fragment digest value, caliber lineage version chain fingerprint, indicator identifier, subject unique identifier and operation timestamp into the evidence index, and writes the evidence index identifier back to the evidence index field of the event ledger record to establish a searchable binding relationship.

9. The enterprise information management integration platform based on big data according to claim 1, characterized in that: The specific steps of the evidence index binding and consistency verification encapsulation module are as follows: The batch grouping unit reads the batch window duration from the encapsulation configuration table and limits the batch window duration to five to sixty minutes. It then groups the evidence index records according to the operation timestamp, generating a batch set and writing the batch identifier, window start time, and window end time to generate batch index records. The intra-batch sorting unit sorts the evidence index records within the same batch in ascending order by operation timestamp and, if timestamps are the same, in lexicographical order by event unique identifier, thus generating an intra-batch ordered record sequence. The preceding digest chain generation unit performs a secure hash calculation on the batch identifier and window start time to generate a chain start digest. It then iteratively aggregates the preceding digest value and the current fragment digest value in ascending order of the intra-batch ordered record sequence to generate a preceding digest chain value sequence. The preceding digest chain value corresponding to the evidence index record is written into the preceding digest chain field of the evidence index record to generate the chain value storage result; the digest tree construction unit aggregates the fragment digest values ​​layer by layer until a single digest root is obtained by concatenating adjacent pairs and performing secure hash calculation to generate the batch digest root. When the number of fragment digest values ​​is even, the digest tree construction unit generates the batch digest root by aggregating adjacent pairs. When the number of fragment digest values ​​is odd, the digest tree construction unit generates the batch digest root by copying the last fragment digest value to make it even and then aggregating adjacent pairs; the digest root signature unit generates the digest root signature value by reading the signature key identifier and signature algorithm type in the key configuration table and performing signature operation on the batch digest root, and writes it into the signature field of the batch index record.

10. The enterprise information management integration platform based on big data according to claim 1, characterized in that: The specific steps of the evidence index binding and consistency verification encapsulation module are as follows: The consistency recalculation verification unit rereads the event fragment string one by one within the ordered record sequence of the batch and recalculates the fragment digest value, the preceding digest chain value, and the batch digest root to generate a recalculated digest root. It then performs an equivalence comparison between the recalculated digest root and the batch digest root in the batch index record to generate a consistency verification result. When the consistency verification result is successful, the consistency recalculation verification unit sets the batch status identifier to "encapsulation passed," triggering the evidence package generation unit to generate a verifiable auditable evidence package. When the consistency verification result is unsuccessful, the consistency recalculation verification unit sets the batch status identifier to "encapsulation failed," writes a failure reason code, generates the first inconsistency position number, and writes it into the failure location field to generate minimum resampling location information. It then performs an equivalence comparison one by one between the preceding digest chain field of the evidence index record and the preceding digest chain value recalculated by the consistency recalculation verification unit. Upon the first inconsistency, it determines the first inconsistency position number and writes it into the failure location field to generate minimum resampling location information. The formula for the evidence inconsistency location algorithm is as follows: , in The consistency recalculation verification unit recalculates the preorder summary chain value obtained from the j-th evidence index record. Let j be the index of the preorder summary chain obtained by recalculation, and j be the index of the ordered record sequence within the batch. For secure hash calculation functions, The fragment digest value is obtained by the consistency recalculation verification unit from the event fragment string corresponding to the j-th evidence index record. It is a hash algorithm type; The failure re-sampling scheduling unit calculates the re-sampling start boundary and re-sampling end boundary by reading the operation timestamp of the record corresponding to the failure location field and combining it with the re-sampling time extension registered in the encapsulation configuration table, thereby generating a supplementary sampling task. The re-sampling time extension is limited to ten seconds to three hundred seconds. The batch identifier, re-sampling start time, re-sampling end time, failure reason code and data source identifier are written into the re-sampling queue to trigger the acquisition side to supplement sampling according to the re-sampling time boundary and re-enter the event fragment serialization processing flow.

Images