Cross-system resource transfer adaptation method, device, equipment, medium and product

Abstract

The invention relates to the field of big data processing, and particularly discloses a cross-system resource transfer adaptation method and device, computer equipment, a computer readable storage medium and a computer program product. The method comprises the following steps: in response to a resource transfer request, obtaining a request end identifier and request content information, and obtaining a plurality of request fields in an arrangement sequence; obtaining a request message template according to the request end identifier, performing data verification on each request field in sequence according to an arrangement sequence to obtain a context data set, generating message fragments corresponding to the request fields, and merging the message fragments to obtain an initial request message; and when the integrity check performed according to the target end message template does not pass, inputting the initial request message into an information repair model to obtain a target request message, and sending the target request message to the target end. By adopting the method, the dynamic expansibility of cross-system resource transfer can be improved when various resource transfer scenes, different system versions or dynamic service strategies are adjusted.

Description

Technical Field

[0001] This application relates to the field of big data processing technology, and in particular to a method, apparatus, computer equipment, computer-readable storage medium, and computer program product for cross-system resource transfer and adaptation. Background Technology

[0002] In traditional distributed system architectures, cross-system resource transfer operations are frequently required between different systems. For example, in microservice architectures, heterogeneous business platforms, fintech systems, bill processing platforms, and enterprise resource management platforms, there are resource transfer instructions initiated by the requesting system to the target system. These resource transfer operations are essentially a process where one system drives another to complete a state change, typically requiring unified process coordination, data structure transformation, and execution consistency guarantees across multiple subsystems.

[0003] However, most related technologies employ static process configuration and hard-coded logic, lacking flexible process template parsing capabilities. When faced with various resource transfer scenarios, different system versions, or dynamic business strategy adjustments, existing processes cannot be quickly adapted or reused, resulting in complex system maintenance and poor scalability. Summary of the Invention

[0004] Based on this, it is necessary to provide a cross-system resource transfer adaptation method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can improve the dynamic scalability of cross-system resource transfer in various resource transfer scenarios, different system versions, or dynamic business strategy adjustments, in order to address the above-mentioned technical problems.

[0005] Firstly, this application provides a cross-system resource transfer adaptation method, including:

[0006] In response to a resource transfer request, the requester identifier and request content information are obtained; wherein, the request content information includes multiple request fields that are arranged in an ordered manner;

[0007] The request message template is obtained based on the requester identifier, and the request message template and the request content information are used to perform data validation on each request field in the order of arrangement to obtain the context dataset.

[0008] Based on the context dataset, message fragments corresponding to each of the request fields are generated, and the message fragments are merged to obtain an initial request message;

[0009] Obtain the target message template based on the request content information, and perform an integrity check on the initial request message based on the target message template.

[0010] If the integrity check fails, the initial request message is input into a pre-trained information repair model to obtain a target request message, and the target request message is sent to the target end; wherein, the information repair model is trained based on historical target request messages and target end message templates.

[0011] In one embodiment, the step of performing data validation on each of the request fields sequentially according to the order of the request message template and the request content information to obtain a context dataset includes:

[0012] Following the stated order, each of the requested fields is used as the current field, and the following steps are performed:

[0013] Find at least one validation rule in the request message template that matches the current field;

[0014] According to the verification rules, the current context dataset is verified, and the current context dataset is updated based on the verification results.

[0015] In one embodiment, the step of performing data validation on the current context dataset according to each of the validation rules, and updating the current context dataset according to the results of the data validation, includes:

[0016] If the verification rule is a data-disabled verification rule, the current field is searched in the disabled list according to the data-disabled verification rule;

[0017] If the current field exists in the disabled list, the data associated with the current field in the context dataset is deleted according to the data disabling verification rules, so as to update the current context dataset.

[0018] In one embodiment, the step of performing data validation on the current context dataset according to each of the validation rules, and updating the current context dataset according to the results of the data validation, includes:

[0019] If the validation rule is a parameter dependency validation rule, the dependent field value associated with the current field is searched in the current context dataset according to the parameter dependency validation rule.

[0020] If the dependency field value is missing in the current context dataset, the value of each request field in the request content information is searched to obtain the dependency field value.

[0021] Update the current context dataset based on the value of the dependency field.

[0022] In one embodiment, before sending the target request message to the target end, the method further includes:

[0023] Based on the target message template, extract the sensitive fields from the target request message;

[0024] Each of the aforementioned sensitive fields is encrypted in order to update the target request message.

[0025] In one embodiment, encrypting each of the sensitive fields to update the target request message includes:

[0026] Calculate the hash value based on the values ​​of each of the aforementioned sensitive fields;

[0027] The sensitive fields are encrypted based on the hash value to update the target request message.

[0028] Secondly, this application also provides a cross-system resource transfer adaptation device, comprising:

[0029] The information acquisition module is used to acquire the requester identifier and request content information in response to a resource transfer request; wherein, the request content information includes multiple request fields that are arranged in an ordered manner;

[0030] The data processing module is used to obtain a request message template based on the requester identifier, and to perform data validation on each request field in the order of the request message template and the request content information to obtain a context dataset.

[0031] The message generation module is used to generate message fragments corresponding to each of the request fields based on the context dataset, and to merge the message fragments to obtain an initial request message;

[0032] The message verification module is used to obtain the target message template based on the request content information, and to perform integrity verification on the initial request message based on the target message template.

[0033] The message sending module is used to input the initial request message into a pre-trained information repair model to obtain a target request message when the integrity check fails, and then send the target request message to the target end; wherein, the information repair model is trained based on historical target request messages and target end message templates.

[0034] In one embodiment, the data processing module is specifically used to: sequentially take each of the request fields as the current field according to the arrangement order, and perform the following steps: find at least one verification rule in the request message template that matches the current field; perform data verification on the current context dataset according to each of the verification rules, and update the current context dataset according to the result of the data verification.

[0035] In one embodiment, the data processing module is specifically configured to: when the verification rule is a data disabling verification rule, search for the current field in the disabled list according to the data disabling verification rule; when the current field exists in the disabled list, delete the data associated with the current field in the context dataset according to the data disabling verification rule, so as to update the current context dataset.

[0036] In one embodiment, the data processing module is further configured to: when the validation rule is a parameter dependency validation rule, search for the dependency field value associated with the current field in the current context dataset according to the parameter dependency validation rule; when the dependency field value is missing in the current context dataset, search for the value of each request field in the request content information to obtain the dependency field value; and update the current context dataset according to the dependency field value.

[0037] In one embodiment, the apparatus further includes a data encryption module, configured to extract sensitive fields from the target request message based on the target message template; and to encrypt each of the sensitive fields to update the target request message.

