Data exchange method and apparatus, and non-transitory storage medium

Abstract

The application discloses a data exchange method and device and a nonvolatile storage medium. The method comprises the following steps: a target node acquires configuration information corresponding to a data query request from a database in response to the data query request, wherein the configuration information is used for providing configuration information for an exchange process corresponding to the data query request; and the target node acquires to-be-exchanged data from a previous node in the exchange process according to the configuration information, and determines that the to-be-exchanged data is data corresponding to the data query request when the target node is the last node in the exchange process. By using the above scheme, the problem of complicated service interfaces and unshareable scripts in the related art is solved, and the efficiency of data aggregation and sharing is improved.

Description

Technical Field

[0001] This application relates to the field of data sharing, and more specifically, to a data exchange method and apparatus, and a non-volatile storage medium. Background Technology

[0002] Different types of business require breaking down data silos between them to achieve data aggregation, sharing, and exchange.

[0003] During the data aggregation process, the data content, format, and source vary greatly. In particular, the data sources include data from Excel files, databases, and even data provided by data service interfaces with proprietary data licensing agreements.

[0004] In the process of data sharing, it is often necessary to deal with the ever-changing data sharing requirements, and to perform various format conversions, field mapping and concatenation on the data before publishing it as an interface for use by various business parties.

[0005] In the industry, Kettle() is commonly used for data extraction, transformation, and loading when handling data integration and aggregation. However, it is cumbersome for data service interfaces with private data authorization protocols, requiring the use of script components to access these interfaces. These scripts contain a large amount of interface access code, and the scripts are independent and cannot be shared. Kettle cannot dynamically hot-deploy adjusted ETL configurations, nor can it directly expose the final data as a service interface for other departments to use.

[0006] There is currently no effective solution to the above problems. Summary of the Invention

[0007] This application provides a data exchange method and apparatus, and a non-volatile storage medium, to at least solve technical problems such as cumbersome service interfaces and inability to share scripts during data exchange.

[0008] According to one aspect of the embodiments of this application, a data exchange method is provided, comprising: a target node responding to a data query request by obtaining configuration information corresponding to the query request from a database, wherein the configuration information is used to provide configuration information for an exchange process corresponding to the query request; obtaining data to be exchanged from the previous node in the exchange process based on the configuration information, and determining that the data to be exchanged is the data corresponding to the data query request when the target node is the last node in the exchange process, wherein each node in the exchange process corresponds to a script to be executed, and the script to be executed is used to execute the function corresponding to each node.

[0009] Optionally, the data to be exchanged is obtained from the previous node in the exchange process based on the configuration information, including: obtaining the data to be exchanged pre-stored in the queue corresponding to the previous node based on the configuration information.

[0010] Optionally, before retrieving the pre-stored data to be exchanged from the queue corresponding to the previous node based on the configuration information, the method further includes: determining the queue identifier corresponding to the previous node, and determining the queue based on the queue identifier, wherein the queue identifier includes: exchange process encoding information, data identifier, node identifier, and status identifier.

[0011] Optionally, before retrieving the configuration information corresponding to the query request from the database, the method further includes: retrieving the configuration information from the cache of the target node, and triggering the retrieval of the configuration information from the database if the retrieval fails.

[0012] Optionally, the target node includes: a service node that supports access to data from multiple data sources; and a rule script node used to write data processing rules.

[0013] The rule script node is used to determine the script in the following ways: determine the initial rule script and the parsed first script encoding set; and obtain the imported second script encoding set; obtain the non-empty script content set from the first script encoding set from the database, and traverse the elements in the script content set; supplement the first script encoding set with the encoding corresponding to the elements in the second script encoding set to obtain the third script encoding set; and concatenate the content in the third script encoding set with the initial rule script to obtain the final script corresponding to the rule script node.

[0014] Optionally, before the target node responds to the data query request and retrieves the configuration information corresponding to the query request from the database, the method further includes: displaying the service interface corresponding to the query request in the target interface; and generating a query request in response to the operation on the service interface displayed in the target interface.

