Heterogeneous system data processing method and device, computer device, computer readable storage medium and computer program product

Abstract

This application relates to a heterogeneous system data processing method, apparatus, computer device, computer-readable storage medium, and computer program product. The method includes: responding to a data processing request from a source business system; the data processing request carrying a target request type, business parameters, and a target system identifier of the source business system; determining a target request processing strategy corresponding to the data processing request from a plurality of pre-configured optional request processing strategies based on the target system identifier and the target request type; wherein, each optional request processing strategy corresponds to one optional request type, and the optional request processing strategy is used to define the processing logic for optional request types initiated by at least one optional business system; processing the data processing request according to the target request processing strategy to obtain a request processing result corresponding to the data processing request. This method can improve development and maintenance costs and enhance system integration flexibility.

Description

Technical Field

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

[0002] As enterprises continue to deepen their informatization and digitalization processes, they typically need to achieve data exchange and business integration between their internal core business systems and numerous external heterogeneous systems (such as major e-commerce platforms, third-party logistics services, and tax authorities' invoicing systems) in order to automate key business processes such as automatic order synchronization, centralized invoice processing, and real-time inventory updates.

[0003] To achieve this type of cross-system integration, the traditional approach is a "point-to-point" customized development method. Under this method, developers need to write separate interface programs or code for each pair of source and target systems that need to interact, as well as for each specific business interaction scenario. This approach suffers from problems such as low development efficiency, high cost, low flexibility, and high maintenance difficulty. Summary of the Invention

[0004] Therefore, it is necessary to provide a heterogeneous system data processing method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can reduce development and maintenance costs and improve system integration flexibility in response to the above-mentioned technical problems.

[0005] Firstly, this application provides a method for processing data in heterogeneous systems, including:

[0006] In response to a data processing request from a source business system; the data processing request carries the target request type, business parameters, and the target system identifier of the source business system;

[0007] Based on the target system identifier and the target request type, a target request processing strategy corresponding to the data processing request is determined from a plurality of pre-configured optional request processing strategies; wherein, one optional request processing strategy corresponds to one optional request type, and the optional request processing strategy is used to define the processing logic for the optional request type initiated by at least one optional business system; the processing logic includes a first invocation rule for the source interface, a data conversion rule, and a second invocation rule for the target interface; the source interface is used to provide data to be processed; the target interface is used to perform request processing; the data conversion rule converts the data to be processed into a preset data format;

[0008] The data processing request is processed according to the target request processing strategy to obtain the request processing result corresponding to the data processing request.

[0009] Secondly, this application also provides a heterogeneous system data processing apparatus, the apparatus comprising:

[0010] The response module is used to respond to data processing requests from the source business system; the data processing request carries the target request type, business parameters, and the target system identifier of the source business system;

[0011] The determining module is configured to determine the target request processing strategy corresponding to the data processing request from a plurality of pre-configured optional request processing strategies based on the target system identifier and the target request type; wherein, each optional request processing strategy corresponds to an optional request type, and the optional request processing strategy is used to define the processing logic for the optional request type initiated by at least one optional business system; the processing logic includes a first invocation rule for the source interface, a data conversion rule, and a second invocation rule for the target interface; the source interface is used to provide data to be processed; the target interface is used to perform request processing; and the data conversion rule converts the data to be processed into a preset data format;

[0012] The processing module is used to process the data processing request according to the target request processing strategy to obtain the request processing result corresponding to the data processing request.

[0013] 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 implement the steps included in any of the foregoing method embodiments.

[0014] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps included in any of the foregoing method embodiments.

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

[0016] The aforementioned heterogeneous system data processing methods, apparatuses, computer equipment, computer-readable storage media, and computer program products, by introducing pre-configured optional request processing strategies, transform the customized coding work for each combination of (source system, request type) in the traditional model into a visual configuration of reusable strategies. Business personnel or implementation personnel can quickly define or reuse processing logic through the configuration interface, which can significantly improve development efficiency. Furthermore, by abstracting the data processing flow into configurable rules (first call rule, data transformation rule, second call rule) through the target request processing strategy, the business logic is decoupled from the interface technology details of specific systems. When any external system interface changes, only the relevant rules need to be updated in the corresponding strategy configuration or underlying interface knowledge base, without modifying and redeploying the core business process code, greatly simplifying maintenance work and improving system stability and maintainability. In summary, the embodiments of this application encapsulate and simplify the complexity of heterogeneous system integration, realizing a paradigm shift from "hard-coded integration" to "configurable integration," and systematically and effectively overcoming the various defects of the traditional "point-to-point" model. Attached Figure Description

[0017] 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.

[0018] Figure 1 This is an application environment diagram of a heterogeneous system data processing method in one embodiment;

[0019] Figure 2 This is a flowchart illustrating a heterogeneous system data processing method in one embodiment;

[0020] Figure 3 This is a structural block diagram of a heterogeneous system data processing device in one embodiment;

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

[0022] 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.

[0023] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0024] The heterogeneous system data processing method provided in this application embodiment can be applied to, for example... Figure 1 In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104 or located on the cloud or other network servers. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, 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 composed of multiple physical servers, or a cloud server providing cloud computing services.

[0025] In one exemplary embodiment, such as Figure 2 As shown, a method for processing data in heterogeneous systems is provided, which can be applied to... Figure 1 Taking server 104 as an example, the explanation includes the following steps 202:

[0026] Step 202: Responding to a data processing request from the source business system; the data processing request carries the target request type, business parameters, and the target system identifier of the source business system.

[0027] In this embodiment, the system can be deployed on a data integration service platform. This platform acts as a central hub, continuously monitoring and receiving requests from external source business systems. Source business systems refer to external application systems that serve as the starting point for the data interaction process; these systems can exhibit technological heterogeneity and diverse interfaces. Source business systems include various e-commerce platforms, legacy systems within enterprises, customer relationship management systems, supply chain systems, and third-party service platforms. These systems are typically developed by different vendors, employing different technology stacks (such as Java, .NET, PHP), data formats (such as XML, JSON, CSV), and communication protocols.

