A universal data exchange system based on a configurable tag structure

Abstract

The application discloses a kind of general data exchange systems based on configurable label structure, it is related to the technical field of data processing and information integration, including parameter module for establishing the identity authentication mechanism of exchange party;Business document module is used to establish data structure definition based on preset exchange demand;Document logic module is used for logical analysis and code decoupling to data structure definition, generates tokenization language script code and execution instruction, constructs execution matrix, realizes the mapping of database physical field and memory logic variable;Standard adaptation module is used to compare and check the generated data content, and the verification result is fed back to the parameter module to correct the exchange rule and parameter configuration.The application implements more intelligent logic separation strategy through structured insight, cooperatively controls data reading, writing and transmission, and realizes complete decoupling of business logic and program code using nested label structure, optimizes the flexibility, universality and maintenance efficiency of data exchange.

Description

Technical Field

[0001] This invention relates to the technical field of data processing and information integration, and in particular to a general data exchange system based on a configurable tag structure. Background Technology

[0002] In the era of enterprise digital transformation, there is a significant demand for data exchange between various data carriers and information systems (such as ERP, WMS, POS, etc.). However, currently, most enterprise data is in a state of silos, with vastly different data structures, database types (such as Oracle, MySQL, etc.), and business logics across different systems. Existing data exchange methods often rely on hard-coded interface development. Whenever business logic changes or new business documents are added, the source code needs to be modified and recompiled and released, resulting in high maintenance costs and slow response times. Furthermore, based on data asset management needs, enterprises require the rapid storage and reuse of data from various media carriers, including text data and file data (audio and video files, graphic image files, office documents, PDF documents, CAD documents, 3D documents, virtual simulation models, AR / VR documents, program code and documentation, etc.), into their systems. Currently, although some ETL tools or middleware exist, they are typically black-boxes, lacking the ability to explicitly describe business logic and unable to flexibly respond to complex changes in business rules. Existing technologies cannot simultaneously solve the problems of logical decoupling, multi-database adaptation, automated environment deployment, and standard verification. In particular, in complex scenarios involving the interaction of multiple heterogeneous systems, there is a lack of a general system that can uniformly describe and execute the exchange logic.

[0003] Currently, Chinese invention patent application number CN201310716493.4 discloses a method and system for universal data exchange using XML. The method includes the following steps: describing the data structure using XML format, where the data description includes field names, field values ​​of preset lengths, and field start position information; during serialization, setting the values ​​of each field to the specified positions according to the XML description information, resulting in a binary stream of data; and during deserialization, reading the corresponding field values ​​from the binary stream using the field names according to the XML description information. This invention employs a universal design to deserialize or serialize binary data streams, simplifying data maintenance in client-server architecture systems. Even if a data structure is modified, the entire system does not need to be recompiled, and unnecessary network traffic is reduced. However, existing data exchange systems suffer from problems such as strong coupling between business logic and code, difficulty in adapting to various database types and business standards, lack of automated environment deployment capabilities, and high maintenance costs. Summary of the Invention

[0004] The technical problem solved by this invention is that existing data exchange systems suffer from strong coupling between business logic and code, difficulty in adapting to various database types and business standards, lack of automated environment deployment capabilities, and high maintenance costs.

[0005] To address the aforementioned technical problems, this invention provides the following technical solution: a universal data exchange system based on a configurable tag structure, comprising a parameter module, a business document module, a document logic module, and a standard adaptation module.

[0006] The parameter module is used to parse the end-scheme header tags of both parties, establish the identity authentication mechanism of both parties, and establish the basic operating environment for data exchange.

[0007] The business document module is used to construct a data interaction parameter network for identifying data interaction paths based on preset exchange requirements, and to establish data structure definitions based on the data interaction parameter network;

[0008] The document logic module is used to perform logical parsing and code decoupling on the data structure definition, generate markup language script code and execution instructions. The logical parsing includes identifying logical step action labels and execution code categories according to the logical step sequence number, constructing an execution matrix through action execution units, realizing the mapping between database physical fields and memory logical variables, and extracting, cleaning, transforming and transmitting exchanged data based on the execution instructions.

[0009] The standard adaptation module is used to read relevant tags from the end solution standard, build a verification rule base to compare and verify the generated data content, and feed the verification results back to the parameter module to correct the exchange rules and parameter configuration.

[0010] Preferably, the parameter module includes a header identification unit and an environment adaptation unit:

[0011] The two parties involved in the data exchange include a sending information system and a receiving information system. The sending information system is the source of the data output, including the end system owner ID, the end system owner name, and the end system name. The receiving information system is the target system entity to which the data is finally transmitted and entered into the database.

[0012] The header identification unit is used to parse the end solution title tag in the tag structure file, extract the end solution number, end solution version number, end solution standard related tags, submitter information and verification status, and establish an identity authentication mechanism between the two parties exchanging information.

[0013] The process of parsing the end-to-end scheme title tag in the tag structure file includes: using the tag structure file parser to locate the first child node under the root node, and sequentially reading the text data wrapped inside the child node. The root node is the end-to-end switching scheme, the child node is the end-to-end scheme title, and the end-to-end scheme standard related tags include the end-to-end scheme execution standard number and the end-to-end scheme execution standard name.

[0014] The submitter information includes the end-to-end solution submitter ID, end-to-end solution submitter name, and solution submitter phone number; the verification status is represented by a numeric code used to identify the legality of the solution.

[0015] Establishing an identity authentication mechanism for both parties involved in the exchange includes:

[0016] Step S001: Read the end system ID and end system owner ID from the tag structure file;

[0017] Step S002: Read the end-solution submitter ID from the tag structure file;

[0018] Step S003: Query the user permission table and system registry in the local database, and determine whether the end system ID in the tag structure file is consistent with the end system ID registered in the local system. At the same time, determine whether the end solution submitter ID has corresponding administrator privileges or data exchange privileges in the local user permission table. The authentication is successful if and only if the end system ID is consistent and the end solution submitter ID has corresponding administrator privileges or data exchange privileges.

[0019] If the end system ID is inconsistent or the end solution submitter ID does not have administrator privileges or data exchange privileges, an authentication failure exception will be thrown.

[0020] Preferably, the environment adaptation unit is used to identify the database type label of the end system, which includes Oracle, MsSQL, MySQL, and MongoDB, and to establish connection sessions with the source and target databases based on the end system owner ID, and configure the underlying driver parameters for data interaction.

[0021] The environment adaptation unit reads the end system database type and end system owner ID from the tag structure file, and uses the end system owner ID as an index to search for the database connection string corresponding to the index in the encrypted configuration file or registry of the local system. The database connection string specifically includes the database server IP address, the port number of the end system database type, the database instance name SID, and the login username and password.

[0022] Based on the type of database in the end system, dynamically load the corresponding Java database connection driver class;

[0023] Call the driver's connection method, pass in the URL, login username and password, and initiate a TCP handshake request to the database server. The URL includes the Java database connection driver class, the database server IP address, the port number of the end system's database type and the database instance name SID.

[0024] After a successful TCP handshake, a database session object is created in memory. The database session object is used to execute SQL statements and is an instance of a Java interface implementation class.

[0025] Preferably, the business document module includes a data interaction parameter network construction unit, a structure definition unit, and an additional item maintenance unit:

[0026] The data interaction parameter network construction unit is used to establish a data carrier mapping relationship set and construct a data interaction parameter network based on the data carrier mapping relationship set. The data interaction parameter network includes the physical processes of data sending, data receiving and intermediate table construction. The data interaction parameter network is used to identify the physical path and logical association of data flow between various business documents.

[0027] Establishing a data carrier mapping relationship set specifically includes:

[0028] Traverse all business document nodes in the tag structure file, extract business theme keywords from the business document names of the business document nodes, extract the database table names associated with the business documents, extract the prefix rules of the tag structure file from the prefixes of the business document names, and construct a Map structure mapping set in memory based on the dictionary combination format of business theme keywords, database table names and prefix rules.

[0029] Based on the Map structure mapping set, the document flow label and whether additional item is created label of each business document are parsed, the discrete business documents are linked into a directed network, and the specific physical process is identified. The specific physical process includes the physical process of data sending, the physical process of data receiving, and the physical process of intermediate table construction.

[0030] The physical process of identifying data transmission specifically includes:

[0031] When the document flow direction tag of the first and second documents is both sent, an outbound node is created in the initial empty network. The initial physical action of the outbound node is the initial physical action of the initial empty network.

[0032] The physical process of identifying data reception specifically includes:

[0033] When the document flow label of the third document is "received", create an inbound node in the network with outbound nodes.

