Cross-system data management method based on dynamic protocol analysis and metadata driven rendering

Abstract

The invention belongs to the technical field of cross-platform information processing, and relates to a cross-system data management method based on dynamic protocol analysis and metadata driven rendering, which comprises the following steps: a cross-system general data operation request comprises a data object type identifier and an operation parameter; querying a service registration center by using the service name identifier to obtain a target service instance; assembling through a unified data management protocol and sending a remote calling request to the target service instance; executing business data operation by using the operation parameters to generate original business data; packaging the original business data into a standard data transmission object, and returning the standard data transmission object; combining the standard data transmission object with the metadata configuration information to generate a comprehensive response packet; and driving the client to dynamically generate an interface control based on the metadata configuration information, and filling data in the standard data transmission object. The problems that cross-system data interaction is poor in flexibility, and codes need to be frequently modified for adaptation in front-end rendering are solved.

Description

Technical Field

[0001] This invention belongs to the technical field of cross-platform information processing and relates to a cross-system data management method based on dynamic protocol parsing and metadata-driven rendering. Background Technology

[0002] In the current evolution of large-scale enterprise software architecture, business systems are increasingly exhibiting heterogeneity due to their construction at different times and the selection of different technology stacks. Typical application scenarios often involve multiple functionally independent business subsystems, such as enterprise resource planning (ERP) systems, supplier relationship management (SRM) systems, and customer relationship management (CRM) systems, each maintaining its own independent database and service interfaces. To enable cross-system business flows, client applications or front-end pages typically need to interface with the specific API endpoints of each business system. In this architectural model, traditional techniques rely on front-end developers hard-coding the physical addresses, interface paths, and data parameter structures of each back-end service in the client-side code. There is a tight logical mapping between the front-end page and the back-end database table structure, and the data display often relies on static HTML templates and JavaScript scripts to bind and render each field individually.

[0003] Based on the aforementioned traditional development model, when facing complex and ever-changing business requirements, the system architecture suffers from deep-seated rigid coupling and limitations. Because the client directly relies on the physical definition of the backend service, the semantic logic of the business side and the physical addressing of the infrastructure layer are not separated. Once the backend business system undergoes service migration or expansion leading to IP address changes, or minor changes in interface parameter definitions due to adjustments in business rules, these changes will directly penetrate to the frontend access layer. In the data display stage, due to the lack of digital abstraction of the physical attributes of the data and metadata description mechanisms, the data itself only carries numerical information and loses display rule information. The frontend system cannot autonomously understand the business meaning and interaction constraints of the data and must rely on manually writing specific code logic to parse and assemble interface controls.

[0004] This tightly coupled technical architecture leads to serious code maintenance delays and version fragmentation issues in practical applications. Any change to the backend data model forces the frontend code to be modified, recompiled, and released synchronously, resulting in lengthy development and deployment cycles. Due to the lack of unified data interaction standards and dynamic protocol parsing capabilities, data interface definitions vary between different systems, making it difficult to form a standardized data governance system. This makes cross-system data aggregation and interaction logic extremely cumbersome, reducing the overall scalability of the system and its agility in responding to business changes.

[0005] In view of the above problems, the present invention aims to solve the problems in the prior art that the tight coupling between the front-end and back-end and the lack of a metadata-driven mechanism result in poor flexibility of cross-system data interaction and the need for frequent code modifications for front-end rendering to adapt. Summary of the Invention

[0006] To address the aforementioned problems, this invention provides a cross-system data management method based on dynamic protocol parsing and metadata-driven rendering.

[0007] A cross-system data management method based on dynamic protocol parsing and metadata-driven rendering includes the following steps: S1. Receive a cross-system general data operation request sent by the client. The cross-system general data operation request includes a data object type identifier and operation parameters. S2. Based on the data object type identifier, query the preset data source configuration module to obtain the service name identifier, and use the service name identifier to check the health of the target service instance with the service registry center to obtain the target service instance; S3. Based on the network address of the target service instance, and combined with the standard interface path pre-agreed between the data management platform and the downstream system, assemble the remote call request and send it. S4. Within the target service instance, the SDK package introduced by the downstream system pre-exposes standard service interfaces according to the unified data management protocol. After receiving remote call requests through these standard service interfaces, the carrying unit of the SDK package extracts the data object type identifier, calls the strategy factory module to match and execute specific strategy implementation classes, and uses operation parameters to perform business data operations to generate original business data. S5. Encapsulate the original business data into a standard data transmission object and return the standard data transmission object; S6. Receive the standard data transmission object, query the metadata management system to obtain metadata configuration information according to the data object type identifier, and merge the standard data transmission object and the metadata configuration information to generate a comprehensive response package. S7. Output a comprehensive response package to the client to drive the client to dynamically generate interface controls based on metadata configuration information and populate the data in the standard data transfer object.

[0008] A further aspect of the present invention involves receiving a cross-system general data operation request sent by a client, comprising the following steps: The client-side script responds to data operation events triggered by the user in the graphical user interface and obtains the target application identifier and data object type identifier corresponding to the current business scenario from the page context. Collect the query conditions or entity data entered by the user on the interface and organize them into structured operation parameters; The target application identifier, data object type identifier, and operation parameters are encapsulated into a JSON data structure to generate a cross-system general data operation request. By executing an HTTP POST request, the serialized cross-system common data operation request is sent to a unified service access point.

[0009] A further aspect of this invention involves querying a service registry center using the service name identifier to obtain a target service instance, including the following steps: The protocol parsing component within the core processing module obtains a list of available service instances, which contains network address information for multiple online service instances. Apply the preset load balancing strategy to select a unique instance object from the list of available service instances as the target service instance; The target service instance contains a specific IP address and port number.