[0028] A data processing request is a data processing instruction initiated or pushed by the source business system when a specific business event occurs (such as new order generation, invoice status change, logistics information update, etc.) or in response to a user operation. A data processing request can include the following parameters: Target request type, which can be a predefined string or enumeration value used to identify the core business logic or processing flow that needs to be executed in this request. For example, "download_invoice" (download invoice), "sync_order" (synchronize orders), "push_inventory" (push inventory). Business parameters, used to characterize the business data necessary to specifically execute the target request type. For example, for a request of type "download_invoice", its business parameters might be {"order_id": "202410010001", "platform_code": "xx"}, where order_id specifies which invoice to download, and platform_code (in this example, it can be consistent with the target system identifier) ​​may be used for finer-grained internal routing. Business parameters can serve as the basis for calling subsequent interfaces to obtain specific business data.

[0029] The target system identifier is a string or code used to uniquely identify the source business system that initiated this request. Examples include "XXshop", "Xmall", or "Internal_ERP" (internal ERP system). The target system identifier determines which system initiated the request, potentially leading to different processing rules.

[0030] Step 204: Based on the target system identifier and the target request type, determine the target request processing strategy corresponding to the data processing request from a plurality of pre-configured optional request processing strategies; wherein, one optional request processing strategy corresponds to one optional request type, and the optional request processing strategy is used to define the processing logic for the optional request type initiated by at least one optional business system; the processing logic includes a first invocation rule for the source interface, a data conversion rule, and a second invocation rule for the target interface; the source interface is used to provide data to be processed; the target interface is used to perform request processing; the data conversion rule converts the data to be processed into a preset data format.

[0031] Each optional request processing strategy corresponds to an optional request type. For example, one strategy might specifically handle the "download_invoice" type, while another might handle the "sync_order" type. An optional request processing strategy defines the processing logic for the current optional request type initiated by at least one optional business system. This allows a request processing strategy for a single business processing request to be reused by multiple different source business systems. For instance, a strategy named "General Invoice Download Strategy" can be used by three different e-commerce platforms identified as "XXshop," "XMALL," and "XXsell." When any of these three platforms sends a business data request of type "download_invoice," it will be matched with the same strategy. This improves the reusability and configuration efficiency of data processing strategies and avoids repeatedly configuring similar logic for each platform.

[0032] Considering that for many enterprises, the core processing logic (data acquisition -> conversion -> sending) for the same type of business request (such as downloading invoices) from different source business systems (such as different e-commerce platforms) is highly similar, with differences mainly in specific technical details such as interface address, authorization method, and data format, this embodiment of the invention associates an optional request processing strategy with multiple optional business system identifiers (such as "XXshop", "XMALL", "XXsell"). For example, an optional request processing strategy named "General Invoice Download Strategy" can be associated with the three system identifiers "XXshop", "XMALL", and "XXsell" simultaneously. When any of these three platforms initiates a "download_invoice" request, it can be matched with this same optional request processing strategy. This avoids the repetitive work of developing or configuring an independent process for each (source system, request type) combination in the traditional model, greatly improving configuration efficiency and system maintainability.

[0033] Multiple optional request handling strategies can be generated through program code, or optionally defined and managed through a visual strategy configuration center. This configuration center provides a graphical user interface for system administrators, implementation consultants, or business analysts (collectively referred to as "configuration personnel"), enabling them to build complex integration processes without writing code. The guiding principle of configuration operations is to deconstruct a complete data interaction process into a programmable template that defines "under what conditions (When), for whom (Who) what kind of request (What), and which standardized steps (How) to execute," thereby achieving separation of business logic and technical implementation, and decoupling of general processes from specific systems.

[0034] Specifically, configuration personnel can create a new optional request handling policy in the interface and specify a unique optional request type for it (e.g., "download_invoice"). Simultaneously, in the policy's "Associated Source System" configuration item, they can select or enter one or more optional business system identifiers to which the policy applies (e.g., simultaneously selecting "XXshop", "XMALL", and "XXsell"). For example, configuration personnel recognize that the "download invoice" business logic is essentially the same across platforms A, B, and C, therefore creating a universal policy to cover all similar sources. This converges the previously scattered business logic across multiple customized programs into a unified configuration point, which is fundamental to improving configuration efficiency and maintainability.

[0035] Specifically, the processing logic may include: First invocation rules for the source API define which specific source API should be invoked to obtain the raw business data. These rules may directly specify the API identifier or be a dynamically selected mapping rule based on the target system identifier (e.g., for "XXshop", the source API is "XX Order Query API"; for "XMALL", the source API is "XMALL Order Details API"). Data transformation rules define how to convert the raw data (i.e., data to be processed) returned by different source APIs with vastly different formats into a preset, internally unified intermediate data format (i.e., preset data format) through operations such as field mapping, format conversion, and data cleaning. Specifically, the data transformation process can be performed according to the requirements of the internal unified data model as follows: Fill the source data fields into the corresponding positions in the internal model according to the predefined mapping relationship. Standardize the format of fields such as execution date and amount. Convert platform-specific status codes into general business status descriptions. After the above transformation, the originally heterogeneous source data is transformed into a clearly structured and semantically clear standard data whose format fully conforms to the internal unified data model. Therefore, all subsequent processing logic (such as business validation, data persistence, and routing decisions) only needs to be developed and configured for this unified model, without needing to care which heterogeneous system the data originally came from. This achieves decoupling of business logic and technical interfaces and provides a foundation for strategy reuse.

[0036] The second invocation rule for the target API defines which specific target API the converted standard data should be sent to after data processing is complete. Similar to the source API, the determination of the target API may also be dynamic.

[0037] In this embodiment of the invention, the target system identifier (e.g., "XXshop") and the target request type (e.g., "download_invoice") in the data processing request are combined into a query key (e.g., ("XXshop", "download_invoice")), and this key is used for precise matching in the policy library. The successfully matched policy is determined as the target request processing policy for this request, which contains the complete set of operational procedures required to process the request. The data processing policy library can be organized in various data structures, such as using a policy routing table. This table records the mapping relationship between the policy selection key composed of the target system identifier and the target request type and the specific optional request processing policy identifiers.

[0038] Step 206: Process the data processing request according to the target request processing strategy to obtain the request processing result corresponding to the data processing request.

[0039] Once the target request processing strategy is determined, the business process is executed according to the logic defined in the target request processing strategy. The specific execution behavior is determined by the target request processing strategy, and may include the following processes:

[0040] Based on the first invocation rule in the target request processing strategy, the specific source interface to be invoked is determined (e.g., the "XXshop invoice download interface"). Using business parameters in the request (such as the order number) and the authorization information pre-configured for this source interface in the target request processing strategy (such as AppKey and signature algorithm), a request conforming to the interface specification is constructed and sent to obtain the raw invoice data from the "XXshop" platform as the data to be processed. Then, according to the data transformation rules in the target request processing strategy, the obtained raw invoice data in the preset format is processed. For example, the "orderId" field in the JSON returned by the "XXshop" platform is mapped to the "platform_order_sn" field of the internal unified model; the date format is standardized; and the status code is converted into readable text, thereby obtaining standard data conforming to the internal unified data model.

[0041] Based on the second invocation rule in the target request processing strategy, the specific target interface to be invoked is determined (e.g., the "invoice entry interface of the internal ERP system" or the "invoice application interface of the tax bureau system"). Standard data is then transformed according to the requirements of the target interface to form a data format recognizable by the target interface (e.g., converted to XML), and the authorization credentials required by the target interface are attached. A request is then constructed and sent to the target interface to enable data processing. After the target interface completes processing, it returns a response (e.g., {"code": 200, "message": "Invoice data successfully entered", "invoice_id": "INV202410010001"} or "Invoice successful" or "Data entered"). This response is standardized, encapsulated, or transformed to generate a unified request processing result, which is ultimately returned to the original business system that initiated the request or the specified callback address, thus completing the closed loop of the entire data flow.

[0042] This application transforms the original "point-to-point" integration model, which required customized development for each combination (source system, target system, business type), into a model driven by a unified, configurable strategy. The requesting party only needs to send a standardized request carrying clear identifiers and parameters; complex routing decisions, API calls, data transformations, and other logic are automatically handled by the integration engine based on pre-configured strategies. By shifting from coding to configuration, and requiring only policy modifications for changes, development efficiency is significantly improved, maintenance costs are reduced, and since adding a new platform only requires configuring new rules, system flexibility and scalability are enhanced, while ensuring data processing consistency and accuracy.

[0043] In some embodiments, before determining the target request processing strategy corresponding to the data processing request from a plurality of pre-configured optional request processing strategies based on the system identifier and the target request type, the method includes:

[0044] A preset visual configuration interface is displayed; wherein, the visual configuration interface includes authorization information configuration items, interface specification configuration items, and request processing strategy configuration items;

[0045] In response to a configuration operation on the authorization information configuration item, the authorization parameters and signature algorithm of at least one optional interface of at least one optional business system are obtained;

[0046] In response to a configuration operation on the interface specification configuration item, an interface specification for the at least one optional interface is obtained; the interface specification includes at least one of the following: interface address, request method, request header structure, request body structure, and response body structure.

[0047] In response to a configuration operation on the request processing strategy configuration item, the system identifier of the at least one optional business system, at least one optional request type, and the association between the optional request processing strategies are obtained.

[0048] The step of processing the data processing request according to the target request processing strategy to obtain the request processing result corresponding to the data processing request includes:

[0049] The source interface defined in the target request processing strategy is called according to the business parameters and the first calling rule to obtain the data to be processed corresponding to the data processing request;

[0050] The data to be processed is converted into standard data that conforms to the preset data format according to the data conversion rules defined in the target request processing strategy.

[0051] The target interface defined in the target request processing strategy is invoked according to the standard data and the second invocation rule to obtain the request processing result.

[0052] The visual configuration interface can be a pre-defined interactive interface. Considering that in related technologies, developers need to mix three types of information in their code: the key and signature logic for interface access; the address, parameters, and other call details of each interface; and the business process logic that connects multiple interfaces, this mixture leads to rigid and difficult-to-maintain code. This invention, through analysis, decouples these three types of information and maps them to three independent, functionally cohesive configuration items in the configuration interface, thus achieving "separation of concerns." The authorization information configuration item is used to extract all system-integrated security credentials from scattered code and configuration files, enabling unified and secure storage and management. In subsequent data processing strategy execution, the engine dynamically retrieves credentials from here based on the interface identifier and calculates the signature, allowing security policies to be updated independently of business logic (such as key rotation). The interface specification configuration item is used to establish an interface knowledge graph. The technical details of each API (such as contracts) are preserved as queryable and reusable knowledge. This replaces the previous process of reading external documentation and manually writing call code. When the strategy is executed, the engine can automatically construct a compliant request by querying this knowledge base, ensuring the accuracy of the call and limiting the impact of interface changes to the knowledge base update.

[0053] The request processing strategy configuration item is used to translate business intent into executable instructions. At this stage, the configuration personnel only need to focus on the business logic ("first retrieve data from A, convert it to format B, and then send it to system C"), without needing to concern themselves with the specific implementation of the aforementioned identities and contracts. The strategy achieves transparency of technical details by referencing elements defined in the first two configuration items (authorization configuration, interface specifications).

[0054] Specifically, configuration personnel use the authorization information configuration item to configure unique authentication information for each specific optional interface of each optional business system that needs to be integrated (e.g., the order query interface of a shopping platform, the invoicing interface of a tax bureau). Authentication information may include: authorization parameters such as access keys (AppKey / AppSecret), client ID, username / password, digital certificates, etc., as well as algorithm rules used to generate dynamic access credentials (such as API signatures), for example, a signature method based on HMAC-SHA256.

[0055] For example, the configuration personnel configure the authorization parameters {"app_key":"xx_app_123", "app_secret":"secret_xyz"} for the "Order Details Query API" of the "XX" business system, and specify the signature algorithm as "HMAC-SHA256". This configuration information can be structured and stored in a central authorization information repository to form a secure credential pool for interface calls.

[0056] Correspondingly, through the interface specification configuration items, the technical contract is defined in detail for each authorized optional interface. The interface specification is a complete description of the interface invocation method, which may include: Interface address: the complete URL of the API; Request method: such as GET, POST, PUT, etc.; Request header structure: the HTTP header information to be carried and its format; Request body structure: for methods such as POST / PUT, the data format of the request body (such as JSON Schema, XML Schema); Response body structure: the data format returned when the interface succeeds or fails. For example, defining the interface specification for "XXshop Order Details Query API": the address is "https: / / api.xx.com / routerjson", the method is "POST", and the request body must conform to a specific JSON structure, containing fields such as "method" and "param_json". These specifications are stored in an interface knowledge base as guiding data for constructing valid requests.