[0015] According to another aspect of the embodiments of this application, a data exchange apparatus is also provided, comprising: a first acquisition module, configured to acquire configuration information corresponding to a query request from a database in response to a data query request, wherein the configuration information is used to provide configuration information for an exchange process corresponding to the query request; a second acquisition module, configured to acquire data to be exchanged from the previous node in the exchange process based on the configuration information; and a determination module, configured to determine that the data to be exchanged is the data corresponding to the data query request when the target node is the last node in the exchange process, wherein each node in the exchange process corresponds to an executable script, and the executable script is used to execute the function corresponding to each node.

[0016] Optionally, the second acquisition module is also used to acquire the pre-stored data to be exchanged from the queue corresponding to the previous node based on the configuration information.

[0017] According to another aspect of the embodiments of this application, a non-volatile storage medium is also provided, wherein a program is stored in the non-volatile storage medium, and the program controls the device where the non-volatile storage medium is located to perform the above data exchange method when it runs.

[0018] According to another aspect of the embodiments of this application, an electronic device is also provided, including: a memory and a processor, wherein the processor is configured to run a program stored in the memory, wherein the program executes the above-described data exchange method during runtime.

[0019] In this embodiment, the target node responds to a data query request by retrieving configuration information corresponding to the query request from the database. This configuration information provides configuration information for the exchange process corresponding to the query request. Based on the configuration information, it retrieves the data to be exchanged from the previous node in the exchange process. When the target node is the last node in the exchange process, it determines that the data to be exchanged corresponds to the data query request. This approach solves the problems of cumbersome service interfaces and incompatible scripts in related technologies, improving the efficiency of data aggregation and sharing. Attached Figure Description

[0020] The figures illustrated herein are provided to further illustrate this application and form part of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation thereof. In the figures:

[0021] Figure 1 This is a flowchart of a data exchange method according to an embodiment of this application;

[0022] Figure 2 This is a system ER diagram according to an embodiment of this application;

[0023] Figure 3 This is a schematic diagram of an optional data flow between switching nodes according to an embodiment of this application;

[0024] Figure 4 This is a schematic diagram of an optional script syntax parsing process according to an embodiment of this application;

[0025] Figure 5 This is a schematic diagram of the node types available in an optional switching process according to an embodiment of this application;

[0026] Figure 6 This is a schematic diagram of an optional data source access interface class diagram according to an embodiment of this application;

[0027] Figure 7 This is an optional exchange process startup execution sequence diagram according to an embodiment of this application;

[0028] Figure 8 This is an optional script execution sequence diagram according to an embodiment of this application;

[0029] Figure 9 This is a structural block diagram of a data exchange device according to an embodiment of this application. Detailed Implementation

[0030] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the figures. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0031] It should be noted that the terms "first," "second," etc., in the specification, claims, and figures of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0032] To facilitate understanding of the embodiments of this application, the technical terms involved in the embodiments of this application are explained below:

[0033] Kettle is an ETL tool. ETL (Extract-Transform-Load) is a process of extracting, transforming, and loading data.

[0034] The advantages of using this application for data exchange compared to Kettle in related technologies are as follows: Scripts in the rule script component are reusable; data channel configurations are reusable, allowing existing data channel configurations to be reused directly in the rule scripts for data processing; after modifying the exchange configuration, the configuration takes effect immediately without exporting the configuration file and then uploading and deploying it; there is no need to develop a new application to wrap the data service interface for data processing and expose the new data service interface, and an interface is provided for online data service queries.

[0035] According to an embodiment of this application, a method embodiment for a data exchange method is provided. It should be noted that the steps shown in the flowchart can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0036] To solve the above problems, the specific technical solutions adopted are as follows:

[0037] Figure 1 This is a flowchart of a data exchange method according to an embodiment of this application. The method includes:

[0038] In step S102, the target node responds to the data query request by obtaining the configuration information corresponding to the query request from the database. The configuration information is used to provide configuration information for the exchange process corresponding to the query request.

[0039] Step S104: Obtain the data to be exchanged from the previous node in the exchange process according to the configuration information, and when the target node is the last node in the exchange process, determine that the data to be exchanged is the data corresponding to the data query request. Each node in the exchange process corresponds to a script to be executed, and the script to be executed is used to execute the function corresponding to each node.