[0034] The physical process of identifying intermediate tables specifically includes:

[0035] When the "Create Extra Item" tag is 1 for both the first and third documents, an environment initialization node is created in the network with outbound and inbound nodes, and the environment initialization node is placed before the outbound and inbound nodes as a prerequisite.

[0036] Acquire data interaction parameters including outbound nodes, inbound nodes, environment initialization nodes, and pointers between nodes.

[0037] Preferably, the structure definition unit is used to establish a data structure definition based on the data interaction parameter network. The data structure definition includes configuration parameters such as business document serial number, document file type, document flow label, and whether to create additional item labels. The process of establishing the data structure definition includes:

[0038] For each node in the data interaction parameter network, instantiate a BusinessDocumentConfig object in memory, extract the business document number, document file type, document flow label, and whether to create additional items label, and store the business document number, document file type, document flow label, and whether to create additional items label in the form of a dictionary into the corresponding BusinessDocumentConfig object. Output the structured data included in the BusinessDocumentConfig objects of all nodes to obtain a structured configuration list. The structured configuration list is the established data structure definition.

[0039] Preferably, the extra item maintenance unit is used to parse the creation statement tags in the tag structure file, extract the SQL statements in the CDATA data segment, and when the creation extra item tag is activated, the extra item maintenance unit automatically executes the SQL statements in the client database to form data tables, views, sequences, triggers, and stored procedures. The extra item maintenance unit specifically includes:

[0040] Iterate through the configuration list defined in the data structure, check the value of the "Create Extra Item" tag for each business document. When the value of the "Create Extra Item" tag is 0, skip the extra item maintenance unit directly and do nothing.

[0041] When the value of the "Create Extra Item" label is 1, the following actions are performed:

[0042] The tag structure file parser is used to extract the CDATA data segment. In the active state, all text in the CDATA data segment is extracted and stored as a long string in the memory variable RawSQLScript. The creation statement node in the tag structure file is located.

[0043] Using the string splitting function split(";"), the long string is split into a list of SQL statements, with the semicolon as the delimiter. The list of SQL statements is then traversed to remove whitespace, newline characters, and tab characters before and after each statement.

[0044] Request a reused database session object from the parameter module;

[0045] Set the Connection.setAutoCommit(false) class to instantiate a Statement object for sending SQL commands;

[0046] It iterates through the list of SQL statements and executes exception handling, command execution, and fault tolerance operations for each statement. Exception handling includes wrapping each execution operation in a try-catch block. Command execution includes calling `Statement.execute(sqlString)`. Fault tolerance operations include:

[0047] When executing CREATE TABLE, if an exception is found that the table already exists, the exception will be handled according to the preset strategy.

[0048] After all SQL statements in the SQL statement list have been executed, call Connection.commit() to permanently save all structural changes to the end system database, close the Statement object, and release the cursor resources of the end system database.

[0049] Preferably, the document logic module includes a logic step parsing unit and an action execution unit:

[0050] The logical step parsing unit is used to load business logic sequentially according to the logical step sequence number, identify logical step action tags and execution code categories. The logical step action tags include GET, CREATE_XML, UP_XML, and DOWN_XML, and the execution code categories include SQL and CODE. The identification includes:

[0051] The tag structure file parser traverses the DOM tree, filters out all logical blocks whose business document sequence number is equal to the current business document ID, loads the logical blocks into memory to form a list of logical nodes to be processed, reads the logical step sequence number of each logical node, and rearranges the list of logical nodes using the quicksort algorithm.

[0052] Traverse the sorted list of logical nodes in order, and perform a parsing operation on each logical node. The parsing operation steps include:

[0053] Step S201: Read the text value of the logical step action label;

[0054] If the text value of the logical step action label is GET, mark the current logical step action label as data extraction and enter the database read mode;

[0055] If the text value of the logical step action tag is CREATE_XML, mark the current logical step action tag as a file generated and call the XML builder;

[0056] If the text value of the logical step action tag is UP_XML, mark the current logical step action tag as file upload and call the FTP client;

[0057] If the text value of the logical step action tag is DOWN_XML, mark the current logical step action tag as file download and database insertion, and call the FTP downloader and SQL inserter;

[0058] Step S202: Read the text value of the execution code category label;

[0059] If the code category label value is SQL, activate the SQL interpreter, read the SQL category label (which includes query and update), obtain the judgment result of the query or update operation, and read the table / view name;

[0060] If the code category label value is CODE, the code segment interpreter is activated to parse the function call instructions in the code segment label.

[0061] Step S203: Construct a LogicStepContext object in memory. The LogicStepContext object is used to encapsulate all metadata, including logical step sequence number, logical step action label, execution code category label, table / view name, and field label.

[0062] Step S204: Based on the list of logical nodes, output an ordered executable logical queue composed of the metadata corresponding to each logical node.

[0063] Preferably, the action execution unit is used to construct an execution matrix based on the parsing result of the logic step parsing unit, and the construction of the execution matrix includes:

[0064] The action execution unit receives the current logical step from the ordered executable logical queue output by the logical step parsing unit, and extracts the original text content including the corresponding field label from the current logical step. The field label includes a mapping string in the format {table name, field name, field type, variable name}. Each mapping string is parsed and structured to construct a field variable mapping table, which is the execution matrix.

[0065] Building a field variable mapping table includes:

[0066] The mapping string is decomposed into four independent metadata items using comma separators. The metadata items include table name, field name, field type and variable name. The decomposition results are stored in a table structure in memory to form the format of an execution matrix. The rows of the execution matrix represent the physical field meaning of the decomposition results, and the columns of the execution matrix represent the meaning of the converted memory variables. The memory variables are logical variables.

[0067] The execution matrix is ​​used to map physical field values ​​in the end system database to logical variable values ​​in memory, and to reverse-map logical variable values ​​in memory to physical field values ​​in the end system database.

[0068] The action execution unit reads the logical step action label and execution code category from the logical step context;

[0069] When the execution code type is SQL:

[0070] For the SELECT query operation, when the logical step action label is GET, the SQL generator is called. It uses the correspondence between table names and field names or variable names extracted from the field variable mapping table to automatically generate an executable SELECT statement, reads data from the end system database and stores it into memory variables.

[0071] For INSERT operations, when the logical step action tag is DOWN_XML and needs to be written to the end system database, the SQL generator is called to automatically generate parameterized INSERT statements by using the table names and field names or variable names defined in the field variable mapping table, and write the memory variables to the end system database table.

[0072] When the execution code category is CODE:

[0073] Parse code segment tags to extract the names of built-in procedures in the client system;

[0074] Initialize the corresponding procedure call instructions, which include tag structure file generation and FTP transfer operations.

[0075] Preferably, the action execution unit further includes:

[0076] Executing a GET request to extract data includes:

[0077] After executing the SELECT statement and the end system database returns the result set, it iterates through each row of data in the result set and assigns the values ​​read from the physical fields in the end system database to the corresponding logical variables in memory according to the execution matrix.

[0078] The executable file generates CREATE_XML, which includes:

[0079] The action type is identified as CREATE_XML. The preset tag structure file generation process is invoked. Based on the variable names defined in the execution matrix, the corresponding logical variable values ​​are read from memory in a loop. The logical variable values ​​are filled into the nodes corresponding to the details of the tag structure file to generate an exchange file that conforms to the preset prefix rules.

[0080] The executable file download and storage DOWN_XML includes:

[0081] If the action type is identified as DOWN_XML, an FTP download operation is performed to download the tag structure file to the local machine. The downloaded tag structure file is parsed, and its logical nodes are traversed. Based on the mapping relationship in the execution matrix, the data in the logical nodes of the tag structure file is parsed and assigned to the corresponding memory variables. An INSERT statement is executed, and the parsed memory variable values ​​are used as parameters to automatically write to the database table defined in the business document module.

[0082] Preferably, the standard adapter module includes:

[0083] The tag structure file parser locates the end-solution standard related tags in the parameter module, reads the text value of the end-solution execution standard number, and loads the corresponding set of verification rules in the preset local rule repository based on the extracted end-solution execution standard number to form a verification rule library in memory.

[0084] Load all specific validation rules in the local rule repository associated with the end scheme execution standard number, and store the specific validation rules in the validation rule repository in XML structured format;

[0085] The validation rule base is imported into the in-memory rule engine for data comparison. The specific comparison steps of the rule engine include:

[0086] The standard adaptation module waits for the document logic module to complete the data generation and parsing operations, receives the reference to the exchange file generated by the action execution unit, receives the data object collection parsed from the XML file and stored in memory by the action execution unit, and obtains the output data to be verified.