[0057] Configuration personnel create and define optional request processing strategies in a "building block" manner through request processing strategy configuration items. First, the configuration personnel create a new strategy and name it (e.g., "General Invoice Download Strategy"), while specifying the optional request types that the strategy handles (e.g., "download_invoice"). On the strategy's configuration page, the configuration personnel select one or more system identifiers from the list of optional business systems to which the strategy applies (e.g., simultaneously selecting "XXshop", "XMALL", and "XXsell"). This reflects the design philosophy of "one logical strategy covering multiple physical sources." Within the strategy framework, the configuration personnel specifically configure the processing logic: Configure the first invocation rule: For each source system associated with the strategy, the configuration personnel select a specific source interface for that system from the interface knowledge base (e.g., "XX Order Details Query API"). This interface automatically associates with the aforementioned authorization information. The system can automatically display a list of corresponding interfaces for selection based on the selected source system identifier. Configure data transformation rules: The configuration personnel define or select an internal unified data model (e.g., "Standard Invoice Information Model"). Subsequently, a visual field mapping tool is used to establish a mapping relationship between sample data fields returned from the source interface and the fields of the internal model, and conversion functions (such as date formatting) can be configured. A second invocation rule is configured: the configuration personnel select one or more target interfaces (such as the "Internal ERP Invoice Archiving Interface") from the interface knowledge base and associate them with their authorization information. For complex scenarios, simple routing logic can be configured. In response to the configuration personnel completing the above configuration, the optional request processing strategy will be saved, and an association relationship between the strategy identifier and the (system identifier, request type) combination will be established. This relationship can be reflected in the strategy routing table for runtime querying.

[0058] In some embodiments, the configuration process based on a visual configuration interface is described as follows:

[0059] The configuration personnel create a new optional request processing policy in the interface and specify a unique optional request type for it (e.g., "download_invoice"). At the same time, in the "Associated Source System" configuration item of the policy, they check or enter one or more optional business system identifiers to which the policy applies.

[0060] Considering that the "download invoice" business is essentially the same across platforms, a general strategy can be created to cover all similar sources. This will bring together the same business logic that was originally scattered across multiple customized programs into a unified configuration point, which is the foundation for improving configuration efficiency and maintainability.

[0061] In the strategy configuration interface, the user associates source interfaces with the strategy. Since the strategy is associated with multiple source systems, the configuration interface allows specifying the corresponding specific interface for each associated source system. For example, on the same strategy configuration page: for the system "XXshop", select or enter the source interface as "XX Order Details API", and associate the required authorization configuration "XX_Auth" for that interface. For the system "XMALL", select the source interface as "XMALL Transaction Query API", and associate the authorization configuration "XMALL_Auth". The strategy defines the general step of "requiring order details", but the specific technical details for each platform, such as which API to call and which key to use, are extracted and dynamically bound to the strategy as independently manageable and changeable configuration items.

[0062] Furthermore, by defining the field structure of the internal unified data model in the visual mapping interface (or selecting a preset model from the model library, such as the "Standard Invoice Application Form Model"), the mapping relationship between the sample data fields returned from various source system interfaces and the fields of this internal model can be established through methods such as drag-and-drop connections or form selection, and format conversion functions (such as "string to date") can be configured.

[0063] Instead of writing code to directly convert "XX format to tax bureau format", configuration personnel define mappings for "XX format -> internal standard model" and "internal standard model -> tax bureau format" respectively. This "star-shaped conversion" architecture reduces the original M (source) × N (target) types of converters to M + N types.

[0064] The configuration personnel specify one or more target interfaces for the policy (e.g., fixed as "tax bureau invoicing interface") and associate them with its authorization configuration. For scenarios requiring dynamic routing, the interface can support configuring simple routing rules based on standard data content (e.g., if the invoice amount > 10,000, then call the "large invoice special review interface"). This ensures the closed loop and directionality of the business process. The policy not only defines the source and transformation method of the data, but also clarifies the destination of the data, forming a complete and executable pipeline definition.

[0065] Through the above configuration process, a reusable optional request processing strategy is created. When a matching type request (such as downloading an invoice) arrives from any associated source system (such as XX), the system can automatically "understand" and execute the entire predefined process: using XX's key to call the XX interface, converting the returned data into an internal standard format according to the configured rules, and then calling the tax bureau interface to complete the invoicing. The entire process is completely configuration-driven, requiring no additional code development, compilation, or deployment. When adding an invoice download function for a new platform (such as "XHS"), the configuration personnel only need to associate the new system "XHS" with the existing "download_invoice" strategy and configure its dedicated source interface and authorization information. The core conversion logic and destination rules in the strategy do not need any modification, enabling rapid function integration and deployment, and greatly responding to business changes.

[0066] Correspondingly, during the application process, after matching the target request processing strategy, the first invocation rule defined therein is executed first. Specifically, this may include: based on the target system identifier (e.g., "XX") in the request, finding the specific source interface configured for that identifier (e.g., "XX Order Details Query API") within the target request processing strategy. Then, combining the authorization parameters and signature algorithm of this interface in the authorization information database, as well as the business parameters carried in the request (e.g., {"order_id": "123456"}), access credentials (e.g., API signature) are dynamically generated, and a valid HTTP request is constructed according to the interface specification in the interface knowledge base. Sending this request to the XX platform will then retrieve the original XX system's formatted order data, which will be used as data to be processed.

[0067] The predefined data transformation rules in the strategy are then applied. These rules explicitly specify how to convert the formatted data to be processed obtained in the previous step into the internal unified data model specified by the strategy. For example, the data transformation rules define mapping the "xxOrderId" field in the JSON returned by the called interface to the "platformOrderSn" field in the internal model. This mapping is performed, and fields such as date and amount are standardized and cleaned to obtain standardized, structured data that conforms to the defined rules. The specific target interface (e.g., "tax bureau invoicing interface") is determined according to the second calling rule. The request body specification of the target interface is obtained by querying the interface knowledge base, and the standard data is formatted according to this specification (e.g., from the internal JSON model to the XML format required by the tax bureau). Simultaneously, the authorization information for the target interface is obtained from the authorization information database, and a voucher is generated. Finally, a calling request conforming to the target interface specification is constructed. The response returned by the target interface after processing is processed and returned as the unified request processing result.

[0068] This application's embodiments enable the rapid construction, reuse, and adjustment of cross-system data processing workflows through a graphical interface. During runtime, the system automatically completes all technical operations strictly according to the configuration information, ensuring the accuracy, security, and high efficiency of the workflow. This "configuration as development" model significantly lowers the technical threshold, improves the agility of business response, and makes system maintenance and expansion exceptionally clear and simple.