[0010] A further aspect of this invention involves assembling and sending a remote call request to the target service instance via a unified data management protocol, including the following steps: Obtain the standard interface path that is uniformly defined by the data management platform and exposed by downstream systems through the SDK package; The network address information of the target service instance is concatenated with the standard interface path to generate a complete remote call URL; Create a request body data structure that conforms to the unified data management protocol specification; The data object type identifier in the cross-system general data operation request is mapped to the type encoding field in the new request body, and the operation parameters are copied into the new request body to complete the dynamic assembly of the remote call request.

[0011] A further aspect of this invention involves matching and executing a specific strategy implementation class through a strategy factory module, including the following steps: The downstream system accesses the SDK package provided by the platform. The controller of the carrying unit in the SDK package accesses the hash mapping table maintained inside the policy factory module. The hash mapping table stores the correspondence between data object type identifiers and policy instances. Use the extracted data object type identifier as the key to perform a lookup operation in the hash map table; Returns an instance of the specific strategy implementation class corresponding to the key. The specific strategy implementation class is a Java class that is automatically discovered and instantiated in advance through the classpath scanning mechanism.

[0012] A further aspect of the present invention utilizes operational parameters to perform business data operations and generate original business data, including the following steps: Deserialize the operation parameters in the remote call request into a parameter object of the type required by the specific strategy implementation class; Invoke the predefined execution method of the class instance implementing the specific strategy, and pass in the parameter object; Within the specific strategy implementation class, a database query statement is constructed based on the passed parameter object, and the query statement is executed in the local database through the database access component, or external system interfaces are called to obtain data from third-party systems and assembled into the original business data.

[0013] A further aspect of this invention involves encapsulating the original business data into a standard data transmission object and returning the standard data transmission object, including the following steps: Instantiate a standard data transfer object that conforms to a unified data model structure; Set the status code field of the standard data transfer object to the preset value indicating success, and fill it with the corresponding text message; Assign the original business data to the data carrier field of the standard data transmission object; If pagination information or additional metadata exists, it is stored in the extended attribute field of the standard data transmission object to complete the unified encapsulation of the business execution results.

[0014] A further aspect of this invention involves merging standard data transmission objects and metadata configuration information to generate a comprehensive response package, including the following steps: Create a response data structure as a composite response package; Migrate the data carrier, status code, and extended attribute fields from the standard data transfer object to the data portion of the integrated response package; The metadata configuration information obtained from the metadata management system will be incorporated into the metadata section of the comprehensive response package; Serialize the composite response packet into a JSON string.

[0015] A further aspect of this invention involves driving the client to dynamically generate UI controls based on metadata configuration information, including the following steps: The front-end client's deserialization operation retrieves metadata configuration information from the comprehensive response packet; Iterate through each metadata object in the metadata configuration information, and dynamically create the corresponding HTML element or UI control by calling the pre-built front-end component library according to its front-end component type attribute. Set the control's label text based on the business name attribute in the metadata object, and set the control's editability and visibility based on the interaction permission attribute.

[0016] A further aspect of the present invention involves filling data into a standard data transmission object, comprising the following steps: The front-end client iterates through each data record contained in the data carrier of the comprehensive response package; Based on the mapping relationship between field key values ​​and data record attribute names defined in the metadata configuration information, the value of each data record is filled into the corresponding cell of the generated table column; The table and filter controls, populated with data, are rendered on the front-end client interface.

[0017] In summary, the present invention has the following beneficial technical effects: 1. By introducing a dynamic protocol parsing and service discovery mechanism into the data management platform, physical service instances can be dynamically retrieved and located based on common business semantic identifiers. The reverse proxy mode shields the specific network details of the underlying heterogeneous system. After receiving common requests from clients, this mechanism uses pre-defined mapping relationships to convert logical data types into specific service addresses and standard interface paths, achieving complete decoupling between the client access layer and the backend physical architecture layer. This allows business continuity to be maintained without modifying any client code when backend services are migrated, nodes are scaled, or network topology changes, thus enhancing the fault tolerance and operational flexibility of the system architecture.

[0018] 2. By building service and strategy factory pattern carrier units based on SDK for middleware invocation within the target business system, and distributing requests through a unified standard interface path, specific strategy implementation classes can be dynamically matched and loaded based on data object type identifiers at a single interface entry point. This mechanism not only standardizes cross-system communication contracts but also separates protocol processing logic from specific business data operation logic at the memory level. This allows developers to extend support for new business data types simply by registering new strategy classes without intruding on the main control flow or adding additional interface endpoints, thus reducing the impact of business logic extensions on the stability of the original system.

[0019] 3. This invention utilizes a metadata-driven data semantic enrichment mechanism, which dynamically merges and encapsulates simple business data values ​​with metadata configuration information describing that data on the server side. This mechanism endows the data packets returned to the client with "self-describing" characteristics, thereby driving the front-end rendering engine to automatically generate table columns, filter controls, and form items based on metadata instructions. This achieves zero-code dynamic rendering of the front-end interface, eliminates the need for front-end releases due to minor adjustments to the back-end data structure, and shortens the delivery cycle of cross-system business functions. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. The drawings are used to provide a further understanding of the present invention.

[0021] Figure 1 A flowchart illustrating an embodiment of this application is disclosed.

[0022] Figure 2 Structural schematic diagrams of embodiments of this application are disclosed. Detailed Implementation

[0023] The following is in conjunction with the appendix Figures 1-2 A preferred description of the present invention is provided below.