[0087] Iterate through the content of the data to be validated and perform item-by-item comparison using the validation rule base:

[0088] Iterate through each data record in the dataset, and apply all the rules in the validation rule base to each data record for rule comparison. When any rule validation fails, record an error message. The error message includes: the ID of the violating data record, the name of the violating field, the description of the violated rule, and the execution standard number of the end solution.

[0089] After verification, the subsequent data exchange process is determined based on the recorded error messages. The criteria for this determination include:

[0090] If no errors are logged or only non-fatal error messages are logged, mark the result as valid.

[0091] When any fatal error message is recorded, the result is marked as a verification failure, the error message is encapsulated, and fed back to the parameter module. Upon receiving the verification failure feedback, the parameter module adjusts the subsequent data exchange process according to the control strategy, which includes:

[0092] If the sender's verification fails, prevent the document logic module from executing subsequent UP_XML instructions;

[0093] If the recipient fails verification, prevent the document logic module from executing subsequent INSERT commands;

[0094] The system outputs detailed error information to the user interface and prompts the user to modify the business logic configuration and source data in the tag structure file based on the error details.

[0095] The beneficial effects of this invention are as follows: By constructing a data interaction parameter network to locate the logical root cause and implementing an innovative logic decoupling strategy, this invention fundamentally eliminates the strong coupling between business logic and program code, while avoiding the maintenance difficulties caused by hard-coded development. This significantly improves the versatility and flexibility of the data exchange system. The system features structured insight and strong configurability, no longer relying solely on fixed interface code. Instead, it collaboratively controls data reading, environment deployment, and file transfer. In particular, by utilizing the self-descriptive characteristics of nested tag structures, it achieves rapid adaptation to heterogeneous systems, effectively responding to environmental disturbances such as database type changes and significantly shortening the interface development cycle. Combined with standard adaptation verification, the system can continuously self-optimize data quality and has strong adaptive capabilities to changes in execution standards and adjustments to business rules, ensuring the stability and compliance of long-term data interaction. This system has the advantage of strong interpretability. Its core logic is based on a textualized tag structure, and the configuration and execution processes have clear business meanings, facilitating engineers' understanding, diagnosis, and maintenance. Attached Figure Description

[0096] Figure 1 This is a basic flowchart of a general data exchange system based on a configurable tag structure, provided as an embodiment of the present invention. Detailed Implementation

[0097] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0098] Reference Figure 1 As one embodiment of the present invention, a general data exchange system based on a configurable tag structure is provided, including a parameter module, a business document module, a document logic module, and a standard adaptation module:

[0099] The parameter module is used to parse the end-scheme header tags of both parties, establish the identity authentication mechanism of both parties, and establish the basic operating environment for data exchange.

[0100] The business document module is used to construct a data interaction parameter network for identifying data interaction paths based on preset exchange requirements, and to establish data structure definitions based on the data interaction parameter network;

[0101] The document logic module is used to perform logical parsing and code decoupling of data structure definitions, generate markup language script code and execution instructions. Logical parsing includes identifying logical step action labels and execution code categories according to logical step sequence numbers, constructing an execution matrix through action execution units, realizing the mapping between database physical fields and memory logical variables, and extracting, cleaning, transforming and transmitting exchanged data based on execution instructions.

[0102] The standard adaptation module is used to read relevant tags from the end solution standard, build a verification rule base to compare and verify the generated data content, and feed the verification results back to the parameter module to correct the exchange rules and parameter configuration.

[0103] This invention constructs a closed-loop general-purpose data exchange system capable of understanding data at the structural level, intelligent configuration, multi-dimensional collaborative execution, and continuous standard adaptation, thereby achieving precise control over data exchange between heterogeneous systems. The core concept is to separate business logic from program code, enabling dynamic configuration of data interaction logic. The controlled objects are the collaborative output of three major control variables: system parameters, data structures, and logical steps.

[0104] By introducing proactive, dynamic, and precise parsing of tag structure files, and coordinating this parsing capability with traditional database interactions through a logically decoupled model, a leap from hard-coded interfaces to configurable, universal exchange is achieved. It can respond more quickly to business changes, adapt more flexibly to different databases, and more intelligently adhere to industry standards, ultimately providing the ultimate solution for high-quality, low-cost enterprise data integration.

[0105] The parameter module includes a header identifier unit and an environment adaptation unit:

[0106] The two parties involved in the data exchange include the sending information system and the receiving information system. The sending information system is the source of the data output, including the end system owner ID, end system owner name, and end system name. The receiving information system is the target system entity to which the data is finally transmitted and entered into the database.

[0107] The header identifier unit is used to parse the end solution title tag in the tag structure file, extract the end solution number, end solution version number, end solution standard related tags, submitter information and verification status, and establish an identity authentication mechanism between the two parties exchanging information.

[0108] The process of parsing the end scheme title tag in the tag structure file includes: using the tag structure file parser to locate the first child node under the root node, and sequentially reading the text data wrapped inside the child node. The root node is the end switching scheme, the child node is the end scheme title, and the end scheme standard related tags include the end scheme execution standard number and the end scheme execution standard name.

[0109] Submitter information includes end-to-end solution submitter ID, end-to-end solution submitter name, and solution submitter phone number. The verification status is represented by a numeric code that identifies the validity of the solution.

[0110] Establishing an identity authentication mechanism for both parties involved in the exchange includes:

[0111] Step S001: Read the end system ID and end system owner ID from the tag structure file;

[0112] Step S002: Read the end-solution submitter ID from the tag structure file;

[0113] Step S003: Query the user permission table and system registry in the local database, and determine whether the end system ID in the tag structure file is consistent with the end system ID registered in the local system. At the same time, determine whether the end solution submitter ID has corresponding administrator privileges or data exchange privileges in the local user permission table. The authentication is successful if and only if the end system ID is consistent and the end solution submitter ID has corresponding administrator privileges or data exchange privileges.

[0114] If the end system ID is inconsistent or the end solution submitter ID does not have administrator privileges or data exchange privileges, an authentication failure exception will be thrown.

[0115] The steps for reading the text data wrapped inside a child node include:

[0116] Step S011: Identify the data identifier label. When the value of the data identifier label is Header, it is determined that the current location is in the header information area.

[0117] Step S012: Read the text "1" within the terminal scheme number label;

[0118] Step S013: Read the text "Yunyin Publishing ERP System_V1.0_Circulation Information" from the terminal solution name label;

[0119] Step S014: Read the text 1.0 within the terminal solution version number label;

[0120] Step S015: Read the text within the timestamp of the solution submission, such as "2021-06-17 07:00:01";

[0121] The read string is stored in a Header object in memory for subsequent modules to call;

[0122] Tag structure file parsers include DOM parsers and SAX parsers;

[0123] The verification status specifically includes:

[0124] 0 indicates no verification;

[0125] 1 indicates that the verification passed;

[0126] 2 indicates that part of the verification passed;

[0127] 3 indicates that the verification failed;

[0128] 4 represents an unknown state.

[0129] The identity authentication mechanism is a permission verification logic based on matching the end system ID with the end system owner ID. It ensures that the imported tag structure file configuration scheme was created by a legitimate end system owner and that the currently running end system has the permission to execute the tag structure file configuration scheme.

[0130] The environment adaptation unit is used to identify the database type label of the end system. The end system database types include Oracle, MsSQL, MySQL, and MongoDB. It establishes connection sessions with the source and target databases based on the end system owner ID and configures the underlying driver parameters for data interaction.

[0131] The environment adaptation unit reads the end system database type and end system owner ID from the tag structure file, and uses the end system owner ID as an index to search for the corresponding database connection string in the encrypted configuration file or registry of the local system. The database connection string specifically includes the database server IP address, the port number of the end system database type, the database instance name SID, and the login username and password.

[0132] Based on the database type of the end system read, dynamically load the corresponding Java database connection driver class (e.g., oracle.jdbc.driver.OracleDriver).

[0133] Call the driver's connection method (such as DriverManager.getConnection), pass in the URL, login username and password, and initiate a TCP handshake request to the database server. The URL includes the Java database connection driver class, the database server IP address, the port number of the end system's database type, and the database instance name SID.

[0134] After a successful TCP handshake, a database session object is created in memory. The database session object is used to execute SQL statements and is an instance of a Java interface implementation class.

[0135] A database session object is not just a simple network connection, but a complex memory object that includes a network socket, transaction state, and user permission context.

[0136] In this embodiment, creating a database session object includes:

[0137] The class loader is invoked to load the Java database connection driver class, which was previously configured in the underlying driver parameters, into the method area of ​​the Java Virtual Machine (JVM). The URL, login username, and password are passed directly as parameters. The driver's connection method is called, and the underlying driver immediately initiates a network request, performing a TCP three-way handshake to the IP address and port specified in the URL. A physical TCP data transmission channel is established at the operating system level. After the TCP channel is established, the driver sends protocol packets (TNS protocol) through the TCP channel. The server corresponding to the database type of the end system verifies the account's legitimacy. If successful, a region PGA is allocated in the server's memory, and a unique Session ID is generated. After successful authentication, the driver instantiates a Connection object in the client's (i.e., this general data exchange system) heap memory using the new operator. The Connection object encapsulates the established TCP Socket reference, the Session ID returned by the server, and the transaction's auto-commit status. The Connection object is returned to the environment adaptation unit and marked as active. All subsequent CREATE TABLE or SELECT commands must be sent to the database by calling the methods of this Connection object.

[0138] This design provides the system with comprehensive environmental awareness and multi-dimensional connectivity and adaptation capabilities, which is the foundation for realizing universal data exchange.

[0139] When a new system is first connected or a solution is initialized, the parameter identification phase begins. Engineers input the end system ID, owner name, and end system database type information to automatically establish the basic operating environment of the system and identify environmental differences, such as the source end being Oracle and the target end being MySQL.

[0140] It provides high-quality, multi-dimensional environmental input and powerful multi-database adaptation capabilities for the entire intelligent switching system, enabling universal adaptation rather than customized development. Through unified label description and dynamic driver loading, it extends the control object from a single system to multiple heterogeneous databases, which is a prerequisite for realizing the leap from dedicated interfaces to universal switching.

[0141] The parameter module enables system environment awareness and universal adaptation. By parsing the end-scheme title, version, and submitter information, the system establishes an ID-based authentication mechanism to ensure the security of configuration scheme execution. More importantly, the environment adaptation unit identifies heterogeneous database types such as Oracle and MsSQL, dynamically loads drivers, and creates database session objects containing transaction states. This provides multi-dimensional connection adaptation capabilities, solving the problems of rigid traditional interfaces and difficulty in adapting to multiple databases. This is a prerequisite for achieving universal exchange across databases.

[0142] The business document module includes a data interaction parameter network construction unit, a structure definition unit, and an additional item maintenance unit:

[0143] The data interaction parameter network construction unit is used to establish a data carrier mapping relationship set and construct a data interaction parameter network based on the data carrier mapping relationship set. The data interaction parameter network includes the physical processes of data sending, data receiving and intermediate table construction. The data interaction parameter network is used to identify the physical path and logical relationship of data flow between various business documents.

[0144] Establishing a data carrier mapping relationship set specifically includes:

[0145] Traverse all business document nodes in the tag structure file, extract business theme keywords from the business document names of the business document nodes, extract the database table names associated with the business documents, extract the prefix rules of the tag structure file from the prefixes of the business document names, and construct a Map structure mapping set in memory based on the dictionary combination format of business theme keywords, database table names and prefix rules.

[0146] Business subject keywords include book product information, book inventory information, and purchase order information; database table names include GDI_T_DS and GDI_T_ORDER; prefix rules include sender code_receiver code_book product information; and the Map structure mapping set is like this: { "document 1": { "DB_Table": "GDI_T_DS", "File_Prefix": "book product information_"}, ...}. This establishes the binding relationship that book data must be stored in the GDI_T_DS table and transmitted through book product information_*.XML. The database table names associated with the business documents are derived from big data collection.

[0147] Based on the Map structure mapping set, the document flow label and whether additional item is created label of each business document are parsed, the discrete business documents are linked into a directed network, and the specific physical process is identified. The specific physical process includes the physical process of data sending, the physical process of data receiving, and the physical process of intermediate table construction.

[0148] The physical process of identifying data transmission specifically includes:

[0149] When the document flow direction tag of the first and second documents is both sent, an outbound node is created in the initial empty network. The initial physical action of the outbound node is the initial physical action of the initial empty network.

[0150] The initial pointer points to a physical action such as "Database(GDI_V_DS)->Tag Structure File Generator->FTPUpload";

[0151] The physical process of identifying data reception specifically includes:

[0152] When the document flow label of the third document is "received", create an inbound node in the network with outbound nodes.

[0153] The physical action pointed to by the inbound node is, for example, "FTP Download -> Tag Structure File Parser -> Database (GDI_T_ORDER)";

[0154] The physical process of identifying intermediate tables specifically includes:

[0155] When the "Create Extra Item" tag is 1 for both the first and third documents, an environment initialization node is created in the network with outbound and inbound nodes, and the environment initialization node is placed before the outbound and inbound nodes as a prerequisite.

[0156] The environment initialization node points to a physical action, such as "Execute SQL(CREATE TABLE...)";

[0157] Retrieve data interaction parameters including outbound nodes, inbound nodes, environment initialization nodes, and pointers between nodes. For example, "Init Node -> [Outbound Node 1, Outbound Node 2, Inbound Node 3]".

[0158] The core task of this unit is to parse the static description in the tag structure file into a dynamic, relational data network model in memory.

[0159] The structure definition unit is used to establish data structure definitions based on data interaction parameters. The data structure definition includes configuration parameters such as business document sequence number, document file type, document flow label, and whether to create additional item labels. The process of establishing the data structure definition includes:

[0160] For each node in the data interaction parameter network, instantiate a BusinessDocumentConfig object in memory, extract the business document number, document file type, document flow label, and whether to create additional items label, and store the business document number, document file type, document flow label, and whether to create additional items label in the form of a dictionary into the corresponding BusinessDocumentConfig object. Output the structured data included in the BusinessDocumentConfig objects of all nodes to obtain a structured configuration list. The structured configuration list is the completed data structure definition.

[0161] The business document sequence number determines the execution priority and index key of each node in the parameter network;

[0162] The document file type is used to configure the serializer used by subsequent logic modules. Here, we specify the tag structure file generator instead of the JSON generator.

[0163] The document flow direction label is used to set the direction flag of the data flow. If the document flow direction label is "send", the read-to-database and write-to-file mode is activated. If the document flow direction label is "receive", the read-to-file and write-to-database mode is activated.

[0164] The "Whether to create an extra item" label is a Boolean switch. If the "create extra item" label is 1, extract the CDATA SQL script from the creation statement and mark the business document as needing to perform an environment self-check before running.

[0165] If the additional item label is set to 0, the business document is marked as ready to run without any environment changes.

[0166] A structured configuration list structure is as follows:

[0167] { "ID": 1, "Type": "Tag structure file", "Direction": "SEND", "NeedInit":true, "SQL": "CREATE TABLE..."};

[0168] { "ID": 2, "Type": "Tag structure file", "Direction": "SEND", "NeedInit":false, "SQL": null};

[0169] { "ID": 3, "Type": "Tag structure file", "Direction": "RECV", "NeedInit":true, "SQL": "CREATE TABLE..."};

[0170] The task of this unit is to concretize the node attributes in the data interaction parameter network into configuration parameter objects that can be called by the program.

[0171] The Additional Items Maintenance Unit is used to parse the Create Statement tags in the tag structure file, extract the SQL statements in the CDATA data segment, and automatically execute the SQL statements in the client database when the Create Additional Items tag is activated, thus building additional data tables and views.

[0172] Document flow status is divided into sending and receiving, and document file types are divided into tag structure files and JSON;

[0173] The traditional manual table creation method has been abandoned. By constructing a tag-based description network, subsequent data structure maintenance has a clear automated execution capability. For example, book product information documents require the creation of the GDI_T_DS table and the GDI_V_DS view. This makes the system more intelligent and self-sufficient, and easier to implement when deploying new business logic. It provides structural support for subsequent logical execution, avoids exchange failures caused by missing table structures, and improves the accuracy and efficiency of deployment.

[0174] The Additional Item Maintenance Unit is used to parse the Create Statement tags in the tag structure file and extract the SQL statements from the CDATA data segment. When the Create Additional Item tag is activated, the Additional Item Maintenance Unit automatically executes the SQL statements in the client database to build the data tables, views, sequences, triggers, and stored procedures required for data exchange, thereby achieving automated deployment and maintenance of the local data environment. The Additional Item Maintenance Unit specifically includes:

[0175] Iterate through the configuration list defined in the data structure, check the value of the "Create Extra Item" tag for each business document. When the value of the "Create Extra Item" tag is 0, skip the extra item maintenance unit directly and do nothing.

[0176] When the value of the "Create Extra Item" label is 1, the following actions are performed:

[0177] The tag structure file parser is used to extract the CDATA data segment. In the active state, all text in the CDATA data segment is extracted and stored as a long string in the memory variable RawSQLScript. The creation statement node in the tag structure file is located.

[0178] Using the string splitting function split(";"), the long string is split into a list of SQL statements, with the semicolon as the delimiter. The list of SQL statements is then traversed to remove whitespace, newline characters, and tab characters before and after each statement, ensuring that each statement is a clean and executable instruction.

[0179] Since the extracted RawSQLScript may contain multiple SQL statements (separated by semicolons), the system cannot execute them all at once and preprocessing is required.

[0180] Request a reused database session object from the parameter module;

[0181] Call DBManager.getConnection() to obtain the handle of the currently active Oracle database connection.

[0182] Set the Connection.setAutoCommit(false) class to instantiate a Statement object for sending SQL commands;

[0183] To ensure the atomicity of table creation (either all succeed or all fail), a database transaction is started on the connection object.

[0184] It iterates through the list of SQL statements and executes exception handling, command execution, and fault tolerance operations for each statement. Exception handling includes wrapping each execution operation in a try-catch block. Command execution includes calling `Statement.execute(sqlString)`. Fault tolerance operations include:

[0185] When an exception is caught that the table already exists during the execution of CREATE TABLE, the exception is handled according to the preset strategy (Drop first, then Create) or a warning is recorded in the log to ensure that the process is not interrupted.

[0186] The execution of the command operation includes: executing CREATE TABLE PO.GDI_T_DS to create a table available for single books in the database, and executing CREATE OR REPLACE FORCE VIEW to create a view in the database;

[0187] After all SQL statements in the SQL statement list have been executed, call Connection.commit() to permanently save all structural changes to the end system database, close the Statement object, and release the cursor resources of the end system database.

[0188] Through the above steps, the infrastructure of tables (GDI_T_DS) and views (GDI_V_DS) required for data exchange is automatically built in the client's Oracle database without any manual intervention, realizing the automated deployment of the local data environment.

[0189] The business document module enables structured insights into data structures and automated deployment in the environment. By constructing a data interaction parameter network, the system can accurately identify the physical paths and logical relationships of data, providing structural support for subsequent logical processing. In particular, the additional item maintenance unit, by parsing the CDATA SQL scripts in the tag structure file, automatically performs operations such as table creation and view creation in the client database, abandoning the traditional manual table creation method. This greatly improves the accuracy and efficiency of new business deployment and is an important manifestation of the system's automation capabilities.

[0190] The document logic module includes a logic step parsing unit and an action execution unit:

[0191] The logical step parsing unit is used to load business logic sequentially according to the logical step number, identify logical step action tags and execution code categories. Logical step action tags include GET, CREATE_XML, UP_XML, and DOWN_XML, and execution code categories include SQL and CODE. The unit identifies the following:

[0192] The tag structure file parser traverses the DOM tree, filters out all logical blocks whose business document sequence number is equal to the current business document ID, loads the logical blocks into memory to form a list of logical nodes to be processed, reads the logical step sequence number of each logical node, and rearranges the list of logical nodes using the quicksort algorithm.

[0193] Since the node order in the tag structure file may not be strict, the list needs to be sorted in ascending order according to the logical step sequence number tag.

[0194] Traverse the sorted list of logical nodes in order, and perform a parsing operation on each logical node. The parsing operation steps include:

[0195] Step S201: Read the text value of the logical step action label;

[0196] If the text value of the logical step action label is GET, mark the current logical step action label as data extraction and enter the database read mode;

[0197] If the text value of the logical step action tag is CREATE_XML, mark the current logical step action tag as a file generated and call the XML builder;

[0198] If the text value of the logical step action tag is UP_XML, mark the current logical step action tag as file upload and call the FTP client;

[0199] If the text value of the logical step action tag is DOWN_XML, mark the current logical step action tag as file download and database insertion, and call the FTP downloader and SQL inserter;

[0200] Step S202: Read the text value of the execution code category label;

[0201] If the code category label value is SQL, activate the SQL interpreter, read the SQL category label (which includes query and update), obtain the judgment result of the query or update operation, read the table / view name (GDI_V_DS), and lock the operation object.

[0202] If the code category tag value is CODE, the code segment interpreter is activated to parse the function call instruction (XML_START_PRO) in the code segment tag.

[0203] Step S203: Construct a LogicStepContext object in memory. The LogicStepContext object is used to encapsulate all metadata, including logical step sequence number, logical step action label, execution code category label, table / view name, and field label.

[0204] Step S204: Based on the list of logical nodes, output an ordered executable logical queue composed of the metadata corresponding to each logical node.

[0205] Field labels are the raw input for the action execution unit to perform decoupling mapping analysis. They originate from the configuration of specific logical steps in the label structure file. The logical step parsing unit uses the label structure file parser to locate the business document logical node corresponding to the currently processed business document ID in the label structure file. When traversing this logical block, the parser reads the relevant field labels under each logical step. The relevant field labels contain the raw text content of the mapping string in the format {table name, field name, field type, variable name}. The logical step parsing unit encapsulates this raw text content as part of the metadata into a LogicStepContext object in memory. This context object containing field labels is output as part of an ordered executable logic queue and passed to the action execution unit, which further parses it to construct the execution matrix.

[0206] Output an ordered queue of executable logic, with a structure such as "[Step1(GET, SQL), Step2(CREATE_XML, CODE), Step3(UP_XML, CODE)]". This queue will be passed to the action execution unit to actually run.

[0207] In form, logical steps are atomic operations for data exchange. By combining the actions of GET, CREATE_XML, and UP_ tag structure files, complex exchange processes can be described using concise tag sequences.

[0208] The action execution unit is used to construct an execution matrix based on the parsing results of the logical step parsing unit. The construction of the execution matrix includes:

[0209] The action execution unit receives the current logical step from the ordered executable logical queue output by the logical step parsing unit, and extracts the original text content including the corresponding field label from the current logical step. The field label includes a mapping string in the format {table name, field name, field type, variable name}. Each mapping string is parsed and structured, and a field variable mapping table is constructed. The field variable mapping table is the execution matrix.

[0210] In this embodiment, the field labels {GDI_V_DS, BNAME, C, V_BNAME} are identified and extracted;

[0211] The field labels tell the action execution unit which physical fields the current logical step needs to process, and which logical variables these fields should correspond to in memory. The table names and field names guide the SQL generator to construct the correct SELECT or INSERT statement, and the variable names guide the data binding process.

[0212] Field tags completely separate the physical definition of a data field (table and field names in the database) from its logical definition (variable names in memory);

[0213] Developers or business configuration personnel no longer need to write underlying SQL code directly. They only need to configure the required mapping relationships in the field labels. The action execution unit is responsible for interpreting these labels and dynamically generating the underlying code, thereby effectively reducing or even eliminating the impact of hard coding.

[0214] Building a field variable mapping table includes:

[0215] The mapping string is decomposed into four independent metadata items using comma separators. The metadata items include table name, field name, field type and variable name. The decomposition results are stored in a table structure in memory to form the format of the execution matrix. The rows of the execution matrix represent the meaning of the physical fields of the decomposition results, and the columns of the execution matrix represent the meaning of the converted memory variables. The memory variables are logical variables.

[0216] The execution matrix is ​​used to map physical field values ​​in the end system database to logical variable values ​​in memory, and vice versa.

[0217] Mapping physical field values ​​in the end system database to logical variable values ​​in memory includes GET and DOWN_XML parsing;

[0218] The process of mapping logical variable values ​​in memory to physical field values ​​in the end system database includes generating INSERT statements based on CREATE_XML and DOWN_XML.

[0219] The action execution unit executes SELECT statements to read data from physical fields and assigns their values ​​to the corresponding logical variables. Then, it executes INSERT statements to write the values ​​stored in the logical variables to the corresponding physical fields. Finally, it calls built-in procedures to populate the corresponding nodes in the tag structure file with the values ​​stored in the logical variables. This stage is used to establish the correspondence between the physical meaning of data fields and the logical meaning of memory variables, i.e., to construct the execution matrix.

[0220] The action execution unit reads the logical step action label and execution code category from the logical step context;

[0221] When the execution code type is SQL:

[0222] For the SELECT query operation, when the logical step action label is GET, the SQL generator is called. It uses the correspondence between table names and field names or variable names extracted from the field variable mapping table to automatically generate an executable SELECT statement, reads data from the end system database and stores it into memory variables.

[0223] For INSERT operations, when the logical step action tag is DOWN_XML and needs to be written to the end system database, the SQL generator is called to automatically generate parameterized INSERT statements by using the table names and field names or variable names defined in the field variable mapping table, and write the memory variables to the end system database table.

