Data transmission method and apparatus, electronic device, and storage medium

Abstract

Embodiments of the present specification provide a data transmission method and device, electronic equipment and storage medium, the method comprising: obtaining target transmission data of a transaction party, determining whether there is abnormal data in the target transmission data according to a preset semantic rule set, if there is abnormal data, determining whether the abnormal data is repairable data according to a repair rule, if it is repairable data, repairing the repairable data according to a preset repair action indicated in the repair rule to obtain repaired transmission data, and transmitting the repaired transmission data and qualified data except the abnormal data in the target transmission data to a receiving party.

Description

Technical Field

[0001] This specification relates to the field of data processing technology, and in particular to a data transmission method, apparatus, electronic device and storage medium. Background Technology

[0002] In cross-system data reporting scenarios, data must be submitted to the target platform according to a unified standard. In practice, data that does not conform to the platform's specifications is often returned and needs to be resubmitted. This not only leads to a high data transmission failure rate and reduced efficiency in cross-system collaboration, but also causes a series of problems such as increased costs of repetitive operations, serious waste of resources, data consistency deviations, and the accumulation of compliance risks. There is an urgent need to propose an efficient pre-processing solution to address these issues. Summary of the Invention

[0003] The main purpose of this specification is to provide a data transmission method, apparatus, electronic device, and storage medium, aiming to solve the problem of requiring extensive manual intervention when data anomalies occur, achieving automated repair, and improving transmission efficiency and quality. The technical solution is as follows:

[0004] Firstly, embodiments of this specification provide a data transmission method, including:

[0005] Obtain the target data to be transmitted from the transaction party;

[0006] Determine whether there is abnormal data in the target transmitted data based on a preset semantic rule set;

[0007] If abnormal data exists, the abnormal data is identified as repairable data according to the repair rules.

[0008] If the data is repairable, the repairable data is repaired according to the preset repair actions indicated in the repair rules to obtain the repaired transmission data;

[0009] The repaired transmission data, along with the qualified data (excluding the abnormal data) in the target transmission data, is transmitted to the receiver.

[0010] Secondly, embodiments of this specification provide a data transmission device, including:

[0011] The acquisition unit is used to acquire the target transmission data of the transaction party.

[0012] An anomaly detection unit is used to determine whether there is abnormal data in the target transmitted data according to a preset semantic rule set;

[0013] The repair identification unit is used to identify whether the abnormal data is repairable data according to the repair rules if abnormal data exists.

[0014] The repair processing unit is used to repair the repairable data according to the preset repair actions indicated in the repair rules if the data is repairable, so as to obtain the repaired transmission data.

[0015] A transmission unit is used to transmit the repaired transmission data together with the qualified data in the target transmission data, excluding the abnormal data, to the receiver.

[0016] Thirdly, embodiments of this specification provide an electronic device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the method described above.

[0017] Fourthly, embodiments of this specification provide a storage medium storing a computer program, which, when executed by a processor, implements the steps of the method described above.

[0018] Fifthly, embodiments of this specification provide a computer program product, including: a computer program that, when executed by a processor of an electronic device, enables the processor to at least implement the method described in the first or second aspect.

[0019] In the embodiments of this specification, the target transmission data of the transaction party is obtained, and it is determined whether there is abnormal data in the target transmission data according to a preset semantic rule set. If abnormal data exists, it is identified whether the abnormal data is repairable according to the repair rules. If it is repairable, the repairable data is repaired according to the preset repair actions indicated in the repair rules to obtain repaired transmission data. The repaired transmission data is then transmitted to the receiver along with the qualified data in the target transmission data excluding the abnormal data. By automatically determining whether there is abnormal data in the data to be transmitted and identifying repairable data among the abnormal data, and repairing the repairable data according to the preset repair actions, manual intervention in abnormal data is reduced, data accuracy is improved, and data is transmitted only after repair processing, thereby improving the transmission success rate. Attached Figure Description

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

[0021] Figure 1 This is a schematic diagram illustrating an example of a data transmission method provided in the embodiments of this specification;

[0022] Figure 2 This is a flowchart illustrating a data transmission method provided in an embodiment of this specification;

[0023] Figure 3 This is a flowchart illustrating a data transmission method provided in an embodiment of this specification;

[0024] Figure 4 This is a flowchart illustrating a data transmission method provided in an embodiment of this specification;

[0025] Figure 5 This is a schematic diagram of the overall process of a data transmission method provided in the embodiments of this specification;

[0026] Figure 6 This is a schematic diagram of the structure of a data transmission device provided in the embodiments of this specification;

[0027] Figure 7 This is a schematic diagram of the structure of a data transmission device provided in the embodiments of this specification;

[0028] Figure 8 This is a schematic diagram of the structure of an electronic device provided in the embodiments of this specification. Detailed Implementation

[0029] The technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this specification.

[0030] Furthermore, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data transmitted, data stored, data displayed, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0031] In related technologies, most implementing entities still adopt the following operating mode during data reporting: first, submit the data to the target platform; after receiving the data return file from the target platform, manually analyze the cause of data errors, then manually correct the errors, and finally resubmit the corrected data to the target platform. Some data senders have built preliminary pre-verification mechanisms that can identify obviously abnormal data through simple rules before data reporting; however, such mechanisms only support interception and alarms and lack data repair capabilities. All anomalies still need to be transferred to manual processing, leading to increased manual operation costs, time-consuming rework, and a high risk of errors.

[0032] To address the aforementioned problems, this specification provides a data transmission method. Please refer to the embodiments provided. Figure 1 This diagram illustrates an example of a data transmission method provided in this specification. It involves acquiring the target transmission data from the transaction party, determining whether abnormal data exists within the target transmission data based on a preset semantic rule set, and identifying whether the abnormal data is repairable according to repair rules. If repairable, the repairable data is repaired according to preset repair actions indicated in the repair rules, resulting in repaired transmission data. This repaired transmission data, along with the qualified data (excluding abnormal data) from the target transmission data, is then transmitted to the receiver. By automatically determining whether abnormal data exists in the data to be transmitted and identifying repairable data within the abnormal data, and repairing the repairable data according to preset repair actions, manual intervention in abnormal data is reduced, improving data accuracy. Transmission is then performed after repair processing, thereby increasing the transmission success rate.

[0033] Data transmission methods can be implemented using data transmission devices. It is understood that the data transmission devices provided in the embodiments of this specification can be terminal devices such as mobile phones, computers, tablets, smartwatches, or in-vehicle devices, or modules within terminal devices used to implement the data transmission method, such as transaction servers. The transaction party is the sender that needs to transmit data to the receiver. The receiver can be a data statistics platform, a data auditing platform, or a data storage center; no specific limitation is made.