[0069] In some embodiments, the authorization parameters and signature algorithm are stored in a preset authorization information database; the interface specification is stored in a preset interface knowledge base; the step of calling the source interface defined in the target request processing strategy according to the business parameters and the first calling rule to obtain the data to be processed corresponding to the data processing request includes:

[0070] Obtain the source interface identifier of the source interface from the target request processing strategy, and query the interface knowledge base based on the source interface identifier to obtain the source interface specification corresponding to the source interface;

[0071] The source authorization parameters and source signature algorithm corresponding to the source interface are obtained by querying the authorization information database based on the source interface identifier.

[0072] Based on the source authorization parameters, source signature algorithm, and business parameters, generate source access credentials for the source interface;

[0073] Based on the source interface specification, the business parameters, and the source access credentials, a call request for the source interface is constructed and initiated, and the data returned by the source interface is used as the data to be processed.

[0074] In this context, considering that an optional request strategy may be associated with multiple sources (such as XXshop, xxMALL), the first invocation rule actually maintains a mapping relationship: for each associated source identifier, there is a corresponding specific source interface identifier. Therefore, based on the target identifier carried by the current request (such as "XXshop"), the specific source interface identifier (such as "XXshop_OrderDetail_API") to be used in this invocation can be obtained by searching in this mapping relationship.

[0075] After obtaining the source interface identifier, it is used as the query key to access the pre-configured interface knowledge base. The interface knowledge base is a structured storage where each record corresponds to a configured interface and stores its complete interface specification. By querying, the source interface specification corresponding to the source interface identifier is obtained. The source interface specification is a structured data object that may contain the following fields: interface address: such as "https: / / api.xx.com / routerjson"; request method: such as "POST"; request header structure specification: specifying which HTTP headers should be included, such as "Content-Type:application / json"; and request body structure specification: describing the valid structure of the request body using a data schema definition language (such as JSON Schema). For example, defining the request body requires two top-level fields: "method" (string type) and "param_json" (object type).

[0076] Using the same source interface identifier, the authorization information repository is queried to obtain the source authorization parameters (e.g., {"app_key": "xx_app_123", "app_secret": "secret_xyz"}) and source signature algorithm (e.g., "HMAC-SHA256") bound to that interface. This repository stores authentication information for all interfaces.

[0077] Then, following the rules specified by the source signature algorithm (such as HMAC-SHA256), the business parameters (such as order ID, timestamp, etc.) are combined and encrypted with the app_secret in the source authorization parameters. The calculation result (i.e., the digital signature) together with parameters such as app_key constitutes a complete source access credential. For example, the generated credential may be reflected in a field in the HTTP request header: Authorization: XX-HMAC-SHA256 app_key=xx_app_123, signature=calculated_signature.

[0078] Finally, synthesizing all the acquired information, construct a fully compliant HTTP request. This can be done by using the API address and request method specified in the source API specification, specifying the request header structure defined in the source API specification, and injecting the generated source access credentials. For example, set Content-Type: application / json and the Authorization header generated in the previous step. Based on the request body structure specification in the source API specification, populate the business parameters into the specified structure. For example, construct a JSON object {"method": "jingdong.order.detail.get", "param_json": {"order_id": "123456"}}. Send the constructed HTTP request to the specified URL.

[0079] Upon receiving this compliance request, the source interface (such as the server on the XXshop platform) verifies and processes it, then returns response data (such as order details JSON). This response is received and used as pending data for subsequent data transformation steps in this process.

[0080] This application embodiment enables the execution engine to dynamically and accurately construct a legitimate call for any configured interface by querying the interface knowledge base and the authorization information base, without having to hardcode interface details or key information.

[0081] In some embodiments, the data transformation rules include field mapping relationships and data cleaning rules; the field mapping relationships are used to map the data to be processed to a preset unified data model; the step of converting the data to be processed into standard data conforming to the preset data format according to the data transformation rules defined in the target request processing strategy includes:

[0082] The data transformation rules are parsed to obtain the field definitions of the unified data model and the field mapping relationships;

[0083] Based on the field mapping relationship, the value of at least one field in the data to be processed is assigned to the corresponding field in the unified data model to obtain the assigned data model;

[0084] The values ​​of each field in the assigned data model are standardized according to the data cleaning rules to obtain the standard data.

[0085] This involves parsing the predefined data transformation rules in the target request processing strategy. These rules include field definitions of the unified data model and field mapping relationships. The field definitions of the unified data model describe the target format for the transformation. This unified data model is an internal standard predefined for a specific business domain (such as "invoice" or "order"), specifying which fields exist (such as invoice_number and purchase_date), the data type of each field (such as string, date, numeric, or enumeration), and its constraints (such as whether it is required and format requirements).

[0086] Field mapping defines the correspondence between specific fields in the data to be processed returned from the source interface and various fields in the unified data model. For example, the mapping might be expressed as: assigning the value of the "orderId" field in the source data to the "platform_order_sn" field in the target model; and assigning the value of the "createTime" field in the source data to the "purchase_date" field in the target model.

[0087] Based on the parsed field mapping relationships, the system iterates through and extracts data to be processed (usually structured data in JSON or XML format). For each source field specified in the mapping relationship, the system searches for that field in its data to be processed and retrieves its value. This value is then "filled in" or "assigned" to the corresponding target field of the previously parsed unified data model instance.

[0088] For example, suppose the data to be processed is the order JSON returned by XXshop: {"orderId": "XX123456", "createTime": "2023-10-01 14:30:00",...}. Based on the mapping "orderId -> platform_order_sn", the system assigns the value "XX123456" to the `platform_order_sn` field of the model instance. Similarly, based on "createTime -> purchase_date", the value "2023-10-01 14:30:00" is assigned to the `purchase_date` field of the model. After this step, a data model with some fields already populated is obtained.

[0089] To address the issue of inconsistent formatting and semantics, each field value in the assigned data model undergoes appropriate cleansing operations. For example, format conversion can be performed. In the source system, a date might be the string "2023-10-01 14:30:00" or a timestamp "1696153800," while the unified data model requires the standardized ISO 8601 format "2023-10-01T14:30:00Z." The system will call pre-defined format conversion functions (such as stringToISODate) for processing. Similarly, a monetary field might need to be converted from the string "100.50" to the numeric type "100.50," or from "cents" to "yuan."