[0224] When the execution code category is CODE:

[0225] Parse code segment tags to extract the names of built-in procedures in the end system (e.g., XML_XM_PRO).

[0226] Initialize the corresponding procedure call instructions, which include tag structure file generation and FTP transfer operations.

[0227] This stage transforms the logical step description into computer-executable instructions based on the action type and code category of the current logical step.

[0228] The document logic module supports logic reuse, which can encapsulate commonly used data processing logic into standardized code segments, which can be called and combined through logic step sequence numbers to realize the modular construction of complex business logic.

[0229] The action execution unit also includes:

[0230] Executing a GET request to extract data includes:

[0231] After executing the SELECT statement and the end system database returns the result set, each row of data in the result set is traversed. According to the execution matrix, the values ​​read from the physical fields in the end system database are assigned to the corresponding logical variables in memory, thus completing the conversion from database to memory.

[0232] The executable file generates CREATE_XML, which includes:

[0233] If the action type is identified as CREATE_XML, a preset tag structure file generation process (such as XML_XM_PRO) is invoked. Based on the variable names defined in the execution matrix, the corresponding logical variable values ​​are read from memory in a loop. The logical variable values ​​are then filled into the nodes corresponding to the details of the tag structure file to generate an exchange file that conforms to the preset prefix rules.

[0234] The executable file download and storage DOWN_XML includes:

[0235] The action type is identified as DOWN_XML. An FTP download operation is performed to download the tag structure file to the local machine. The downloaded tag structure file is parsed, and its logical nodes are traversed. Based on the mapping relationship in the execution matrix, the data in the logical nodes of the tag structure file is parsed and assigned to the corresponding memory variables (e.g., parsing the purchase order number node data as V_PNO). An INSERT statement is executed, and the parsed memory variable values ​​are used as parameters to automatically write them into the database table defined in the business document module, completing the file-to-database conversion.

[0236] Through the detailed steps described above, the action execution unit, acting as an interpreter, efficiently transforms the business rules defined by tags into computer-executable code, greatly improving the system's development efficiency and adaptability.

[0237] This stage involves extracting, transforming, generating, or writing data based on the initialized script and mapping table.

[0238] Technically, the action execution unit is an interpreter that transforms the business rules defined by tags into computer-executable code (SQL language and scripts), greatly simplifying the development process.

[0239] In this embodiment, logical step 1 is to retrieve new book product data, with the action type being GET, the execution code category being SQL, parsing the relevant field tags, and automatically generating a SELECT statement to read data from the view GDI_V_DS and store it in variables.

[0240] Logical step 2 is to generate a tag structure file, with the action type being CREATE_XML. This involves calling the built-in procedure XML_XM_PRO and using the variables obtained in the previous step to populate the tag structure file nodes.

[0241] Logical step 3 involves downloading the purchase order and writing the data into the table. The action type is DOWN_XML. The tag structure file is parsed, and INSERT statements are automatically generated using the mapping tables GDI_T_ORDER, PNO, C, and V_PNO.

[0242] By decoupling the action execution unit, the impact of hard coding can be effectively weakened or even eliminated, while retaining the flexibility of business logic. This process not only improves the development efficiency of the system, but also significantly enhances its maintainability and adaptability.

[0243] The document logic module only needs to manage a few independent, well-defined logical steps, making its operation exceptionally simple and efficient. The execution matrix perfectly handles the coordinated mobilization of all underlying resources to accurately read and write data.

[0244] In this way, the system achieves a fundamental shift from passive and rigid code writing to proactive and flexible configuration generation, thereby achieving stronger adaptability and response speed.

[0245] The document logic module achieves the core creative effect of this invention: complete decoupling and dynamic execution of business logic. The logic step parsing unit atomizes complex business processes into ordered logical queues (GET, CREATE_XML, DOWN_XML). The action execution unit, as the core interpreter, constructs a field variable mapping table (execution matrix) by parsing field tags, bidirectionally mapping database physical fields to memory logical variables. This mechanism enables the system to dynamically generate executable SQL statements or built-in procedure call instructions, thereby efficiently converting tag-defined business rules into computer code, effectively reducing or even eliminating the impact of hard coding, and significantly enhancing the system's maintainability and adaptability.

[0246] Standard adapter modules include:

[0247] The tag structure file parser locates the end-solution standard related tags in the parameter module, reads the text value of the end-solution execution standard number, and loads the corresponding set of verification rules in the preset local rule repository based on the extracted end-solution execution standard number to form a verification rule library in memory.

[0248] Load all specific validation rules in the local rule repository associated with the end scheme execution standard number, and store the specific validation rules in the validation rule repository in XML structured format;

[0249] Example of specific verification rules:

[0250] Data type rule: The V_ISBN field must be a 13-digit number;

[0251] The value range rule is that the field V_PRICE must be greater than 0;

[0252] The mandatory rule is that the V_BNAME field must not be empty;

[0253] The validation rule base is imported into the in-memory rule engine for data comparison. The specific comparison steps of the rule engine include:

[0254] The standard adaptation module waits for the document logic module to complete the data generation and parsing operations, receives the reference to the exchange file generated by the action execution unit, receives the data object collection parsed from the XML file and stored in memory by the action execution unit, and obtains the output data to be verified.

[0255] Iterate through the content of the data to be validated and perform item-by-item comparison using the validation rule base:

[0256] Iterate through each data record in the dataset, and apply all the rules in the validation rule base to each data record for rule comparison. When any rule validation fails, record an error message. The error message includes: the ID of the violating data record, the name of the violating field, the description of the violated rule, and the execution standard number of the end solution.

[0257] For example: for the V_ISBN field, perform rule checks on whether the length is equal to 13 and whether it is all numbers; if the value of the V_PRICE field is negative, immediately record an error message;

[0258] After verification, the subsequent data exchange process is determined based on the recorded error messages. The criteria for this determination include:

[0259] If no errors are logged or only non-fatal error messages are logged, the result is marked as valid (corresponding to validation status code "1" or "2").

[0260] When any fatal error message is recorded, the result is marked as verification failed (corresponding to verification status code "3"), the error message is encapsulated, and fed back to the parameter module. After receiving the feedback of verification failure, the parameter module adjusts the subsequent data exchange process according to the control strategy, which includes:

[0261] If the sender's verification fails, prevent the document logic module from executing subsequent UP_XML instructions;

[0262] If the recipient fails verification, prevent the document logic module from executing subsequent INSERT commands;

[0263] The user interface outputs detailed error information and prompts the user to modify the business logic configuration and source data in the tag structure file according to the error details to correct the configuration, thereby achieving real-time control of data quality and ensuring compliance.

[0264] Non-fatal error messages are those that do not affect the identification, storage, or continued execution of core business processes. Fatal error messages are those that must be corrected, otherwise data exchange will lead to business process interruption, compromised data integrity, or serious lack of legal compliance.

[0265] The validation rule base structure is a set of XML Schema Definition (XSD) files used to constrain the structure and data content of the tag structure files. After executing CREATE_XML to generate the file, the standard adaptation module calls the XML Schema validator to compare the generated tag structure file with the XSD defined in the rule base to ensure that the data structure conforms to industry standards. For content validation (such as numerical range and enumeration value), it is implemented by executing predefined business validation scripts.

[0266] Significantly improving data quality and compliance, automated verification reduces oversights and errors from manual checks; real-time feedback greatly shortens error correction time and directly improves exchange success rates. Simultaneously, unified standard adaptation helps break down industry data barriers and promotes information sharing. This feature brings direct and significant management and interoperability benefits to the system.

[0267] Nested tag structure files support the physical separation of data logic and business logic specific to the information system involved in data exchange. Data reading logic, writing logic, and field mapping relationships are stored independently in text or markup language format, allowing for adaptation to different business rules without modifying the application system source code.

[0268] The tag structure file adopts the XML language format, which includes the terminal solution title, identity authentication information (identity authentication mechanism), environment adaptation information, business document definition (data structure definition), field mapping (input to the execution matrix), and additional item maintenance (CDATA SQL script).

[0269] When data transformation is mainly completed in the SELECT statement through database functions (such as type conversion and formatting), the transformation logic can be implemented through the SQL functions in the SELECT statement dynamically generated by the action execution unit;

[0270] When complex business logic transformations (such as unit conversions and data validation) are implemented through the execution code category CODE, the built-in system procedures called by the CODE category (such as XML_XM_PRO) integrate data cleaning and transformation functions. These functions are completed by reading the field types in the execution matrix or the preset transformation function instructions.