[0034] The data transmission method provided in this specification will be described in detail below with reference to specific embodiments.

[0035] Please see Figure 2 This is a flowchart illustrating a data transmission method provided in an embodiment of this specification. Figure 2 As shown, the method in the embodiments of this specification may include the following steps S102-S110.

[0036] S102, Obtain the target transmission data of the transaction party;

[0037] In one embodiment of this specification, the transaction party refers to the entity that initiates the data transmission request, which can cover various data generation or sending nodes, such as transaction systems, data acquisition terminals, and participants in cross-platform collaboration. The target transmitted data refers to the original dataset that the transaction party needs to transmit to the receiver. This dataset contains one or more data fields (such as document type field, loan date field, amount field, etc.) and is the object of subsequent anomaly detection and repair.

[0038] For example, in a financial scenario, the transaction party could be a consumer finance company, the recipient could be a bank, and the target data to be transmitted could be user credit data.

[0039] S104, determine whether there is abnormal data in the target transmitted data according to the preset semantic rule set;

[0040] In one embodiment of this specification, the preset semantic rule set refers to a set of rules used to determine whether a data field conforms to the transaction specification. Optionally, this preset semantic rule set can be written based on a self-developed domain-specific language (DSL). Each rule targets a specific data field and includes three elements: field range, verification condition, and judgment action. It can be configured as needed and supports flexible expansion. A rule example is explained below: The verification target field of rule R001 is id_type, i.e., the document type code. The verification condition is that the field value is not in the compliance list. The judgment action is to mark the field as invalid data and add the reason "document type code does not conform to the specification".

[0041] The system loads a preset semantic rule set that matches the metadata of the currently target transmitted data. This preset semantic rule set supports canary releases, allowing only a portion of the rules to take effect within a specified range. If any field in the target transmitted data does not meet the verification requirements of the preset semantic rule set, it is identified as abnormal data. Abnormal data can include data with format errors, invalid values, logical contradictions, etc. If no abnormal data is found after verification, the system waits to proceed to the data transmission stage.

[0042] For example, the transaction's rule engine performs field-by-field validation on the target transmitted data. For each data field, it matches the rule corresponding to the field attribute in the rule set. The engine executes the condition judgment in the rule. If the field data meets the condition, the field is determined to be abnormal data. If the condition is not met, the field is determined to be valid data.

[0043] S106, If abnormal data exists, then the abnormal data is identified as repairable data according to the repair rules;

[0044] In one embodiment of this specification, the repair rule is a subset of rules associated with a preset semantic rule set, used to define the criteria for determining whether abnormal data is repairable, and the corresponding repair logic. The repair rule can be bound to domain-specific language validation rules or configured independently. For each piece of abnormal data, a corresponding repair rule is matched. If the abnormal data does not meet the repair rule or there is no matching repair rule, it is determined to be unrepairable data, such as abnormal data where core key fields are completely missing and no related data can be used to supplement them.

[0045] S108, If the data is repairable, the repairable data is repaired according to the preset repair action indicated in the repair rule to obtain the repaired transmission data;

[0046] In one embodiment of this specification, repairable data refers to abnormal data with standardized repair logic, which can be corrected into compliant data by executing preset repair actions. Repairable data that meets the repairable conditions indicated in the repair rules is identified, and the preset repair actions indicated by the repair rules are executed to obtain repaired transmission data. The repaired transmission data is compliant data that conforms to the requirements of a preset semantic rule set. In one feasible implementation, the preset repair actions may include automatic filling, format conversion, value correction, logical verification completion, etc.

[0047] For example, the condition of the repair rule is evaluated. If the field data meets the condition, an action is triggered. Taking rule R002 as an example, when the loan_date field is empty and the apply_date field has a valid value, the system automatically calls the rptdate function to process the value of the apply_date field, generates a date format that conforms to the specification, and fills it into the loan_date field.

[0048] Optionally, after the repair is completed, the system performs a second verification on the repaired data, and calls the preset semantic rule set again to verify whether the repaired data meets the requirements, and to determine whether the repair will cause other rule conflicts, thereby improving the security of the repair.

[0049] Optionally, in one embodiment of this specification, if the abnormal data is identified as not repairable according to the repair rules, the abnormal data is pushed to manual processing. For abnormal data that is determined to be unrepairable automatically, manual processing can be prompted. When pushing to manual processing, preset rules that the abnormal data does not meet can also be simultaneously fed back.

[0050] S110, the repaired transmission data and the qualified data in the target transmission data, excluding the abnormal data, are transmitted to the receiver.

[0051] In one embodiment of this specification, the repaired transmission data is integrated with the qualified data in the target transmission data to form a complete final transmission dataset that meets the recipient's requirements. The system sends the final transmission dataset to the recipient according to a preset transmission protocol, which may include Hypertext Transfer Protocol, Hypertext Transfer Secure Protocol, File Transfer Protocol, Database Synchronization Protocol, etc.

[0052] Optionally, a transmission log can be recorded, including transmission time, data volume, repair records, and receiver feedback, to facilitate subsequent traceability and auditing.

[0053] In the embodiments of this specification, the target transmission data of the transaction party is obtained; the target transmission data is verified according to a preset semantic rule set to determine whether there is abnormal data; if the verification result shows that there is abnormal data, the abnormal data is further identified as repairable data in combination with repair rules; if it is determined to be repairable data, the repair operation is performed on the repairable data according to the preset repair actions specified by the repair rules to generate repaired transmission data; finally, the repaired transmission data is integrated with the qualified data in the target transmission data excluding abnormal data and transmitted together to the receiver. This method automatically determines abnormal data in the data to be transmitted, accurately identifies data that has repair conditions, and then completes the correction of repairable data based on preset repair actions, effectively reducing the degree of manual intervention in abnormal data processing, improving the accuracy of the data itself, and improving the overall data transmission success rate by completing the repair processing before data transmission.

[0054] Please see Figure 3 This is a flowchart illustrating a data transmission method provided in an embodiment of this specification. Figure 3 As shown, the method described in the embodiments of this specification may include the following steps S202-S212.

[0055] S202, determine whether the abnormal field in the abnormal data belongs to the field type that is allowed to be automatically repaired;

[0056] In one embodiment of this specification, specific criteria for determining the repair rule are provided. First, the repair rule must include determining whether the abnormal field belongs to a field type that is allowed for automatic repair. It is understood that the purpose of determining whether a field is a field type that is allowed for automatic repair is to prevent accidental manipulation of sensitive fields, such as identity codes and amounts. Which fields belong to fields that are allowed for automatic repair can be defined in advance according to transaction requirements, and this definition can be written into the repair rule.