[0040] In this embodiment, the target node responds to a data query request by retrieving configuration information corresponding to the query request from the database. This configuration information provides configuration information for the exchange process corresponding to the query request. Based on the configuration information, it retrieves the data to be exchanged from the previous node in the exchange process. When the target node is the last node in the exchange process, it determines that the data to be exchanged corresponds to the data query request. This approach solves the problems of cumbersome service interfaces and incompatible scripts in related technologies, improving the efficiency of data aggregation and sharing.

[0041] In some embodiments, obtaining the data to be exchanged from the previous node in the exchange process based on configuration information includes: obtaining the data to be exchanged pre-stored in the queue corresponding to the previous node based on configuration information.

[0042] In the exchange process, each exchange node has a queue to store the data that needs to be transferred from the previous node to the next node. The next node can read the data transferred from the previous node from this queue, as shown in the figure. Figure 3 As shown.

[0043] Queue middleware can be used as a runtime data storage mechanism between process nodes.

[0044] In some embodiments, before obtaining the pre-stored data to be exchanged from the queue corresponding to the previous node based on the configuration information, the method further includes: determining the queue identifier corresponding to the previous node, and determining the queue based on the queue identifier, wherein the queue identifier includes: exchange process encoding information, data identifier, node identifier and status identifier.

[0045] In some embodiments, before retrieving the configuration information corresponding to the query request from the database, the method further includes: retrieving the configuration information from the cache of the target node, and triggering the retrieval of the configuration information from the database if the retrieval fails.

[0046] In some embodiments, the target node includes: a service node that supports access to data from multiple data sources; and a rule script node for writing data processing rules.

[0047] The rule script node is used to determine the script in the following ways: determine the initial rule script and the parsed first script encoding set; obtain the imported second script encoding set; obtain the non-empty script content set from the database in the first script encoding set, and traverse the elements in the script content set; supplement the first script encoding set with the encoding corresponding to the elements in the second script encoding set to obtain the third script encoding set; and concatenate the content in the third script encoding set with the initial rule script to obtain the final script corresponding to the rule script node.

[0048] To save computing resources, duplicate script codes need to be removed from the first script code set and the second script code set before obtaining the script content set.

[0049] Optionally, before the target node responds to the data query request and retrieves the configuration information corresponding to the query request from the database, the method further includes: displaying the service interface corresponding to the query request in the target interface; and generating a query request in response to the operation on the service interface displayed in the target interface.

[0050] The following details a specific example illustrating the solution of using a database to store exchange process information:

[0051] The solution provided in this application differs from Kettle; it does not use files as the carrier of configuration data, but instead uses a database to store the configuration data. The database ER model is as follows: Figure 2As shown in the diagram, the business service flow entity is the root configuration data entity for the exchange process. It contains a draft attribute used to temporarily store exchange process configuration data that the user has not yet published. When the exchange process engine executes the exchange process, it reads the cached exchange process data. When a user publishes an exchange process, the data is first saved to the draft field, then saved to the various configuration tables in the database, and finally the corresponding exchange process cache is cleared. The next time the engine executes the business process, it cannot retrieve the data from the cache, so it reloads the configuration data from the database into the cache. This solves the problem of configuration changes taking effect immediately.

[0052] The queues between nodes are named as follows: Exchange Process Code: Data ID: Node ID: Status Identifier. The Data ID is the record ID stored in the database table for the data passed in when the exchange process starts. At the end of the exchange process, the data from the queue corresponding to the last node is retrieved and returned as the final data processed by the exchange process.

[0053] Additionally, JavaScript syntax needs to be extended to address script reuse within script components:

[0054] The exchange process supports rule script nodes, used to write complex data processing rules. The scripts use JavaScript syntax and are executed using the JDK's built-in JavaScript engine. This solution uses a custom syntax of JavaScript comment lines ` / **import rule script1,..., rule scriptn** / ` to import other rule scripts for script reuse. When executing a rule script node, additional pre-compilation and linking of the scripts are performed, recursively scanning and concatenating the scripts of the current node to produce the final script. During recursion, the scripts on the stack are recorded, and duplicate scripts are skipped to prevent circular imports. The specific script pre-compilation process is as follows. Figure 4 As shown. Rule scripts are used to provide a convenient way to run scripts, enabling configured scripts to run on specified services.

[0055] Define a unified interface specification for reading and writing data sources, supporting component-based extensions:

[0056] All nodes supported by the switching process, such as Figure 5 As shown. The service node is used to access various data sources, including Excel file reading and writing, database table reading and writing, HTTP interface access, WebServices interface access, and Dubbo service access. The rule node can use the built-in function `executeOperate` to access data sources, achieving the same effect as the service node. Both the service node and the `executeOperate` function use methods from the unified data source access interface `DataChannel` for data reading and writing.

[0057] Figure 6 This is a class diagram of DataChannel and its subclasses. To use it, you first need to call DataChannel.getInstance to create a data channel, then call connection() to establish a connection, then call process() to access data, and finally use close() to close the channel.

[0058] Add a resource directory module to register metadata for service interfaces exposed during the exchange process, enabling online interface service queries based on metadata:

[0059] In this embodiment, an HTTP interface is provided to complete an exchange process. The system adds a resource directory module to register the HTTP interface, with the interface URL being http: / / IP:port / api / edi / result / doExchange / {exchange process code}. The key point is the registration of metadata information for the interface input and output parameters. The parameter information fields are as follows:

[0060]

[0061]

[0062]

[0063] The solution provided in this application has the following advantages compared to related technologies:

[0064] The solution provided in this application offers the following advantages over Kettle for data exchange: the scripts in the rule script component are reusable; the data channel configuration is reusable, and existing data channel configurations can be directly reused in the rule script for data processing; after the exchange configuration is modified, the configuration takes effect immediately without exporting the configuration file and then uploading and deploying it; there is no need to develop a new application to wrap the access data service interface for data processing and expose the new data service interface, and an interface is provided for online data service queries.

[0065] 1. According to Figure 2The logical model is used to create a corresponding physical model. Then, based on the physical model, corresponding data tables are created in the database: t_edi_bis_serv_flow, t_edi_bis_serv_flow_line, t_edi_bis_serv_flow_node, t_edi_bis_resource, t_edi_bis_operate, t_edi_bis_config, t_edi_dictionary, t_edi_dictitonary_adapter, t_edi_mapping, t_edi_mapping_entry, t_edi_schema, t_edi_entry, t_edi_service, t_edi_service_prop, t_edi_operate.

[0066] 2. As shown in the figure Figure 7 Create classes: TransHandler, BaseCmd, StepThread, AutoDataGetThread, DataStage, based on Figure 5 Create the corresponding node classes: StartCmd, StopCmd, ChannelCmd, ForkCmd, JoinCmd, QueueCmd, MappingCmd, RuleCmd, and SchemaCmd.

[0067] When each node's BasesCmd is executed, it will start a StepThread to execute the logic of the current node and an AutoDataGetThread to retrieve queued data. Figure 5 Each specific node needs to override the initStart(), processRow(), and initFinish() methods.

[0068] StepThread execution steps:

[0069] 1) Call the node's markStart() method;

[0070] Set start time

[0071] The abstract method initStart() is called, and specific nodes implement it in their own way. Generally, it is used for logging. Some nodes need to start a data thread, AutoDataGetThrend, to retrieve data. The data passed between nodes is stored in Redis. This thread will retrieve the data processed by the previous node from Redis and put it into the queue line by line.

[0072] 2) The processRow() method of the node is executed repeatedly until no data is available or an exception occurs, at which point the processRow() method is terminated.

[0073] If the current node has an AutoDataGetThrend data thread, then retrieve the row data from the queue in the AutoDataGetThrend data thread, and then call the abstract method processRow(RowMeta) for specific processing on a specific node. The loop continues until there is no data left in the queue or an exception occurs.

[0074] Execute the markFinish() method of the node;

[0075] Set end time