[0271] When the logical step action label is CODE, the CODE execution category invokes standardized programs pre-compiled within the system. For example, the CODE execution category is used to call standard function interfaces pre-built into the system's core runtime environment (such as the Java Virtual Machine) for file serialization (e.g., XML_XM_PRO) and network communication (e.g., FTP clients), rather than executing user-defined, uncompiled external code. This defines its functionality and avoids unnecessary security and implementation complexity issues.

[0272] This system achieves universal adaptation and dynamic control of data exchange between heterogeneous systems through structured insights and logical decoupling strategies. The interrelationships between modules include: the parameter module is responsible for parsing tag structure files, establishing authentication between the exchanging parties, and dynamically creating database connection sessions with the source and target ends based on database types, providing the basic operating environment for the system. Subsequently, the business document module uses these environment parameters to parse business document information in the files, constructing a data interaction parameter network that identifies data flow and physical paths, and generating a structured data structure definition configuration list. Simultaneously, it automates the deployment of the data exchange environment (such as automatic table creation) through an additional item maintenance unit. The document logic module receives the configuration list, transforms it into an ordered executable logic queue, and dynamically generates and executes underlying SQL statements or built-in procedure calls through the core action execution unit, utilizing the mapping relationship (execution matrix) parsed from the field tags, to complete data extraction, cleaning, transformation, and transmission, achieving complete decoupling between business logic and program code. The standard adaptation module performs standard consistency verification on the exchange results and feeds back the verification results to the parameter module.

[0273] This invention, by constructing a universal data exchange system based on a configurable tag structure, achieves a fundamental shift from passive, rigid code writing to proactive, flexible configuration generation. Its core innovative effect lies in the complete decoupling and dynamic execution of business logic. The system abstracts complex business rules into configurable tag sequences (atomic actions such as GET and CREATE_XML) through action execution units in the document logic module, and uses field tags to construct a field variable mapping table (execution matrix), accurately mapping physical database fields to in-memory logical variables in a two-way manner. This mechanism enables the system to dynamically generate executable SQL statements or system-built-in procedure call instructions, thereby efficiently converting business rules into computer code and completely eliminating the hard-coded coupling between business logic and program code. Simultaneously, combined with the parameter module's dynamic environment adaptation to heterogeneous databases and the business document module's automated deployment capabilities for the data environment, this system greatly improves the universality, flexibility, and maintainability of data exchange, providing the ultimate solution for high-quality, low-cost enterprise data integration.

[0274] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product implemented on one or more computer-usable storage media containing computer-usable program code. The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Red-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0275] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A general data exchange system based on a configurable tag structure, characterized in that, It includes a parameter module, a business document module, a document logic module, and a standard adaptation module: The parameter module is used to parse the end-scheme header tags of both parties, establish the identity authentication mechanism of both parties, and establish the basic operating environment for data exchange. The business document module is used to construct a data interaction parameter network for identifying data interaction paths based on preset exchange requirements, and to establish data structure definitions based on the data interaction parameter network; The business document module includes a data interaction parameter network construction unit, a structure definition unit, and an additional item maintenance unit: The data interaction parameter network construction unit is used to establish a data carrier mapping relationship set and construct a data interaction parameter network based on the data carrier mapping relationship set. The data interaction parameter network includes the physical processes of data sending, data receiving and intermediate table construction. The data interaction parameter network is used to identify the physical path and logical association of data flow between various business documents. Establishing a data carrier mapping relationship set specifically includes: Iterate through all business document nodes in the tag structure file, extract business theme keywords from the business document names of the business document nodes, extract the database table names associated with the business documents, extract the prefix rules of the tag structure file from the prefixes of the business document names, and construct a Map structure mapping set in memory based on the dictionary combination format of business theme keywords, database table names and prefix rules. Based on the Map structure mapping set, the document flow label and whether additional item is created label of each business document are parsed, the discrete business documents are linked into a directed network, and the specific physical process is identified. The specific physical process includes the physical process of data sending, the physical process of data receiving, and the physical process of intermediate table construction. The document logic module is used to perform logical parsing and code decoupling on the data structure definition, generate markup language script code and execution instructions. The logical parsing includes identifying logical step action labels and execution code categories according to the logical step sequence number, constructing an execution matrix through action execution units, realizing the mapping between database physical fields and memory logical variables, and extracting, cleaning, transforming and transmitting exchanged data based on the execution instructions. The action execution unit is used to construct an execution matrix based on the parsing results of the logic step parsing unit, including: The action execution unit receives the current logical step from the ordered executable logical queue output by the logical step parsing unit, and extracts the original text content including the corresponding field label from the current logical step. The field label includes a mapping string in the format {table name, field name, field type, variable name}. Each mapping string is parsed and structured to construct a field variable mapping table, which is the execution matrix. Building a field variable mapping table includes: The mapping string is decomposed into four independent metadata items using comma separators. The metadata items include table name, field name, field type and variable name. The decomposition results are stored in a table structure in memory to form the format of an execution matrix. The rows of the execution matrix represent the physical field meaning of the decomposition results, and the columns of the execution matrix represent the meaning of the converted memory variables. The memory variables are logical variables. The execution matrix is ​​used to map physical field values ​​in the end system database to logical variable values ​​in memory, and to reverse-map logical variable values ​​in memory to physical field values ​​in the end system database. Among them, table names and field names guide the SQL generator to construct the correct SELECT or INSERT statement, while variable names guide the data binding process; The standard adaptation module is used to read relevant tags from the end solution standard, build a verification rule base to compare and verify the generated data content, and feed the verification results back to the parameter module to correct the exchange rules and parameter configuration.

2. The general data exchange system based on a configurable tag structure as described in claim 1, characterized in that, The parameter module includes a header identification unit and an environment adaptation unit: The two parties involved in the data exchange include a sending information system and a receiving information system. The sending information system is the source of the data output, including the end system owner ID, the end system owner name, and the end system name. The receiving information system is the target system entity to which the data is finally transmitted and entered into the database. The header identification unit is used to parse the end solution title tag in the tag structure file, extract the end solution number, end solution version number, end solution standard related tags, submitter information and verification status, and establish an identity authentication mechanism between the two parties exchanging information. The process of parsing the end-to-end scheme title tag in the tag structure file includes: using the tag structure file parser to locate the first child node under the root node, and sequentially reading the text data wrapped inside the child node. The root node is the end-to-end switching scheme, the child node is the end-to-end scheme title, and the end-to-end scheme standard related tags include the end-to-end scheme execution standard number and the end-to-end scheme execution standard name. The submitter information includes the end-to-end solution submitter ID, end-to-end solution submitter name, and solution submitter phone number; the verification status is represented by a numeric code that identifies the legality of the solution. Establishing an identity authentication mechanism for both parties involved in the exchange includes: Step S001: Read the end system ID and end system owner ID from the tag structure file; Step S002: Read the end-solution submitter ID from the tag structure file; Step S003: Query the user permission table and system registry in the local database, and determine whether the end system ID in the tag structure file is consistent with the end system ID registered in the local system. At the same time, determine whether the end solution submitter ID has corresponding administrator privileges or data exchange privileges in the local user permission table. The authentication is successful if and only if the end system ID is consistent and the end solution submitter ID has corresponding administrator privileges or data exchange privileges. If the end system ID is inconsistent or the end solution submitter ID does not have administrator privileges or data exchange privileges, an authentication failure exception will be thrown.

3. The general data exchange system based on a configurable tag structure as described in claim 2, characterized in that, The environment adaptation unit is used to identify the database type label of the end system. The end system database types include Oracle, MsSQL, MySQL, and MongoDB. It establishes connection sessions with the source and target databases based on the end system owner ID and configures the underlying driver parameters for data interaction. The environment adaptation unit reads the end system database type and end system owner ID from the tag structure file, and uses the end system owner ID as an index to search for the database connection string corresponding to the index in the encrypted configuration file or registry of the local system. The database connection string specifically includes the database server IP address, the port number of the end system database type, the database instance name SID, and the login username and password. Based on the type of database in the end system, dynamically load the corresponding Java database connection driver class; Call the driver's connection method, pass in the URL, login username and password, and initiate a TCP handshake request to the database server. The URL includes the Java database connection protocol header, the database server IP address, the port number of the end system's database type and the database instance name SID. After a successful TCP handshake, a database session object is created in memory. The database session object is used to execute SQL statements and is an instance of a Java interface implementation class.