[0057] S204, If it belongs to a field type that allows automatic repair, then determine whether the abnormal field has a reliable source of supplementary data or supplementary derivation logic;

[0058] In one embodiment of this specification, if the abnormal field belongs to a field type that allows automatic repair, then it is further determined whether there is a corresponding reliable data supplementary source or supplementary derivation logic for the abnormal field. The reliable data supplementary source can be a high-confidence external data source, such as a customer master data platform, core system accounting records, official information registration system, etc.

[0059] The existence of supplementary derivation logic means that the value of this field can be generated based on calculations with explicit derivation logic, such as the existence of mathematical or transactional formulas. For example, the derivation logic for the loan disbursement date can be set as: application date + 7 days = loan disbursement date. Then, when the loan disbursement date is empty, the loan disbursement date can be derived from the queried application date.

[0060] Optionally, the supplementary derivation logic may also include preset replacement logic, such as requiring that the value of a certain field cannot be empty, and that when it is empty, it is identified as an abnormal field. For this abnormal field, a repair rule can be set so that when the value (content) of the field is empty, it can be filled with "unknown".

[0061] S206, if there is a reliable source of supplementary data or supplementary derivation logic, then the abnormal data is determined to be repairable data.

[0062] In one embodiment of this specification, if the abnormal field is both a field type that allows automatic repair and has a corresponding reliable source of supplementary data or supplementary derivation logic, then the data is determined to be repairable data.

[0063] S208, if there is a reliable data supplementation source for the repairable data, then obtain the standard reference value corresponding to the abnormal field from the reliable data supplementation source, and use the standard reference value as the value of the abnormal field to obtain the repaired transmission data;

[0064] In one embodiment of this specification, when repairing repairable data, if the repairable data belongs to a source of reliable supplementary data, the standard reference value corresponding to the abnormal field is obtained from the source of reliable supplementary data, and the obtained standard reference value is filled into the position of the abnormal field to replace the original abnormal data content, thereby completing the repair of the abnormal field and integrating it to obtain the repaired transmission data.

[0065] In one feasible implementation, the abnormal field can be directly used as a query condition to query the standard reference value corresponding to the abnormal field in the trusted data supplement source.

[0066] For example, if the name field is found to be empty in the registration form of the target transmitted data, and the name field is determined to be repairable abnormal data, the name information of the record can be obtained from other trusted data sources that store the name field, such as a confirmation form (which registers names).

[0067] In another feasible implementation, the effective associated field information of the abnormal field is extracted. The aforementioned effective associated field information is the field content that can uniquely match the target data in the trusted data supplementary source. The extracted effective associated field information is used as the query condition, and a retrieval operation is performed in the trusted data supplementary source to obtain the standard reference value corresponding to the abnormal field.

[0068] For example, if the name field in the target transmitted data is empty, and the name field is determined to be repairable abnormal data, the system further identifies that the target transmitted data contains an ID number field with a valid value. In this case, the ID number field becomes the valid associated field information, and the preset trusted data supplementation source is the customer information registration platform. The system uses the ID number as a query parameter, accesses the customer information registration platform's interface and performs a retrieval, retrieves the name information bound to that ID number as a standard reference value, and fills that name information into the name field of the target transmitted data, thus completing the repair of the abnormal field.

[0069] S210, if the repairable data has supplementary derivation logic, then a set reference value is obtained based on the indication of the supplementary derivation logic, and a supplementary value is generated according to the supplementary derivation logic and the set reference value. The supplementary value is used as the value of the abnormal field to obtain the repaired transmission data.

[0070] In one embodiment of this specification, supplementary derivation logic matching the abnormal field is retrieved. This supplementary derivation logic is a pre-defined derivation rule based on the transaction rules, data relationships, or algorithm model of the transaction parties, used to generate abnormal field values ​​that conform to the specifications. According to the requirements of the supplementary derivation logic, reference values ​​are extracted from other qualified fields of the target transmitted data. These reference values ​​are the basic data required for the derivation process. Operations, transformations, or correlation derivations are performed according to the steps of the supplementary derivation logic to generate supplementary values ​​matching the abnormal field. The generated supplementary values ​​are used as the values ​​of the abnormal field, replacing the original abnormal data content, and integrated to obtain the repaired transmitted data.

[0071] For example, if the loan maturity date field in the target transmitted data is empty, and this field is determined to be repairable abnormal data, the system identifies the preset supplementary derivation logic as "Loan Maturity Date = Loan Disbursement Date + Loan Term". In this case, the values ​​of the loan disbursement date and loan term fields are extracted from the qualified fields in the target transmitted data as reference values ​​for the supplementary derivation. The system performs calculations according to this derivation logic. For example, if the loan disbursement date is 2025-01-01 and the loan term is 12 months, the derived supplementary value will be 2026-01-01. This date is then filled into the loan maturity date field, completing the repair of the abnormal field.

[0072] For example, if the report statistics date field in the target transmitted data is empty, the supplementary derivation logic is "the report statistics date is the last day of the month corresponding to the application date". The system extracts the value of the application date field in the target transmitted data as a set reference value. If the application date is 2025-03-15, then according to the derivation logic, the last day of the month is calculated to be 2025-03-31. This date is then used as a supplementary value to fill the report statistics date field, completing the repair.

[0073] S212, record the repairable data, the repaired transmission data, the rule version of the repair rule, and the repair timestamp to the repair record table of the transaction party.

[0074] In one embodiment of this specification, four types of data are collected synchronously from the repair process: repairable data (i.e., the original abnormal data), repaired transmitted data, the rule version of the repair rule, and the repair timestamp. This information is written into a dedicated repair record table for the transaction party, enabling traceability of the repair process.

[0075] For example, when transaction party "BIZ001" (a financial company) transmits customer credit data to the recipient, the system detects that the "id_type" field of 10 data entries is a textual description (such as "ID card" or "passport"), which does not comply with the recipient's "digital encoding" specification (rule R001 v2.3 stipulates that "ID card corresponds to code 01, passport corresponds to code 05"). After the system automatically corrects "ID card" to "01" through the repair rule, an entry is created in the repair record table of transaction party "BIZ001" for each repaired data entry, recording "repairable data 'ID card', repaired transmission data '01', repair rule version v2.3, and repair timestamp 2025-03-15T10:23:00".

[0076] For example, the repair log table can be recorded in JSON format:

[0077] {

[0078] "original": {"id_type": "ID card"},

[0079] "corrected": {"id_type": "01"},

[0080] "rule_version": "v2.3",

[0081] "timestamp": "2025-03-15T10:23:00"

[0082] }