[0038] In one embodiment, the data encryption module is specifically used to: calculate a hash value based on the value of each of the sensitive fields; and encrypt each of the sensitive fields based on the hash value to update the target request message.

[0039] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0040] In response to a resource transfer request, the requester identifier and request content information are obtained; wherein, the request content information includes multiple request fields that are arranged in an ordered manner;

[0041] The request message template is obtained based on the requester identifier, and the request message template and the request content information are used to perform data validation on each request field in the order of arrangement to obtain the context dataset.

[0042] Based on the context dataset, message fragments corresponding to each of the request fields are generated, and the message fragments are merged to obtain an initial request message;

[0043] Obtain the target message template based on the request content information, and perform an integrity check on the initial request message based on the target message template.

[0044] If the integrity check fails, the initial request message is input into a pre-trained information repair model to obtain a target request message, and the target request message is sent to the target end; wherein, the information repair model is trained based on historical target request messages and target end message templates.

[0045] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0046] In response to a resource transfer request, the requester identifier and request content information are obtained; wherein, the request content information includes multiple request fields that are arranged in an ordered manner;

[0047] The request message template is obtained based on the requester identifier, and the request message template and the request content information are used to perform data validation on each request field in the order of arrangement to obtain the context dataset.

[0048] Based on the context dataset, message fragments corresponding to each of the request fields are generated, and the message fragments are merged to obtain an initial request message;

[0049] Obtain the target message template based on the request content information, and perform an integrity check on the initial request message based on the target message template.

[0050] If the integrity check fails, the initial request message is input into a pre-trained information repair model to obtain a target request message, and the target request message is sent to the target end; wherein, the information repair model is trained based on historical target request messages and target end message templates.

[0051] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:

[0052] In response to a resource transfer request, the requester identifier and request content information are obtained; wherein, the request content information includes multiple request fields that are arranged in an ordered manner;

[0053] The request message template is obtained based on the requester identifier, and the request message template and the request content information are used to perform data validation on each request field in the order of arrangement to obtain the context dataset.

[0054] Based on the context dataset, message fragments corresponding to each of the request fields are generated, and the message fragments are merged to obtain an initial request message;

[0055] Obtain the target message template based on the request content information, and perform an integrity check on the initial request message based on the target message template.

[0056] If the integrity check fails, the initial request message is input into a pre-trained information repair model to obtain a target request message, and the target request message is sent to the target end; wherein, the information repair model is trained based on historical target request messages and target end message templates.

[0057] The aforementioned cross-system resource transfer adaptation method, apparatus, computer equipment, computer-readable storage medium, and computer program product, in response to a resource transfer request, actively parse and extract the requester identifier and request content information, obtaining multiple request fields with an ordered sequence. This enables the system to clearly identify and control the flow of multiple request sources during the initialization phase of the processing flow, no longer relying on a fixed process template to handle a single business source. Instead, it can dynamically adapt to resource transfer requests initiated by different systems or business entities. By obtaining the request message template based on the requester identifier, and performing data verification on each request field in the ordered sequence based on the request message template and request content information, a context dataset is obtained. This sequential processing and context-driven approach enhances the flexibility of field parsing and message generation, and also enables dynamic adaptation based on semantic constraints between fields. This solves the problems of strong field content dependencies and high coupling between upstream and downstream data in complex resource transfers. Finally, based on the context dataset, the corresponding fields for each request field are generated. The system processes message fragments and merges them to obtain an initial request message. It can quickly support the combination of multiple message structures, the replacement of different field sequences, and the expansion of field hierarchy structures. It is more suitable for scenarios where multiple business versions and industry standard messages are operated collaboratively. The system obtains the target message template based on the request content information and performs integrity checks on the initial request message based on the target message template. If the integrity check fails, the initial request message is input into an information repair model pre-trained based on historical target request messages and target message templates to obtain the target request message. It can dynamically perform integrity checks according to the requirements of the target end and achieves automatic repair and reconstruction capabilities when the integrity check fails, avoiding information transmission failures caused by system incompatibility. Finally, the target request message is sent to the target end. This makes the above method widely adaptable to various resource transfer scenarios and system version evolution needs, and improves the dynamic scalability of cross-system resource transfer when various resource transfer scenarios, different system versions, or dynamic business strategy adjustments are implemented. Attached Figure Description

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

[0059] Figure 1 This is an application environment diagram of a cross-system resource transfer adaptation method in one embodiment;

[0060] Figure 2 This is a flowchart illustrating a cross-system resource transfer and adaptation method in one embodiment;

[0061] Figure 3 This is a flowchart illustrating step S204 in one embodiment;

[0062] Figure 4 This is a structural block diagram of a cross-system resource transfer adaptation device in one embodiment;

[0063] Figure 5 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0064] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. It should be noted that existing industry solutions such as software, components, and models may be mentioned in the embodiments of this application. These should be considered exemplary and are intended only to illustrate the feasibility of implementing the technical solutions of this application, but do not imply that the applicant has already used or necessarily used such solutions.

[0065] 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 stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with relevant regulations. The acquisition, storage, use and processing of data in the technical solution of this application all comply with the relevant provisions of national laws and regulations.

[0066] The cross-system resource transfer and adaptation method provided in this application can be applied to systems such as... Figure 1In the application environment shown, terminal 102 communicates with server 104 via a network. Terminal 102 can receive resource transfer requests, receive the requester's identifier and request content information, and send the received information to server 104. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated on server 104 or placed on the cloud or other network servers. The data storage system can be used to store various request message templates, target message templates, and context datasets generated during data processing. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, projection devices, etc. Portable wearable devices can include smartwatches, smart bracelets, head-mounted devices, etc. Head-mounted devices can be virtual reality (VR) devices, augmented reality (AR) devices, smart glasses, etc. Server 104 can be a standalone physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server that provides cloud computing services.

[0067] In one exemplary embodiment, such as Figure 2 As shown, a cross-system resource transfer and adaptation method is provided, which can be applied to... Figure 1 Taking server 104 as an example, in this embodiment, server 104 is configured to handle cross-system resource transfer operations. This operation is initiated by an external system (i.e., the requesting end) and requires the transfer of a set of structured resource instructions to another system (i.e., the target end) through a unified flow control and message generation mechanism. The method includes the following steps S202 to S210. Wherein:

[0068] Step S202: In response to the resource transfer request, obtain the requester's identifier and request content information.

[0069] The request originator identifier refers to the unique technical identification information of the system from which the resource transfer request originates. It can exist in the form of a system number, interface identifier, or unified code, and is used to distinguish different request sources. For example, a request from system A may carry "SYS-A-001" as its request originator identifier. This identifier can be used not only for template selection, but also for permission verification, data adaptation, and process routing.