[0090] Optionally, data cleaning and enhancement can be performed to logically correct or supplement the data. Value domain conversion: Converting source system-specific enumeration values ​​or status codes into business-common readable text. For example, converting the status code "1" for an order on XXshop to "Pending Payment" and "4" to "Shipped". Data derivation: Calculating and generating new fields based on existing fields. For example, calculating total_amount based on unit_price and quantity. Data validation and correction can also be performed: Performing data validity checks, such as verifying email formats and ID card verification codes, and standardizing and correcting obvious errors (e.g., removing leading and trailing spaces from strings).

[0091] After data cleaning, the originally inconsistent and semantically fragmented data is transformed into clean, standardized data that fully conforms to the unified data model definition and can be directly used for internal business logic processing. This application's embodiments detail how the transformation logic is abstracted into configurable field mapping relationships and data cleaning rules, and then bound to the unified data model. This eliminates the need for business systems to understand and process countless external data formats; they only need to process one internal standard format. Changes to external system interfaces only require adjustments to the mapping or cleaning logic in the corresponding data transformation rules; the internal business code remains unaffected.

[0092] In some embodiments, the authorization parameters and signature algorithm are stored in an authorization information base; the interface specification is stored in an interface knowledge base; and the step of invoking the target interface defined in the target request processing strategy according to the standard data and the second invocation rule to obtain the request processing result includes:

[0093] Obtain the target interface identifier of the target interface from the target request processing strategy, and query the interface knowledge base based on the target interface identifier to obtain the target interface specification corresponding to the target interface;

[0094] The target authorization parameters and target signature algorithm corresponding to the target interface are obtained by querying the authorization information database based on the target interface identifier.

[0095] Based on the target authorization parameters and the target signature algorithm, generate a target access credential for the target interface;

[0096] The standard data is converted according to the target interface specification to obtain target request data that conforms to the target request body structure corresponding to the target interface;

[0097] Based on the target request data and the target access credentials, and in accordance with the target request method in the target interface specification, a call request for the target interface is constructed and initiated, and the request processing result returned by the target interface is obtained.

[0098] After completing the data transformation to obtain standard data, the second invocation rule defined in the target request processing strategy is parsed, and the target interface identifier (e.g., "Tax_Bureau_Invoice_Issue_API") is extracted from this rule. The second invocation rule may contain conditional logic that dynamically determines the final target interface based on certain field values ​​of the standard data (such as invoice type and amount). This logic will be executed to determine the final target interface identifier.

[0099] Similar to calling the source interface, the target interface identifier is used as the key to query the interface knowledge base and obtain the complete target interface specification. The target interface specification may include: the target interface address (e.g., the URL of a tax bureau invoicing interface: "https: / / fpdk.example.com / api / invoice / issue"); the target request method (e.g., "POST"); the target request header structure specification (defining the necessary HTTP headers for calling this interface, such as "Content-Type: application / xml", "X-Tax-App-Id", etc.); and the target request body structure specification (using a data schema definition language (e.g., XML Schema) to precisely describe the expected request body format, fields, types, and constraints of the interface. For example, specifying the root element of the request body as... <invoicerequest>It needs to include <invoicecode> , <invoicenumber> , <amount>Sub-elements.

[0100] Simultaneously, the target interface identifier is used to query the authorization information database to obtain the authentication information required to call the target interface. This includes target authorization parameters (e.g., {"app_id": "tax_app_001", "private_key": "-----BEGIN PRIVATE KEY-----\n...."} which the tax authority interface might require) and the target signature algorithm (e.g., the RSA-based signature algorithm "RSA-SHA256").

[0101] Based on the obtained target signature algorithm, access credentials suitable for the target are generated using the target authorization parameters. For example, for a tax authority interface, it might be necessary to use a private key to perform an RSA signature on a specific part of the request (or the entire request body), generating a signature string, and then using the app_id and this signature to construct a specific HTTP request header. This process completely encapsulates the complex signature algorithm implementation, making it transparent to configuration and business logic.

[0102] Next, based on the target request body structure specification in the target interface specification, the field values ​​in the standard data are reorganized and encapsulated according to the requirements of the target format. For example, the standard data in the internal JSON format, {"invoice_code":"141001", "total_amount": 500.00}, is converted into the XML format required by the tax authorities. Considering that although the source data has been converted to the standard format, the field names of the target interface may still be different from the internal model, this step also includes a final field name mapping (e.g., internal total_amount -> tax authority Amount) and format fine-tuning (e.g., keeping two decimal places for amounts).

[0103] Use the target interface address and target request method (e.g., POST) from the target interface specification. Set the headers according to the target request header structure specification in the target interface specification and inject the target access credentials (e.g., X-Tax-Signature header). Use the converted target request data (e.g., XML string) as the request body. Send the request to the target interface address. After the target business (e.g., tax bureau server) processes the request, it will return a response (e.g., a successful response might be {"success":true, "invoice_no": "12345678", "pdf_url": "..."}, and a failed response includes an error code and message). Receive this response and use it as the final request processing result of this data processing flow.

[0104] In some embodiments, determining the target request processing strategy corresponding to the data processing request from a plurality of pre-configured optional request processing strategies based on the system identifier and the request type includes:

[0105] The system identifier and the request type are combined to form a strategy selection key. The strategy selection key is used to query a preset strategy routing table to obtain the target request processing strategy. The strategy routing table records the mapping relationship between the strategy selection key and the optional processing strategy identifier.

[0106] Alternatively, if the system identifier of the data processing request belongs to one of the multiple optional business system identifiers associated with the same optional request processing strategy, and the request type matches the target request type, then the same optional request processing strategy is determined as the target request processing strategy.

[0107] Upon receiving a data processing request, the system first extracts its routing parameters: the target identifier (identifying the request source, such as "XXshop") and the target request type (identifying the business action, such as "download_invoice"). These two parameters are then combined according to predetermined rules (such as using underscores to connect them or combining them into tuples) into a composite, globally unique strategy selection key. For example, this could form the key ("XXshop", "download_invoice") or the string "XXshop_download_invoice".

[0108] A pre-configured policy routing table is maintained. This table is essentially an efficient mapping data structure (such as a hash table or database table), its core content recording the one-to-one correspondence between policy selection keys and optional processing policy identifiers. Using the policy selection key, a fast lookup (such as a hash lookup) is performed in the policy routing table. A successful lookup returns the optional processing policy identifier bound to that key (e.g., "P_Invoice_Download"). Based on the retrieved optional processing policy identifier, the complete policy definition corresponding to that identifier (including the first invocation rule, data transformation rule, second invocation rule, etc.) is located in the data processing policy library. This complete policy is then determined as the target request processing policy for this request. Optional request processing policies explicitly maintain a list of optional business identifiers they "cover" or "serve". For example, the policy "P_Invoice_Download" is associated with the lists ["XXshop", "XMALL", "Xsell"] in its configuration metadata. When a request arrives, all optional request processing policies are traversed, checking whether the target identifier of the current request (such as "XX") is included in the associated identifier list of a certain policy. After identifying candidate strategies, further verification is performed to determine whether the target request type of the current request (e.g., "download_invoice") completely matches the optional request types defined by the strategy (e.g., "download_invoice"). The strategy ("P_Invoice_Download") is determined as the target request processing strategy for this request only if both conditions are met simultaneously (i.e., "XX" ∈ ["Xshop", "xxmall", "XXsell"] and "download_invoice" == "download_invoice"). If multiple strategies meet the conditions, a unique target can be determined using priority rules or the first-match rule.

[0109] 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 in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0110] Based on the same inventive concept, this application also provides a data processing apparatus for implementing the data processing method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more data processing apparatus embodiments provided below can be found in the limitations of the data processing method described above, and will not be repeated here.