[0083] In one embodiment of this specification, recording the repairable data, the repaired transmission data, the rule version of the repair rule, and the repair timestamp into the repair record table specifically includes the following steps:

[0084] S2122, Generate the first encrypted digest identifier corresponding to the repairable data;

[0085] In one embodiment of this specification, to achieve tamper-proofing and efficient retrieval, an encrypted digest is generated for the repairable data and the repaired transmitted data. An encryption algorithm is used to generate a first encrypted digest identifier for the repairable data, ensuring that the same repairable data generates a unique digest identifier, and different repairable data correspond to different digest identifiers.

[0086] For example, the SHA-256 hash algorithm can be used to calculate the cryptographic digest identifier.

[0087] S2124, Generate a second encrypted digest identifier corresponding to the repaired transmission data;

[0088] In one embodiment of this specification, the same encryption algorithm is used, but only the repaired transmitted data (i.e., the corrected data) is encrypted to generate a second encrypted digest identifier. By generating digests independently for both the data before and after modification, it is ensured that any tampering of the data can be quickly identified through the corresponding digest.

[0089] S2126, Record the first encrypted digest identifier, the second encrypted digest identifier, the repairable data, the repaired transmission data, the rule version of the repair rule, and the repair timestamp to the repair record table of the transaction party.

[0090] In one embodiment of this specification, the first encrypted digest identifier, the second encrypted digest identifier, the repairable data, the repaired transmission data, the rule version, and the timestamp are written into the transaction party's repair record table. Optionally, the two digest identifiers can be used as "retrieval primary keys" to achieve efficient retrieval based on the characteristics of the data itself.

[0091] Understandably, if a field undergoes multiple repair processes, then these repair processes for the same field can be recorded sequentially.

[0092] This specification provides specific implementation methods for determining whether abnormal data is repairable and specific repair methods for repairable data in its embodiments. It determines whether the abnormal field in the abnormal data belongs to a field type that allows automatic repair; if it does, it determines whether the abnormal field has a reliable data supplementary source or supplementary derivation logic; if a reliable data supplementary source or supplementary derivation logic exists, the abnormal data is determined to be repairable. If the repairable data has a reliable data supplementary source, a standard reference value corresponding to the abnormal field is obtained from the reliable data supplementary source, and the standard reference value is used as the value of the abnormal field to obtain the repaired transmission data; if the repairable data has supplementary derivation logic, a set reference value is obtained based on the indication of the supplementary derivation logic, and a supplementary value is generated according to the supplementary derivation logic and the set reference value, and the supplementary value is used as the value of the abnormal field to obtain the repaired transmission data. Furthermore, a repair record scheme is provided, recording the repairable data, the repaired transmission data, the rule version of the repair rule, and the repair timestamp in the transaction's repair record table to ensure that data modifications are traceable.

[0093] Please see Figure 4 This is a flowchart illustrating a data transmission method provided in an embodiment of this specification. Figure 4 As shown, the method described in the embodiments of this specification may include the following steps S302-S312.

[0094] S302, Receive the transmission feedback result sent by the receiver;

[0095] In one embodiment of this specification, the receiver has data verification capabilities and feedback output functions. After verifying the transmitted data, the receiver returns a transmission feedback result, such as successful reception or reception failure. Furthermore, the transmission feedback result may also include a unique identifier of the failed transmission data, a description of the reason for the failure, etc.

[0096] S304, Based on the transmission feedback results, collect transmission failure data samples and transmission success data samples to construct a dataset for comparative analysis;

[0097] In one embodiment of this specification, based on the transmission feedback results indicating transmission failure or success, transmission failure data samples and transmission success data samples are collected to construct a dataset for comparative analysis. Transmission failure data samples refer to the set of data selected from the transmission feedback results and marked as transmission failure by the receiver. Transmission success data samples refer to the set of data selected from the transmission feedback results and marked as transmission success by the receiver.

[0098] Generally, transmission failures may include the following five situations: 1. Illegal enumeration values: The field uses a value not in the standard code table, such as id_type = "ID card", but should be the standard code "01" to represent an ID card. 2. Null values: A field is frequently empty in failed samples but rarely empty in successful samples. 3. Values ​​out of bounds / unreasonable: Values ​​exceed reasonable ranges or violate common sense, such as age = 150 years old. 4. Missing cross-field constraints: Only one of the fields that should exist simultaneously is filled in, such as a spouse's name but marital status is empty. 5. Non-compliant text format: Values ​​do not conform to the preset format, such as an ID card code length not being 18 digits or a mobile phone number containing Chinese characters. When pre-generating the preset rule set, these possible causes of transmission failures may not be identified or fully covered, or the receiver may have updated the transmission specifications but not synchronized them with the transaction party in a timely manner. Therefore, by collecting transmission failure data samples and transmission success data samples and constructing a dataset for analysis, the causes of transmission failures can be further identified, enabling automatic updates to the preset rule set.

[0099] S306, For each field in the dataset, compare the value of the field in the transmission failure data sample with the value in the transmission success data sample, and identify the field with the value difference in the transmission failure data sample;

[0100] In one embodiment of this specification, the value characteristics of each field in the dataset are compared individually between failed and successful samples. The comparison dimensions include value range, data format, frequency of occurrence, and logical association features. Examples include: value range (e.g., a list of possible values ​​for `id_type`); data format (e.g., date format "YYYY-MM-DD" or "YYYY / MM / DD"); frequency distribution (e.g., the number of times a value appears in the samples and its percentage); and logical association features (e.g., whether `loan_date` is earlier than `apply_date`).

[0101] Identify fields whose values ​​differ significantly between failed samples and successful samples. These differences are the core cause of data transmission failures. For example, "the id_type field is mostly textual in failed samples, but numeric in successful samples, so the id_type field is a field with a value difference." or "the loan_date field is mostly later than apply_date in successful samples, but earlier than apply_date in failed samples, so loan_date is a field with a value difference."

[0102] S308, Generate a verification rule for the value difference field based on the value of the value difference field in the successful transmission data sample.

[0103] In one embodiment of this specification, for a value difference field, a verification rule for the value difference field is generated based on the value of the value difference field in the successfully transmitted data sample. The quantifiable characteristics of the value difference field in the successfully transmitted sample, such as the compliant value range, format standard, and logical rules, are the core basis for the verification rule.

[0104] In one feasible implementation, compliance features are extracted from successful samples for each value difference field. Compliance features may include: value range features (e.g., a list of compliant values ​​for id_type ["01", "05", "06"]); format features (e.g., the compliant format of loan_date is "YYYY-MM-DD"); logical association features (e.g., loan_date must be later than apply_date); optionally, feature confidence scores can also be calculated for compliance features (the coverage percentage of the compliance feature in successful samples, e.g., if the compliant values ​​of id_type cover 100% of successful samples, the confidence score is 1.0).