[0070] The request content information includes multiple request fields arranged in a specific order. It is a set of structured parameters submitted by the requesting client. These parameters can be physically represented as key-value pairs and logically constitute a complete resource operation intent. This information can consist of multiple request fields, each representing a resource description or parameter setting, such as resource type, operation scope, execution conditions, target identifier, and policy constraints. It is important to note that the request fields can be arranged in a specific order according to business logic or protocol standards. This order cannot be arbitrarily changed and determines the parsing dependencies and execution sequence between fields. For example, the first field might be "Operation Type" set to "Write," the second field might be "Resource Path" set to " / cluster1 / node2," and the third field might be "Data Content."

[0071] For example, upon receiving the entry data of a resource transfer request, server 104 can parse the network packet or interface call content, extract the requester identifier carried in the request, and map it to the locally configured system registry to find and confirm the identity of the requester, the supported template version, and its adaptation rules. Subsequently, server 104 can further parse the content information in the request body, extract all request fields, identify their order, and organize them into an internal structured dataset in the form of a linked list or array. In this process, server 104 can not only preserve the original field order but also preprocess the fields, such as field name standardization (unified naming), preliminary decoding of field values ​​(e.g., escape and restoration), and pre-parsing of field dependency structures (for subsequent process driving), ensuring that each request field can be correctly called and processed in subsequent processes. For example, when a request content is: "Field 1: Operation type = Write", "Field 2: Resource ID = RG-104", "Field 3: Timestamp = 1693452300", server 104 can process them one by one in this order and generate a preliminary field mapping relationship in the internal context structure. Among them, "Operation Type" is the first field, which determines the resource processing branch to be called subsequently; "Resource ID" is used to determine the address or path of the transfer target; and "Timestamp" is used to compare the process snapshot record with the message version.

[0072] Furthermore, when performing cross-platform resource transfer tasks, server 104 can adopt differentiated processing strategies based on different types of platform environments, system structures, and data specifications to ensure high adaptability, high security, and high consistency of the overall process. This enables the above methods to adapt to changing needs and makes the resource transfer process both efficient and secure.

[0073] At the first level, server 104 can identify the platform type of the resource transfer task based on the platform identification information of the requesting and target ends. Platform types can include local subsystems, heterogeneous modules within the same group, heterogeneous platforms across groups, and third-party system access platforms. Each type of platform differs significantly in data format, protocol specifications, encryption standards, and process interfaces. Therefore, server 104 can select differentiated process templates, field mapping tables, encryption strategies, and verification strength methods based on these identification results.

[0074] For example, if both the requesting and target ends are local subsystems, server 104 can mark the platform as a resource transfer site on the same platform. In this case, only lightweight field consistency checks and quick structure verification are needed. In such scenarios, due to the existence of trust links and data format consistency foundations between the systems, server 104 can skip deep dependency completion and strict message repair models, reducing system resource consumption and response time.

[0075] However, if the target platform is a heterogeneous platform across different groups, server 104 can initiate a full set of high-strength verification and protection measures, including but not limited to full field dependency verification of request fields, bidirectional template comparison, full encryption of sensitive fields, and context integrity scanning. It also forces the activation of information repair models and redundant data injection to ensure complete compatibility of the target platform in terms of data structure and semantic interpretation. This differentiated approach can significantly improve data robustness and error tolerance in high-risk platform migration scenarios.

[0076] At the second level, server 104 can further refine the sensitivity levels of fields, with different levels of fields exhibiting differences in data processing methods, verification logic, and encryption algorithm selection. Fields can be categorized into three types: ordinary fields, important fields, and core sensitive fields. For example, "Task ID" can be classified as an ordinary field, only participating in structural alignment; "Access Level" can be marked as an important field, requiring dependency judgment and masquerading processing; while fields such as "Resource Key" and "Schedule Token" belong to core sensitive fields, requiring hash-driven encryption processing and recording complete encrypted metadata.

[0077] In addition, server 104 can also be configured at the policy level for the target platform. That is, the platform administrator can define which fields need to be forcibly encrypted, which fields are allowed to be partially de-identified, and which fields must be semantically filled when the verification fails through configuration files or policy services. This method provides flexibility for the minimum communicable structure between platforms, so that message generation is no longer limited to a single template.

[0078] Step S204: Obtain the request message template based on the requester identifier, and perform data validation on each request field in the order of the request message template and request content information to obtain the context dataset.

[0079] The request message template refers to a pre-configured message format model for different requesting systems. It defines field structures, field names, type constraints, validation rules, default value strategies, and logical relationships between fields. In some embodiments, each template corresponds one-to-one with the requesting system identifier to ensure adaptability to the field specifications and data expression habits of different systems. For example, if the requesting system identifier is "SYS-A-001", server 104 can retrieve its associated request message template version as "TEMPLATE-V3". This template specifies that: "Field 1 is the operation type, which must be a string and not empty; Field 2 is the resource ID (Identifier), which must be a 32-bit encoded string starting with RG-; Field 3 is the timestamp, which must be an integer and its value must not be earlier than the current time minus 60 seconds," etc. Based on these template rules, server 104 can perform field-level data validation operations by corresponding to each field in the request content information.

[0080] For example, after completing the basic parsing of the resource transfer request, server 104 can perform template retrieval in the locally configured template management module based on the previously extracted requester identifier. Then, server 104 can verify each field in the original order of the request. First, it reads the first field, "Operation Type," and determines whether its data type matches the template rules (e.g., it must be a string), and then checks whether its value is valid, such as allowing only write, query, and release enumerated values. If the field verification passes, the field value can be written to the context dataset in a standard format; if the field is missing or incorrectly formatted, server 104 can call a preset exception completion method, such as attempting to extract the default value from the default value table, or recording the field as pending completion for subsequent processing. Then, server 104 can continue reading the second field, "Resource ID," verifying its format by checking if it starts with "RG-" and its total length conforms to the specifications, and further calling the resource identifier registration module in the system for existence verification to ensure that the ID does indeed exist in the resource pool or management directory. Similarly, after successful field validation, server 104 can write the standardized resource ID into the context dataset as the resource anchor for the process execution. Subsequently, server 104 can read the third field, "timestamp." This field not only needs to meet the integer format requirement but can also perform upper and lower limit reasonableness checks. For example, if the current system time is 's', server 104 can verify that the timestamp is not earlier than 's' minus 60 seconds to ensure the real-time nature and traceability of the request. If the field value is empty or invalid, server 104 can extract a default time from the system reception time of the interface request message or directly mark the field status as "abnormal and pending confirmation."