[0076] If there are no exceptions, start the next node using startNextNode(); otherwise, do not continue execution.

[0077] The execution of initFinish() and initStart() is implemented in specific nodes, and is generally used for logging.

[0078] The node's status is set to "End".

[0079] 3) According to Figure 6 The following classes are created: DataChannel, DatabaseChannel, DubboGenericChannel, HttpServiceChannel, FileServiceChannel, and WebServiceChannel. DataChannel is an abstract class, and the others are its subclasses, requiring the implementation of the connection(), process(), and close() methods. In the initStart() method, the ChannelCmd class obtains the service channel operation configuration and calls the DataChannel.getInstance method to create a DataChannel instance, then calls the dataChannel's connect method to establish the service channel connection. In the doProcessRow method, the dataChannel.process method is called to retrieve data, and in the afterProcess method, the data is written to a Redis data queue for use by the next node. In the initFinish method, the dataChannel's close method is called to close the service channel connection.

[0080] according to Figure 8Create classes RuleEngineAssist, RuleEngineInstance, and RuleEngineClass. RuleEngineAssist is the script execution entry point, RuleEngineInstance is used to execute the script, and RuleEngineClass is used to pre-compile the rule script.

[0081] The compilation steps of RuleEngineClass are as follows: Obtain the JS engine; Set the code name; Scan the imported rules and assemble the complete rule script, i.e., the importRule method. The process is as follows: Figure 4 As shown; the code is explained as follows: it processes the built-in custom function name funxxx in the script, including instance methods and class methods; it processes the variables $xxxx$ wrapped by $, including data class fields and literals; it loads packages and concatenates importPackage(...);

[0082] Wrap the script rules into a function, and then call that function: function_edi_rule_wrapper_(){}; $return$ = $edi_rule_wrapper_();

[0083] Perform variable substitution on the script, including node variables, system variables, and process variables.

[0084] Create an OpenApiServiceImpl class to provide an HTTP interface to the outside world. Internally, it calls the start of the exchange engine to execute the specified exchange process. After the process is completed, it retrieves the data of the last node from DataStage and returns it.

[0085] See the database table model for exchanging process configuration data. Figure 2 ;

[0086] A queue is used as a temporary storage area for runtime data flushing between process nodes. In the exchange process, each exchange node has a queue to store the data to be transferred from the previous node to the next node. The next node can read the data transferred from the previous node from this queue.

[0087] Extend JavaScript syntax to solve script reuse within script components. Use the custom syntax of JavaScript comment lines / **import rule script1,..., rule scriptn** / to import other rule scripts and achieve script reuse;

[0088] Built-in functions for data channel access are created, which internally call the unified data source access interface DataChannel to implement the functionality. Before the script engine executes, it pre-compiles and processes the built-in functions to reuse the data channel information already configured on the interface and enable direct access.

[0089] For example, the parameter information field in the technical solution can be used to render an input and output parameter form on the page, thereby enabling online interface service queries.

[0090] This application also provides a data exchange device, such as... Figure 9 As shown, the device includes: a first acquisition module 90, used to acquire configuration information corresponding to the query request from the database in response to the data query request, wherein the configuration information is used to provide configuration information for the exchange process corresponding to the query request; a second acquisition module 92, used to acquire the data to be exchanged from the previous node in the exchange process based on the configuration information; and a determination module 94, used to determine that the data to be exchanged is the data corresponding to the data query request when the target node is the last node in the exchange process, wherein each node in the exchange process corresponds to a script to be executed, and the script to be executed is used to execute the function corresponding to each node.

[0091] Optionally, the second acquisition module 92 is also used to acquire the data to be exchanged pre-stored in the queue corresponding to the previous node based on the configuration information.

[0092] Figure 9 Optional implementations of the illustrated embodiments can be found in [reference needed]. Figure 1-8 The solutions in the corresponding embodiments will not be described again here.

[0093] This application also provides a non-volatile storage medium storing a program, wherein the program controls the device where the non-volatile storage medium is located to execute the above data exchange method when it runs.

[0094] This application also provides an electronic device, including: a memory and a processor, wherein the processor is used to run a program stored in the memory, wherein the program executes the above-described data exchange method during runtime.