[0024] See attached document Figure 1 This invention proposes a cross-system data management method based on dynamic protocol parsing and metadata-driven rendering, comprising the following steps: S1. Receive a cross-system general data operation request sent by the client. The cross-system general data operation request includes a data object type identifier and operation parameters. S2. Based on the data object type identifier, query the preset data source configuration module to obtain the service name identifier, and use the service name identifier to check the health of the target service instance with the service registry center to obtain the target service instance; S3. Based on the network address of the target service instance, and combined with the standard interface path pre-agreed between the data management platform and the downstream system, assemble the remote call request and send it. S4. Within the target service instance, the SDK package introduced by the downstream system pre-exposes standard service interfaces according to the unified data management protocol. After receiving remote call requests through these standard service interfaces, the carrying unit of the SDK package extracts the data object type identifier, calls the strategy factory module to match and execute specific strategy implementation classes, and uses operation parameters to perform business data operations to generate original business data. S5. Encapsulate the original business data into a standard data transmission object and return the standard data transmission object; S6. Receive the standard data transmission object, query the metadata management system to obtain metadata configuration information according to the data object type identifier, and merge the standard data transmission object and the metadata configuration information to generate a comprehensive response package. S7. Output a comprehensive response package to the client to drive the client to dynamically generate interface controls based on metadata configuration information and populate the data in the standard data transfer object.

[0025] In one embodiment of the present invention, step S1 includes the following steps: The system receives cross-system generic data operation requests from clients, which point to a unified service access entry point. In response to frontend interaction events, the client constructs a generic data operation request containing the target application identifier, data object type identifier, and operation parameters.

[0026] General data operation requests are sent to the core processing module of the data management platform, which serves as the unified logical entry point for all cross-system business calls, shielding the specific interface definitions of the underlying heterogeneous business systems.

[0027] Specifically, the execution entity is a client application deployed on the user's terminal device, such as a single-page application running in a web browser. When a user triggers a data operation event on the application's graphical user interface, such as clicking the "Query Supplier List" button, the JavaScript logic embedded in the client is activated. This script obtains the target application identifier and data object type identifier corresponding to the current business scenario from the page context or preset configuration. The script collects the query conditions entered by the user on the interface, such as pagination information and filter keywords, and organizes this information into a structured operation parameter object. The client encapsulates the obtained target application identifier, data object type identifier, and operation parameters into a JSON-formatted data structure, which constitutes a cross-system general data operation request.

[0028] The client sends a cross-system general data operation request, serialized into a JSON string, to a fixed, globally unique service access point, such as an endpoint with the URI / api / data / service, by executing an HTTP POST request. This endpoint is provided by the core processing module of the data management platform deployed in the server cluster. As the sole gateway for all business system calls, the core processing module receives this HTTP request, deserializes the JSON data in the request body, and converts it into a data object in memory for subsequent processing, thus completing the reception of the general data operation request.

[0029] Cross-system general data operation requests are structured data objects. Their specific data structure is defined by a predefined protocol and includes the following core fields: The target application identifier is a string field used to uniquely specify the business system carrying the target data; for example, "srm-system" represents the supplier relationship management system. The data object type identifier is a string encoding used to uniquely identify the type of data entity to be operated on; its value is uniformly assigned by data governance specifications; for example, "SupplierAuthData" represents supplier authorization data.

[0030] The operation parameters are a set of key-value pairs, usually implemented as a JSON object, with a flexible and variable internal structure, used to carry the context information required for specific operations, such as the filtering conditions {"supplierName":"ABC","page":1,"pageSize":10} during a query operation or the entity data {"name":"NewSupplier","contact":"JohnDoe"} during a creation operation.

[0031] The unified service access entry is an HTTP endpoint with a fixed address in the network. All clients in different business scenarios submit requests by accessing this single entry, which does not change with the change of the target business system. The data management middle platform is an independent backend service cluster, and the core processing module is a microservice component within this middle platform responsible for receiving, parsing, and routing all entry requests, usually implemented by combining components such as the Java Spring Boot framework and Spring Cloud Gateway.

[0032] Exemplarily, assume that a purchaser uses a browser to access the integrated procurement management platform. The purchaser needs to query the information of all suppliers in the supplier relationship management system whose names contain "Technology" and status is "Certified", and view the first page with 10 items per page. The user enters "Technology" as the filtering term for the supplier name on the interface, selects the "Certified" status, and then clicks the "Query" button, triggering the front-end application script running in the browser.

[0033] The script determines that the target application identifier for this operation is "srm-system" and the data object type identifier is "SupplierAuthData". The script collects the user's input and constructs the operation parameters as a JSON object {"supplierName":"Technology","status":"certified","page":1,"pageSize":10}. The script combines these three parts of information into a complete cross-system general data operation request, and its JSON-formatted message is {"targetAppId":"srm-system","dataTypeId":"SupplierAuthData","params":{"supplierName":"Technology","status":"certified","page":1,"pageSize":10}}.

[0034] The front-end application initiates an HTTP POST request using the fetchAPI. The target URL of the request is the unified service access point of the data management platform: https: / / api.dataplatform.com / data / service. The Content-Type header is set to application / json, and the request body is the JSON string generated above. After receiving this request, the core processing module of the data management platform parses its request body into an internal data object. This internal data object contains all the intent information of the user's query. This step is then complete.

[0035] In one embodiment of the present invention, step S2 includes the following steps: Dynamic protocol parsing is performed based on general data operation requests to decouple the binding relationship between business semantics and physical service addresses. The target application identifier or data object type identifier in the general data operation request is parsed, and the corresponding service name identifier is retrieved from the pre-configured data source module. A query is then initiated to the service registry using the service name identifier to obtain a list of currently online available service instances for the target business system. Finally, the target service instance is selected from the list of available service instances, completing the dynamic mapping from business semantic identifiers to physical service addressing information.

[0036] Specifically, after the core processing module of the data management platform successfully receives a cross-system general data operation request, it initiates a dynamic protocol parsing process. This process is executed by the protocol parsing component within the core processing module. This component extracts the value of the data object type identifier field from the deserialized cross-system general data operation request object in memory. Using the extracted data object type identifier as the query primary key, the component initiates a retrieval operation to the pre-defined data source configuration module. The data source configuration module executes a database query statement to search for a record matching this primary key in the data source mapping table, thereby obtaining the corresponding service name identifier.