[0081] After each field validation is completed, server 104 can record its validation result and processing status in the context dataset. This context dataset not only retains the field name and value, but also includes metadata such as the field processing status (e.g., "Validation passed", "Default completion", "Value abnormal"), the source record (e.g., "User submitted", "System inference"), and semantic annotations (e.g., "Primary key field", "Time-limited field").

[0082] The entire field validation process described above can be fully template-driven, supporting hot updates of field rules and the coexistence of multiple versions. It also allows for field expansion and compatibility degradation through configuration. Through these steps, server 104 can transform unstructured or semi-structured request information into a structured, semantically clear, and state-defined context dataset. More importantly, this template-driven field processing approach provides versatility and high scalability for resource transfer tasks supporting multiple request ends, multiple language messages, and multiple system versions.

[0083] Step S206: Based on the context dataset, generate message fragments corresponding to each request field, and merge the message fragments to obtain the initial request message.

[0084] For example, after completing the construction of the context dataset, server 104 can generate structured message fragments that can be recognized by the target system based on the information of each verified field in the context, and merge these fragments in a predetermined order and format to finally form a complete initial request message.

[0085] In this context, a message fragment refers to a unit of message content generated for each request field through specific formatting rules, field mapping logic, and nested structure definitions. Each fragment can correspond to the semantic region of a field or a group of fields, and its structure may be an XML (eXtensible Markup Language) tag block, a JSON (JavaScript Object Notation) sub-object, a fixed-length string field group, or a serialization structure conforming to the target protocol.

[0086] Before generating the message fragment, server 104 can load the request message template corresponding to the requesting client. In addition to defining the field validation rules, the template can also specify in detail how each field is represented in the message. For example, for the field "operation type", the template may specify that it is mapped to the JSON field "operation Type"; for the field "resource ID", it may specify that it needs to be converted to a hexadecimal string and encapsulated in a substructure named "target Resource"; for the field "timestamp", it can be converted to UTC (Coordinated Universal Time) format and labeled "timestamp".

[0087] Based on the template information above, server 104 can process each field in the context dataset one by one. Taking the field "Operation Type" as an example, server 104 can standardize its original value "write" to lowercase "write" and encapsulate it into a fragment: {"operationType": "write"}. For the field "Resource ID", if the value in the context is "RG-104", server 104 can first call the built-in encoding function to convert it to the hexadecimal string "52472d313034", and then concatenate it into a structured fragment: {"targetResource": {"id": "52472d313034"}}. For the field "Timestamp", if the context value is 1693452300, server 104 can format it as "2025-08-07T10:45:00Z" and generate a fragment: {"timestamp": "2025-08-07T10:45:00Z"}.

[0088] During the fragment generation process, server 104 can not only format values, but also inject fixed fields, calculate derived fields, or add field source identifiers to the fragment according to template rules. For example, for certain sensitive fields, such as "execution priority", server 104 can add a source tag: "automatically generated by default rules", which is used for subsequent auditing mechanisms of the target system to identify the source.

[0089] Once all fields have generated message fragments, server 104 can perform structure concatenation and order rearrangement. Server 104 can arrange all fragments sequentially according to the predefined field arrangement rules in the request message template; simultaneously, based on the message structure hierarchy (such as root node, substructures, arrays, etc.), it embeds each fragment into a unified message container. During this process, server 104 can also append common fields (such as system serial number, request ID, client information) and perform message integrity preprocessing, such as structure closure checks, field conflict detection, and multi-field merging strategies, to ensure that the generated initial request message conforms to the minimum transmittable specification.

[0090] Through the above steps, server 104 can convert field-oriented data structures into structured messages that can be directly sent externally, while preserving field semantics, source, and structural nesting information. This context-driven fragment generation and merging method not only ensures the structural correctness of the messages but also significantly improves the flexibility and adaptability in multi-field combinations, multi-template rules, and multi-language environments. This provides a highly modular, structurally clear, and semantically consistent communication message construction path for cross-system resource transfer.

[0091] Step S208: Obtain the target message template based on the request content information, and perform an integrity check on the initial request message based on the target message template.

[0092] The target message template can be a set of structured template rules pre-configured and maintained by server 104. This set describes the target system's complete requirements for external message format, field structure, naming conventions, data types, nesting levels, and logical constraints between fields. Each target system may have its own unique message structure requirements. Therefore, server 104 can accurately locate the required matching target template version through fields such as the target system identifier, target resource path, or resource type carried in the request content information. For example, if the request content contains the field "Target Type" as "Centralized Scheduling Node," server 104 can infer that the target is a "Scheduling Subsystem" and further confirm the message template it uses. This template can specify the following rules: the message must contain three fields: "Action Type," "Target Resource Number," and "Scheduling Policy Parameters"; field naming must use camelCase; the field order must be fixed; and some fields must be forcibly signed with their source. These rules can all be stored in server 104's target template library for use in the verification process.

[0093] For example, server 104 can use the initial request message generated in the above steps as input and perform structural integrity checks item by item against the target message template. The checks cover multiple dimensions, including field matching, order alignment, format consistency, value type constraints, nested structure verification, and dependency logic verification. For instance, for field matching checks, server 104 can check whether the initial message fully contains the key fields expected by the target system, such as whether fields like "operation type," "target resource," and "dispatch policy" exist. If any key field is missing, server 104 can record that field as "missing." For order verification, server 104 can compare the order of the message fields with the template requirements to determine whether it strictly follows the order defined by the target interface, avoiding parsing failures due to field misalignment.

[0094] Furthermore, regarding format consistency, server 104 can perform consistency checks on the naming style (e.g., upper camelCase, lowercase underscore, etc.), data type (e.g., integer, boolean, string), and value format (e.g., time format, resource ID encoding rules) of each field. For example, it can check whether the time field has been converted to UTC format, or whether the resource number is a 16-digit fixed-length string. For nested structures, server 104 can check whether the substructure is correctly nested under the target field, such as whether "target Resource" contains fields such as "id" and "type", and ensure that the nesting level has not changed or been lost.

[0095] Furthermore, server 104 can also perform dependency verification based on the logical constraints in the target template. For example, if the template specifies that "when the operation type is write, the dispatch policy field must exist", and the current message lacks this field, then the message will be marked as "dependency verification failed".

[0096] The results of each of the above checks can be recorded in a detailed verification log structure by server 104. This log includes the field name being checked, whether it passed or failed, the reason for failure, the corresponding template location, and potential remediation suggestions. This log can serve as input for subsequent remediation mechanisms, as well as for process alerts, interface tracing, and manual confirmation.