4. The general data exchange system based on a configurable tag structure as described in claim 3, characterized in that, The physical process of identifying data transmission specifically includes: When the document flow direction tag of the first and second documents is both sent, an outbound node is created in the initial empty network. The initial physical action of the outbound node is the initial physical action of the initial empty network. The physical process of identifying data reception specifically includes: When the document flow label of the third document is "received", create an inbound node in the network with outbound nodes. The physical process of identifying intermediate tables specifically includes: When the "Create Extra Item" tag is 1 for both the first and third documents, an environment initialization node is created in the network with outbound and inbound nodes, and the environment initialization node is placed before the outbound and inbound nodes as a prerequisite. Acquire data interaction parameters including outbound nodes, inbound nodes, environment initialization nodes, and pointers between nodes.

5. The general data exchange system based on a configurable tag structure as described in claim 4, characterized in that, The structure definition unit is used to establish a data structure definition based on the data interaction parameter network. The data structure definition includes configuration parameters such as business document serial number, document file type, document flow label, and whether to create additional item labels. The process of establishing the data structure definition includes: For each node in the data interaction parameter network, instantiate a BusinessDocumentConfig object in memory, extract the business document number, document file type, document flow label, and whether to create additional items label, and store the business document number, document file type, document flow label, and whether to create additional items label in the form of a dictionary into the corresponding BusinessDocumentConfig object. Output the structured data included in the BusinessDocumentConfig objects of all nodes to obtain a structured configuration list. The structured configuration list is the established data structure definition.

6. The general data exchange system based on a configurable tag structure as described in claim 5, characterized in that, The additional item maintenance unit is used to parse the creation statement tags in the tag structure file and extract the SQL statements from the CDATA data segment. When the creation additional item tag is activated, the additional item maintenance unit automatically executes the SQL statements in the client database to form data tables, views, sequences, triggers, and stored procedures. The additional item maintenance unit specifically includes: Iterate through the configuration list defined in the data structure, check the value of the "Create Extra Item" tag for each business document. When the value of the "Create Extra Item" tag is 0, skip the extra item maintenance unit directly and do nothing. When the value of the "Create Extra Item" label is 1, the following actions are performed: The tag structure file parser is used to extract the CDATA data segment. In the active state, all text in the CDATA data segment is extracted and stored as a long string in the memory variable RawSQLScript. The creation statement node in the tag structure file is located. Using the string splitting function split(";"), the long string is split into a list of SQL statements with semicolons as the delimiters. The list of SQL statements is then traversed to remove whitespace, newline characters, and tab characters before and after each statement. Request a reused database session object from the parameter module; Set the Connection.setAutoCommit(false) class to instantiate a Statement object for sending SQL commands; It iterates through the list of SQL statements and executes exception handling, command execution, and fault tolerance operations for each statement. Exception handling includes wrapping each execution operation in a try-catch block. Command execution includes calling `Statement.execute(sqlString)`. Fault tolerance operations include: When executing CREATE TABLE, if an exception is found that the table already exists, the exception will be handled according to the preset strategy. After all SQL statements in the SQL statement list have been executed, call Connection.commit() to permanently save all structural changes to the end system database, close the Statement object, and release the cursor resources of the end system database.

7. The general data exchange system based on a configurable tag structure as described in claim 6, characterized in that, The document logic module includes a logic step parsing unit and an action execution unit: The logical step parsing unit is used to load business logic sequentially according to the logical step sequence number, identify logical step action tags and execution code categories. The logical step action tags include GET, CREATE_XML, UP_XML, and DOWN_XML, and the execution code categories include SQL and CODE. The identification includes: The tag structure file parser traverses the DOM tree, filters out all logical blocks whose business document sequence number is equal to the current business document ID, loads the logical blocks into memory to form a list of logical nodes to be processed, reads the logical step sequence number of each logical node, and rearranges the list of logical nodes using the quicksort algorithm. Traverse the sorted list of logical nodes in order, and perform a parsing operation on each logical node. The parsing operation steps include: Step S201: Read the text value of the logical step action label; If the text value of the logical step action label is GET, mark the current logical step action label as data extraction and enter the database read mode; If the text value of the logical step action tag is CREATE_XML, mark the current logical step action tag as a file generated and call the XML builder; If the text value of the logical step action tag is UP_XML, mark the current logical step action tag as file upload and call the FTP client; If the text value of the logical step action tag is DOWN_XML, mark the current logical step action tag as file download and database insertion, and call the FTP downloader and SQL inserter; Step S202: Read the text value of the execution code category label; If the code category label value is SQL, activate the SQL interpreter, read the SQL category label (which includes query and update), obtain the judgment result of the query or update operation, and read the table / view name; If the code category label value is CODE, the code segment interpreter is activated to parse the function call instructions in the code segment label. Step S203: Construct a LogicStepContext object in memory. The LogicStepContext object is used to encapsulate all metadata, including logical step sequence number, logical step action label, execution code category label, table / view name, and field label. Step S204: Based on the list of logical nodes, output an ordered executable logical queue composed of the metadata corresponding to each logical node.

8. The general data exchange system based on a configurable tag structure as described in claim 7, characterized in that, The action execution unit reads the logical step action label and execution code category from the logical step context; When the execution code type is SQL: For the SELECT query operation, when the logical step action label is GET, the SQL generator is called. It uses the correspondence between table names and field names or variable names extracted from the field variable mapping table to automatically generate an executable SELECT statement, reads data from the end system database and stores it into memory variables. For INSERT operations, when the logical step action tag is DOWN_XML and needs to be written to the end system database, the SQL generator is called to automatically generate parameterized INSERT statements by using the table names and field names or variable names defined in the field variable mapping table, and write the memory variables to the end system database table. When the execution code category is CODE: Parse code segment tags to extract the names of built-in procedures in the client system; Initialize the corresponding procedure call instructions, which include tag structure file generation and FTP transfer operations.

9. The general data exchange system based on a configurable tag structure as described in claim 8, characterized in that, The action execution unit further includes: Executing a GET request to extract data includes: After executing the SELECT statement and the end system database returns the result set, it iterates through each row of data in the result set and assigns the values ​​read from the physical fields in the end system database to the corresponding logical variables in memory according to the execution matrix. The executable file generates CREATE_XML, which includes: The action type is identified as CREATE_XML. The preset tag structure file generation process is invoked. Based on the variable names defined in the execution matrix, the corresponding logical variable values ​​are read from memory in a loop. The logical variable values ​​are filled into the nodes corresponding to the details of the tag structure file to generate an exchange file that conforms to the preset prefix rules. The executable file download and storage DOWN_XML includes: If the action type is identified as DOWN_XML, an FTP download operation is performed to download the tag structure file to the local machine. The downloaded tag structure file is parsed, and its logical nodes are traversed. Based on the mapping relationship in the execution matrix, the data in the logical nodes of the tag structure file is parsed and assigned to the corresponding memory variables. An INSERT statement is executed, and the parsed memory variable values ​​are used as parameters to automatically write to the database table defined in the business document module.

10. The general data exchange system based on a configurable tag structure as described in claim 9, characterized in that, The standard adapter module includes: The tag structure file parser locates the end-solution standard related tags in the parameter module, reads the text value of the end-solution execution standard number, and loads the corresponding set of verification rules in the preset local rule repository based on the extracted end-solution execution standard number to form a verification rule library in memory. Load all specific validation rules in the local rule repository associated with the end scheme execution standard number, and store the specific validation rules in the validation rule repository in XML structured format; The validation rule base is imported into the in-memory rule engine for data comparison. The specific comparison steps of the rule engine include: The standard adaptation module waits for the document logic module to complete the data generation and parsing operations, receives the reference to the exchange file generated by the action execution unit, receives the data object collection parsed from the XML file and stored in memory by the action execution unit, and obtains the output data to be verified. Iterate through the content of the data to be validated and perform item-by-item comparison using the validation rule base: Iterate through each data record in the dataset, and apply all the rules in the validation rule base to each data record for rule comparison. When any rule validation fails, record an error message. The error message includes: the ID of the violating data record, the name of the violating field, the description of the violated rule, and the execution standard number of the end solution. After verification, the subsequent data exchange process is determined based on the recorded error messages. The criteria for this determination include: If no errors are logged or only non-fatal error messages are logged, mark the result as valid. When any fatal error message is recorded, the result is marked as a verification failure, the error message is encapsulated, and fed back to the parameter module. Upon receiving the verification failure feedback, the parameter module adjusts the subsequent data exchange process according to the control strategy, which includes: If the sender's verification fails, prevent the document logic module from executing subsequent UP_XML instructions; If the recipient fails verification, prevent the document logic module from executing subsequent INSERT commands; The system outputs detailed error information to the user interface and prompts the user to modify the business logic configuration and source data in the tag structure file based on the error details.

Images