[0111] In one exemplary embodiment, such as Figure 3 As shown, a heterogeneous system data processing device 300 is provided, comprising:

[0112] Response module 302 is used to respond to a data processing request from a source business system; the data processing request carries a target request type, business parameters, and a target system identifier of the source business system;

[0113] The determining module 304 is configured to determine the target request processing strategy corresponding to the data processing request from a plurality of pre-configured optional request processing strategies based on the target system identifier and the target request type; wherein, one optional request processing strategy corresponds to one optional request type, and the optional request processing strategy is used to define the processing logic for the optional request type initiated by at least one optional business system; the processing logic includes a first invocation rule for the source interface, a data conversion rule, and a second invocation rule for the target interface; the source interface is used to provide data to be processed; the target interface is used to perform request processing; the data conversion rule converts the data to be processed into a preset data format;

[0114] The processing module 306 is used to process the data processing request according to the target request processing strategy to obtain the request processing result corresponding to the data processing request.

[0115] In some embodiments, the processing module 306 is further configured to display a preset visual configuration interface; wherein the visual configuration interface includes authorization information configuration items, interface specification configuration items, and request processing strategy configuration items;

[0116] In response to a configuration operation on the authorization information configuration item, the authorization parameters and signature algorithm of at least one optional interface of at least one optional business system are obtained;

[0117] In response to a configuration operation on the interface specification configuration item, an interface specification for the at least one optional interface is obtained; the interface specification includes at least one of the following: interface address, request method, request header structure, request body structure, and response body structure.

[0118] In response to a configuration operation on the request processing strategy configuration item, the system identifier of the at least one optional business system, at least one optional request type, and the association between the optional request processing strategies are obtained.

[0119] The source interface defined in the target request processing strategy is called according to the business parameters and the first calling rule to obtain the data to be processed corresponding to the data processing request;

[0120] The data to be processed is converted into standard data that conforms to the preset data format according to the data conversion rules defined in the target request processing strategy.

[0121] The target interface defined in the target request processing strategy is invoked according to the standard data and the second invocation rule to obtain the request processing result.

[0122] In some embodiments, the authorization parameters and signature algorithm are stored in a preset authorization information database; the interface specification is stored in a preset interface knowledge base; the determining module 304 is further configured to:

[0123] Obtain the source interface identifier of the source interface from the target request processing strategy, and query the interface knowledge base based on the source interface identifier to obtain the source interface specification corresponding to the source interface;

[0124] The source authorization parameters and source signature algorithm corresponding to the source interface are obtained by querying the authorization information database based on the source interface identifier.

[0125] Based on the source authorization parameters, source signature algorithm, and business parameters, generate source access credentials for the source interface;

[0126] Based on the source interface specification, the business parameters, and the source access credentials, a call request for the source interface is constructed and initiated, and the data returned by the source interface is used as the data to be processed.

[0127] In some embodiments, the determining module 304 is further configured to include field mapping relationships and data cleaning rules in the data transformation rules; the field mapping relationships are used to map the data to be processed to a preset unified data model; the step of converting the data to be processed into standard data conforming to the preset data format according to the data transformation rules defined in the target request processing strategy includes:

[0128] The data transformation rules are parsed to obtain the field definitions of the unified data model and the field mapping relationships;

[0129] Based on the field mapping relationship, the value of at least one field in the data to be processed is assigned to the corresponding field in the unified data model to obtain the assigned data model;

[0130] The values ​​of each field in the assigned data model are standardized according to the data cleaning rules to obtain the standard data.

[0131] In some embodiments, the authorization parameters and signature algorithm are stored in an authorization information database; the interface specification is stored in an interface knowledge base; the determining module 304 is further configured to:

[0132] Obtain the target interface identifier of the target interface from the target request processing strategy, and query the interface knowledge base based on the target interface identifier to obtain the target interface specification corresponding to the target interface;

[0133] The target authorization parameters and target signature algorithm corresponding to the target interface are obtained by querying the authorization information database based on the target interface identifier.

[0134] Based on the target authorization parameters and the target signature algorithm, generate a target access credential for the target interface;

[0135] The standard data is converted according to the target interface specification to obtain target request data that conforms to the target request body structure corresponding to the target interface;

[0136] Based on the target request data and the target access credentials, and in accordance with the target request method in the target interface specification, a call request for the target interface is constructed and initiated, and the request processing result returned by the target interface is obtained.

[0137] In some embodiments, the determining module 304 is further configured to: combine the system identifier and the request type into a strategy selection key, and query a preset strategy routing table according to the strategy selection key to obtain the target request processing strategy; wherein, the strategy routing table records the mapping relationship between the strategy selection key and the optional processing strategy identifier;

[0138] Alternatively, if the system identifier of the data processing request belongs to one of the multiple optional business system identifiers associated with the same optional request processing strategy, and the request type matches the target request type, then the same optional request processing strategy is determined as the target request processing strategy.

[0139] Each module in the aforementioned data processing 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, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0140] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 4 As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a data processing method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0141] Those skilled in the art will understand that Figure 4 The 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.