[0097] Through this integrity verification process, server 104 can fully verify the compatibility of initial request messages before they are sent, thereby minimizing cross-system communication failures caused by structural inconsistencies, missing fields, or semantic deviations. More importantly, this verification mechanism is automatically executed based on the target-side template, possessing high automation, flexible configuration, and version compatibility capabilities. It can effectively support resource transfer needs in scenarios involving multiple target systems, multiple business strategies, and rapid system iteration, ensuring that messages are complete and compliant before entering the target system, thus guaranteeing stable collaboration between systems from the source.

[0098] In step S210, if the integrity check fails, the initial request message is input into the pre-trained information repair model to obtain the target request message, and the target request message is sent to the target end.

[0099] The information repair model is trained based on historical target request messages and target message templates. This model is a structured intelligent prediction model pre-trained by server 104 using machine learning based on historical target request message samples and target message template rules. Instead of relying on fixed rule matching or template replacement, this model understands the contextual semantics, structural logic, and template requirements between message fragments, enabling adaptive repair, field inference, and format reconstruction of the message structure.

[0100] For example, server 104 can use the "verification failure items" recorded during the aforementioned verification process as one of the inputs to the repair task, and combine them with the original content of the initial request message, inputting them into the information repair model. The information repair model can generate a new, structurally compliant target request message based on its internally learned historical repair patterns, field dependencies, and target format rules in the template. For example, if the initial message is missing the "dispatchPolicy" field, and the model recognizes that this field often appears as "standard" as the default value in requests with "operationType" as "write", the model can automatically infer the field and complete it: "dispatchPolicy": "standard". For example, if a field in the message is formatted incorrectly (such as a timestamp that is not in UTC format), the model can rewrite it into a compliant format according to the template rules, such as converting "2025 / 08 / 07 10:45" to "2025-08-07T10:45:00Z"; or, if the order of some fields does not conform to the template definition, the model can rearrange the entire field structure to meet the field arrangement specifications expected by the target end.

[0101] In addition, while generating a new message using the repair model, server 104 can also simultaneously obtain a repair description report, which marks which fields have been modified, supplemented, or rearranged, indicates the reason for each repair and the reference template rules, and provides a credibility score for the repair action. This description information can be written as a log to the system backend for subsequent operation and maintenance audits, backtracking, or manual confirmation.

[0102] After the repair is completed, server 104 can re-execute the integrity check of the target request message to ensure that the repair result fully meets all the structural and semantic requirements of the target message template. Only when all checks pass will server 104 officially send the finally generated target request message to the target system through a preset system interface, message queue, or communication channel, triggering the resource transfer execution process.

[0103] By introducing an information repair model, Server 104 can achieve highly automated and intelligent message adaptation capabilities when facing problems such as dynamically changing target system template versions, inconsistent cross-system communication specifications, differences in field formats, or frequent interface upgrades. This not only significantly improves the system's fault tolerance to abnormal inputs but also ensures the continuity and stability of cross-system resource transfers, avoiding problems such as manual retries, message dropping, or service interruptions in traditional systems when fields are incompatible, thus achieving intelligent collaboration between complex systems.

[0104] Furthermore, to ensure data security and compliance of the target system's reception during cross-system resource transfer, before sending the target request message to the target end, server 104 can extract sensitive fields from the target request message based on the target end message template; and encrypt each sensitive field to update the target request message. For example, server 104 can parse the set of fields marked as sensitive fields in the loaded target end message template.

[0105] Sensitive fields refer to data items that are explicitly marked as requiring protection in the template definition. These fields can include, but are not limited to, resource IDs, policy parameters, system credentials, key identifiers, and scheduling tokens. For example, fields such as "resource Token," "transfer AuthKey," or "secure routing path" can all belong to the sensitive field set. These markers can be implemented using dedicated attribute tags such as "is Encrypted": true or in field declarations within data sections.

[0106] Next, server 104 can extract the values ​​of these sensitive fields sequentially from the target request message. To adapt to the encryption requirements and algorithm differences of various target systems, server 104 can maintain an internal field encryption policy mapping table. This table specifies the specific encryption algorithm, encryption parameters (such as key and padding method), and encryption format (such as Base64 output, binary output, or hexadecimal string) based on the target identifier and field name. Server 104 can then perform corresponding encryption algorithm processing on each sensitive field value based on this mapping table. For example, for the original value "RSC-ABC-202508" of the "resource Token" field, server 104 can load the corresponding AES (Advanced Encryption Standard) key and initialization vector according to the configuration, perform symmetric encryption to obtain ciphertext, and encapsulate it in Base64 format. Subsequently, server 104 can write this ciphertext value back to the original field position in the target request message, replacing the plaintext field value. Meanwhile, to prevent structural shifts caused by changes in field length, server 104 can also re-execute the message structure verification to ensure that the overall field length, boundaries, and format of the message still conform to the definition of the target template.

[0107] In addition to encrypting field values, server 104 can also add an "encryption processing flag" and "encryption digest information" to the context dataset of the target request message. The encryption flag can be used to identify which fields in the current message have been encrypted and the encryption algorithm used; the encryption digest information can be used to record the original field name before encryption, encryption timestamp, encryption algorithm ID and key identifier, as a transmission log or audit basis, supporting subsequent decryption verification at the target end or relay node.

[0108] It is worth noting that if the target message template also requires desensitization or structural spoofing of certain fields, such as replacing plaintext with hash values ​​or covering part of the field content with a mask, server 104 can also perform these operations at this stage. These operations can all be driven by the field processing strategy in the target template, ensuring that server 104 completes all necessary compliant encryption processing in the final stage of message generation.

[0109] Through the aforementioned encryption process, server 104 can significantly improve the security, tamper resistance, and data compliance of messages during cross-system transmission while ensuring message structure consistency. This is particularly effective in complex transfer tasks involving sensitive resource configuration policies, system identity credentials, or multi-level scheduling tokens, effectively blocking potential security risks.

[0110] For example, server 104 can calculate hash values ​​based on the values ​​of each sensitive field; and encrypt each sensitive field according to the hash values ​​to update the target request message. Through hash-based encryption, server 104 can achieve dual protection for sensitive fields: on the one hand, by providing field-level desensitization capabilities through irreversible hash operations, it can prevent the leakage of original sensitive content; on the other hand, by encrypting the hash values, it ensures structural protection and content traceability during data transmission. Furthermore, this method has extremely high scalability, allowing dynamic changes to the hash algorithm and encryption method based on the configuration of different target systems, ensuring the security, legitimacy, and compatibility of cross-system resource transfer messages.