[0105] For example, if a field is mostly empty in failed samples but rarely empty in successful samples, then this field is a value difference field, and this field may not be allowed to be empty. Rules can be generated for this field, requiring the detection of whether the field is empty, identifying an anomaly when it is empty, or automatically filling in the empty fields.

[0106] For example, the values ​​of the id_type field are mostly textual descriptions in failed samples and numeric codes in successful samples. Therefore, a new rule can be added to determine that id_type is abnormal when the value of id_type is "Hong Kong and Macao Travel Permit". The value of the id_type field needs to be in data encoding format.

[0107] More specifically, for the abnormal value field id_type, features are extracted from successful data samples, and a list of compliant values ​​["01", "05", "06"] (covering 100% of successful samples, with a confidence level of 0.98) is generated. Textual descriptions are prohibited. Therefore, the following JSON-formatted validation rules can be generated:

[0108] / / Automatically generated rule ID: AUTO_R_20250401_001

[0109] rule AUTO_R_20250401_001 {

[0110] field: id_type / / The target field for verification is the document type code.

[0111] condition: value not in ["01","05","06"] ||

[0112] value matches_chinese_pattern() / / The value is not in the compliance list or is Chinese

[0113] action: mark_invalid("Document type must use standard numeric encoding, compliant encoding is 01, 05, 06") / / Mark invalid and indicate the reason.

[0114] source: anomaly_mining_v2 / / Rule source is the anomaly mining module

[0115] confidence: 0.98 / / Rule confidence (based on successful sample coverage) applicable_business: ["Personal Loans", "Business Loans"] / / Applicable business lines

[0116] }

[0117] S310, Obtain the constraints of the value difference field based on the transaction metadata knowledge base of the transaction party; wherein, the constraints include at least the standard encoding table of the field, the definition of mandatory fields, the data source identifier, and the dependency relationship between fields;

[0118] In one embodiment of this specification, the transaction metadata knowledge base refers to a structured knowledge base preset by the transaction party to define the basic attributes of data fields and transaction constraints. For the identified value difference fields, the constraints stored in the transaction metadata knowledge base can also be obtained to determine whether the difference is caused by the value of the value difference field not meeting the constraints, and then a verification rule can be generated.

[0119] Constraints refer to standardized control rules extracted from the transaction metadata knowledge base for fields with differing values. They are the core benchmark for determining field compliance and include at least a standard coding table, mandatory field definitions, data source identifiers, and inter-field dependencies. The standard coding table stores the mapping relationship between compliant field values ​​and their definitions; for example, the standard codes for `id_type` are 01, 05, and 08. Mandatory field definitions indicate whether a field is a mandatory field for a transaction, including three types: "mandatory," "optional," and "conditionally mandatory," along with the conditional triggering logic. Data source identifiers are the codes for the legitimate data collection channels of the field (e.g., "CRM system = S001," "manual entry = S002"), used to verify the legality of the data source. Inter-field dependencies are the logical association rules between this field and other fields (e.g., when "marital status = married," it must be associated with the "spouse information" field).

[0120] For example, the constraints of the id_type field are as follows: Standard encoding table (version V2.0, adapted for personal loan transactions): {"01":"Resident ID card","05":"Passport","08":"Mainland Travel Permit for Hong Kong and Macao Residents"}; Required field definition: "Required", and there are no exemptions in the "Personal Loan" transaction scenario; Data source identifier: The legal source is "Customer Identity Authentication System (S003)" and "CRM Customer File (S001)"; Dependency relationship between fields: When "id_type=07", it needs to be associated with the "Validity Period of Mainland Travel Permit for Hong Kong and Macao Residents" field.

[0121] S312, if the value of the value difference field does not meet the constraint condition, then a verification rule for the value difference field is generated based on the constraint condition.

[0122] In one embodiment of this specification, the value of the value difference field is verified to meet the constraints extracted from the transaction metadata knowledge base, thereby generating a verification rule for the value difference field.

[0123] For example, if the text value of 'Hong Kong and Macao Travel Permit' in id_type does not correspond to the code 07, then a verification rule will be generated, and id_type needs to meet the standard encoding format.

[0124] For example, in the case of an abnormal value field, the transaction number, the transaction number in a successful transmission sample is 10 or 11 digits, while the transaction number in a failed transmission sample is 10 digits. In this case, directly setting the verification rules for the transaction number based on the value range of the successful transmission sample may not be accurate. It is possible to further obtain the constraints of the transaction metadata knowledge base. The constraints of the historical transaction number may be 10 or 11 digits, while the latest constraint is that the transaction number must be 11 digits, which leads to transmission failure. At this time, the verification rules for the transaction code can be generated based on the constraints of the transaction metadata knowledge base.

[0125] This approach, based on the constraints of the transaction metadata knowledge base, ensures that the rules comply with the core transaction specifications of the transaction parties, thus avoiding the limitations of relying on transmission feedback samples.

[0126] In the embodiments of this specification, based on the actual transmission feedback results of the receiver, the verification rules are automatically extracted according to the compliance characteristics of the successfully transmitted data samples. The rule updates can be completed without manual intervention, adapting to the dynamic changes of the receiver's verification standards.

[0127] Please see Figure 5This document provides a schematic diagram of the overall flow of a data transmission method according to an embodiment of this specification. The method involves: acquiring the target transmission data from the transaction party (which can be data to be reported to the receiver daily); then entering the rule center, which maintains a preset semantic rule set; executing this set on the target transmission data to identify abnormal data that does not meet the preset semantic rules and qualified data that does; further identifying whether abnormal data is repairable according to repair rules; if so, repairing the repairable data using preset repair actions indicated in the repair rules, generating and storing a repair record, and then transmitting the repaired data to the transmission channel entry point; and for data that cannot be automatically repaired, generating a work order for intercepted abnormal data and pushing it to a human operator. The human operator can then investigate and repair the problem using the preset semantic rules not met recorded in the intercepted work order, and send the manually repaired data to the transmission channel entry point, integrating it with the qualified data and automatically repaired transmission data before sending it to the receiver. The transmission feedback results sent by the receiver can be sent to the rule optimizer. The rule optimizer automatically generates verification rules based on the transmission feedback results and updates them to the rule center. The rule center can verify and test them. If the test passes, they are added to the preset semantic rule set for subsequent data detection.