[0142] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps included in any of the foregoing method embodiments.

[0143] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps included in any of the foregoing method embodiments.

[0144] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps included in any of the foregoing method embodiments.

[0145] 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 the relevant data must comply with relevant regulations.

[0146] 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, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0147] 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.

[0148] 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.< / amount> < / invoicenumber> < / invoicecode> < / invoicerequest>

Claims

1. A method for processing data in a heterogeneous system, characterized in that, The method includes: In response to a data processing request from a source business system; the data processing request carries the target request type, business parameters, and the target system identifier of the source business system; Based on the target system identifier and the target request type, a target request processing strategy corresponding to the data processing request is determined from a plurality of pre-configured optional request processing strategies; wherein, one optional request processing strategy corresponds to one optional request type, and the optional request processing strategy is used to define the processing logic for the optional request type initiated by at least one optional business system; the processing logic includes a first invocation rule for the source interface, a data conversion rule, and a second invocation rule for the target interface; the source interface is used to provide data to be processed; the target interface is used to perform request processing; the data conversion rule converts the data to be processed into a preset data format; The data processing request is processed according to the target request processing strategy to obtain the request processing result corresponding to the data processing request.

2. The method according to claim 1, characterized in that, Before determining the target request processing strategy corresponding to the data processing request from a plurality of pre-configured optional request processing strategies based on the system identifier and the target request type, the method includes: A preset visual configuration interface is displayed; wherein, the visual configuration interface includes authorization information configuration items, interface specification configuration items, and request processing strategy configuration items; In response to a configuration operation on the authorization information configuration item, the authorization parameters and signature algorithm of at least one optional interface of at least one optional business system are obtained; In response to a configuration operation on the interface specification configuration item, an interface specification for the at least one optional interface is obtained; the interface specification includes at least one of the following: interface address, request method, request header structure, request body structure, and response body structure. In response to a configuration operation on the request processing strategy configuration item, the system identifier of the at least one optional business system, at least one optional request type, and the association between the optional request processing strategies are obtained. The step of processing the data processing request according to the target request processing strategy to obtain the request processing result corresponding to the data processing request includes: The source interface defined in the target request processing strategy is called according to the business parameters and the first calling rule to obtain the data to be processed corresponding to the data processing request; The data to be processed is converted into standard data that conforms to the preset data format according to the data conversion rules defined in the target request processing strategy. The target interface defined in the target request processing strategy is invoked according to the standard data and the second invocation rule to obtain the request processing result.

3. The method according to claim 2, characterized in that, The authorization parameters and signature algorithm are stored in a preset authorization information database; the interface specification is stored in a preset interface knowledge base; the step of calling the source interface defined in the target request processing strategy according to the business parameters and the first calling rule to obtain the data to be processed corresponding to the data processing request includes: Obtain the source interface identifier of the source interface from the target request processing strategy, and query the interface knowledge base based on the source interface identifier to obtain the source interface specification corresponding to the source interface; The source authorization parameters and source signature algorithm corresponding to the source interface are obtained by querying the authorization information database based on the source interface identifier. Based on the source authorization parameters, source signature algorithm, and business parameters, generate source access credentials for the source interface; Based on the source interface specification, the business parameters, and the source access credentials, a call request for the source interface is constructed and initiated, and the data returned by the source interface is used as the data to be processed.

4. The method according to claim 2, characterized in that, The data transformation rules include field mapping relationships and data cleaning rules; the field mapping relationships are used to map the data to be processed to a preset unified data model; the step of converting the data to be processed into standard data conforming to the preset data format according to the data transformation rules defined in the target request processing strategy includes: The data transformation rules are parsed to obtain the field definitions of the unified data model and the field mapping relationships; Based on the field mapping relationship, the value of at least one field in the data to be processed is assigned to the corresponding field in the unified data model to obtain the assigned data model; The values ​​of each field in the assigned data model are standardized according to the data cleaning rules to obtain the standard data.

5. The method according to claim 2, characterized in that, The authorization parameters and signature algorithm are stored in an authorization information database; the interface specification is stored in an interface knowledge base; the step of calling the target interface defined in the target request processing strategy according to the standard data and the second calling rule to obtain the request processing result includes: Obtain the target interface identifier of the target interface from the target request processing strategy, and query the interface knowledge base based on the target interface identifier to obtain the target interface specification corresponding to the target interface; The target authorization parameters and target signature algorithm corresponding to the target interface are obtained by querying the authorization information database based on the target interface identifier. Based on the target authorization parameters and the target signature algorithm, generate a target access credential for the target interface; The standard data is converted according to the target interface specification to obtain target request data that conforms to the target request body structure corresponding to the target interface; Based on the target request data and the target access credentials, and in accordance with the target request method in the target interface specification, a call request for the target interface is constructed and initiated, and the request processing result returned by the target interface is obtained.

6. The method according to claim 2, characterized in that, The step of determining the target request processing strategy corresponding to the data processing request from a plurality of pre-configured optional request processing strategies based on the system identifier and the request type includes: The system identifier and the request type are combined to form a strategy selection key. The strategy selection key is used to query a preset strategy routing table to obtain the target request processing strategy. The strategy routing table records the mapping relationship between the strategy selection key and the optional processing strategy identifier. Alternatively, if the system identifier of the data processing request belongs to one of the multiple optional business system identifiers associated with the same optional request processing strategy, and the request type matches the target request type, then the same optional request processing strategy is determined as the target request processing strategy.

7. A heterogeneous system data processing device, characterized in that, The device includes: The response module is used to respond to data processing requests from the source business system; the data processing request carries the target request type, business parameters, and the target system identifier of the source business system; The determining module is configured to determine the target request processing strategy corresponding to the data processing request from a plurality of pre-configured optional request processing strategies based on the target system identifier and the target request type; wherein, each optional request processing strategy corresponds to an optional request type, and the optional request processing strategy is used to define the processing logic for the optional request type initiated by at least one optional business system; the processing logic includes a first invocation rule for the source interface, a data conversion rule, and a second invocation rule for the target interface; the source interface is used to provide data to be processed; the target interface is used to perform request processing; and the data conversion rule converts the data to be processed into a preset data format; The processing module is used to process the data processing request according to the target request processing strategy to obtain the request processing result corresponding to the data processing request.

8. 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.

9. 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.

10. 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