[0037] After obtaining the service name identifier, the protocol parsing component uses it as a parameter to invoke the integrated service discovery client, initiating a service instance query request to the enterprise's internally deployed service registry. Upon receiving the request, the service registry retrieves its internally maintained real-time service registry, filters out all online service instances registered using the service name identifier and currently in a healthy heartbeat state, and returns a list of these instances' network address information—the list of usable service instances—to the protocol parsing component.

[0038] The protocol resolution component selects a target service instance from the list of available service instances using a preset load balancing strategy, such as round-robin or a random algorithm. The system performs a dynamic mapping from the data object type identifier at the business layer to the service instance address at the physical network layer, generating a target service instance object containing a specific IP address and port number. This object will be passed to subsequent steps to construct the remote call.

[0039] Dynamic protocol resolution refers to a series of operations that dynamically determine the physical address of the target service based on the request content during program execution, rather than hard-coding it at compile time. The data source configuration module is a persistent storage facility, typically implemented as a table in a relational database, such as a table named `data_source_mapping`. This table contains fields such as `data_type_id`, `service_name`, and `app_id`, used to establish the association between data objects, service names, and applications.

[0040] The service name identifier is the logical service name, such as "srm-service," which is unique within the service registry and registered by each business system with the service registry at startup. The service registry is an infrastructure component, such as Nacos or Eureka, that maintains a dynamic list of all microservice instances, including the service name, IP address, port number, and health status of each instance. The list of available service instances is a data structure, typically an array of objects containing service instance information, with each object containing host and port attributes. The target service instance is a unique instance object selected from the list of available services through a load balancing algorithm; it contains information about the specific network endpoint to which this request will be sent.

[0041] For example, the core processing module has received a cross-system general data operation request containing a data object type identifier of "SupplierAuthData". The protocol parsing component extracts the value of the data object type identifier, i.e., the string "SupplierAuthData". The component initiates a query to the data source configuration module, executing the SQL statement SELECT service_name FROM data_source_mapping WHERE data_type_id='SupplierAuthData'. Assuming that a record exists in the database as ('SupplierAuthData', 'srm-service', 'srm-system'), the query will successfully return the service name identifier as "srm-service".

[0042] The protocol resolution component uses a service discovery client to query the service registry for a service named "srm-service". The service registry finds two running, healthy instances and returns a list of available service instances: [{host:'192.168.1.10',port:8081},{host:'192.168.1.11',port:8081}]. The component's built-in load balancer uses a round-robin strategy; since this is the first request of the current period, the first instance in the list is selected.

[0043] The final target service instance generated in this step is a data object representing the business system service instance with IP address 192.168.1.10 and port number 8081. This object will serve as the target address for building the remote call in the next step.

[0044] In one embodiment of the present invention, step S3 includes the following steps: Building a cross-system remote call chain for a target service instance involves establishing a unified contract: the data management platform predefines a unified data management protocol, which specifies a fixed service entry address, i.e., a standard interface path, that all downstream business systems must provide, such as / api / common / execute. At this point, the data management platform does not need to know the specific business interfaces within the downstream systems, such as / user / get or / order / list, but only this standard interface path.

[0045] The core processing module uses the IP address and port of the target service instance obtained in step S2 to concatenate with the standard interface path to generate a complete remote call URL. The operation parameters and data object type identifier are encapsulated in a standard HTTP or RPC request body, and a call is initiated to the target service instance. This means that the interaction between the middle platform and downstream systems is entirely based on a loosely coupled model of "address (provided by the registration center) + interface path (defined by the protocol)".

[0046] Specifically, after completing the dynamic mapping from business semantics to physical service addresses, the remote call construction and distribution component within the core processing module of the data management platform continues execution to construct and send cross-system remote calls. This component loads a predefined unified data management protocol based on its internal configuration. This protocol specifies the standardized set of interfaces that all business systems accessing the data management platform must implement, including standard interface paths for data queries. Based on the operation type of the request, the component determines the standard interface path to be used in this call. Using the network address information of the target service instance selected in step S2 and the determined standard interface path, the component concatenates the information to form a complete remote call URL.

[0047] The component extracts the data object type identifier and operation parameters from the original cross-system general data operation request, and assembles them into a request body data structure that conforms to the unified data management protocol specification. This process completes the dynamic assembly of the remote call request. The remote call construction and distribution component uses an internal HTTP client instance to send the assembled remote call request to the generated URL via the HTTP POST method. This request reaches the target service instance through network transmission and is received and processed by the hosting unit that listens for the standard interface path and is deployed within the target business system, thus achieving cross-system distribution of the request.

[0048] Among them, the unified data management protocol is a pre-negotiated technical specification that defines the contract for interaction between the data management middle platform and each business system, including communication methods such as HTTP or RPC, interface path naming rules, request and response data model structures, and the meaning of status codes. The standard interface path is a URI endpoint that remains consistent across all accessed business systems. For example, / api / data / service / getDataObjectList is used for data query.

[0049] / api / data / service / createDataObject is used for data creation. This consistency ensures that the data management middle platform can call any business system in the same way. The remote call request is a data packet sent by the data management middle platform to a specific business system, which is an HTTP request in this embodiment. Its request body is a JSON object dynamically assembled according to the unified data management protocol, and its structure is different from the original cross-system general data operation request, only containing the information required for the target business system to execute the operation. The hosting unit is a software development kit or general service component pre-set within each target business system, responsible for implementing the listening of the standard interface path and serving as the unified entry point for the data management middle platform request within the business system.

[0050] Exemplarily, the remote call construction and distribution component has obtained the target service instance as {host: '192.168.1.10', port: 8081}, and the original cross-system general data operation request, with its dataTypeId being "SupplierAuthData" and params being {"supplierName": "Technology", "status": "certified", "page": 1, "pageSize": 10}. The component identifies the standard interface path corresponding to this query operation as / api / data / service / getDataObjectList according to the internally configured unified data management protocol.