[0128] The following will be combined with the appendix Figure 6 - Appendix Figure 7 This specification provides a detailed description of the data transmission apparatus provided in the embodiments. It should be noted that the appendix... Figure 6 The data transmission device described herein is used to execute this specification. Figures 1-5 The methods shown in the embodiments are illustrated for ease of explanation, showing only the parts related to the embodiments of this specification. For specific technical details not disclosed, please refer to this specification. Figures 1-5 The example shown.

[0129] Please see Figure 6 This diagram illustrates a schematic representation of a data transmission apparatus provided in an exemplary embodiment of this specification. The data transmission apparatus can be implemented as all or part of a device through software, hardware, or a combination of both. The data transmission apparatus 1 includes an acquisition unit 11, an anomaly identification unit 12, a repair identification unit 13, a repair processing unit 14, and a transmission unit 15.

[0130] Acquisition unit 11 is used to acquire the target transmission data of the transaction party;

[0131] The anomaly identification unit 12 is used to determine whether there is abnormal data in the target transmitted data according to a preset semantic rule set;

[0132] The repair identification unit 13 is used to identify whether the abnormal data is repairable data according to the repair rules if abnormal data exists.

[0133] Repair processing unit 14 is used to repair the repairable data according to the preset repair action indicated in the repair rule if the data is repairable, so as to obtain the repaired transmission data.

[0134] The transmission unit 15 is used to transmit the repaired transmission data together with the qualified data in the target transmission data, excluding the abnormal data, to the receiver.

[0135] Optionally, the repair identification unit 13 is specifically used to determine whether the abnormal field in the abnormal data belongs to the field type that allows automatic repair;

[0136] If it belongs to a field type that allows automatic repair, then determine whether the abnormal field has a reliable source of supplementary data or supplementary derivation logic;

[0137] If a reliable source of supplementary data or supplementary derivation logic exists, then the abnormal data is determined to be repairable data.

[0138] Optionally, the repair processing unit 14 is specifically used to obtain the standard reference value corresponding to the abnormal field from the reliable data supplementation source if the repairable data has a reliable data supplementation source, and use the standard reference value as the value of the abnormal field to obtain the repaired transmission data;

[0139] If the repairable data has supplementary derivation logic, a set reference value is obtained based on the indication of the supplementary derivation logic, and a supplementary value is generated according to the supplementary derivation logic and the set reference value. The supplementary value is used as the value of the abnormal field to obtain the repaired transmission data.

[0140] Optionally, the repair processing unit 14 is further configured to record the repairable data, the repaired transmission data, the rule version of the repair rule, and the repair timestamp to the repair record table of the transaction party.

[0141] Optionally, the repair processing unit 14 is further configured to generate a first encrypted digest identifier corresponding to the repairable data;

[0142] Generate a second encrypted digest identifier corresponding to the repaired transmitted data;

[0143] Record the first encrypted digest identifier, the second encrypted digest identifier, the repairable data, the repaired transmission data, the rule version of the repair rule, and the repair timestamp to the repair record table of the transaction party.

[0144] Optional, please see Figure 7 This diagram illustrates a structural schematic of a data transmission apparatus provided in an exemplary embodiment of this specification. This data transmission apparatus can be implemented as all or part of a device through software, hardware, or a combination of both. The data transmission apparatus 2 also includes a rule generation unit 16, specifically used to receive transmission feedback results sent by the receiver;

[0145] Based on the transmission feedback results, samples of failed transmission data and samples of successful transmission data are collected to construct a dataset for comparative analysis.

[0146] For each field in the dataset, compare the value of the field in the failed transmission data sample with the value in the successful transmission data sample to identify the field with the difference in value in the failed transmission data sample;

[0147] The verification rules for the value difference field are generated based on the values ​​of the value difference field in the successful transmission data sample.

[0148] Optionally, the rule generation unit 16 is further configured to obtain the constraints of the value difference field based on the transaction metadata knowledge base of the transaction party; wherein the constraints include at least the standard encoding table of the field, the definition of mandatory fields, the data source identifier, and the dependency relationship between fields;

[0149] If the value of the value difference field does not meet the constraint condition, then a verification rule for the value difference field is generated based on the constraint condition.

[0150] Optionally, the repair processing unit 14 is specifically used to push the abnormal data to manual processing if it is not repairable data.

[0151] It should be noted that the data transmission device provided in the above embodiments is only illustrated by the division of the above functional modules when executing the data transmission method. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the data transmission device and the data transmission method embodiments provided in the above embodiments belong to the same concept, and the implementation process can be found in the method embodiments, which will not be repeated here.

[0152] It is understood that the data transmission device provided in the embodiments of this specification can be a terminal device such as a mobile phone, computer, tablet computer, smartwatch or vehicle device, or it can be a module in the terminal device used to implement the data transmission method and the training method of the data transmission model.

[0153] The embodiment numbers in this specification are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments. In some cases, the actions or steps described in the claims can be performed in a different order than that shown in the embodiments and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0154] This specification also provides a storage medium storing a computer program, which, when executed by a processor, implements the above-described functionality. Figures 1-5 The data transmission method described in the illustrated embodiment can be found in the following document for a detailed execution process: Figures 1-5 The specific details of the illustrated embodiments will not be elaborated here.

[0155] Please refer to Figure 8 This diagram illustrates the structure of an electronic device provided in an exemplary embodiment of this specification. The electronic device in this specification may include one or more components such as a processor 110, a memory 120, an input device 130, an output device 140, and a bus 150. The processor 110, memory 120, input device 130, and output device 140 may be connected via the bus 150.

[0156] Processor 110 may include one or more processing cores. Processor 110 connects to various parts of the electronic device using various interfaces and lines, and performs various functions and processes data of electronic device 100 by running or executing instructions, programs, code sets, or instruction sets stored in memory 120, and by calling data stored in memory 120. Optionally, processor 110 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). Processor 110 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user page, and applications; the GPU is responsible for rendering and drawing the displayed content; and the modem handles wireless communication. It is understood that the modem may also not be integrated into processor 110, but may be implemented separately using a communication chip.

[0157] The memory 120 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 120 may include non-transitory computer-readable storage medium. The memory 120 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 120 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for implementing at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the various method embodiments described above, etc. The operating system may be the Android system, including systems deeply developed based on the Android system, the iOS system developed by Apple Inc., including systems deeply developed based on the iOS system, or other systems.

[0158] The memory 120 can be divided into operating system space and user space. The operating system runs in the operating system space, while native and third-party applications run in user space. To ensure that different third-party applications can achieve good running performance, the operating system allocates corresponding system resources for each application. However, different application scenarios within the same third-party application have different requirements for system resources. For example, in local resource loading scenarios, third-party applications have high requirements for disk read speed; in animation rendering scenarios, third-party applications have high requirements for GPU performance. Since the operating system and third-party applications are independent of each other, the operating system often cannot promptly perceive the current application scenario of a third-party application, resulting in the operating system's inability to adapt system resources accordingly.

