A system for dynamically dumping document data
By using a dynamic document data dumping system, which combines input devices, DRM reactors, and output devices, the system solves the problem of enterprises accessing external data efficiently and at low cost, enabling fast and flexible data access and reducing the R&D costs of small and medium-sized enterprises.
Patent Information
- Application Number
- CN202111343781.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2021-11-14
- Publication Date
- 2025-11-07
- Estimated Expiration
- 2041-11-14
Smart Images

Figure CN114090670B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of electric digital data processing, and particularly relates to a system for dynamically dumping document data. BACKGROUND
[0002] With the continuous development of social informatization, informatization services have gradually entered the subdivided fields, and a large number of high-quality data service providers in the subdivided fields have emerged. They have deposited a lot of very valuable data in their respective subdivided fields through continuous deepening and refining.
[0003] For a large number of resource integration enterprises, in order to provide better services for customers, it is necessary to access as much external high-quality data as possible. How to efficiently and low-cost access these data is a problem that these enterprises need to consider.
[0004] In the prior art, the most commonly used tool for accessing data is KTL tools such as Kettle. Of course, it is also a common choice to invest in development forces to realize access one by one. The former is generally operated by data engineers, and general-scale companies do not have such ability, and it is relatively cumbersome. If the access amount is not large, the cost performance is too low, and the latter adopts the coding mode, which is very inflexible, and due to high cost and long development cycle, it is generally impossible to meet the rapid development strategy of a company. SUMMARY
[0005] The present application solves the problems in the prior art and provides an optimized system for dynamically dumping document data to realize the ability of quickly and low-cost accessing external data.
[0006] The technical solution adopted by the present application is a system for dynamically dumping document data, which comprises an input device, a DRM reactor and an output device connected in sequence. A document relationship mapping protocol is provided in cooperation with the system to define the mapping relationship of document data to database data.
[0007] Preferably, the input device is extensible, and the number of input devices corresponds to the number of input sources.
[0008] Preferably, the input device is configured in a double-star wildcard mode, a multi-value matching mode, a multi-variable analysis mode or a Loop cycle configuration mode.
[0009] Preferably, the operation steps of the input device are as follows:
[0010] A.1 Load the input device related configuration;
[0011] A.2 Build an Http request object;
[0012] A.3 Request API structure;
[0013] A.4 If the request receiving is verified successfully, go to the next step, otherwise end;
[0014] A.5 Convert the request result into the data format supported by the DRM reactor, send the data to the DRM reactor, and end.
[0015] Preferably, the document relationship mapping protocol is a tree structure, including a DRM node as a root node, with first-level child matrix nodes and sibling matrix nodes cooperating with the DRM node, and the next level of child matrix nodes and sibling matrix nodes being set with any first-level child matrix nodes and sibling matrix nodes; the child matrix nodes and sibling matrix nodes of any level are one or more.
[0016] Preferably, the operation steps of the DRM reactor are:
[0017] Step B.1 Load the DRM protocol configuration;
[0018] Step B.2 Obtain the data in the preset format sent by the inputter;
[0019] Step B.3 Traverse and convert the document in a recursive and depth-first manner;
[0020] Step B.4 Output the tree-shaped data matrix to the outputter.
[0021] Preferably, the step B.3 includes the following steps:
[0022] Step B.3.1 Start the DRM object, and obtain the document data object from the document according to the document attribute configuration in the DRM;
[0023] Step B.3.2 If the document data object is a collection object, traverse the data collection and execute the conversion sub-process, then go to the next step, otherwise, go to the next step directly;
[0024] Step B.3.3 Convert the data object into a matrix row object according to the matrix cell attribute configuration in the DRM;
[0025] Step B.3.4 Determine whether there is a child matrix collection, if yes, traverse and process the child matrix DRM, and return to step B.3.1, otherwise go to the next step;
[0026] Step B.3.5 Determine whether there is a sibling matrix collection, if yes, traverse and process the sibling matrix DRM, and return to step B.3.1, otherwise end.
[0027] Preferably, the outputter is extensible, and the number of outputters corresponds to the number of storage modes.
[0028] Preferably, the operation steps of the outputter are:
[0029] Step C.1 reading in the outputter configuration;
[0030] Step C.2 judging whether the database for storage has created a connection, if not, initializing the database connection, proceeding to the next step, otherwise directly proceeding to the next step;
[0031] Step C.3 reading in the matrix data tree processed by the DRM reactor;
[0032] Step C.4 pre-processing, checking the database state and completing the creation of the database table; starting the database transaction;
[0033] Step C.5 traversing the matrix in a recursive and depth-first manner by row;
[0034] Step C.6 if an exception occurs, rolling back the database transaction, otherwise committing the database transaction, completing.
[0035] Preferably, the step C.5 comprises the following steps:
[0036] Step C.5.1 judging whether the matrix is empty, if yes, ending, otherwise proceeding to the next step;
[0037] Step C.5.2 according to the unique key in the matrix data row, finding the data in the database; if the data does not exist, proceeding to step C.5.4, otherwise judging whether to rebuild;
[0038] Step C.5.3 if rebuilding, generating a statement for deleting the database data and caching, filling in the value of the unique key in the matrix row, generating an executable statement and executing, proceeding to the next step, otherwise judging whether to update, if not updating, ending, if updating, recording the data ID value and caching the parent object, generating a statement for updating the database data and caching, filling in the value of the unique key in the matrix row, generating an executable statement and executing, proceeding to step C.5.6;
[0039] Step C.5.4 generating a statement for adding new database data and caching;
[0040] Step C.5.5 traversing all the cells in the matrix row, filling in the values into the new object, executing the new SQL, and caching the obtained record IDs to the parent object one by one;
[0041] Step C.5.6 judging whether there is a child matrix set, if yes, returning to step C.5.1, otherwise proceeding to the next step;
[0042] Step C.5.7 judging whether there is a brother matrix set, if yes, returning to step C.5.1, otherwise ending.
[0043] This invention relates to an optimized system for dynamically dumping document data, which sequentially connects an input device, a DRM reactor, and an output device to define the mapping relationship between document data and database data in accordance with the system's document relationship mapping protocol. The design principle is simple, the configuration is flexible, and the scalability is good.
[0044] This invention transforms the complex and inefficient coding access process in existing technologies into a simple and efficient configuration access process, greatly improving the efficiency of the system accessing external data services, reducing costs, and lowering the overall implementation cost. It is particularly suitable for small and medium-sized enterprises that need to control R&D costs. Attached Figure Description
[0045] Figure 1 This is a system structure diagram of the present invention;
[0046] Figure 2 This is a flowchart illustrating the operation steps of the input device of the present invention;
[0047] Figure 3 This is a schematic diagram of document relationship mapping in this invention;
[0048] Figure 4 This is a flowchart illustrating the operation steps of the DRM reactor of the present invention.
[0049] Figure 5 This is a flowchart of step B.3 in this invention;
[0050] Figure 6 This is a flowchart illustrating the operation steps of the output device of the present invention;
[0051] Figure 7 This is a flowchart of step C.5 of the present invention. Detailed Implementation
[0052] The present invention will be further described in detail below with reference to embodiments, but the scope of protection of the present invention is not limited thereto.
[0053] like Figure 1 As shown, the present invention relates to a system for dynamically dumping document data. The system includes an input device, a DRM reactor, and an output device connected in sequence. A document relationship mapping protocol is set up in conjunction with the system to define the mapping relationship between document data and database data. Meta-information related to the input device, DRM reactor, and output device is configured in the document relationship mapping protocol.
[0054] This invention is a flexible, scalable, and lightweight document data dumping system that can be used to dump external interface data into a local database table to complete data access.
[0055] In the present application, the inputter is extensible, when a new input source needs to be supported, one or more implementations of the inputter can be added to support the corresponding new input source; similarly, the outputter is also extensible, when a new storage method needs to be supported, one or more implementations of the outputter can be added to support the corresponding new storage method.
[0056] The present application works in a configurable manner, in actual application, only the configuration file needs to be modified to complete the storage process of a new document data to the database; correspondingly, the system has:
[0057] A variable resolver supports multiple variable types, including but not limited to OGNL expression, Groovy Script, double underscore (__ ) variable;
[0058] A document operation operator resolver supports pre-data processing on data documents; it is an operator set, which is executed in sequence from front to back in pipeline mode, that is, the output of the previous operator is taken as the input of the next operator;
[0059] A value operation operator resolver supports post-processing on the values of the matrix grid; it is an operator set, which is executed in sequence from front to back in pipeline mode, that is, the output of the previous operator is taken as the input of the next operator.
[0060] In the present application, the double-star wildcard mode can simplify the mapping configuration of document properties and relational database fields; of course, in the actual application process, the inputter is not only for the double-star wildcard mode.
[0061] In the present application, the tree-shaped data matrix structure is defined, which can support data dumping to data in a relational database, and further realize the reference of parent-child properties.
[0062] The inputter is extensible, and the number of the inputter corresponds to the number of input sources.
[0063] The inputter is configured in a double-star wildcard mode or a multi-value matching mode or a multi-variable resolution mode or a Loop cycle configuration mode.
[0064] As shown in Figure 2 The operation steps of the inputter are:
[0065] A.1 Load the inputter related configuration;
[0066] A.2 Build an Http request object;
[0067] A.3 Request API structure;
[0068] A.4 If the request receiving is successful, proceed to the next step, otherwise end;
[0069] A.5 Convert the request result into the data format supported by the DRM reactor, send the data to the DRM reactor, and end.
[0070] In the present application, the inputter is one of the core components of the system, responsible for obtaining data from the outside and parsing it into the data format supported by the DRM reactor, including but not limited to JSON data format.
[0071] In the present application, an embodiment of the related configuration of the inputter is given:
[0072] { -- Inputter related configuration
[0073] "type": "API", -- Inputter type, for example: API indicates querying data from interface
[0074] "loop": { -- Start loop
[0075] "variables": { -- Define variables used in loop conditions
[0076] "Total": "$.result.total", -- Custom parameter, here is the field value of the total record count in the response message
[0077] "Step": 50 -- Custom parameter
[0078] },
[0079] "condition": "[ __Total > __loopIndex * __Step ]", -- Loop condition, continue loop if condition is met, otherwise end loop, where __loopIndex is a built-in variable representing the current loop number
[0080] },
[0081] "metadata": { -- Define the meta information of each inputter
[0082] "method": "GET", -- Request type of API inputter
[0083] "url": "http: / / notreal.com / api / book / list", -- Request URL of API inputter
[0084] "documentType": "application / json", -- Data type of API inputter, such as application / json, application / xml
[0085] "variables": { --Custom variables
[0086] "key": "abc", --Custom variable, application identifier
[0087] "secret": "123", --Custom variable, application key
[0088] },
[0089] "headers": { --Request header parameters for API input method
[0090] "contentType": "application / x-www-form-urlencoded", -- Request message encoding type, such as application / x-www-form-urlencoded, application / json
[0091] "token": "{import java.security.MessageDigest;
[0092] def plainText = __key + __timestamp + __secret;
[0093] return MessageDigest.getInstance('MD5').digest(plainText.bytes).encodeHex().toString().toUpperCase();
[0094] --Dynamically generate request tokens
[0095] },
[0096] "parameters": { --Request body parameters for API input method
[0097] "key": "__key", -- Retrieves the application identifier from the custom variable and adds it to the request body parameter list.
[0098] "pageIndex": "__loopIndex", -- Use the current loop iteration as the current page.
[0099] "pageSize": "__Step" -- Number of records per page
[0100] },
[0101] "success": "[ result.status == 200 ]" -- API inputter's data request success judgment condition, such as result.status == 200, result is the interface return content
[0102] }
[0103] };
[0104] The annotation after '--' is the meaning of each attribute.
[0105] In the present application, the inputter-related configuration includes a double-star wildcard mode or a multi-value matching mode or a multi-variable parsing mode or a Loop cycle configuration mode.
[0106] The double-star wildcard mode means that all non-object and non-array type attributes under the document node are automatically mapped as field names, and the field name is the snake-shaped element name, that is, the camel type name is converted into a snake-shaped format, such as {"field": "*", "element": "*"}.
[0107] In the multi-value matching mode, the system generally supports three value types, element type (element), reference type (reference) and constant type (value); the element type (element) corresponds to the element in the data document, supports relative path search and absolute path ($. starting attribute name) search; the reference type (reference) supports external data reference in the form of (@) and parent field data reference in the form of (.); the constant type (value) is the original value; the priority of the three is in turn element type, reference type and constant type.
[0108] The multi-variable parsing mode can flexibly support value parsing and acquisition. Generally, "$." represents a document element type variable, and the value is parsed from the source document; "{...}" represents a Groovy script type variable; "[... ]" represents an OGNL expression type variable; "__xxx" represents a reference variable, such as a variable defined in loop.variables and metadata.variables and a __loopIndex built-in loop subscript variable; the metadata can reference the variables in the loop, but only non-document element type variables can be referenced because the document has not been obtained; however, the loop cannot reference the variables in the metadata.
[0109] Loop Loop configuration mode, condition must be an OGNL expression, its available variables from the loop variable, wherein __ loopIndex as a marker from 1 start increment, indicating the current loop times, the non-document element type in loop.variables, that is, the variable starting with "$." Will be passed to the meta variable metadata.variables, in the metadata.headers object can reference the variables in the loop object, such as __ loopIndex and __ Step, Groovy Script can also reference these variables.
[0110] In the application, when docking external service interface, the formats of data requests of different service providers are often different, and the interfaces of most service providers need to be signed for interface input parameters, and the signature rules are different, the inputter of the system can dynamically generate signature, and some interfaces are page query, and the inputter needs to dynamically generate page information, in view of the dynamic ability, the inputter realizes the functions of variable, script and Loop cycle.
[0111] The document relationship mapping protocol is a tree structure, comprising a DRM node as a root node, a first-level child matrix node and a sibling matrix node are arranged in cooperation with the DRM node, and a next-level child matrix node and a sibling matrix node are arranged in cooperation with any first-level child matrix node and sibling matrix node; the child matrix node and the sibling matrix node of any level are one or more.
[0112] In the application, a document relationship mapping (Document Relationship Mapping, a.k.a., DRM) protocol defines a mapping relationship from document data to database data, and is one of cores of the whole system, as a tree structure, the DRM protocol can be referred to as Figure 3 The drm node is a root node, and children and siblings are used for defining child matrix nodes and sibling matrix nodes, and are matrix sets, that is, there can be multiple child matrix nodes and sibling matrix nodes in the same layer.
[0113] In the application, for example, the structure of a matrix is as follows:
[0114] {
[0115] "document": "$.book", --document node, original data, '$.' symbol represents a document root node
[0116] "matrix": "t_book", --matrix name, book matrix
[0117] "keys": ["isbn"], -- data unique identifier
[0118] "operates": ["toJson()"], -- operation operator, can be used to manipulate the document
[0119] "cells": [ -- data grid in the matrix
[0120] {
[0121] "cell": "title", -- cell name
[0122] "element": "title", -- document element, default to the same as the cell name by default
[0123] "operates": "trim(), length(30)" -- operation operator, manipulate the document return value
[0124] },
[0125] {
[0126] "cell": "author" -- default to get data from the document by cell name
[0127] },
[0128] {
[0129] "cell": "isbn",
[0130] },
[0131] {
[0132] "cell": "create_user",
[0133] "reference": "@operator" -- reference value, the '@' symbol indicates that the reference comes from the externally passed-in parameter
[0134] },
[0135] {
[0136] "cell": "create_time",
[0137] "value": "now()" -- fixed value
[0138] }
[0139] ],
[0140] "children": [{}], -- child matrix (node) set
[0141] "siblings": [{}] -- sibling matrix (node) set
[0142] }
[0143] The meaning of each attribute is annotated after ‘--’.
[0144] As shown in Figure 4 , the operation steps of the DRM reactor are:
[0145] Step B.1 loads the DRM protocol configuration;
[0146] Step B.2 obtains the data in the preset format sent by the inputter;
[0147] Step B.3 traverses and converts the document in a recursive and depth-first manner;
[0148] As shown in Figure 5 , the step B.3 includes the following steps:
[0149] Step B.3.1 starts the DRM object, and obtains the document data object from the document according to the document attribute configuration in the DRM;
[0150] Step B.3.2 if the document data object is a collection object, then traverse the data collection, execute the conversion sub-process, and proceed to the next step, otherwise, directly proceed to the next step;
[0151] Step B.3.3 converts the data object into a matrix row object according to the matrix grid attribute configuration in the DRM;
[0152] Step B.3.4 judges whether there is a child matrix set, if yes, then traverse and process the child matrix DRM, and return to step B.3.1, otherwise, proceed to the next step;
[0153] Step B.3.5 judges whether there is a sibling matrix set, if yes, then traverse and process the sibling matrix DRM, and return to step B.3.1, otherwise, end.
[0154] Step B.4 outputs the tree-shaped data matrix to the outputter.
[0155] In the present application, the DRM reactor is responsible for converting the input data into a data matrix object, traversing and converting the document in a recursive and depth-first manner, supporting the JSON format data input object, and converting it into a tree-shaped data matrix output object.
[0156] In the present application, the conversion flow includes document operation and value operation; the document operation operator set is composed of individual operation operators, supports pipeline mode execution, each operation operator can process the input document and return the processing result; the returned processing result can be further processed by the next operation operator, and the result is returned; when all the operation operators are processed, the result is taken as the data document of the current DRM object, and DRM data conversion is performed; the value operation operator set performs post-processing on the value of the current matrix lattice, which also supports pipeline mode execution.
[0157] The output device is extensible, and the number of the output devices corresponds to the number of storage modes.
[0158] As shown in Figure 6 The operation steps of the output device are as follows:
[0159] Step C.1 reads in the output device configuration;
[0160] Step C.2 judges whether the database for storage has established a connection, if not, initializes the database connection, and proceeds to the next step, otherwise, directly proceeds to the next step;
[0161] Step C.3 reads in the matrix data tree processed by the DRM reactor;
[0162] Step C.4 pre-processes, checks the database state and completes the creation of the database table; opens the database transaction;
[0163] Step C.5 traverses the matrix in a recursive and depth-first manner by row;
[0164] As shown in Figure 7 The step C.5 includes the following steps:
[0165] Step C.5.1 judges whether the matrix is empty, if yes, ends, otherwise, proceeds to the next step;
[0166] Step C.5.2 finds the data in the database according to the unique key in the matrix data row; if the data does not exist, proceeds to step C.5.4, otherwise, judges whether to rebuild;
[0167] Step C.5.3 if rebuilding, generates a statement for deleting the database data and caches it, fills in the value of the unique key in the matrix row, generates an executable statement and executes it, proceeds to the next step, otherwise, judges whether to update, if not updating, ends, if updating, records the data ID value and caches the parent object, generates a statement for updating the database data and caches it, fills in the value of the unique key in the matrix row, generates an executable statement and executes it, proceeds to step C.5.6;
[0168] Step C.5.4 generates a statement for adding new database data and caches it;
[0169] Step C.5.5 Traverse all cells in the matrix row, inject values into the newly added object, execute the new SQL, and cache the obtained record IDs to the parent object one by one;
[0170] Step C.5.6 Determine whether there is a child matrix set, if yes, return to step C.5.1, otherwise proceed to the next step;
[0171] Step C.5.7 Determine whether there is a brother matrix set, if yes, return to step C.5.1, otherwise end.
[0172] Step C.6 If an exception occurs, roll back the database transaction, otherwise commit the database transaction, and complete.
[0173] In the present application, the output device is responsible for outputting the data matrix generated by the DRM reactor to an external storage device, such as a relational database.
[0174] In the present application, an embodiment of the related configuration of the output device is:
[0175] { --Output device related configuration
[0176] "type": "MySQL", --MySQL output device, output to MySQL storage medium
[0177] "mode": "Pararel", --Parallel mode
[0178] "workerSize": 5, --Number of worker threads, default 1
[0179] "executor": { --Thread pool configuration, default
[0180] "customize": "myExecutor", --Custom thread pool
[0181] "coreSize": "3", --Core thread number
[0182] "maxSize": "10" --Maximum number of threads
[0183] },
[0184] "metadata": { --Output device meta information configuration
[0185] "url": "jdbc:mysql: / / 127.0.0.1:3306 / warehouse", --URL configuration of MySQL output device
[0186] "username": "demo", -- connection database username of MySQL outputter
[0187] "password": "123456" -- connection database password of MySQL outputter
[0188] }
[0189] }
[0190] The meaning of each attribute is indicated by the comment after '--'.
[0191] In the present application, the outputter traverses the matrix by row in a recursive and depth-first manner, fills the values into the new object one by one while traversing all the cells in the matrix row, at this time, the individual word data of the matrix is parsed, it is judged whether the ID of the parent matrix row is referenced, if yes, the ID of the parent node is obtained from the upper level object and returned, otherwise the value of the matrix cell is directly obtained and returned.
Claims
1. A system for dynamically dumping document data, the system comprising: The system comprises an inputter, a DRM reactor and an outputter connected in sequence, and a document relationship mapping protocol is arranged in cooperation with the system to define a mapping relationship of document data to database data; The document relationship mapping protocol is a tree structure comprising a DRM node as a root node, first-level child matrix nodes and sibling matrix nodes arranged in cooperation with the DRM node, and next-level child matrix nodes and sibling matrix nodes arranged in cooperation with any first-level child matrix node and sibling matrix node; any level of child matrix node and sibling matrix node is one or more; The operation steps of the inputter are: A.1 loading inputter-related configurations; A.2 constructing an Http request object; A.3 requesting an API structure; A.4 if the request receiving is verified to be successful, proceeding to the next step, otherwise ending; A.5 converting the request result into a data format supported by the DRM reactor, sending the data to the DRM reactor, and ending; The operation steps of the DRM reactor are: Step B.1 loading DRM protocol configurations; Step B.2 obtaining data in a preset format sent by the inputter; Step B.3 traversing and converting a document in a recursive and depth-first manner; Step B.4 outputting a tree-shaped data matrix to the outputter; The operation steps of the outputter are: Step C.1 reading in outputter configurations; Step C.2 judging whether a database for storage has established a connection, if not, initializing a database connection, proceeding to the next step, otherwise directly proceeding to the next step; Step C.3 reading in a tree-shaped data matrix processed by the DRM reactor; Step C.4 preprocessing, checking a database state and completing creation of a database table; Starting a database transaction; Step C.5 traversing the matrix in a recursive and depth-first manner, including the following steps: Step C.5.1 judging whether the matrix is empty, if yes, ending, otherwise proceeding to the next step; Step C.5.2 finding data in the database according to a unique key in a matrix data row; if the data does not exist, proceeding to step C.5.4, otherwise judging whether to rebuild; Step C.5.3 if rebuilding, generating a statement for deleting database data and performing caching, filling in a value of the unique key in the matrix row, generating an executable statement and executing, proceeding to the next step, otherwise judging whether to update, if not updating, ending, if updating, recording a data ID value and caching a parent object, generating a statement for updating database data and performing caching, filling in the value of the unique key in the matrix row, generating an executable statement and executing, proceeding to step C.5.6; Step C.5.4 generating a statement for adding new database data and performing caching; Step C.5.5 traversing all fields in the matrix row, filling in the values into the new object, executing the new SQL, and caching the obtained record IDs to the parent object one by one; Step C.5.6 judging whether there is a child matrix set, if yes, returning to step C.5.1, otherwise proceeding to the next step; Step C.5.7 judging whether there is a sibling matrix set, if yes, returning to step C.5.1, otherwise ending; Step C.6 if an exception occurs, rolling back the database transaction, otherwise committing the database transaction, and completing.
2. The system for dynamically dumping document data of claim 1, wherein: The inputters are extensible, and the number of the inputters corresponds to the number of input sources.
3. The system for dynamically dumping document data according to claim 1 or 2, wherein: The inputters are configured as a double-star wildcard mode, a multi-value matching mode, a multi-variable analysis mode, or a Loop cycle configuration mode.
4. The system for dynamically dumping document data of claim 1, wherein: The step B.3 includes the following steps: Step B.3.1 starts a DRM object, and obtains a document data object from a document according to a document attribute configuration in the DRM; Step B.3.2 if the document data object is a collection object, traverses the data collection, executes a conversion sub-process, and proceeds to the next step, otherwise, directly proceeds to the next step; Step B.3.3 converts the data object into a matrix row object according to a matrix cell attribute configuration in the DRM; Step B.3.4 judges whether there is a sub-matrix collection, if yes, traverses and processes a sub-matrix DRM, returns to step B.3.1, otherwise, proceeds to the next step; Step B.3.5 judges whether there is a brother matrix collection, if yes, traverses and processes a brother matrix DRM, returns to step B.3.1, otherwise, ends.
5. The system for dynamically dumping document data of claim 1, wherein: The outputters are extensible, and the number of the outputters corresponds to the number of storage modes.
Citation Information
Patent Citations
Configurable multi-source heterogeneous data sharing system and method based on intermediate file
CN112287011A