[0051] The component concatenates the address information of the target service instance with the standard interface path to generate a request URL of http: / / 192.168.1.10:8081 / api / data / service / getDataObjectList. The component starts to assemble the HTTP request body, creates a new JSON object, assigns the value of the dataTypeId field "SupplierAuthData" in the original request to a new field named dataObjectTypeCode, and copies the entire params object in the original request. The request body of the assembled remote call request is {"dataObjectTypeCode":"SupplierAuthData","params":{"supplierName":"Technology","status":"certified","page":1,"pageSize":10}}.

[0052] The component uses an HTTP client library, such as Apache HttpClient, to initiate an HTTP POST request to http: / / 192.168.1.10:8081 / api / data / service / getDataObjectList and sends the above JSON string as the request body, triggering the corresponding processing logic within the target business system.

[0053] In one embodiment of the present invention, step S4 includes the following steps: The ecological logic distribution is triggered through the policy factory mechanism within the target business system to perform specific business data operations. The request is processed within the target business system. Before this step, there is a service startup and registration phase: The downstream system introduces the SDK package provided by the platform. When the system starts, the bearing unit of the SDK package will automatically register the standard interface path, such as / api / common / execute, to the Web container of the downstream system according to the unified data management protocol, exposing the service capabilities externally.

[0054] When the remote call request arrives at the target service instance, it is uniformly received by this standard service interface exposed by the SDK. The bearing unit of the SDK serves as the traffic entry point, intercepts the request and analyzes the request body, extracting the "data object type identifier" therein. The controller inside the SDK calls the policy factory module. The policy factory module maintains a mapping table. This mapping table, at startup, establishes a correspondence between the "data object type identifier" and the "specific policy implementation class" by scanning specific annotations.

[0055] Based on the extracted identifier, the SDK looks up and instantiates the corresponding specific strategy implementation class, such as SupplierQueryStrategy, in the mapping table, and calls its execution method. The specific strategy implementation class is the actual executor of the business logic. Using the passed operation parameters, it calls the local DAO layer or external interface to perform specific business data operations and finally generate the original business data.

[0056] Through the above mechanism, the SDK not only undertakes the responsibility of policy routing, but its more core responsibility is to shield the heterogeneity of downstream systems and realize "blind calls" from the middle platform to downstream systems by automatically exposing standard interfaces.

[0057] After receiving a remote call request, the carrier unit within the target business system extracts the data object type identifier; it calls the strategy factory module integrated with the carrier unit, using the data object type identifier as the index key, to match a pre-registered specific strategy implementation class in memory; it loads the corresponding business logic using the matched specific strategy implementation class, and performs CRUD operations on the target business system's local database or external resources using operation parameters; the carrier unit automatically scans and registers each strategy implementation class through the introduced SDK components, achieving decoupling between the protocol layer and the business logic layer.

[0058] Specifically, when a remote call request arrives at the target service instance, its internally deployed transport unit begins executing the ecosystem logic distribution. This transport unit, as an SDK component implemented based on the Java Spring Boot framework, has a built-in standard REST controller. This controller listens for standard interface paths. Upon receiving an HTTP request, it first deserializes the JSON data in the request body into an internal data transfer object. The controller then extracts the data object type identifier field from this object. Next, the controller calls the strategy factory module integrated with it. This module, during system startup, automatically scans and registers all strategy implementation classes marked with specific annotations via dependency injection, storing them in a hash map with the data object type identifier as the key and the strategy instance as the value.

[0059] The controller uses the extracted data object type identifier as the key to look up and retrieve the corresponding instance of the specific strategy implementation class from the hash map. After retrieving the instance, the controller further deserializes the operation parameters in the remote call request into a parameter object of the type required by the strategy implementation class, and calls a predefined method of the instance, such as the executeSearch method, passing in the parameter object. The specific strategy implementation class encapsulates the specific business logic for this data type, constructs a database query statement based on the passed parameters, and executes the SQL query on the target business system's local database through its injected database access component, completing CRUD operations and ultimately obtaining the original business data results.

[0060] Among them, the hosting unit is a standard software development kit integrated into each business system, namely the SDK, which provides unified request reception and distribution capabilities, enabling the business system to not care about the protocol docking details with the data management middleware platform. The policy factory module is one of the core components of this SDK. It implements the policy design pattern. When the application starts, through the class path scanning mechanism, it automatically discovers all Java classes that implement the predefined policy interface, such as DataObjectHandler and use specific annotations (such as @Service("SupplierAuthData")), instantiates them, and stores them in the in-memory registry implemented by java.util.concurrent.ConcurrentHashMap, establishing the mapping relationship between the data object type identifier and the specific processing logic.

[0061] The specific policy implementation class is an ordinary Java class that implements specific business logic and is responsible for handling the create, read, update, and delete operations of specific data object types. For example, the class named SupplierAuthDataHandleImpl is specifically responsible for handling the query of supplier permission data. The operation parameters are the data required to execute the specific business logic, such as a structured object containing filter conditions, pagination information, or data to be written.

[0062] Exemplarily, a remote call request sent by the data management middleware platform arrives at the target business system with the IP address 192.168.1.10 and the port number 8081. The REST controller of the hosting unit deployed in this system successfully matches the / api / data / service / getDataObjectList path. The controller receives the request body {"dataObjectTypeCode":"SupplierAuthData","params":{"supplierName":"Technology","status":"certified","page":1,"pageSize":10}}. The controller extracts the data object type identifier as "SupplierAuthData". It发起 a query to the policy factory module, that is, executes the get("SupplierAuthData") operation in the internal ConcurrentHashMap. Since it has been scanned and registered during system startup, this operation successfully returns an instance of the SupplierAuthDataHandleImpl class. The controller deserializes the JSON object in the params field into a SupplierQuery object.