[0111] In the aforementioned cross-system resource transfer adaptation method, in response to a resource transfer request, the system actively parses and extracts the requester identifier and request content information, obtaining multiple request fields with an ordered sequence. This enables the system to clearly identify and control the flow of multiple request sources during the initialization phase of the processing flow. It no longer relies on a fixed process template to handle a single business source, but can dynamically adapt to resource transfer requests initiated by different systems or business entities. By obtaining the request message template based on the requester identifier, and then performing data verification on each request field sequentially according to the request message template and request content information, a context dataset is obtained. This sequential and context-driven approach enhances the flexibility of field parsing and message generation, and also enables dynamic adaptation based on semantic constraints between fields. This solves the problems of strong field content dependencies and high coupling between upstream and downstream data in complex resource transfers. Finally, based on the context dataset, message fragments corresponding to each request field are generated, and each message fragment is processed... The process merges rows to obtain the initial request message, which can quickly support the combination of multiple message structures, the replacement of different field sequences, and the expansion of field hierarchy structures. It is more suitable for scenarios where multiple business versions and industry standard messages are operated collaboratively. The target message template is obtained based on the request content information, and the initial request message is checked for integrity based on the target message template. If the integrity check fails, the initial request message is input into an information repair model pre-trained based on historical target request messages and target message templates to obtain the target request message. The integrity check can be dynamically performed according to the requirements of the target end. When the integrity check fails, automatic repair and reconstruction capabilities are realized to avoid information transmission failures caused by system incompatibility. Finally, the target request message is sent to the target end. This method is widely adaptable to various resource transfer scenarios and system version evolution requirements, and improves the dynamic scalability of cross-system resource transfer when various resource transfer scenarios, different system versions, or dynamic business strategy adjustments are implemented.

[0112] In one exemplary embodiment, such as Figure 3As shown, step S204 may include sequentially selecting each request field as the current field according to the arrangement order, and then performing steps S302 to S304. Wherein:

[0113] Step S302: Find at least one validation rule in the request message template that matches the current field.

[0114] For example, validation rules refer to a set of logical conditions and processing methods predefined in the template to determine the validity, compliance, dependency integrity, and context consistency of field values. For each field, the template may contain multiple rules of different types. Server 104 can locate the rule definition node for that field based on its name or path and extract all applicable rule items. For instance, if the current field is "Operation Mode," server 104 can find the following three rules in the request message template: first, a data type validation rule requiring the field to be a string; second, a value range rule allowing the value "auto"; and third, a context dependency rule, if the previous field "Resource Category" is "Shared," then this field cannot be "Manual." Server 104 can collect these rules one by one and store them in a structured manner in a temporary rule table as the basis for the next validation step.

[0115] Step S304: Perform data verification on the current context dataset according to each verification rule, and update the current context dataset based on the data verification results.

[0116] For example, server 104 can read the original value of the field from the request content information and call the type judgment function pointed to in the template to verify whether the basic type of the value matches, such as whether "operation Mode" is a string. If not, it can be marked as a type exception.

[0117] Subsequently, server 104 can perform enumeration validation on this value, that is, determine whether it belongs to the set of allowed values ​​defined by the template. If the value is "auto", the validation passes; if it is "manual", server 104 can further trigger the context dependency rule judgment logic, read the "resource category" field value recorded in the context dataset, and determine whether it is "shared". If the dependency is not satisfied, server 104 can mark the field as "context conflict" in the context dataset and record the conflict source field.

[0118] For fields that fail validation, server 104 will not immediately halt the process. Instead, it can attempt to supplement candidate values ​​in the context dataset based on the "completion strategy" or "default inference logic" attached to the rule. For example, if the "operationMode" field is missing, and the template rule specifies the default value as "auto", server 104 can directly write the default value into the context dataset and mark its source as "default completion"; if there is no default value, the field is recorded as "missing and pending processing".

[0119] In addition, server 104 can record process metadata for each field validation, including the rule ID used, whether it passed, the original value, the alternative value, and conflicting dependencies. This information will be appended to the state structure of the corresponding field in the context dataset, so that the entire dataset not only carries the business data itself, but also has a complete processing history and validation description.

[0120] Through the above steps, server 104 can convert the original request fields into a semantically clear and state-controllable set of context fields. This rule-driven, sequence-controlled, and dependency-sensitive validation method enables server 104 to efficiently adapt to changing field logic relationships and system format differences, fundamentally improving the accuracy and automation level of resource transfer operations.

[0121] In some embodiments, server 104 may, if the verification rule is a data-disabled verification rule, search for the current field in the disabled list according to the data-disabled verification rule; if the current field exists in the disabled list, delete the data associated with the current field in the context dataset according to the data-disabled verification rule, so as to update the current context dataset.

[0122] Among them, data disabling validation rules are a special type of rule extracted by server 104 from the request message template. These rules describe the conditional logic that certain fields should not be effective or appear under specific scenarios, configurations, policies, or versions. For example, the template might specify that when the "Requester Identifier" is "System A-V3," the "Resource Expiration Time" field is disabled; or, if the "Resource Type" field is "Temporary Resource," the "Assignment Priority" field is invalid. This type of disabling logic is predefined in a disabling list and stored in association with each requester version, field group logic, or context state.

[0123] For example, during the field-level data validation process, server 104 can check whether there is a data disabling validation rule related to the field in the current request message template based on the field name, and read the disabling list pointed to by the rule. The structure of the disabling list may include field identifier, applicable conditions, trigger status, and disabling level. Taking the field "expire Time" as an example, the disabling list may record the following condition: "If the requesting party is system A-V3, then the field expire Time is disabled."

[0124] Subsequently, server 104 can parse the auxiliary information in the current context dataset to confirm whether the disabling rule has been triggered. For example, if it reads the current requester identifier field and finds that it is "System A-V3", which meets the triggering conditions of the disabling rule, then server 104 can determine that the current field should be in a disabled state.

[0125] If a field is confirmed to be disabled, server 104 can immediately perform an update operation: removing all data associated with the field from the context dataset, including the field value, field source identifier, validation result record, and completion status. This deletion operation not only clears the field's data itself but also ensures that any context-inferred fields, dependency chains, or derived logic associated with it are synchronously updated or marked as invalid, preventing the misuse of invalid fields during subsequent message construction. For example, if the aforementioned "expire Time" field is disabled, server 104 will not only delete its value but also clear its status flag "user-inputted" and cancel the corresponding fragment originally intended to be concatenated during message construction, preventing the field from appearing in a message structure unacceptable to the target.

[0126] In addition, server 104 can add a disabled field list area to the context dataset to record the list of disabled fields in the current request, the disabled trigger conditions and the disabled timestamp, which can be used for subsequent message construction control logic or operation and maintenance audit process.