[0095] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0096] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0097] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between units or modules may be electrical or other forms.

[0098] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0099] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0100] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to related technologies, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0101] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A data exchange method, characterized in that, include: The target node responds to a data query request by retrieving configuration information corresponding to the query request from the database. This configuration information is used to provide configuration information for the exchange process corresponding to the query request. The target node includes: a service node, which supports access to data from multiple data sources; and a rule script node, used to write data processing rules. The rule script node determines the script by: determining an initial rule script and a parsed first script encoding set; obtaining an imported second script encoding set; determining reusable script encodings from the initial rule script to obtain a second encoding set; retrieving a set of non-empty script content from the first script encoding set from the database and iterating through the elements in the script content set; supplementing the first script encoding set with the encodings corresponding to the elements in the second script encoding set to obtain a third script encoding set; and concatenating the content in the third script encoding set with the initial rule script to obtain the final script corresponding to the rule script node. Based on the configuration information, the data to be exchanged is obtained from the previous node in the exchange process, and when the target node is the last node in the exchange process, the data to be exchanged is determined to be the data corresponding to the data query request. Each node in the exchange process corresponds to a script to be executed, and the script to be executed is used to execute the function corresponding to each node.

2. The method according to claim 1, characterized in that, Based on the configuration information, the data to be exchanged is obtained from the previous node in the exchange process, including: Based on the configuration information, the data to be exchanged is obtained from the queue pre-stored in the queue corresponding to the previous node.

3. The method according to claim 2, characterized in that, Before retrieving the data to be exchanged pre-stored in the queue corresponding to the previous node based on the configuration information, the method further includes: Determine the queue identifier corresponding to the previous node, and determine the queue based on the queue identifier. The queue identifier includes: exchange process encoding information, data identifier, node identifier, and status identifier. The data identifier is the identifier of the data passed to the database when the exchange process starts. The status identifier is used to indicate the status of the node, which includes: start and end.

4. The method according to claim 1, characterized in that, Before retrieving the configuration information corresponding to the query request from the database, the method further includes: The configuration information is retrieved from the cache of the target node, and if the retrieval of the configuration information fails, the retrieval of the configuration information from the database is triggered.

5. The method according to claim 1, characterized in that, Before the target node responds to a data query request and retrieves the configuration information corresponding to the query request from the database, the method further includes: The service interface corresponding to the above query request is displayed on the target interface; in response to the operation of the service interface displayed on the target interface, the query request is generated.

6. A data exchange device, characterized in that, include: The first acquisition module is used by the target node to retrieve configuration information corresponding to the query request from the database in response to the data query request. The configuration information is used to provide configuration information for the exchange process corresponding to the query request. The target node includes: a service node, which supports accessing data from multiple data sources; and a rule script node, used to write data processing rules. The rule script node is used to determine the script in the following ways: determining an initial rule script and a parsed first script encoding set; and obtaining an imported second script encoding set; determining reusable script encodings from the initial rule script to obtain a second encoding set; retrieving a set of non-empty script content from the first script encoding set from the database, and iterating through the elements in the script content set; supplementing the first script encoding set with the encodings corresponding to the elements in the second script encoding set to obtain a third script encoding set; and concatenating the content in the third script encoding set with the initial rule script to obtain the final script corresponding to the rule script node. The second acquisition module is used to acquire the data to be exchanged from the previous node in the exchange process based on the configuration information; The determination module is used to determine that the data to be exchanged is the data corresponding to the data query request when the target node is the last node in the exchange process. Each node in the exchange process corresponds to a script to be executed, and the script to be executed is used to execute the function corresponding to each node.

7. A non-volatile storage medium, characterized in that, The non-volatile storage medium stores a program, wherein when the program is executed, it controls the device containing the non-volatile storage medium to perform the data exchange method according to any one of claims 1 to 5.

8. An electronic device, characterized in that, include: A memory and a processor, the processor being configured to run a program stored in the memory, wherein the program, when running, performs the data exchange method according to any one of claims 1 to 5.

Images