[0063] The controller calls the supplierAuthDataHandleImpl.executeSearch(queryObject) method. Inside the executeSearch method, the business logic code generates the SQL statement SELECT id, supplier_code, supplier_name, status, create_time FROM t_supplier WHERE supplier_name LIKE '%Technology%' AND status = 'certified' LIMIT 0, 10 based on the attributes such as supplierName and status in the SupplierQuery object through the MyBatis framework. This SQL statement is sent to the local MySQL database of the business system for execution.

[0064] After the database executes the query, it returns a result set, which is mapped to a list of Java objects containing two supplier records, i.e., List <supplier>This list, as raw business data, will be returned to the carrier unit for encapsulation in subsequent steps.

[0065] In one embodiment of the present invention, step S5 includes the following steps: The system encapsulates the business execution results into a unified model to generate standardized intermediate data responses; it acquires the original business data after the execution of a specific strategy implementation class; it maps and populates the original business data into a standard data transmission object according to a preset unified data model structure, which includes a data carrier, status code, and extended attribute fields; and it returns the encapsulated standard data transmission object to the data management platform through a standard interface path.

[0066] Specifically, after the specific strategy implementation class completes the database operation within the target business system, the execution flow returns to the controller of the carrier unit. The controller first obtains the raw business data returned by the specific strategy implementation class. Based on the standard data model structure specified in the unified data management protocol, the controller instantiates a standard data transmission object. The controller sets the execution status code to a preset value indicating success, such as 200, and fills in the corresponding text message. The controller directly assigns the obtained raw business data to the data carrier field of the standard data transmission object. If the specific strategy implementation class also returns pagination information such as the total number of records, the controller stores this information in the extended attribute fields of the standard data transmission object.

[0067] After the data is populated, the encapsulated standard data transmission object serves as the response body of the HTTP request. It is automatically serialized into a JSON string by the web service framework where the hosting unit resides, such as the Jackson component in Java Spring Boot. This JSON string is then returned as a response to the core processing module of the data management platform that initiated the call through the HTTP connection corresponding to the standard interface path, generating and outputting a standardized intermediate data response.

[0068] Raw business data refers to a collection of unstandardized data generated by the local business logic of a business system. Its data structure directly corresponds to the internal model of the business system, such as a list of Java objects containing records of multiple database tables. Standard data transfer objects are predefined container classes used for unified data exchange between the data management platform and all business systems, and can be named DataObjectDTO.

[0069] The unified data model structure is the structural definition of the DataObjectDTO class. It includes an integer status code field (code) to represent the operation result, a string message field (message) to provide a result description, a data carrier field (data) of a generic object type to store the raw business data, and an extended attribute field (ext) of a key-value pair collection type to pass additional metadata such as pagination and permissions. This structure definition is packaged in a shared SDK to ensure all participants adhere to the same standard. The return of the HTTP response is accomplished through the underlying TCP / IP protocol stack; the web service framework manages the socket connection and writes the serialized data to the output stream.

[0070] For example, after the controller of the bearer unit calls the executeSearch method of the SupplierAuthDataHandleImpl instance, it successfully obtains the original business data, which is a List of Java objects containing two supplier records. <supplier>, the content is [{id: 101, supplier_code:'S-TECH-001', supplier_name: '…… Co., Ltd.', status: 'certified'}, {id: 102, supplier_code:'S-TECH-002', supplier_name: '…… Co., Ltd.', status: 'certified'}], and the total number of records obtained is 2. The controller instantiates the standard data transfer object, that is, the DataObjectDTO object.

[0071] The controller fills this object, sets its code field to 200, the message field to the string "Query successful", and the above List containing two records <supplier>The object is assigned to the `data` field of the `DataObjectDTO` object. The controller creates a `HashMap` object, stores the total number of records in it (i.e., `ext.put("total", 2L)`), and assigns this `HashMap` object to the `ext` field of the `DataObjectDTO`. The populated `DataObjectDTO` object is then serialized into a JSON string by the web service framework. This JSON string is sent as the HTTP response body to the data management platform that initiated the request.

[0072] In one embodiment of the present invention, step S6 includes the following steps: The intermediate data response is semantically enriched based on a metadata-driven mechanism, establishing a binding relationship between the data and the display rules. The data management platform receives standard data transmission objects and extracts data field information from them.

[0073] The metadata management system is queried based on the data object type identifier to obtain the metadata configuration information corresponding to the data type. The metadata configuration information includes at least the business name of the field, the front-end component type, the filtering rules, and the interaction permissions. The data values ​​in the standard data transmission object are dynamically merged with the metadata configuration information at the field level to generate a comprehensive response package containing data content and rendering instructions.

[0074] Specifically, after the core processing module of the data management platform receives the HTTP response of a standard data transfer object from the target business system, its internal semantic enrichment component executes. This component deserializes the JSON string of the response body into a DataObjectDTO object in memory. The component extracts the initial data object type identifier from the processing context of the current request. Using this data object type identifier as a query parameter, the component initiates an HTTP GET request to the independent metadata management system to obtain the metadata configuration information associated with that data type. Upon receiving the request, the metadata management system retrieves the information from its internal configuration database and returns a structured data object containing descriptions of all relevant fields.

[0075] After receiving the metadata configuration information, the semantic enrichment component constructs the final comprehensive response package, creates a new response data structure, and completely migrates the content of the received standard data transmission object, including the data carrier, status code, and extended attribute fields, to the data section of the new structure. The acquired metadata configuration information is then placed holistically into the metadata section of the new structure. In this way, the original plain data values ​​and the metadata describing their business meaning, display method, and interactive behavior are dynamically merged and bound at the field level. The final comprehensive response package is serialized into a JSON string and prepared for sending to the front-end client.