[0127] Through the above steps, server 104 can not only dynamically perceive the validity of fields under different request conditions, but also accurately perform field-level data pruning, thereby significantly improving the consistency of message construction and target-side compatibility. Especially in cross-system scenarios with diverse system versions, complex business rules, and inconsistent field compatibility, this disabling mechanism provides a fine-grained, highly reliable dynamic adaptability, effectively avoiding structural conflicts and execution anomalies caused by invalid fields, and achieving message structure scalability and stability.

[0128] In other embodiments, server 104 may also, if the validation rule is a parameter dependency validation rule, search for the dependency field value associated with the current field in the current context dataset according to the parameter dependency validation rule; if the dependency field value is missing in the current context dataset, search for the value of each request field in the request content information to obtain the dependency field value; and update the current context dataset according to the dependency field value.

[0129] Parameter dependency validation rules refer to the logical sequence, structural linkage, or semantic matching requirements between fields. For example, the value of field A is only valid when field B is in a specific state, or the format of field A needs to be parsed with reference to the type information of field B. Such rules can be described in the request message template as an associative logical expression, such as "when the resource type is 'shared', the value of field X can only be a non-empty string"; or "the validation method of field Y depends on the value of field Z".

[0130] For example, during field-level data validation, server 104 can locate the set of dependent fields for the current field, which may originate from a predefined dependency chain in the template. For instance, if the current field is "accessControl Level" and its dependent field is defined as "resource Type" in the template, server 104 can search for the current value of "resource Type" in the current context dataset. If "resource Type" has already been validated and a valid value, such as "shared," has been recorded in the context dataset, server 104 can directly use this value to call the bound dependency validation logic to determine whether the current field "access Control Level" conforms to the rules. For example, if the rule stipulates that access control level must be enabled under shared resources, then "access Control Level" must be non-empty, and the value must be selected from "low," "medium," and "high." If the field is missing or the value is invalid, server 104 can immediately record the validation failure information and mark the context update status as "dependency not satisfied."

[0131] Furthermore, if the current context dataset does not yet contain a value for "resource type", server 104 can trace back to the original request content information to check if a field named "resource type" exists and extract its value. If the field is found and its value is "shared", server 104 can write its value into the context dataset and mark its source as "backtracking completion". Subsequently, it can perform judgment and update the results according to the regular dependency verification process.

[0132] Furthermore, if the dependent field is still not found in the request content information, server 104 can mark the current field as "cannot be verified" and register it in the context as "pending the supplementation of dependent values" for subsequent unified processing or message repair module use. This ensures the rigor of field verification and avoids the overall interruption of the process due to the absence of a single field, thereby improving the stability and fault tolerance of the system.

[0133] After obtaining the dependency value, server 104 can re-execute the dependency validation logic for the current field based on the actual value. If the validation is successful, the result, value source, and dependency path can be written to the status area of ​​the field in the context dataset, and marked "dependency validation passed"; if it fails, the reason for the failure and the specific dependency rule entry that was triggered will be explained, providing traceable information for subsequent repair modules or operation alarms.

[0134] Through the steps described above, server 104 not only enhances its ability to handle complex field logic relationships but also achieves a high degree of coordination between data validation and context synchronization updates. This enables it to maintain high accuracy and adaptability when processing resource transfer requests with nested logic, cross-field judgments, or dynamic rules.

[0135] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0136] Based on the same inventive concept, this application also provides a cross-system resource transfer adaptation device for implementing the cross-system resource transfer adaptation method described above. The solution provided by this device is similar to the implementation described in the above method; therefore, the specific limitations in one or more cross-system resource transfer adaptation device embodiments provided below can be found in the limitations of the cross-system resource transfer adaptation method described above, and will not be repeated here.

[0137] In one exemplary embodiment, such as Figure 4As shown, a cross-system resource transfer adaptation device is provided, including: an information acquisition module 402, a data processing module 404, a message generation module 406, a message verification module 408, and a message sending module 410, wherein:

[0138] The information acquisition module 402 is used to acquire the requester identifier and request content information in response to a resource transfer request; wherein, the request content information includes multiple request fields that are arranged in an ordered manner;

[0139] The data processing module 404 is used to obtain the request message template according to the requester identifier, and to perform data validation on each request field in the order of the request message template and request content information to obtain the context dataset.

[0140] The message generation module 406 is used to generate message fragments corresponding to each request field based on the context dataset, and to merge the message fragments to obtain the initial request message;

[0141] The message verification module 408 is used to obtain the target message template based on the request content information, and to perform integrity verification on the initial request message based on the target message template.

[0142] The message sending module 410 is used to input the initial request message into the pre-trained information repair model to obtain the target request message when the integrity check fails, and then send the target request message to the target end; wherein, the information repair model is trained based on the historical target request messages and the target end message template.

[0143] In one embodiment, the data processing module 404 is specifically used to: sequentially take each request field as the current field according to the arrangement order, and perform the following steps: find at least one verification rule in the request message template that matches the current field; perform data verification on the current context dataset according to each verification rule, and update the current context dataset according to the result of the data verification.

[0144] In one embodiment, the data processing module 404 is specifically used to: when the verification rule is a data disabling verification rule, search for the current field in the disabled list according to the data disabling verification rule; when the current field exists in the disabled list, delete the data associated with the current field in the context dataset according to the data disabling verification rule, so as to update the current context dataset.

[0145] In one embodiment, the data processing module 404 is further configured to: when the validation rule is a parameter dependency validation rule, search for the dependency field value associated with the current field in the current context dataset according to the parameter dependency validation rule; when the dependency field value is missing in the current context dataset, search for the value of each request field in the request content information to obtain the dependency field value; and update the current context dataset according to the dependency field value.

[0146] In one embodiment, the apparatus further includes a data encryption module, configured to extract sensitive fields from the target request message based on the target message template; and to encrypt each sensitive field to update the target request message.

[0147] In one embodiment, the data encryption module is specifically used to: calculate a hash value based on the value of each sensitive field; and encrypt each sensitive field based on the hash value to update the target request message.

[0148] Each module in the aforementioned cross-system resource transfer adaptation device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0149] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 5 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores request message templates, target message templates, and context datasets generated during data processing. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When executed by the processor, the computer program implements a cross-system resource transfer adaptation method.