[0159] In order for the operating system to distinguish the specific application scenarios of third-party applications, it is necessary to establish data communication between the third-party applications and the operating system. This would allow the operating system to obtain the current scenario information of the third-party applications at any time, and then perform targeted system resource adaptation based on the current scenario.

[0160] The input device 130 is used to receive input instructions or data, and includes, but is not limited to, a keyboard, mouse, camera, microphone, or touch device. The output device 140 is used to output instructions or data, and includes, but is not limited to, a display device and a speaker. In one example, the input device 130 and the output device 140 can be combined, and the input device 130 and the output device 140 can be a touch display screen.

[0161] The touch display screen can be designed as a full-screen, curved screen, or irregularly shaped screen. It can also be designed as a combination of a full-screen and a curved screen, or a combination of an irregularly shaped screen and a curved screen; however, this specification does not limit the specific design of the embodiments.

[0162] In addition, those skilled in the art will understand that the structure of the electronic device shown in the above figures does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements. For example, the electronic device may also include radio frequency circuits, input units, sensors, audio circuits, WiFi modules, power supplies, Bluetooth modules, etc., which will not be described in detail here.

[0163] exist Figure 8 In the illustrated electronic device, the processor 110 can be used to call computer applications stored in the memory 120 and specifically perform the following operations:

[0164] Obtain the target data to be transmitted from the transaction party;

[0165] Determine whether there is abnormal data in the target transmitted data based on a preset semantic rule set;

[0166] If abnormal data exists, the abnormal data is identified as repairable data according to the repair rules.

[0167] If the data is repairable, the repairable data is repaired according to the preset repair actions indicated in the repair rules to obtain the repaired transmission data;

[0168] The repaired transmission data, along with the qualified data (excluding the abnormal data) in the target transmission data, is transmitted to the receiver.

[0169] In one embodiment, when the processor 110 performs the operation of identifying whether the abnormal data is repairable based on the repair rules, it specifically performs the following operations:

[0170] Determine whether the abnormal fields in the abnormal data belong to the field types that are allowed to be automatically repaired;

[0171] If it belongs to a field type that allows automatic repair, then determine whether the abnormal field has a reliable source of supplementary data or supplementary derivation logic;

[0172] If a reliable source of supplementary data or supplementary derivation logic exists, then the abnormal data is determined to be repairable data.

[0173] In one embodiment, when the processor 110 performs a preset repair action according to the repair rule to repair repairable data and obtain repaired transmission data, it specifically performs the following operations:

[0174] If there is a reliable data supplementation source for the repairable data, then the standard reference value corresponding to the abnormal field is obtained from the reliable data supplementation source, and the standard reference value is used as the value of the abnormal field to obtain the repaired transmission data.

[0175] If the repairable data has supplementary derivation logic, a set reference value is obtained based on the indication of the supplementary derivation logic, and a supplementary value is generated according to the supplementary derivation logic and the set reference value. The supplementary value is used as the value of the abnormal field to obtain the repaired transmission data.

[0176] In one embodiment, after the processor 110 performs the operation of repairing the repairable data according to the preset repair action indicated in the repair rule if the data is repairable, and obtains the repaired transmission data, it further performs the following operations:

[0177] Record the repairable data, the repaired transmission data, the rule version of the repair rule, and the repair timestamp to the repair record table of the transaction party.

[0178] In one embodiment, when the processor 110 records the repairable data, the repaired transmission data, the rule version of the repair rule, and the repair timestamp to the repair record table, it specifically performs the following operations:

[0179] Generate a first encrypted digest identifier corresponding to the repairable data;

[0180] Generate a second encrypted digest identifier corresponding to the repaired transmitted data;

[0181] Record the first encrypted digest identifier, the second encrypted digest identifier, the repairable data, the repaired transmission data, the rule version of the repair rule, and the repair timestamp to the repair record table of the transaction party.

[0182] In one embodiment, the processor 110 is further configured to perform the following operations:

[0183] Receive the transmission feedback result sent by the receiver;

[0184] Based on the transmission feedback results, samples of failed transmission data and samples of successful transmission data are collected to construct a dataset for comparative analysis.

[0185] For each field in the dataset, compare the value of the field in the failed transmission data sample with the value in the successful transmission data sample to identify the field with the difference in value in the failed transmission data sample;

[0186] The verification rules for the value difference field are generated based on the values ​​of the value difference field in the successful transmission data sample.

[0187] In one embodiment, after the processor 110 performs the following operations: for each field in the dataset, compares the value of the field in the failed transmission data sample with the value in the successful transmission data sample, and identifies the fields with different values ​​in the failed transmission data sample:

[0188] The constraints of the value difference field are obtained based on the transaction metadata knowledge base of the transaction party; wherein, the constraints include at least the standard encoding table of the field, the definition of mandatory fields, the data source identifier, and the dependency relationship between fields;

[0189] If the value of the value difference field does not meet the constraint condition, then a verification rule for the value difference field is generated based on the constraint condition.

[0190] In one embodiment, after the processor 110 performs the operation of identifying whether the abnormal data is repairable according to the repair rules if abnormal data exists, it also performs the following operations:

[0191] If the data is not repairable, the abnormal data will be pushed to manual processing.

[0192] In the embodiments of this specification, the target transmission data of the transaction party is obtained, and it is determined whether there is abnormal data in the target transmission data according to a preset semantic rule set. If abnormal data exists, it is identified whether the abnormal data is repairable according to the repair rules. If it is repairable, the repairable data is repaired according to the preset repair actions indicated in the repair rules to obtain repaired transmission data. The repaired transmission data is then transmitted to the receiver along with the qualified data in the target transmission data excluding the abnormal data. By automatically determining whether there is abnormal data in the data to be transmitted and identifying repairable data among the abnormal data, and repairing the repairable data according to the preset repair actions, manual intervention in abnormal data is reduced, data accuracy is improved, and data is transmitted only after repair processing, thereby improving the transmission success rate.