[0076] The metadata management system is a centralized configuration service responsible for storing and managing metadata for all cross-system data. Metadata configuration information is structured descriptive data, typically stored in JSON format. It defines the attributes of all fields for a specific data object type. These attributes include at least the field's business name (e.g., mapping the database field `supplier_code` to a readable "supplier code"); the front-end component type (e.g., specifying whether a field should be rendered as a text input box, a select dropdown, or a datepicker); filtering rules (e.g., defining whether the field should use exact matching (`equals`) or fuzzy matching (`like`) during queries); and interaction permissions (e.g., marking whether the field is editable or visible by default in the table).

[0077] The comprehensive response package is a composite data structure containing two top-level fields: a `data` field to store the business data itself, i.e., the standard data transmission object, and a `meta` field to store the corresponding metadata configuration information. The purpose of this structure is to encapsulate the data content along with the instructions on how the data should be understood and displayed, delivering them uniformly to the consumer.

[0078] In one embodiment of the present invention, step S7 includes the following steps: Output a comprehensive response package to the client to drive the front-end interface to achieve zero-code dynamic rendering. The comprehensive response package is sent to the front-end client that initiated the request; the front-end client parses the metadata configuration in the comprehensive response package and dynamically generates the corresponding table columns, filter controls, and form input fields; the data values ​​in the comprehensive response package are filled into the generated controls, completing the visualization and interactive construction of cross-system data without modifying the front-end code.

[0079] Specifically, after generating the comprehensive response package, the data management platform sends it as an HTTP response body to the front-end client that initially initiated the request via the established network connection. Upon receiving this HTTP response, the front-end client's JavaScript logic first deserializes the JSON string in the response body to obtain a JavaScript object containing two top-level properties: `data` and `meta`. The client's dynamic rendering engine is then activated.

[0080] The engine iterates through the metadata configuration information array under the `meta` field in the comprehensive response package. For each metadata object in the array, the engine dynamically creates the corresponding HTML element or calls a pre-built front-end component library, such as Vue or React, to generate UI controls based on the value of its `componentType` property. If `componentType` is `text`, then...<inputtype="text"> The element is used as a filter; if componentType is select, then it generates... <select>The dropdown list is populated with options using the options array. The engine sets the label text of the control based on the fieldName attribute in the metadata, and determines whether the field is generated in the corresponding column of the data table based on the visible attribute. After the control and table column are generated, the rendering engine then processes the data under the data field. It iterates through each record in the data.data array and fills the value of each record into the corresponding row and column cell of the data table according to the mapping relationship between the fieldKey defined in meta and the attribute name of the data record.

[0081] Through this series of automated parsing and rendering operations, the data obtained across systems can be visualized and interactively constructed on the front-end interface. The entire process does not require writing any front-end HTML templates or JavaScript rendering logic code for this specific data type.

[0082] The front-end client is a web application running in the user's browser, mainly composed of HTML, CSS and JavaScript. The dynamic rendering engine is the core JavaScript module in the application, responsible for parsing data and metadata and converting them into visual user interface elements. Front-end component libraries are pre-developed, reusable collections of UI controls, such as ElementPlus or AntDesign. Rendering engines quickly build interfaces by calling the APIs of these libraries. Dynamically generated controls refer to creating DOM elements and inserting them into the page at runtime based on metadata instructions, rather than statically writing HTML code during development.

[0083] Data value population refers to displaying business data obtained from the server in the corresponding table cells or form input boxes on the page. The core of zero-code dynamic rendering is that the front-end interface structure is entirely driven by the metadata returned by the back-end. Therefore, when it is necessary to display new data types or modify the display method of existing data types, only the configuration in the metadata management system needs to be changed, without deploying new front-end code.

[0084] Referring to Figure 2, the present invention also proposes a cross-system data management system based on dynamic protocol parsing and metadata-driven rendering, including the following modules: a request receiving module, which receives cross-system general data operation requests sent by clients, the cross-system general data operation requests including data object type identifiers and operation parameters; a protocol parsing and addressing module, which, based on the data object type identifier, queries a preset data source configuration module to obtain a service name identifier, and uses the service name identifier to query the service registry center to obtain a target service instance; a remote call distribution module, which, based on the target service instance, data object type identifier, and operation parameters, assembles and sends a remote call request to the target service instance through a unified data management protocol; and a logic distribution and execution module. Within the target service instance, based on the data object type identifier in the remote call request, the strategy factory module matches and executes a specific strategy implementation class to perform business data operations using operation parameters, generating original business data; the response encapsulation module encapsulates the original business data into a standard data transmission object and returns the standard data transmission object; the semantic enrichment module receives the standard data transmission object, queries the metadata management system to obtain metadata configuration information based on the data object type identifier, and merges the standard data transmission object and metadata configuration information to generate a comprehensive response package; the dynamic rendering module outputs the comprehensive response package to the client to drive the client to dynamically generate interface controls based on the metadata configuration information and fill the data in the standard data transmission object.

[0085] Each of the above modules can be implemented entirely or partially through software, hardware, or a combination thereof, supporting hardware embedded in or independent of the processor in the computer device, and also supporting software stored in the memory of the computer device, facilitating the processor to call and execute the operations corresponding to each of the above modules.

[0086] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.< / select> < / supplier> < / supplier> < / supplier>

Claims