[0150] Those skilled in the art will understand that Figure 5The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0151] In an exemplary embodiment, a computer device is provided, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to perform the following steps: in response to a resource transfer request, obtaining a requesting end identifier and request content information; wherein, the request content information includes multiple request fields arranged in an ordered manner; obtaining a request message template based on the requesting end identifier, and performing data verification on each request field sequentially according to the request message template and the request content information in the ordered manner to obtain a context dataset; generating message fragments corresponding to each request field based on the context dataset, and merging the message fragments to obtain an initial request message; obtaining a target end message template based on the request content information, and performing an integrity check on the initial request message based on the target end message template; if the integrity check fails, inputting the initial request message into a pre-trained information repair model to obtain a target request message, and sending the target request message to the target end; wherein, the information repair model is trained based on historical target request messages and target end message templates.

[0152] In one embodiment, when the processor executes the computer program, it further performs the following steps: sequentially taking each request field as the current field according to the order of arrangement, and performing the following steps: finding at least one validation rule in the request message template that matches the current field; performing data validation on the current context dataset according to each validation rule, and updating the current context dataset according to the result of the data validation.

[0153] In one embodiment, when the processor executes the computer program, it further performs the following steps: if the validation rule is a data-disabled validation rule, it searches for the current field in the disabled list according to the data-disabled validation rule; if the current field exists in the disabled list, it deletes the data associated with the current field in the context dataset according to the data-disabled validation rule, so as to update the current context dataset.

[0154] In one embodiment, when the processor executes the computer program, it further performs the following steps: if the validation rule is a parameter dependency validation rule, it searches for the dependency field value associated with the current field in the current context dataset according to the parameter dependency validation rule; if the dependency field value is missing in the current context dataset, it searches for the value of each request field in the request content information to obtain the dependency field value; and it updates the current context dataset according to the dependency field value.

[0155] In one embodiment, when the processor executes the computer program, it further performs the following steps: extracting sensitive fields from the target request message based on the target message template; and encrypting each sensitive field to update the target request message.

[0156] In one embodiment, when the processor executes the computer program, it further performs the following steps: calculating a hash value based on the value of each sensitive field; and encrypting each sensitive field based on the hash value to update the target request message.

[0157] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0158] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0159] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, graphics processors, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0160] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0161] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A cross-system resource transfer and adaptation method, characterized in that, The method includes: In response to a resource transfer request, the requester identifier and request content information are obtained; wherein, the request content information includes multiple request fields that are arranged in an ordered manner; The request message template is obtained based on the requester identifier, and the request message template and the request content information are used to perform data validation on each request field in the order of arrangement to obtain the context dataset. Based on the context dataset, message fragments corresponding to each of the request fields are generated, and the message fragments are merged to obtain an initial request message; Obtain the target message template based on the request content information, and perform an integrity check on the initial request message based on the target message template. If the integrity check fails, the initial request message is input into a pre-trained information repair model to obtain a target request message, and the target request message is sent to the target end; wherein, the information repair model is trained based on historical target request messages and target end message templates.

2. The method according to claim 1, characterized in that, The step involves performing data validation on each request field sequentially according to the requested message template and the requested content information, in the specified order, to obtain a context dataset, including: Following the stated order, each of the requested fields is used as the current field, and the following steps are performed: Find at least one validation rule in the request message template that matches the current field; According to the verification rules, the current context dataset is verified, and the current context dataset is updated based on the verification results.

3. The method according to claim 2, characterized in that, The step of performing data validation on the current context dataset according to each of the validation rules, and updating the current context dataset according to the data validation results, includes: If the verification rule is a data-disabled verification rule, the current field is searched in the disabled list according to the data-disabled verification rule; If the current field exists in the disabled list, the data associated with the current field in the context dataset is deleted according to the data disabling verification rules, so as to update the current context dataset.

4. The method according to claim 2, characterized in that, The step of performing data validation on the current context dataset according to each of the validation rules, and updating the current context dataset according to the data validation results, includes: If the validation rule is a parameter dependency validation rule, the dependent field value associated with the current field is searched in the current context dataset according to the parameter dependency validation rule. If the dependency field value is missing in the current context dataset, the value of each request field in the request content information is searched to obtain the dependency field value. Update the current context dataset based on the value of the dependency field.

5. The method according to any one of claims 1 to 4, characterized in that, Before sending the target request message to the target end, the method further includes: Based on the target message template, extract the sensitive fields from the target request message; Each of the aforementioned sensitive fields is encrypted in order to update the target request message.

6. The method according to claim 5, characterized in that, The encryption of each of the aforementioned sensitive fields to update the target request message includes: Calculate the hash value based on the values ​​of each of the aforementioned sensitive fields; The sensitive fields are encrypted based on the hash value to update the target request message.

7. A cross-system resource transfer and adaptation device, characterized in that, The device includes: The information acquisition module is used to acquire the requester identifier and request content information in response to a resource transfer request; wherein, the request content information includes multiple request fields that are arranged in an ordered manner; The data processing module is used to obtain a request message template based on the requester identifier, and to perform data validation on each request field in the order of the request message template and the request content information to obtain a context dataset. The message generation module is used to generate message fragments corresponding to each of the request fields based on the context dataset, and to merge the message fragments to obtain an initial request message; The message verification module is used to obtain the target message template based on the request content information, and to perform integrity verification on the initial request message based on the target message template. The message sending module is used to input the initial request message into a pre-trained information repair model to obtain a target request message when the integrity check fails, and then send the target request message to the target end; wherein, the information repair model is trained based on historical target request messages and target end message templates.

8. The apparatus according to claim 7, characterized in that, The data processing module is specifically used to: sequentially take each of the request fields as the current field according to the arrangement order, and perform the following steps: find at least one verification rule in the request message template that matches the current field; perform data verification on the current context dataset according to each of the verification rules, and update the current context dataset according to the result of the data verification.

9. The apparatus according to claim 8, characterized in that, The data processing module is specifically used to: when the verification rule is a data disabling verification rule, search for the current field in the disabled list according to the data disabling verification rule; when the current field exists in the disabled list, delete the data associated with the current field in the context dataset according to the data disabling verification rule, so as to update the current context dataset.

10. The apparatus according to claim 8, characterized in that, The data processing module is further configured to: when the verification rule is a parameter dependency verification rule, search for the value of the dependent field associated with the current field in the current context dataset according to the parameter dependency verification rule; If the dependency field value is missing in the current context dataset, the value of each request field in the request content information is searched to obtain the dependency field value. Update the current context dataset based on the value of the dependency field.

11. The apparatus according to any one of claims 7 to 10, characterized in that, The device further includes a data encryption module, used to extract sensitive fields from the target request message based on the target message template; Each of the aforementioned sensitive fields is encrypted in order to update the target request message.

12. The apparatus according to claim 11, characterized in that, The data encryption module is specifically used to: calculate a hash value based on the value of each of the sensitive fields; and encrypt each of the sensitive fields based on the hash value to update the target request message.

13. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

14. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

15. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images