[0193] Furthermore, specific implementation methods for determining whether abnormal data is repairable and specific repair methods for repairable data are provided. This involves determining whether the abnormal field in the abnormal data belongs to a field type that allows automatic repair; if it does, it determines whether there is a reliable data supplementary source or supplementary derivation logic for the abnormal field; if such a source exists, the abnormal data is determined to be repairable. If a reliable data supplementary source exists, the standard reference value corresponding to the abnormal field is obtained from the source, and this standard reference value is used as the value of the abnormal field to obtain the repaired transmission data. If supplementary derivation logic exists, a set reference value is obtained based on the instruction of the supplementary derivation logic, and a supplementary value is generated according to the logic and the reference value. This supplementary value is used as the value of the abnormal field to obtain the repaired transmission data. Furthermore, a repair record scheme is provided, recording the repairable data, the repaired transmission data, the rule version of the repair rule, and the repair timestamp in the transaction's repair record table to ensure data modification traceability.

[0194] Furthermore, based on the actual transmission feedback results from the receiver, the verification rules are automatically extracted according to the compliance characteristics of the successfully transmitted data samples. The rules can be updated without manual intervention, adapting to the dynamic changes in the receiver's verification standards.

[0195] Additionally, embodiments of this specification provide a computer program product comprising a computer program that, when executed by a processor of an electronic device, enables the processor to at least perform the functions described above. Figures 1 to 5 The method provided in the illustrated embodiment.

[0196] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0197] The above-disclosed embodiments are merely preferred embodiments of this specification and should not be construed as limiting the scope of this specification. Therefore, any equivalent variations made in accordance with the claims of this specification shall still fall within the scope of this specification.

Claims

1. A data transmission method, characterized in that, The method includes: Obtain the target data to be transmitted from the transaction party; Determine whether there is abnormal data in the target transmitted data based on a preset semantic rule set; If abnormal data exists, the abnormal data is identified as repairable data according to the repair rules. If the data is repairable, the repairable data is repaired according to the preset repair actions indicated in the repair rules to obtain the repaired transmission data; The repaired transmission data, along with the qualified data in the target transmission data excluding the abnormal data, is transmitted to the receiver. The step of identifying whether the abnormal data is repairable based on the repair rules includes: Determine whether the abnormal fields in the abnormal data belong to the field types that are allowed to be automatically repaired; If it belongs to a field type that allows automatic repair, then determine whether the abnormal field has a reliable source of supplementary data or supplementary derivation logic; If there is a reliable source of supplementary data or supplementary derivation logic, then the abnormal data is determined to be repairable data; If the data is repairable, then the repairable data is repaired according to the preset repair actions indicated in the repair rules to obtain the repaired transmission data, including: If there is a reliable data supplementation source for the repairable data, then the standard reference value corresponding to the abnormal field is obtained from the reliable data supplementation source, and the standard reference value is used as the value of the abnormal field to obtain the repaired transmission data. If the repairable data has supplementary derivation logic, a set reference value is obtained based on the indication of the supplementary derivation logic, and a supplementary value is generated according to the supplementary derivation logic and the set reference value. The supplementary value is used as the value of the abnormal field to obtain the repaired transmission data.

2. The method as described in claim 1, characterized in that, If the data is repairable, then the repairable data is repaired according to the preset repair actions indicated in the repair rules. After obtaining the repaired transmission data, the process further includes: Record the repairable data, the repaired transmission data, the rule version of the repair rule, and the repair timestamp to the repair record table of the transaction party.

3. The method as described in claim 2, characterized in that, The process of recording the repairable data, the repaired transmission data, the rule version of the repair rule, and the repair timestamp into the repair record table includes: Generate a first encrypted digest identifier corresponding to the repairable data; Generate a second encrypted digest identifier corresponding to the repaired transmitted data; Record the first encrypted digest identifier, the second encrypted digest identifier, the repairable data, the repaired transmission data, the rule version of the repair rule, and the repair timestamp to the repair record table of the transaction party.

4. The method as described in claim 1, characterized in that, The method further includes: Receive the transmission feedback result sent by the receiver; Based on the transmission feedback results, samples of failed transmission data and samples of successful transmission data are collected to construct a dataset for comparative analysis. For each field in the dataset, compare the value of the field in the transmission failure data sample with the value in the transmission success data sample to identify the field with the difference in value in the transmission failure data sample; The verification rules for the value difference field are generated based on the values ​​of the value difference field in the successful transmission data sample.

5. The method as described in claim 4, characterized in that, After comparing the values ​​of each field in the failed transmission data sample with the values ​​in the successful transmission data sample for each field in the dataset, and identifying the fields with different values ​​in the failed transmission data sample, the method further includes: The constraints of the value difference field are obtained based on the transaction metadata knowledge base of the transaction party; wherein, the constraints include at least the standard encoding table of the field, the definition of mandatory fields, the data source identifier, and the dependency relationship between fields; If the value of the value difference field does not meet the constraint condition, then a verification rule for the value difference field is generated based on the constraint condition.

6. The method as described in claim 1, characterized in that, If abnormal data exists, after identifying whether the abnormal data is repairable according to the repair rules, the method further includes: If the data is not repairable, the abnormal data will be pushed to manual processing.

7. A data transmission device, characterized in that, The device includes: The acquisition unit is used to acquire the target transmission data of the transaction party. An anomaly detection unit is used to determine whether there is abnormal data in the target transmitted data according to a preset semantic rule set; The repair identification unit is used to identify whether abnormal data is repairable according to repair rules if abnormal data exists. The identification of whether abnormal data is repairable according to repair rules includes: determining whether the abnormal field in the abnormal data belongs to a field type that allows automatic repair; if it belongs to a field type that allows automatic repair, determining whether the abnormal field has a reliable source of supplementary data or supplementary derivation logic; if a reliable source of supplementary data or supplementary derivation logic exists, determining that the abnormal data is repairable. The repair processing unit is configured to, if the data is repairable, repair the repairable data according to the preset repair actions indicated in the repair rules to obtain repaired transmission data; the repair of the repairable data according to the preset repair actions indicated in the repair rules to obtain repaired transmission data includes: if the repairable data has a reliable data supplementation source, obtaining a standard reference value corresponding to the abnormal field from the reliable data supplementation source, using the standard reference value as the value of the abnormal field to obtain repaired transmission data; if the repairable data has supplementary derivation logic, obtaining a set reference value based on the indication of the supplementary derivation logic, generating a supplementary value according to the supplementary derivation logic and the set reference value, using the supplementary value as the value of the abnormal field to obtain repaired transmission data; A transmission unit is used to transmit the repaired transmission data together with the qualified data in the target transmission data, excluding the abnormal data, to the receiver.

8. An electronic device, characterized in that, include: Processor and memory; The memory stores a computer program adapted to be loaded by the processor and to execute the steps of the method as described in any one of claims 1 to 6.

9. A storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, implements the steps of the method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, include: A computer program, when executed by a processor of an electronic device, causes the processor to perform the steps of the method as described in any one of claims 1 to 6.

Images