1. A cross-system data management method based on dynamic protocol parsing and metadata-driven rendering, characterized in that, Includes the following steps: S1. Receive a cross-system general data operation request sent by the client. The cross-system general data operation request includes a data object type identifier and operation parameters. S2. Based on the data object type identifier, query the preset data source configuration module to obtain the service name identifier, and use the service name identifier to check the health of the target service instance with the service registry center to obtain the target service instance; S3. Based on the network address of the target service instance, and combined with the standard interface path pre-agreed between the data management platform and the downstream system, assemble the remote call request and send it. S4. Within the target service instance, the SDK package introduced by the downstream system pre-exposes standard service interfaces according to the unified data management protocol. After receiving remote call requests through these standard service interfaces, the carrying unit of the SDK package extracts the data object type identifier, calls the strategy factory module to match and execute specific strategy implementation classes, and uses operation parameters to perform business data operations to generate original business data. S5. Encapsulate the original business data into a standard data transmission object and return the standard data transmission object; S6. Receive the standard data transmission object, query the metadata management system to obtain metadata configuration information according to the data object type identifier, and merge the standard data transmission object and the metadata configuration information to generate a comprehensive response package. S7. Output a comprehensive response package to the client to drive the client to dynamically generate interface controls based on metadata configuration information and populate the data in the standard data transfer object.

2. The cross-system data management method based on dynamic protocol parsing and metadata-driven rendering according to claim 1, characterized in that, Receiving a cross-system common data operation request sent by a client includes the following steps: The client-side script responds to data operation events triggered by the user in the graphical user interface and obtains the target application identifier and data object type identifier corresponding to the current business scenario from the page context. Collect the query conditions or entity data entered by the user on the interface and organize them into structured operation parameters; The target application identifier, data object type identifier, and operation parameters are encapsulated into a JSON data structure to generate a cross-system general data operation request. By executing an HTTP POST request, the serialized cross-system common data operation request is sent to a unified service access point.

3. The cross-system data management method based on dynamic protocol parsing and metadata-driven rendering according to claim 1, characterized in that, Using the service name identifier to query the service registry to obtain the target service instance includes the following steps: The protocol parsing component within the core processing module obtains a list of available service instances, which contains network address information for multiple online service instances. Apply the preset load balancing strategy to select a unique instance object from the list of available service instances as the target service instance; The target service instance contains a specific IP address and port number.

4. The cross-system data management method based on dynamic protocol parsing and metadata-driven rendering according to claim 1, characterized in that, Assemble and send remote call requests to the target service instance using a unified data management protocol, including the following steps: Obtain the standard interface path that is uniformly defined by the data management platform and exposed by downstream systems through the SDK package; The network address information of the target service instance is concatenated with the standard interface path to generate a complete remote call URL; Create a request body data structure that conforms to the unified data management protocol specification; The data object type identifier in the cross-system general data operation request is mapped to the type encoding field in the new request body, and the operation parameters are copied into the new request body to complete the dynamic assembly of the remote call request.

5. The cross-system data management method based on dynamic protocol parsing and metadata-driven rendering according to claim 1, characterized in that, Matching and executing specific policy implementation classes through the policy factory module includes the following steps: The downstream system accesses the SDK package provided by the platform. The controller of the carrying unit in the SDK package accesses the hash mapping table maintained inside the policy factory module. The hash mapping table stores the correspondence between data object type identifiers and policy instances. Use the extracted data object type identifier as the key to perform a lookup operation in the hash map table; Returns an instance of the specific strategy implementation class corresponding to the key. The specific strategy implementation class is a Java class that is automatically discovered and instantiated in advance through the classpath scanning mechanism.

6. The cross-system data management method based on dynamic protocol parsing and metadata-driven rendering according to claim 1, characterized in that, Perform business data operations using operation parameters to generate raw business data, including the following steps: Deserialize the operation parameters in the remote call request into a parameter object of the type required by the specific strategy implementation class; Invoke the predefined execution method of the class instance implementing the specific strategy, and pass in the parameter object; Within the specific strategy implementation class, a database query statement is constructed based on the passed parameter object, and the query statement is executed in the local database through the database access component, or external system interfaces are called to obtain data from third-party systems and assembled into the original business data.

7. The cross-system data management method based on dynamic protocol parsing and metadata-driven rendering according to claim 1, characterized in that, The process of encapsulating raw business data into a standard data transfer object and returning the standard data transfer object includes the following steps: Instantiate a standard data transfer object that conforms to a unified data model structure; Set the status code field of the standard data transfer object to the preset value indicating success, and fill it with the corresponding text message; Assign the original business data to the data carrier field of the standard data transmission object; If pagination information or additional metadata exists, it is stored in the extended attribute field of the standard data transmission object to complete the unified encapsulation of the business execution results.

8. The cross-system data management method based on dynamic protocol parsing and metadata-driven rendering according to claim 1, characterized in that, The standard data transfer object and metadata configuration information are combined to generate a comprehensive response package, including the following steps: Create a response data structure as a composite response package; Migrate the data carrier, status code, and extended attribute fields from the standard data transfer object to the data portion of the integrated response package; The metadata configuration information obtained from the metadata management system will be incorporated into the metadata section of the comprehensive response package; Serialize the composite response packet into a JSON string.

9. The cross-system data management method based on dynamic protocol parsing and metadata-driven rendering according to claim 1, characterized in that, The driver client dynamically generates UI controls based on metadata configuration information, including the following steps: The front-end client's deserialization operation retrieves metadata configuration information from the comprehensive response packet; Iterate through each metadata object in the metadata configuration information, and dynamically create the corresponding HTML element or UI control by calling the pre-built front-end component library according to its front-end component type attribute. Set the control's label text based on the business name attribute in the metadata object, and set the control's editability and visibility based on the interaction permission attribute.

10. The cross-system data management method based on dynamic protocol parsing and metadata-driven rendering according to claim 1, characterized in that, Populating a standard data transfer object with data includes the following steps: The front-end client iterates through each data record contained in the data carrier of the comprehensive response package; Based on the mapping relationship between field key values ​​and data record attribute names defined in the metadata configuration information, the value of each data record is filled into the corresponding cell of the generated table column; The table and filter controls, populated with data, are rendered on the front-end client interface.

Images