Model-driven code-free configuration development method and development system

Abstract

The invention discloses a model-driven code-free configuration development method and system, relates to the technical field of platform development, and aims to construct a visual configuration system based on a metadata model and realize cross-platform data interaction and real-time dynamic updating through a directional data association and multi-modal view rendering technology. A lightweight metadata-driven architecture is adopted as the core, a standardized interface, hierarchical authority control and a dynamic routing strategy are integrated, and the double requirements of high concurrency and high availability are considered. Multi-source data access and efficient scheduling are realized through a unified abstraction layer, and an intelligent cache mechanism and a dynamic load balancing algorithm are combined to ensure that the system is quick in overall response and stable in operation. The overall design gives consideration to expansibility and safety, is compatible with a multi-terminal access scene, realizes deep collaboration and refined management and control of a model, a view and an authority system, and effectively improves the system operation efficiency and the user experience.

Description

Technical Field

[0001] This invention relates to the technical field of platform development, specifically to a model-driven no-code configuration development method and system. Background Technology

[0002] As enterprises deepen their digital transformation, the demand for application development is experiencing explosive growth, giving rise to low-code / no-code development platforms.

[0003] In existing technologies, users can quickly build simple applications such as forms and processes through visual drag-and-drop operations, lowering the development threshold. However, existing solutions still have many shortcomings: First, they are mostly form-driven or page-driven, lacking a structured design centered on the data model, resulting in difficulty in ensuring data consistency and poor scalability when facing complex business scenarios; Second, the connection between interface controls and data models and business processes is loose. When the data model changes, the configured views and processes often cannot be automatically updated, requiring manual adjustments one by one, which is inefficient and prone to errors; Third, permission control is mostly limited to the page or function level, making it difficult to achieve fine-grained permission control at the control level; Fourth, the development state and runtime state are separated, and changes to the configuration require redeployment and cannot achieve immediate effects. Summary of the Invention

[0004] In view of the above-mentioned problems, the present invention is proposed.

[0005] Therefore, the technical problem solved by this invention is that existing technologies are mainly form- or page-driven, lacking a structured design centered on data models. This results in loose association between data models and view controls, failure to automatically synchronize updates after model changes, coarse-grained permission control, and a disconnect between development and runtime states, leading to low efficiency and poor scalability. The invention also addresses how to achieve deep linkage driven by models, fine-grained permission control at the control level, and real-time online updates.

[0006] To address the aforementioned technical problems, this invention provides the following technical solution: a model-driven no-code configuration development method, comprising the following steps: constructing multiple parallel first carriers, each first carrier having built-in functional modules for performing visual data processing and interface display, configuring basic attributes and access rules, establishing a directional association with the data source, and storing all operations in metadata form; visually constructing a structured data model based on the data source, defining the core structure and inter-table association rules and synchronizing them to the first carriers, and using the configuration engine built into the first carriers to parse the data model metadata, thereby automatically constructing basic visual modules and data processing services, and customizing them into customized visual modules through visual configuration; configuring processes through visualization, binding customized visual modules to process nodes and configuring business rules, and verifying the matching degree of interface parameters and data flow between the customized visual modules and process nodes according to a preset rule model to ensure the connectivity of process logic; visually verifying and optimizing the customized visual modules and processes, monitoring operational performance indicators in real time, and adjusting the preceding configuration steps based on the monitoring results; selecting multiple deployment modes to release the first carriers, supporting online modification of configuration configurations and dynamic updates through an instant refresh mechanism.

[0007] As a preferred embodiment of the model-driven no-code configuration development method described in this invention, the following features are included: When constructing the first carrier, the configured basic attributes include the carrier name and WEB application identifier; the access rules include role-based hierarchical permissions and operation permission control rules; the access rules are directly mapped to the control operation permissions of its built-in basic visual module and customized visual module; the data source supports mainstream relational databases, time-series databases, and big data systems; connection parameters are configured and established after connectivity verification; the connectivity status is synchronized to the configured data source control in real time; the data source control is the associated configuration control of the data model; the first carrier supports cross-carrier reuse of data tables, layout templates, and functional components; after compatibility verification, the metadata of the reused resources can be directly moved to the view editing area of ​​the current carrier for quick adaptation; the view editing area is the configuration operation area of ​​the first carrier.

[0008] As a preferred embodiment of the model-driven no-code configuration development method described in this invention, the following steps are taken: When visually constructing a data model, the data table structure reused by the first carrier can be directly imported. Field attributes and constraints are defined through the field configuration area of ​​the data model, and association types are set through the association configuration area. Changes to the fields of the data model are automatically synchronized to the associated controls of the basic visual module and the customized visual module of the first carrier through a control linkage mechanism. The basic visual module synchronously generates basic operation views for adding, deleting, modifying, and querying, and its layout structure is bound one-to-one with the core functions of the data processing service. The call results of the data processing service are displayed back to the controls of the basic visual module in real time. During the configuration of the customized visual module, it is implemented through the customized visual component of the model visual module. The customized visual component is the core execution component of the visualization function of the first carrier, which includes a categorized control library, multiple types of layout tools, and a multi-terminal preview unit. It supports control movement and positioning, attribute visualization configuration, and event logic graphical editing. The multi-terminal preview unit allows for real-time switching of multi-terminal effects, and the control elements automatically adapt to the size.

[0009] As a preferred embodiment of the model-driven no-code configuration development method described in this invention, the following features are provided: When configuring a process, a process framework is constructed through node movement and connection. The customized visual module bound to the process node automatically inherits the field permissions of the data model. The visibility and editability of the customized visual module's controls are linked to the access rules of the first carrier. Different user roles present differentiated views when viewing process nodes. The approval subject supports static designation and dynamic assignment. The dynamic assignment logic can call the query function of the data processing service to obtain personnel data. The query results are displayed for selection through drop-down controls or pop-up units. The drop-down controls and pop-up units are built-in interactive controls of the customized visual component. Core approval actions and flow rules are encapsulated. When the system verifies the integrity of the process, it simultaneously verifies the validity of the control binding between the process node and the customized visual module, and the consistency of the association between the fields of the customized visual module and the data model.

[0010] As a preferred embodiment of the model-driven no-code configuration development method described in this invention, the following steps are taken: During verification and optimization, user operations are simulated to test the control response, data submission, and workflow smoothness of the basic visual module and the customized visual module of the first carrier. Performance indicators such as rendering time of the basic visual module, data loading speed of the customized visual module, and workflow response time are collected. When the performance indicators are abnormal, the binding status of the controls of the customized visual module with the fields of the data model and the association relationship between the workflow nodes and the customized visual module are identified first. When the abnormal link is modified, the field adjustment of the data model is automatically synchronized to the associated controls of the customized visual module and the corresponding nodes of the workflow through the control linkage mechanism. The access rule change of the first carrier updates the control permission status of the basic visual module and the customized visual module in real time. After modification, the verification is carried out again until the functions and performance of both types of visual modules meet the standards.

[0011] As a preferred embodiment of the model-driven no-code configuration development method described in this invention, the deployment modes include multi-tenant, independent server, and third-party PaaS platform deployment. During configuration integrity verification, the binding validity of the basic visual module and the control of the customized visual module of the first carrier with the data model is verified, as well as the consistency of the association of reused visualization resources across carriers. After online configuration modification, an instant refresh mechanism is triggered. Changes in data model fields or adjustments to the controls of customized visual modules are automatically synchronized to the corresponding node view of the process. Modifications to reused visualization resources are synchronously updated to all carrier configurations that reference the resource. The reports, data dashboards, and WEB configurations supported after release are all built through dedicated configuration units of the extension modules. The dedicated configuration units include report configuration units, dashboard configuration units, and WEB configuration units. All three are extension units of the visualization function of the first carrier, supporting the movable configuration of column fields and statistical dimensions, providing template libraries and movable layouts, dragging and dropping to draw on-site monitoring views, and directly calling real-time data of the data model. Their access permissions are consistent with the access rules of the first carrier.

[0012] Another objective of this invention is to provide a model-driven, no-code configuration development system, comprising: a carrier module for visually constructing a first carrier, configuring basic attributes, access rules, and data source association parameters, supporting cross-carrier resource reuse, generating and storing relevant metadata, and synchronizing its output permission metadata and resource metadata to the visualization-related modules; a model visualization module that receives metadata from the carrier module, including data model construction components, basic visualization generation components, and customized visualization components, for constructing data models, automatically generating basic visualization modules and data processing services for the first carrier, and customizing customized visualization modules, supporting multi-terminal adaptation and real-time preview; and a process module that receives visualization metadata from the model visualization module and permission metadata from the carrier module, including process configuration components and rule configurations. The system includes several modules: a component and a closed-loop verification component; a verification module; a validation module; a deployment and update module; and an extension module. The latter receives metadata from each module, including functional performance monitoring and rollback / revision linkage components, for functional testing, process flow testing, and performance monitoring of the basic and customized visual modules of the first carrier, locating abnormal links and supporting iterative verification after modification. The former receives metadata from each module and is used for configuring multiple deployment modes, online configuration visualization modification, and real-time refresh updates, serving as the core module for system deployment and updates. The latter receives visualization metadata from the model visualization module and permission metadata from the carrier module, including data display and permission control components, providing extended data visualization display and permission control functions.

[0013] As a preferred embodiment of the model-driven no-code configuration development system described in this invention, the carrier module includes a carrier configuration component, a data source access component, and a resource reuse component. The carrier configuration component collects and generates metadata for the first carrier, and its defined access rule metadata is synchronized to the permission unit of the model visualization module. The permission unit is a built-in functional unit of the customized visualization component. The data source access component adapts to mainstream data source types, configures connection parameters and verifies connectivity, and the generated connection status metadata is synchronized to the data source control of the model visualization module in real time. The resource reuse component provides a cross-carrier retrieval unit, supports keyword search and classification filtering of data tables, layout templates, and functional components, and the output reused resource metadata can be directly called and moved by the data model building component and the customized visualization component.

[0014] As a preferred embodiment of the model-driven no-code configuration development system described in this invention, the data model building component provides a field configuration area and an association configuration area for the data model, receives connection status metadata from the data source access component, and can call the reuse data table of the resource reuse component to generate metadata for the data model; the basic visual generation component calls the template library based on the metadata of the data model to automatically generate basic visual modules and data processing service metadata for the first carrier, with the permission attributes of its controls linked to the access rule metadata of the permission units; the customized visual component provides a categorized control library, multiple layout tools, an attribute panel, and a multi-terminal preview unit, receives field metadata from the data model building component, and realizes control style adjustment and event logic editing through the attribute panel, and the generated customized visual module metadata is synchronized to the process module.

[0015] As a preferred embodiment of the model-driven no-code configuration development system described in this invention, the process configuration component provides a process canvas and node library, receives metadata of customized visual modules from customized visual components, supports directly moving and binding customized visual modules to process nodes, and generates basic process framework metadata; the rule configuration component provides a permission configuration unit and a rule editing panel, reads the field permission metadata of the data model building component, binds the controls and process rules of the customized visual module through the permission configuration unit, and ensures that its approval permissions are consistent with the access rule metadata of the permission unit, forming a linkage; the closed-loop verification component receives the framework metadata of the process configuration component and the association metadata of the rule configuration component, verifies the binding validity of the process node and the customized visual module, the consistency of the association between the fields of the customized visual module and the data model, and outputs complete process metadata to the verification module.

[0016] As a preferred embodiment of the model-driven no-code configuration development system described in this invention, the functional performance monitoring component provides test configuration units and performance charts, receives complete process metadata from the closed-loop verification component, simulates user operation to test the control responses and process flow of the basic visual modules and customized visual modules of the first carrier, collects indicators such as rendering time and data loading speed of the two types of visual modules and compares them with preset thresholds to generate anomaly monitoring results; the revert and linkage component, based on the anomaly monitoring results, sends revert and modification instructions to the data model building component, customized visual component, and process configuration component respectively, supports one-click jump to the corresponding visual editing, model modification, or process configuration unit, receives the modified metadata, and triggers re-verification; the deployment and update module receives qualified metadata from the verification module, supports multi-mode deployment and online visual editing, and synchronizes the changed metadata of each module through an instant refresh mechanism to achieve incremental updates of the two types of visual modules and processes of the first carrier without interrupting service.

[0017] As a preferred embodiment of the model-driven no-code configuration development system described in this invention, the data display component integrates the report configuration unit, large screen configuration unit, and WEB configuration unit of the first carrier. All three receive real-time data metadata from the data model construction component, realizing data visualization display and device monitoring linkage. The permission control component provides an architecture configuration unit, a role allocation unit, and a prompting unit. It receives access rule metadata from the carrier configuration component, maintains organizational and personnel metadata through the architecture configuration unit, defines access permissions for roles to the two types of visualization modules of the first carrier through the role allocation unit, generates a permission control matrix, synchronizes it to the data display component and the customized visualization component, and intercepts unauthorized operations and pops up prompts through the prompting unit.

[0018] The beneficial effects of this invention are: This invention is based on metadata model-driven no-code configuration development technology, which has significant technological advancements and practical industry value compared to traditional low-code or high-code development models.

[0019] First, this invention replaces traditional code writing with metadata-driven methods, constructing a standardized engineering system and a visual operation interface. It enables the visual configuration of business processes and interface settings without the need for underlying code development, significantly reducing the technical threshold, improving development efficiency, and shortening the project delivery cycle.

[0020] Secondly, this invention designs a multi-dimensional permission control and cross-carrier resource reuse mechanism to achieve real-time linkage between role-based hierarchical permissions and control operation permissions, ensuring data security and operational compliance; at the same time, it supports rapid access to cross-project resources and compatibility verification, effectively avoiding redundant development and improving resource utilization.

[0021] Furthermore, this invention supports online modification and dynamic updates of configuration settings through an instant refresh mechanism and a closed-loop end-to-end verification system, eliminating the need for system redeployment and enabling rapid iteration of business processes and interfaces. Combined with performance monitoring and anomaly recovery linkage, it ensures stable system operation and efficient response.

[0022] Overall, this invention achieves zero-code, highly available, and highly scalable configuration development capabilities, adapting to multiple application scenarios such as industrial IoT and enterprise-level systems, significantly reducing development and maintenance costs, and improving the agility and flexibility of enterprise digital transformation. Attached Figure Description

[0023] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is an overall flowchart of the model-driven no-code configuration development method of the present invention.

[0025] Figure 2 This is a schematic diagram of the logic for constructing the first carrier and reusing resources across carriers in this invention.

[0026] Figure 3 This is a schematic diagram illustrating the logic of the data model construction and visualization module of this invention.

[0027] Figure 4 This is a schematic diagram of the process configuration and permission linkage logic of the present invention.

[0028] Figure 5 This is a schematic diagram illustrating the logic of visual verification, optimization, and iterative adjustment in this invention.

[0029] Figure 6 This is a schematic diagram illustrating the deployment, release, and real-time refresh mechanism of this invention.

[0030] Figure 7 This is a schematic diagram of the overall interactive logic of the model-driven no-code configuration development system of the present invention.

[0031] Figure 8 This is a schematic diagram of the interaction logic for data source access and cross-carrier resource reuse in this invention.

[0032] Figure 9 This is a schematic diagram of the data model-driven and visualization configuration generation logic of the present invention.

[0033] Figure 10 This is a schematic diagram of the process module configuration and metadata-driven logic of the present invention.

[0034] Figure 11 This is a schematic diagram illustrating the linkage logic of verification iteration and test deployment for this invention.

[0035] Figure 12 This is a schematic diagram of the permission control and data access interaction logic of the extended module of the present invention.

[0036] Figure 13 This is a diagram of the first carrier interface of the present invention.

[0037] Figure 14 for Figure 13 The "Create Project" configuration interface view at point M.

[0038] Figure 15 for Figure 13 The "Database Management" configuration interface view is located at point N.

[0039] Figure 16 This is the first interface diagram of Embodiment 3 of the present invention.

[0040] Figure 17 This is the second interface diagram of Embodiment 3 of the present invention.

[0041] Figure 18 This is the third interface diagram of Embodiment 3 of the present invention.

[0042] Figure 19 This is the fourth interface diagram of Embodiment 3 of the present invention. Detailed Implementation

[0043] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of the present invention.

[0044] Example 1

[0045] Reference Figures 1-12 This invention provides a model-driven, code-free configuration development method, which specifically includes the following steps in this embodiment: Multiple parallel first carriers 100 are constructed. The first carrier 100 is a dedicated runtime container for no-code configuration based on Spring Cloud (a microservice development framework). It is the core runtime carrier and logical encapsulation unit of the visual configuration function in this embodiment.

[0046] Furthermore, each first carrier 100 uniquely corresponds to a configuration project. The project is divided into five major directory structures: basic configuration, data model, visualization module, process configuration, and deployment management. Its core function is to carry all configuration operations, running logic, and various visualization function modules, so as to realize the independent operation and resource isolation of the configuration project.

[0047] This container integrates four core engines: a metadata parsing engine, a configuration engine, an access control engine, and a module scheduling engine. It supports parallel deployment of multiple instances, and resource isolation of CPU, memory, and storage is achieved between instances through container orchestration system namespaces and independent Pods. Each instance is assigned a unique 32-bit alphanumeric instance ID, and service registration and discovery are achieved through Nacos (a service registration and discovery framework). It supports elastic scaling of instances and ensures stable operation in high-concurrency scenarios.

[0048] The first carrier 100 has built-in functional modules for performing visual data processing and interface display. It configures the basic attributes and access rules of the carrier, establishes a directional association between the first carrier 100 and the data source 200, and stores all operations on the first carrier 100 in the form of metadata.

[0049] Among them, data source 200 is the underlying data source carrier configured and developed in this embodiment. It can be connected to various structured data storage systems. Its core function is to provide raw data support for subsequent data model construction, visualization module rendering and process operation.

[0050] All operations are encapsulated as structured metadata in a pre-defined JSON format, categorized into six main types: basic attribute metadata, access rule metadata, data source association metadata, data model metadata, visualization module metadata, and process metadata. Each type of metadata contains fixed core fields: a 64-bit unique metadata identifier, metadata type, carrier ID, metadata content, creation time, update time, creator, and updater. The metadata is uniformly stored in a distributed metadata database synchronized by MySQL (relational database) and Redis (caching database). MySQL is sharded and partitioned according to the carrier ID, while Redis serves as a first-level cache with a 30-minute expiration time. The metadata is invoked by the metadata parsing engine in an interpreted execution manner. The execution steps are lexical analysis, syntax analysis, semantic verification, instantiation of Java objects, and execution of corresponding functions, without any code compilation, thus avoiding the generation of redundant code from the underlying level.

[0051] Furthermore, a structured data model 201 is constructed visually based on the data source 200. The data model 201 is a structured data abstraction model built on the data source 200, and it is the core data layer carrier for realizing model-driven configuration in this embodiment. Its core function is to define the core structure, inter-table association rules, and field attribute constraints of the data source 200, serving as the core data basis for the visualization module, data processing service, and process, realizing deep linkage between data, view, and process. The core structure and inter-table association rules of the data model 201 are defined, and the data model 201 is synchronized to the first carrier 100. The configuration engine built into the first carrier 100 parses the metadata of the data model 201, thereby automatically constructing the basic visualization module 101 and data processing service.

[0052] The basic visualization module 101 is a standardized visualization operation module automatically generated by the first carrier 100 based on the data model 201. Its core function is to provide a basic visualization operation view for adding, deleting, modifying, and querying data, enabling basic operations and displays on the data corresponding to the data model 201, and meeting basic business data operation needs without manual customization.

[0053] The data processing service is a stateless server-side data interface service built on the RESTful (a software architecture style) specification. It is automatically generated by the configuration engine based on the metadata of data model 201. Each data model 201 uniquely corresponds to a set of data processing services. Its core function is to act as a data interaction bridge between data model 201 and various visualization modules and process nodes, realizing standardized reading, writing and processing of data. It includes standardized interfaces for data addition, deletion, modification and query, filtering, sorting and pagination. The interface uses HTTP / HTTPS as the communication protocol, and the request parameters and return values ​​are all in JSON format.

[0054] This interface integrates a rate limiting strategy based on the token bucket algorithm, generating 100 tokens per second, with each interface request consuming 1 token. It is also configured with a circuit breaker-based circuit breaking strategy, which triggers a circuit breaker if the interface error rate is ≥50% within 5 seconds. The circuit breaker lasts for 30 seconds and automatically attempts to restore the interface to half-open state after the circuit breaker is broken. It is also configured with a fallback strategy, which returns preset fallback data when rate limiting or circuit breaking occurs.

[0055] The interface supports cross-terminal and cross-service calls, with a call timeout configured to 3000ms. The basic visual module 101 is then customized through visual configuration to form a customized visual module 102. Customized visual module 102 is a personalized visual module customized based on the basic visual module 101 through visual configuration. Its core function is to meet the personalized data display and interaction needs of different business scenarios, supporting custom control layouts, event logic, and multi-terminal adaptation. It is the core visual carrier for realizing personalized configuration development.

[0056] Furthermore, the process is configured visually. The process is a visual workflow built based on business logic and serves as the business logic carrier for configuration and development in this embodiment. Its core function is to bind the customized visual module 102 to the process nodes and realize the automated flow of business logic through the configuration of business rules, covering various approval, processing, and scheduling business scenarios.

[0057] The customized visualization module 102 is bound to the process node and configured with corresponding business rules. The process node is the smallest business execution unit of the process and the core carrier of the process logic flow. Its core function is to carry the operation and processing logic of a single business link. It can be bound to the customized visualization module 102 to realize the visualization operation of the business link and supports differentiated configuration of different types of nodes. The system performs matching degree verification on the interface parameters and data flow between the customized visualization module 102 and the process node according to the preset rule model, so as to ensure the connectivity of the process logic.

[0058] Furthermore, the customized visual module 102 and process are visualized for verification and optimization, the operating performance indicators of the first carrier 100 are monitored in real time, and the preceding configuration steps are adjusted in reverse based on the monitoring results.

[0059] Furthermore, the first carrier 100 is deployed using multiple deployment modes. This first carrier 100 supports online modification of configuration settings and achieves dynamic updates of the configuration through an instant refresh mechanism. The instant refresh mechanism is the core technology mechanism for achieving dynamic updates of configuration settings after online modification in this embodiment. Its core function is to achieve real-time synchronization and effectiveness of configuration changes without interrupting the operation of the first carrier 100, thus solving the technical pain point of restarting after modification in traditional development.

[0060] This mechanism is a dynamic update mechanism based on metadata version control, cache invalidation, and incremental reloading of memory objects. The version number follows a 16-bit generation rule of "13-digit timestamp + 3-digit random number". The cache adopts a two-layer architecture of Caffeine (a local caching framework) local caching combined with Redis distributed caching. Memory reloading adopts a dual-instance hot-switching mode.

[0061] The specific execution process of this mechanism is as follows: First, it receives the configuration save instruction, updates the metadata content of the distributed metadata database and generates a new version number, and records the version update log at the same time. The log contains core fields such as unique log identifier, carrier ID, metadata type, old version number, new version number, and updated content.

[0062] Secondly, a cache invalidation command is sent to all running nodes of the carrier via RedisPub / Sub (publish-subscribe mode). The command is in JSON format and includes the tenant ID, carrier ID, metadata type, old version number, and new version number. The subscription channel is channel_refresh_[carrierId].

[0063] After receiving the instruction, each node clears the corresponding old metadata in the double cache, retaining only the unchanged metadata.

[0064] Then, the metadata parsing engine loads incremental change metadata from the metadata database based on the new version number, loading only the difference between the old and new version numbers instead of the full metadata.

[0065] Then, a hot-switching process between two in-memory instances is initiated. The first instance continues to run the old version of metadata to provide services, while the second instance loads the new version of incremental metadata and instantiates new objects. After loading is complete, requests are switched to the second instance via traffic forwarding, and the first instance is destroyed. The entire switching process takes less than 100ms, achieving uninterrupted service.

[0066] Finally, after the front end receives the refresh command, it calls the local refresh() method to re-render the corresponding module or node without refreshing the entire page, and the rendering time is less than 500ms.

[0067] Specifically, in the process of constructing the first carrier 100, the basic attributes configured include the carrier name and the WEB application identifier. The basic attributes must follow a fixed naming rule. The carrier name is a combination of 3 to 20 letters and numbers, which serves as the unique identifier for the engineering business.

[0068] The WEB application identifier is in a fixed format of "domain name:port / project ID". The project ID is a 6-digit number and is bound to the carrier instance ID. Both generate a unique identifier code, which serves as the global identification basis for the first carrier 100 in a distributed environment.

[0069] The configured access rules include role-based hierarchical permissions and operation permission control rules. These access rules are directly mapped to the control operation permissions of the basic visual module 101 and customized visual module 102 built into the first carrier 100. The mapping of access rules is achieved through a three-dimensional permission control matrix. The three-dimensional permission control matrix is ​​the core data model for implementing fine-grained permission control at the control level in this embodiment. Its core function is to store the relationship between roles, controls, and operation permissions, and to provide the core basis for permission verification for the permission control engine.

[0070] This matrix is ​​stored in the t_permission_matrix table of the dedicated permission database. The table structure includes a 32-bit role unique identifier (role_id), a 64-bit control unique identifier (control_id), operation type (operate_type, tinyint type, 1 = visible, 2 = editable, 3 = committable, 4 = deleteable), creation time (create_time), and update time (update_time), with (role_id, control_id, operate_type) as the primary key.

[0071] The first carrier 100's permission control engine is its built-in permission verification core engine. Its core function is to perform permission verification based on the three-dimensional permission control matrix when rendering controls and processing user operation requests, thereby achieving fine-grained permission management at the control level.

[0072] When rendering controls and processing operation requests, the engine performs fixed verification steps. First, after the user logs in, it obtains the current role ID list. Second, when the user triggers a control operation, the engine extracts the control's unique identifier (control_id) and operation type (operate_type). Next, it queries the t_permission_matrix table and determines whether a matching record exists. Finally, if a matching record exists, the operation is allowed; otherwise, it is directly blocked.

[0073] Furthermore, Data Source 200 supports mainstream relational databases, time-series databases, and big data systems. Specifically, it is compatible with relational databases such as MySQL 5.7+ / 8.0+, Oracle 11g / 12c, PostgreSQL 12+, and SQL Server 2019+, time-series databases such as InfluxDB 2.0+ and Prometheus 2.0+, and big data systems such as Hive 3.0+ and HBase 2.0+.

[0074] The data source type 200 can be configured by selecting from the drop-down menu. Different data source types have built-in standardized drivers of corresponding versions, such as mysql-connector-java-8.0.30.jar for MySQL 8.0 and ojdbc6.jar for Oracle 11g. The drivers adopt a plug-in architecture, which supports dynamic addition, updating and uninstallation without restarting the service.

[0075] Configure the connection parameters of data source 200 and, after connectivity verification, establish the association between the first carrier 100 and data source 200. The connectivity status of data source 200 is synchronized to the configured data source control 202 in real time. Data source control 202 is a dedicated control for the association configuration of data model 201. Its core function is to realize the association and binding between data source 200 and data model 201, and at the same time, display the connectivity status of data source 200 in real time, providing a data source status basis for the construction of data model 201.

[0076] The data source control 202 is the associated configuration control of the data model 201. Its connection parameters include the database address (IP / domain name), port number, access account, encryption password, and database instance name / database name. The password is preferably stored using the AES-256 (a symmetric encryption algorithm). The encryption is implemented by using a 32-bit random string as the key and storing it in the Nacos configuration center. The encryption mode is CBC (Cipher Block Chaining), the padding method is PKCS7 (a password padding standard), and the offset is a 16-bit random string.

[0077] Connectivity verification is implemented through a heartbeat mechanism, which is the core technology mechanism for detecting the connectivity of data source 200 in this embodiment. Its core function is to detect the connection status between the first carrier 100 and the data source 200 in real time and trigger an alarm promptly when an anomaly occurs. The heartbeat packet of this mechanism is in JSON format and includes a unique identifier of the data source (dataSourceId), a timestamp, and a signature. The verification frequency can be customized from 5 seconds / time to 60 seconds / time. If no response is received within 300ms after the heartbeat packet is sent, the connection is determined to have failed.

[0078] Upon failure, multiple alarms are triggered simultaneously. The alarm levels are divided into Level 1 (data source failure) and Level 2 (connection timeout). Level 1 alarms trigger SMS, email, and system message push notifications; Level 2 alarms only trigger system message push notifications. The alarm information includes the data source ID, name, cause of the error, and time of occurrence. The data source control 202 will display the abnormal status in red. Hovering the mouse over it will show the specific cause of the failure. It also provides one-click operations for "retesting and editing configuration".

[0079] Furthermore, the first carrier 100 supports cross-carrier reuse of data tables, layout templates, and functional components. After compatibility verification, the metadata of the reused resources can be directly moved to the view editing area 103 of the current carrier for quick adaptation. Compatibility verification is a pre-verification mechanism for cross-carrier resource reuse in this embodiment. Its core function is to detect the compatibility between the reused resources and the current first carrier 100, and to avoid configuration errors caused by resource incompatibility.

[0080] The view editing area 103 is a dedicated operation area for the visualization configuration of the first carrier 100. Its core function is to provide a visual drag-and-drop, editing, and layout operation canvas. It is the core operation carrier for the basic visual module 101 to be customized into the customized visual module 102. The view editing area 103 is the configuration operation area of ​​the first carrier 100. The compatibility verification adopts a four-level progressive verification mechanism. If any level of verification fails, reuse will be terminated and a pop-up window will display the specific incompatible items and automatic correction suggestions. One-click correction or manual adjustment is supported.

[0081] Specifically, the logic of the four-level verification is as follows: The first level is version matching verification. The version number of the reused resource metadata follows the format of "major version, minor version, revision version". It is determined to be compatible only when the major version and minor version are the same. If the major version is different, it is directly incompatible.

[0082] The second level of field type adaptation validation uses a built-in fixed field type mapping table, such as data source VARCHAR—data model string, INT—integer, BIGINT—long integer, DATETIME—date and time, DECIMAL—floating point. If the field type of the reused resource does not match the field type of the current carrier data source, a prompt will be given.

[0083] The third-level permission rule compatibility check checks whether the permission role for the reused resource exists in the current carrier. If it does not exist, it prompts the user to map the reused role to an existing role in the current carrier.

[0084] The fourth level of data source association and adaptation verification checks whether the data source ID bound to the reused resource exists in the current carrier. If it exists, it verifies the connection status; if it does not exist, it prompts the user to add the corresponding data source.

[0085] View editing area 103 is a visual configuration operation canvas based on HTML5 Canvas. The default resolution of the canvas is 1920×1080, and it supports custom resolutions. The grid size is 10px×10px, and the snapping accuracy is ±2px.

[0086] The canvas is divided into four layers: background layer, layout layer, control layer, and mask layer. Each layer can be shown / hidden, locked / unlocked, and layers can be moved up and down.

[0087] Resource movement uses a drag-and-drop operation. After dragging to the canvas, a matching placeholder box is automatically generated. It also provides batch operation functions such as one-click left alignment, right alignment, horizontal centering, top alignment, bottom alignment, vertical centering, and equidistant distribution. It supports shortcut key operations for copying, pasting, and deleting.

[0088] Furthermore, during the process of visually constructing the data model 201, the reusable data table structure of the first carrier 100 is directly imported. Field attributes and constraints are defined through the field configuration area 203 of the data model 201. The field configuration area 203 is a dedicated area for configuring field attributes of the data model 201. Its core function is to provide a visual editing interface for field attributes and constraints, so as to achieve a refined definition of each field of the data model 201.

[0089] The relationship configuration area 204 of data model 201 is used to set the relationship type between tables. The relationship configuration area 204 is a dedicated area for configuring the relationship rules between tables in data model 201. Its core function is to provide a visual interface for configuring the relationship types and fields between tables, so as to define the relationship between multiple tables. The field configuration area 203 supports configuring 12 core attributes of the field, namely the field unique identifier (letter + underscore, 3 to 20 characters), display name, data type, field length, decimal places, default value, NOT NULL constraint, unique constraint, enumeration value, regular expression validation rule, whether it can be queried, and whether it can be edited. Among them, the enumeration value is configured in the form of "key-value" pairs. After configuration, the visual control automatically generates the corresponding drop-down options. The regular expression validation rule supports custom editing and real-time preview of the validation effect. It has built-in commonly used regular expression templates, such as various identity information, which can be directly selected and used.

[0090] The 204 association configuration area supports three types of table associations: one-to-one, one-to-many, and many-to-many. When configuring, you need to select the associated master table, associated slave table, associated fields of the master table, and associated fields of the slave table. You can also configure cascading operation rules for cascading queries, cascading inserts, cascading modifications, and cascading deletes. The specific execution logic of the cascading operation is that when the corresponding operation is triggered in the master table, the same operation is automatically performed on the data in the slave table where "the associated field of the master table = the current field value of the master table". You can choose whether to enable a certain type of cascading operation.

[0091] All configurations generate structured data model metadata, establishing a real-time mapping relationship with the physical table structure of the underlying data source.

[0092] When a field in data model 201 changes, it is automatically synchronized to the associated controls of the basic visual module 101 and the customized visual module 102 of the first carrier 100 through the control linkage mechanism. The control linkage mechanism is the core technology mechanism for realizing the synchronization of data model 201 field changes with visual controls in this embodiment. Its core function is to automatically synchronize the changes to all visual controls bound to the data model when a field in data model 201 is added, deleted, modified, or queried, without the need for manual adjustment of control configuration.

[0093] This mechanism is based on the Redis Pub / Sub publish-subscribe pattern. Data model 201 is the publisher, and all visual controls bound to this data model are subscribers. Each data model corresponds to a unique subscription channel: channel_meta_[modelId].

[0094] When a field in data model 201 undergoes CRUD operations, a change event is immediately published, including the change type (add / modify / delete), the changed field ID, the values ​​before and after the change, and the modelId. Subscribing controls consume the event within 500ms and automatically update their own bound attributes, display rules, and validation rules without requiring manual adjustment of control configuration. If consumption times out, a retry mechanism is triggered. If the retry fails after 3 attempts, an exception log is recorded.

[0095] The basic visual module 101 synchronously generates basic operation views for adding, deleting, modifying, and querying. The layout structure of this view is bound one by one to the core functions of the data processing service, and the call results of the data processing service are displayed to the controls of the basic visual module 101 in real time.

[0096] The basic visual module 101's CRUD basic operation view has a standardized page layout, which is fixedly divided into three main areas: query bar, data display table, and operation button area.

[0097] The control generation of the query bar follows fixed rules: string fields in the data model generate input boxes, enumeration fields generate drop-down lists, date fields generate date pickers, and boolean fields generate radio buttons. The "AND / OR" combination logic of the query conditions can be configured.

[0098] The column names in the data display table correspond one-to-one with the display names of the data model, and support column width adjustment by dragging, column sorting, column hiding, and pagination; the operation button area contains four standardized buttons: add, modify, delete, and refresh, and button permissions are linked with the three-dimensional permission control matrix.

[0099] The layout structure of the basic visual module 101 and the core functions of the data processing service adopt a hard binding method. The query operation is bound to the query interface, the add operation is bound to the add interface, the modify operation is bound to the update interface, and the delete operation is bound to the delete interface. The request parameters of the interface call are automatically encapsulated by the control according to the data model fields, without the need for manual configuration.

[0100] After the call result is returned in JSON format, it is parsed in real time by the Vue (front-end framework) rendering engine and displayed to the corresponding table or form control. When the interface call fails, an error message is displayed in a pop-up window, including a fixed error code and a detailed description, such as 1001 - data source connection failed, 1002 - field does not exist, 1003 - insufficient permissions, 1004 - parameter validation failed. At the same time, the exception log is recorded to the ELK (log collection and analysis framework) logging system.

[0101] Furthermore, the configuration process of the customized visual module 102 is realized through the customized visual component 403 of the model visual module 400. The model visual module 400 is the core module for realizing the data model construction and visualization module generation and customization in this embodiment. Its core function is to receive the metadata of the carrier module 300, complete the construction of the data model 201, the automatic generation of the basic visual module 101, and the personalized customization of the customized visual module 102.

[0102] The customized visual component 403 is the core execution component of the model visual module 400 and also the core execution component of the visualization function of the first carrier 100. Its core function is to provide various controls, layout tools and preview functions required for personalized configuration, so as to realize the personalized customization from the basic visual module 101 to the customized visual module 102. The customized visual component 403 is the core execution component of the visualization function of the first carrier 100. It includes a classified control library, multiple types of layout tools and a multi-terminal preview unit 104. The multi-terminal preview unit 104 is a dedicated multi-terminal preview function unit of the customized visual component 403. Its core function is to provide real-time preview effects on different terminals, ensure that the display effect of the customized visual module 102 on each terminal meets expectations, support the visual debugging of multi-terminal adaptation effects, support control movement and positioning, attribute visual configuration and event logic graphical editing, and the multi-terminal preview unit 104 can switch the multi-terminal display effects in real time.

[0103] Furthermore, the control elements can automatically adapt to different terminal sizes. The categorized control library is based on ElementPlus (front-end UI component library) + ECharts (visual chart library) and is divided into five categories according to function: form, chart, navigation, interaction and data display. It contains more than 300 standardized and reusable controls, including form controls such as input boxes, password boxes, radio buttons, check boxes, date pickers, file uploaders, drop-down selectors, etc.

[0104] Charts include line charts, bar charts, pie charts, dashboards, heatmaps, maps, and radar charts; navigation includes navigation bars, tabs, breadcrumbs, and step bars; interactive elements include pop-ups, prompts, confirmation boxes, drop-down menus, and drawers; data display elements include tables, cards, carousels, progress bars, and number flippers. All controls have built-in standardized properties and event interfaces, supporting custom styles and event extensions. Multiple layout tools support three modes: grid layout, free layout, and responsive layout. Grid layout uses a standard twelve-column grid with adaptive column width, supporting column adjustment, grid merging, and offset configuration. Free layout allows for arbitrary dragging and positioning of controls. Responsive layout allows for separate configuration of layout rules for PC, tablet, and mobile devices to meet the display needs of different terminals.

[0105] The event logic graphical editing is based on a flowchart. The specific operation process is as follows: select the target control — add a trigger event — select the event type (click, hover, submit, load, close, change, etc.) — add an action — configure the action parameters — save. It supports adding multiple condition judgments (AND / OR combination).

[0106] For example, the command "if field A > 100 then call interface Belse pop-up prompt C" can be configured to perform actions such as interface calls, control showing / hiding, data assignment, page redirection, pop-up prompts, and file downloads.

[0107] The multi-terminal preview unit 104 supports real-time preview on four terminals: PC, tablet, mobile, and large screen. The preview window can be freely scaled. The control elements are automatically adapted to the size based on the REM (front-end adaptive layout unit) adaptive layout rule. The REM baseline value is preferably 16px. The adaptation formula is: actual element size = design draft element size / 16, to ensure consistent display effect on different terminals.

[0108] During the configuration process, the process framework is built by moving and connecting nodes. After the process nodes are bound to the customized visual module 102, they automatically inherit the field permissions of the data model 201. The visibility and editability of the controls in the customized visual module 102 are linked with the access rules of the first carrier 100. Different roles of users will see different views when viewing process nodes. The process is a visual flow process based on business logic. The process framework is built using SVG (vector graphics format) vector drawing technology.

[0109] The process nodes include three standardized types: manual nodes, automatic nodes, and sub-process nodes. The core functions of each type of node are: manual nodes are configured with the person in charge, processing time limit, and processing operation. If the processing is not completed within the time limit, an SMS / in-system reminder will be triggered. Timeout processing strategies (automatic approval / automatic rejection) can be configured.

[0110] Automatic node configuration sets the execution interface, conditions, and frequency without manual intervention. Once triggered, the interface is executed automatically, such as calling the data statistics interface every 5 minutes. Sub-process nodes select pre-configured processes and jump to the sub-process during execution. After the sub-process is completed, it automatically returns to the main process to continue execution. Node movement uses drag-and-drop operation, and connections are drawn by clicking on the node port. The port is located in the four directions of the node: up, down, left, and right. The connection automatically snaps to the node port with a precision of 20px around it. A maximum of two corners are supported for the connection, and the corner positions can be manually adjusted by dragging.

[0111] All elements in the process framework can be configured with style attributes such as coordinates, size, color, display name, and font; after the process node is bound to the customized visual module 102, permission inheritance is achieved through metadata association ID.

[0112] The specific steps are as follows: First, extract the unique identifier (control_id) of all controls in the customized visual module 102. Second, query the three-dimensional permission control matrix t_permission_matrix table according to the role ID of the currently logged-in user. Then, filter out controls without permissions and set them to a hidden / grayed state so that no operation can be triggered. Finally, only render the controls with matching records to realize the differentiated view display when users with different roles view process nodes.

[0113] Furthermore, the approval entity of the process supports both static designation and dynamic assignment. The dynamic assignment logic can call the query function of the data processing service to obtain personnel data. The query results are displayed for selection through drop-down control 105 or pop-up unit 106. Drop-down control 105 is a built-in basic interactive control of customized visual component 403, whose core function is to provide drop-down option selection function, suitable for scenarios where a small number of people / options are selected. Pop-up unit 106 is a built-in pop-up interactive control of customized visual component 403, whose core function is to provide pop-up multi-condition filtering and batch selection function, suitable for scenarios where a large number of people / options are selected. Both drop-down control 105 and pop-up unit 106 are built-in interactive controls of customized visual component 403.

[0114] The specific operation process for static designation is as follows: Click the "Select Approver" button—an organizational structure tree diagram will pop up (supporting four levels: Group—Company—Department—Group)—select the target personnel—click Confirm. You can select one or more people. If multiple people are selected, the countersigning rule will be triggered by default.

[0115] The specific configuration process for dynamic assignment is as follows: First, select the query interface of the data processing service. Second, configure the query parameters, which support binding static and dynamic parameters. Dynamic parameters are fields, such as department {model.deptId}. The field values ​​of the data model are automatically obtained at runtime. Next, configure the interface return value mapping, mapping the personnel ID and name returned by the interface to parameters that the process can recognize. Finally, configure the assignment scope, such as limited to this department or limited to a specified position. After the query function is executed, the personnel data that meet the conditions are obtained.

[0116] The preferred configuration for dropdown control 105 is a page size of 10 items / page, supports fuzzy search (matching personnel name / account), allows selection of up to 20 people, supports one-click deletion of selected personnel, and supports sorting by name / position / rank. Pop-up unit 106 is a full-screen pop-up, providing multi-condition combination filtering (department, position, role, rank), and the filtering logic supports "AND / OR" combinations. The filtering results are displayed in a table format, supporting pagination and sorting, batch selection of personnel, and real-time preview of the selected personnel list after selection.

[0117] This embodiment encapsulates core approval actions and workflow rules. The core approval actions are standardized business operation actions encapsulated in this embodiment for the approval process. Their core function is to achieve standardized and automated execution of the approval process, covering the basic operational needs of various approval scenarios.

[0118] Among them, the flow rules are standardized rules encapsulated for the logical flow of the process in this embodiment. Their core function is to define the flow logic between process nodes and realize the automated flow of business processes. When the system verifies the integrity of the process, the integrity of the process is the judgment standard for the compliance of the process configuration and the logical connectivity in this embodiment. Its core function is to ensure that the process configuration is complete and the logic is unbroken, so that it can run normally. It also verifies the validity of the binding between the process nodes and the controls of the customized visual module 102, and the consistency of the association between the fields of the customized visual module 102 and the data model 201. The core approval actions are encapsulated as standardized rule components, including six major actions: countersigning, adding signatures, rollback, rejection, transfer, and completion.

[0119] The specific execution logic for each action is as follows: **Countersigning:** If all countersigners approve, the node is completed; if any one person rejects, the node is rejected. A countersigning timeout can be configured. **Adding a Signatory:** The current handler adds a signatory. After the signatory approves, the process returns to the current handler. **Rollback:** The current node rolls back to a specified preceding node, requiring the preceding node handler to re-examine the process. A reason for rollback can be entered. **Rejection:** The node is directly rejected back to the process's starting node, requiring the process to restart. A reason for rejection can be entered. **Transfer:** The current handler transfers the node's processing authority to another handler. After transfer, the original handler has no further operational authority. **Completion:** The node is completed and automatically moves to the next node.

[0120] The flow rules include four types: sequential flow, branch flow, parallel flow, and conditional flow. The specific configuration of conditional flow is as follows: add judgment conditions, select data model fields, select operators (>, <, =, ≠, contain, do not contain, between), set thresholds, and configure flow nodes that meet the conditions and flow nodes that do not meet the conditions. Multiple judgment conditions can be added, and the combination logic is "AND / OR".

[0121] The process integrity verification is implemented using a depth-first traversal algorithm, which is the core algorithm for verifying the logical connectivity of the process in this embodiment. Its core function is to traverse all nodes and connections in the process and detect whether there are any problems such as unvisited nodes or broken connections in the process.

[0122] The specific execution steps are as follows: First, mark the starting node of the process as "visited" and push it onto the stack. Second, pop the top node of the stack and traverse all its outgoing edges. Then, for each target node of the connection, if it is not marked as "visited", mark it and push it onto the stack and repeat the above traversal steps. If the stack is empty, check whether all nodes in the process are "visited". If they are not visited, it is determined that the process is disconnected.

[0123] During the traversal, five checks are performed synchronously on each node: completeness of required node attributes, validity of connection pointers, validity of node-module binding, consistency of module-data model association, and legality of approval actions and workflow rule configurations. After the checks are completed, a detailed check report is generated, including check time, check results, total number of anomalies, list of anomaly nodes, description of each anomaly and modification suggestions. The report can be exported to Excel format. Anomaly nodes and anomaly connections are highlighted in red on the workflow canvas, and the specific reason for the anomaly can be viewed by hovering the mouse over them.

[0124] In the verification and optimization phase, which is the testing and optimization stage of the configuration development in this embodiment, its core function is to test the configuration effect by simulating user operations, collect performance indicators and locate anomalies, modify and re-verify to ensure that the configuration function of the first carrier 100 is normal and the performance meets the standards. By simulating user operations, the control response, data submission and flow smoothness of the basic visual module 101 and customized visual module 102 of the first carrier 100 are tested. Performance indicators such as the rendering time of the basic visual module 101, the data loading speed of the customized visual module 102 and the flow response time are collected. Performance indicators are the core quantitative indicators for evaluating the running performance of the first carrier 100 in this embodiment. Their core function is to reflect the running efficiency of the visualization module and the process through specific values, and provide data basis for anomaly location and optimization. The simulated user operations are implemented based on the TestCafe (automated testing framework) automated test script engine, which supports recording real user operation processes and generating reusable automated test scripts.

[0125] The automated test scripts are in JSON format and contain an array of steps. Each step includes an action type, a CSS (Cascading Style Sheets) / XPath (XML Path Language) selector for the control, an input / selection value, and a wait time (in milliseconds). The scripts support editing, saving, importing, exporting, and batch execution.

[0126] It also supports configuring high concurrency / large data volume test parameters, preferably including test concurrency (selectable 10 / 50 / 100 / 200), number of tests (selectable 100 / 500 / 1000), test data volume (selectable 1000 / 5000 / 10000 records), and test duration (selectable 5 / 10 / 30 minutes) to simulate the actual production environment operation scenario.

[0127] Performance metrics are collected using event tracking technology, which is the core technology for collecting performance metrics in this embodiment. Its core function is to set up collection points at key stages of system operation to achieve refined and real-time collection of performance metrics. This technology is preferably based on SkyWalking (full-link tracing framework) 8.0, generating a unique tracing identifier for each request and a unique span identifier and parent span identifier for each event tracking stage. The collected metric fields include tracing identifier, span identifier, module name, control ID, node ID, start time, end time, execution time, execution status, and error information. Event tracking data is stored in InfluxDB in 10ms buckets, supporting multi-dimensional queries by time, module, control, and node.

[0128] Furthermore, when the collected performance indicators are abnormal, the abnormality is the judgment result of the performance indicator exceeding the preset threshold in this embodiment. Its core function is to identify the links where the system operation performance is substandard and there is room for optimization. It prioritizes locating the binding status of the controls of the customized visual module 102 and the fields of the data model 201, as well as the association relationship between the process node and the customized visual module 102. The judgment of abnormal performance indicators is based on a customizable preset threshold. The preset threshold is the core reference standard for judging whether the performance indicators are abnormal in this embodiment. Its core function is to set a reasonable range of values ​​for the performance indicators according to business needs and system performance requirements.

[0129] The preferred core threshold configuration items are: page rendering time ≤ 500ms, control rendering time ≤ 100ms, interface call time ≤ 300ms, data loading time ≤ 1000ms, chart rendering time ≤ 800ms, node response time ≤ 500ms, total process flow time ≤ 3000ms, interface call success rate ≥ 99.9%, CPU utilization ≤ 70%, memory utilization ≤ 80%, disk I / O ≤ 100MB / s, and network I / O ≤ 50MB / s.

[0130] If the value of an indicator exceeds the threshold, it is judged as abnormal. It supports configuring the threshold and alarm level of a certain type of indicator individually. The anomaly location is achieved by full-link tracing technology. Full-link tracing technology is the core technology for locating the core links of performance anomalies in this embodiment. Its core function is to trace the entire execution trajectory of the request, intuitively display the time consumption of each link, and quickly locate the root cause of the anomaly. This technology generates a visual call chain chart based on SkyWalking, which intuitively displays the time consumption, execution status, service to which it belongs, and calling method of each span. The span with the longest time consumption will be highlighted in red.

[0131] The system follows fixed anomaly localization rules: First, investigate the span with the longest execution time in the call chain to determine the core link of the anomaly; if the high execution time is due to control rendering, prioritize checking whether there are invalid bindings or many-to-many binding issues in the field binding between the control and the data model; if the high execution time is due to interface calls, prioritize checking the data source connection status, SQL query efficiency, and interface rate limiting / circuit breaking status; if the high execution time is due to process nodes, prioritize checking whether the binding between the node and the customized visual module is broken and whether the approval rule configuration is complex; after localization, an anomaly localization report is generated, including the anomaly link, execution time data, threshold standards, root cause analysis, and optimization suggestions.

[0132] When modifying abnormal links, the abnormal links are the specific configuration links where the system identifies abnormal performance indicators or abnormal function operation. The core function is to clearly identify the modification targets in the verification and optimization phase, and to achieve precise optimization. The field adjustments of data model 201 are automatically synchronized to the associated controls and corresponding nodes of the process in the customized visual module 102 through the control linkage mechanism. Changes in the access rules of the first carrier 100 will update the control permission status of the basic visual module 101 and the customized visual module 102 in real time. After the modification is completed, the verification is performed again until the functions and performance of the basic visual module 101 and the customized visual module 102 both reach the preset standards.

[0133] The preset standard is the core basis for determining whether the modified configuration steps meet the standards in this embodiment. Its core function is to clarify the qualification standards for functions and performance, ensuring that the modified configuration steps can operate normally and efficiently. The field adjustments and access rule changes of data model 201 are synchronized using an incremental update method. The incremental update method is the core method for realizing metadata synchronization in this embodiment. Its core function is to synchronize only the changed metadata fragments, rather than the entire metadata, thereby improving synchronization efficiency. Specifically, it is implemented as follows: When metadata changes, the system records a change log in the metadata database, storing only the unique identifier of the changed metadata, metadata type, old value, and new value. During synchronization, only the change log is pushed to the associated controls / nodes, rather than the full metadata, which greatly improves synchronization efficiency. When access rules change, the permission control engine updates the t_permission_matrix table in real time and sends permission refresh instructions to all relevant visualization modules. The instructions are in JSON format and include role ID, control ID, operation type, and status. After receiving the instructions, the controls immediately re-execute permission verification and update their own visibility / operability status without refreshing the page.

[0134] The modified re-verification adopts incremental verification logic, which is the core logic for implementing the modified re-verification in this embodiment. Its core function is to perform targeted verification only on the modified parts, rather than full verification, thereby improving verification efficiency. This logic only performs targeted verification on the modules, controls, nodes or processes corresponding to the unique identifier of the changed metadata, and does not perform full verification. The items of incremental verification are completely consistent with the original integrity verification and performance verification, until all functional verifications pass and the performance indicators are all below the preset threshold, thus completing the verification optimization of this part.

[0135] The deployment modes of the first carrier 100 include multi-tenancy, independent server, and third-party PaaS platform deployment. The deployment mode refers to the specific runtime environment deployment method of the first carrier 100 released in this embodiment. Its core function is to adapt to the deployment needs of different enterprises and different business scenarios, improving the system's adaptability and flexibility. During configuration integrity verification, which is a pre-deployment full-scale verification before deploying the first carrier 100 in this embodiment, its core function is to ensure that all configurations of the first carrier 100 are complete and effective, without binding failures or inconsistent associations, to guarantee normal operation after deployment. The verification focuses on the binding validity of controls and data models 201 in the basic visual module 101 and customized visual module 102 of the first carrier 100, and the consistency of cross-carrier reuse of visual resources. Multi-tenancy deployment is implemented based on a four-level resource isolation method of "namespace + database + storage + runtime container," specifically: The first level is namespace isolation, where each tenant is allocated an independent Kubernetes namespace, and resources between tenants are not visible to each other; the second level is database isolation, where each tenant is allocated an independent MySQL database instance or schema with independent permissions; the third level is storage isolation, where each tenant is allocated an independent OSS / MinIO (object storage system) storage directory, and the directory name is bound to the tenant ID; the fourth level is runtime container isolation, where each tenant's primary container instance runs in an independent Kubernetes Pod, and the Pod's CPU, memory, and storage quotas are configured separately.

[0136] It also supports tenant-level resource quota configuration, preferably including CPU quota (0.5~4 cores), memory quota (1~16GB), storage quota (10~1000GB), and number of interface calls (1000~100000 times / day); independent server deployment supports physical machine and virtual machine deployment, and has clear hard requirements for the operating environment: operating system is CentOS7.6 / Ubuntu18.04 / WindowsServer2019, JDK (Java Development Kit) version is 1.8.0_202+, MySQL version is 5.7+ / 8.0+, Redis version is 5.0+ / 6.0+, memory ≥4GB, disk ≥100GB (SSD), and network bandwidth ≥100Mbps.

[0137] The system provides an automated environment detection tool, which is a dedicated tool for detecting the deployment environment of a standalone server in this embodiment. Its core function is to automatically detect whether the operating environment meets the deployment requirements, generate a detection report, and mark any items that do not meet the requirements. The detection steps of this tool are as follows: First, the operating system version and kernel are checked. Next, the JDK version and environment variable configuration are checked. Then, it is checked whether MySQL / Redis are installed and running normally. Then, it is checked whether core ports are occupied. Following this, it is checked whether the available disk space and memory capacity meet the requirements. Finally, an environment detection report is generated, indicating the specific reasons and rectification suggestions for any non-compliant items. The third-party PaaS platform deployment supports mainstream cloud platforms. Containerization technology is used to encapsulate the runtime environment, dependent components, and metadata parsing engine of the first carrier 100 into a standardized Docker (containerized platform) image. Containerization technology is the core technology for implementing the third-party PaaS platform deployment in this embodiment. Its core function is to encapsulate the runtime environment and dependent components of the first carrier 100 into a standardized image, enabling rapid cross-platform deployment.

[0138] The image is built on AlpineLinux (a lightweight Linux system), reducing its size. It also supports Kubernetes container orchestration, enabling automatic scaling and self-healing. The configuration integrity pre-deployment verification is a full verification. In addition to verifying the binding validity of the basic visual module 101, the customized visual module 102 and the data model 201, and the consistency of cross-carrier reused resources, it also verifies the validity of data source association, the integrity of permission configuration, the legality of process configuration, and the integrity of metadata storage. After the verification passes, a pre-deployment detection report is generated. Items that fail must be repaired before deployment can proceed.

[0139] After online modification of the configuration, an instant refresh mechanism is triggered. Changes to the fields of the data model 201 or adjustments to the controls of the customized visual module 102 will be automatically synchronized to the corresponding node view of the process. Modifications to the reused visual resources will be synchronously updated to all carrier configurations that reference the resource. The reused visual resources are the visualization-related resources that support cross-carrier reuse in this embodiment, including data tables, layout templates, functional components, etc. The core function is to realize cross-carrier sharing of resources, avoid repeated development, and improve configuration efficiency.

[0140] Modification of this resource is achieved through a global association identifier in metadata. All first carriers 100 that reference this resource are configured with the global association identifier of this resource. After the resource is modified, the system traverses all associated carriers according to the identifier and automatically triggers the real-time refresh mechanism of each carrier to achieve global synchronous update of the reused resource. During the synchronization process, only incremental change metadata is pushed, which does not affect the normal operation of the carrier.

[0141] After the first carrier 100 is released, the reports, data dashboards, and WEB configurations supported are all constructed through the dedicated configuration units of the extension module 800. The extension module 800 is the core module for extending the visualization function of the first carrier 100 in this embodiment. Its core function is to provide dedicated configuration units for reports, data dashboards, and WEB configurations, enriching the visualization display and application scenarios of the first carrier 100. The dedicated configuration units include report configuration unit 107, data dashboard configuration unit 108, and WEB configuration unit 109. The report configuration unit 107 is the dedicated configuration unit for report visualization of the extension module 800. Its core function is to provide professional report configuration functions to realize the report display and export of various structured data.

[0142] The large-screen configuration unit 108 is a dedicated large-screen visualization configuration unit for the expansion module 800. Its core function is to provide large-screen configuration functions for industrial monitoring and data display, enabling the visualization of data on a large screen and linkage with equipment monitoring. The WEB configuration unit 109 is a dedicated WEB application configuration unit for the expansion module 800. Its core function is to provide visual configuration functions for WEB applications, enabling the rapid construction of single-page / multi-page WEB applications. All three are extension units of the visualization function of the first carrier 100. They support the movable configuration of column fields and statistical dimensions, provide template libraries and movable layouts, draw on-site monitoring views by dragging and dropping, and directly call the real-time data of the data model 201. Their access permissions are consistent with the access rules of the first carrier 100.

[0143] Report configuration unit 107 is a professional report visualization configuration unit that supports the configuration of single-table reports, cross-table reports, grouped reports, and cross-reports. It allows for the movable configuration of report column fields, statistical dimensions, filtering conditions, and sorting rules. It supports custom calculation formulas and aggregate functions, and provides nearly 200 standardized report templates. Generated reports support online preview, printing, and export in formats including Excel, PDF, CSV, and Word. Report data supports scheduled and manual refreshes, with a refresh rate configurable from 1 minute to 24 hours. Large screen configuration unit 108 is a large screen configuration unit designed for industrial monitoring and data visualization. It provides standardized large screen templates for various scenarios such as industrial sites, smart parks, smart cities, and enterprise operations. It supports drag-and-drop drawing of on-site monitoring views, and allows configuration of equipment locations, real-time data display, and abnormal warning thresholds. Warnings are displayed using various methods such as color highlighting, flashing, pop-ups, and sound. It supports multi-screen linkage and large screen splicing, with a data refresh rate down to the second level.

[0144] WEB configuration unit 109 is a configuration unit for WEB application development, supporting visual configuration of single-page and multi-page applications. It can configure page routing, navigation menus, and page layout. The generated WEB application is implemented based on the Vue.js framework, supports custom domains, HTTPS configuration, and static resource packaging, and can be independently deployed to a server or cloud platform. All three components directly call the real-time data of data model 201 through metadata association ID, and fully inherit the three-dimensional permission control matrix of the first carrier 100 through the permission inheritance mechanism. The permission inheritance mechanism is the core mechanism for implementing permission management of extension module 800 in this embodiment. Its core function is to enable the dedicated configuration unit of extension module 800 to directly inherit the access rules of the first carrier 100, achieving consistency of permission management across the entire system without the need for separate permission configuration. This mechanism achieves fine-grained permission management at the role level and control level. When permission rules change, the permission status of the three components will be updated synchronously in real time.

[0145] Example 2

[0146] Reference Figures 1 to 15 This invention provides a model-driven no-code configuration development system. The development system in this embodiment is built based on the model-driven no-code configuration development method of Embodiment 1 above, and specifically includes: a carrier module 300, a model visualization module 400, a process module 500, a verification module 600, a deployment and update module 700, and an extension module 800.

[0147] The carrier module 300 is the core module of the basic configuration of the development system in this embodiment. Its core function is to realize the visual construction of the first carrier 100, the configuration of basic attributes and access rules, the association of data sources and the reuse of cross-carrier resources, generate and store various metadata, and provide basic metadata support for other modules.

[0148] The model visualization module 400 is the core module for visualization modeling of the development system in this embodiment. Its core function is to receive metadata from the carrier module 300, complete the construction of the data model 201, automatically generate the basic visualization module 101, and personalize the customized visualization module 102.

[0149] The process module 500 is the core module for process configuration and verification of the system developed in this embodiment. Its core function is to receive metadata from the model visualization module 400 and the carrier module 300 to realize the visualization configuration, rule configuration and integrity verification of the process.

[0150] The verification module 600 is the core module for testing and optimization of the development system in this embodiment. Its core function is to receive metadata from each module and realize functional testing, performance monitoring, anomaly location and backtracking optimization of the first carrier 100.

[0151] The deployment and update module 700 is the core module for deployment and dynamic update of the system developed in this embodiment. Its core function is to receive qualified metadata from each module and realize multi-mode deployment, online configuration modification and real-time refresh update of the first carrier 100.

[0152] Extension module 800 is the core module for functional expansion and access control of the system developed in this embodiment. Its core function is to receive metadata from model visualization module 400 and carrier module 300, realize the visualization function expansion of reports, large screens, and WEB, and implement unified access control for the entire system. The functions of each module and the connection relationship of its internal components are as follows: Specifically, the carrier module 300 is the basic configuration module of the entire system. Based on a microservice architecture design, all components are independent microservice units. Service registration and discovery are achieved through Nacos (a service registration and discovery framework), and remote calls between components are achieved through Feign (a remote procedure call framework). All kinds of metadata generated adopt a distributed storage method with master-slave synchronization, stored in MySQL master-slave databases and Redis cache, to ensure high availability and high read and write performance of metadata. The carrier module 300 is used to visually construct the first carrier 100, configure the basic attributes, access rules and data source association parameters of the first carrier 100, support cross-carrier resource reuse, generate and store metadata related to the first carrier 100, and synchronize the output permission metadata and resource metadata to visualization-related modules such as the model visualization module 400, process module 500, and extension module 800.

[0153] The model visualization module 400 is the core visualization modeling module of the system and a key unit for realizing model-driven configuration. It integrates core functions such as metadata parsing, template matching, control generation, and module customization. The operation of all components is based on the metadata output by the carrier module 300, realizing deep linkage with the basic configuration. The model visualization module 400 receives the metadata output by the carrier module 300, specifically including the data model construction component 401, the basic visualization generation component 402, and the customized visualization component 403.

[0154] Among them, the data model building component 401 is the core modeling component of the model visualization module 400. It is the core unit for realizing model-driven operation. Its core function is to provide a visual building interface for the data model 201, receive connection status metadata from the data source access component 302, call the reused data table of the resource reuse component 303, complete the configuration of field attributes and inter-table association rules of the data model 201, and generate metadata.

[0155] The basic visualization generation component 402 is an automatic generation component of the model visualization module 400. Its core function is to automatically generate the metadata of the basic visualization module 101 and data processing services based on the metadata call template library of the data model 201, thereby realizing zero-code generation of basic visualization functions.

[0156] The customized visual component 403 is the core execution component of the model visual module 400 and also the core execution component of the visualization function of the first carrier 100. Its core function is to provide personalized configuration tools such as classification control library, layout tools, and attribute configuration panel. It receives field metadata from the data model building component 401, completes the personalized configuration of the customized visual module 102 and generates metadata for building the data model 201, automatically generating the basic visual module 101 and data processing services of the first carrier 100 based on the data model 201, and customizing the basic visual module 101 to form the customized visual module 102. It also supports multi-terminal adaptation and real-time preview.

[0157] The process module 500 is the system's process configuration and verification module. It is implemented based on the BPMN2.0 (Business Process Modeling and Annotation Specification) process specification and supports visual process construction and rule configuration. The closed-loop verification component 503 is the core of this module, realizing the legality and integrity verification of the entire process lifecycle. The process module 500 receives the visual metadata output by the model visualization module 400 and the permission metadata output by the carrier module 300.

[0158] Specifically, it includes a process configuration component 501, a rule configuration component 502, and a closed-loop verification component 503. The process configuration component 501 is the process building component of the process module 500. Its core function is to provide a process canvas and node library, receive metadata of the customized visual module 102 from the customized visual component 403, support the binding of modules and process nodes, and generate basic process framework metadata.

[0159] The rule configuration component 502 is the rule configuration component of the process module 500. Its core function is to provide a permission configuration unit and a rule editing panel, read the field permission metadata of the data model building component 401, complete the process rules and permission configuration, and generate associated metadata. The closed-loop verification component 503 is the core verification component of the process module 500. Its core function is to receive the process framework metadata and rule association metadata, verify the connectivity and integrity of the process logic, generate complete process metadata and push it to the verification module 600. It is used to realize the binding of the customized visual module 102 with the process node and the configuration of business rules, automatically verify the connectivity and integrity of the process logic and generate process metadata.

[0160] The verification module 600 is the system's testing and optimization module, integrating functions such as automated testing, performance monitoring, anomaly location, and backtracking linkage. It realizes closed-loop optimization between the development and runtime states and is one of the core innovative modules in this embodiment. The verification module 600 receives various metadata output from the carrier module 300, the model visualization module 400, and the process module 500.

[0161] Specifically, it includes a functional performance monitoring component 601 and a revert / modify linkage component 602. The functional performance monitoring component 601 is the test monitoring component of the verification module 600. Its core function is to provide test configuration units and performance charts, receive complete process metadata from the closed-loop verification component 503, simulate user operation to test the functionality and performance of the visualization module and process, collect and analyze performance indicators, and generate anomaly monitoring results. The revert / modify linkage component 602 is the core linkage component of the verification module 600. Its core function is to locate abnormal links based on anomaly monitoring results, send revert / modify instructions to the corresponding components, support one-click jump modification and iterative verification, realize closed-loop optimization, and perform functional testing, process flow testing and performance monitoring on the basic visualization module 101 and customized visualization module 102 of the first carrier 100, locate abnormal links in configuration and operation and support iterative verification after modification.

[0162] The deployment and update module 700 is the system's deployment and dynamic update module, integrating functions such as environment detection, image building, deployment execution, metadata synchronization, and cache management. It supports deployment in multiple environments and modes. The real-time refresh mechanism is the core function of this module, enabling uninterrupted dynamic updates. The deployment and update module 700 receives various metadata output from the carrier module 300, model visualization module 400, process module 500, and verification module 600, which is used for configuring multiple deployment modes, online configuration visualization modification, and dynamic updates of configuration through the real-time refresh mechanism. It is the core module for system deployment and updates.

[0163] The extension module 800 is a function extension and access control module for the system. The data display component 801 realizes the visualization extension of reports, large screens, and WEB. The access control component 802 realizes the unified access management of the entire system to ensure the security and compliance of the system. The extension module 800 receives the visualization metadata output by the model visualization module 400 and the access metadata output by the carrier module 300, specifically including the data display component 801 and the access control component 802.

[0164] The data display component 801 is the core display component of the extension module 800. Its core function is to integrate three types of dedicated configuration units: reports, large screens, and web applications. It receives real-time data metadata from the data model building component 401 to realize extended data visualization display and linkage with equipment monitoring.

[0165] The access control component 802 is the core component of the access control of the extension module 800. Its core function is to receive access rule metadata from the carrier configuration component 301, maintain organizational and personnel information, define role permissions and generate an access control matrix to achieve unified access control of the entire system. It is used to provide extended data visualization and access control functions for the entire system.

[0166] Specifically, the carrier module 300 includes a carrier configuration component 301, a data source access component 302, and a resource reuse component 303.

[0167] The carrier configuration component 301 is the core configuration component of the carrier module 300. It provides a visual interface for creating, editing, deleting, cloning, enabling, and disabling the first carrier 100. The collected configuration information includes basic attributes, access rules, and running parameters. The generated metadata is stored by type, and a unique instance ID and project ID are generated for each first carrier 100 as a global identification basis. The carrier configuration component 301 collects and generates the metadata of the first carrier 100. Its defined access rule metadata is synchronized to the permission unit 404 of the model visualization module 400. The permission unit 404 is a built-in permission control unit of the customized visualization component 403. Its core function is to integrate the calling, parsing, and verification functions of the permission control matrix. It receives the access rule metadata synchronized by the carrier configuration component 301, updates the permission control matrix in real time, and provides permission verification services for the controls of the customized visualization module 102. The permission unit 404 is a built-in functional unit of the customized visualization component 403.

[0168] The data source access component 302 is the system's data source management component. It has built-in standardized drivers for mainstream relational databases, time-series databases, and big data systems. The drivers adopt a plug-in architecture, supporting dynamic addition and updates. It provides a visual data source configuration interface, supporting operations such as adding, editing, deleting, testing connectivity, enabling, and disabling data sources. This data source access component 302 is compatible with mainstream data source types, configures the connection parameters of the data source and verifies connectivity. The generated connection status metadata is synchronized to the data source control 202 of the model visualization module 400 in real time. The configured connection parameters are stored after being encrypted with AES-256. The generated connection status metadata includes data source ID, type, connection status, last verification time, and exception reason, and is synchronized to the data source control 202 at a frequency of 5 seconds. At the same time, it provides a global monitoring panel for the data source connection status, realizing centralized management of all data sources.

[0169] Resource reuse component 303 is the system's resource management and reuse component. It constructs a unified resource library, which stores all reusable data tables, layout templates, and functional components of the first carrier 100. All resources generate a unique global association identifier and version number, and support resource upload, download, editing, deletion, and sharing operations. Resource reuse component 303 provides cross-carrier retrieval unit 304, which is the core retrieval unit of resource reuse component 303.

[0170] Implemented based on Elasticsearch (full-text search engine), its core function is to provide multi-dimensional resource retrieval and filtering functions. It supports keyword search and category filtering of data tables, layout templates, and functional components. The search results are displayed in sorted order by matching degree. It supports resource preview and reuse. The output reusable resource metadata can be directly called and moved by the data model building component 401 and the customized visual component 403. The metadata call of reusable resources adopts a lazy loading mechanism, and the complete metadata is only obtained when the resource is moved to the view editing area 103, which improves page loading speed and configuration efficiency.

[0171] The data model building component 401 is the core modeling component of the model visualization module 400 and is the key to realizing model-driven development. This component provides a visual data model building interface, supports direct import of physical table structures from data sources, can also call the reused data tables of the resource reuse component 303, and can also manually create custom data models. It supports version management of data models, generates a unique version number for each modification of each data model, records version update logs, and supports one-click version rollback and version comparison.

[0172] The generated data model metadata is mapped in real time to the physical table structure of the underlying data source. When the physical table structure changes, it can be synchronized to the data model with one click without manual adjustment. The data model building component 401 provides the field configuration area 203 and the association configuration area 204 of the data model 201, receives the connection status metadata output by the data source access component 302, and can call the reused data table of the resource reuse component 303 to generate and store the metadata of the data model 201.

[0173] The basic visual generation component 402 is an automatic generation component for the model visual module 400. This component has a built-in standardized visualization template library and interface generation template library. The visualization template library contains standardized templates for basic CRUD operations, and the interface generation template library contains interface generation templates based on RESTful specifications. Based on the metadata call template library of the data model 201, the basic visual generation component 402 automatically generates the basic visual module 101 and data processing service metadata for the first carrier 100. The permission attributes of the controls in the generated basic visual module 101 are linked to the access rule metadata of the permission unit 404. The core execution flow of this component is as follows: First, the metadata of data model 201 is parsed to extract core information such as field attributes and inter-table relationships. Second, the corresponding standardized template is matched from the visualization template library, and the template is dynamically rendered based on the data model metadata to generate the metadata of the basic visualization module 101. Next, the corresponding interface template is matched from the interface generation template library, and the interface metadata of the data processing service is generated based on the data model metadata, including interface address, request method, parameter list, return value format, and validation rules. Then, the access rule metadata of permission unit 404 is mapped to the controls of the basic visualization module 101 to generate the permission attributes of the controls. Finally, the metadata of the basic visualization module 101 and the data processing service are bound together to generate complete relational metadata.

[0174] The customized visual component 403 provides a categorized control library, multiple layout tools, an attribute panel 405, and a multi-terminal preview unit 104. The attribute panel 405 is the core configuration panel of the customized visual component 403. Its core function is to provide control style, data binding, and event configuration functions. It supports visual drag-and-drop adjustment and precise numerical configuration to realize personalized customization of controls. It receives field metadata output by the data model building component 401 and realizes control style adjustment and event logic editing through the attribute panel 405. The generated metadata of the customized visual module 102 is synchronized to the process module 500.

[0175] The attribute panel 405 is divided into three tabs: style configuration, data binding, and event configuration. Style configuration allows you to adjust the position, size, color, font, margin, background, and other style attributes of controls. Data binding allows you to bind controls to fields of data model 201 in a one-to-one or one-to-many manner and configure data reading and submission rules. Event configuration allows you to graphically edit the trigger events and actions of controls, and supports nested events and conditional judgments. The generated metadata of the customized visual module 102 is stored in layers according to layout metadata, control metadata, event metadata, and data binding metadata, which facilitates independent modification and management. After the metadata is generated, it is synchronized to the process module 500 in real time through a message queue (such as RabbitMQ) to provide a foundation for process configuration.

[0176] The process configuration component 501 provides a process canvas 504 and a node library. The process canvas 504 is the core operation carrier of the process configuration component 501. It is implemented based on SVG (vector graphics format). Its core function is to provide a visual process editing interface, supporting operations such as dragging and dropping process nodes, drawing lines, and configuring styles. It is the core area for building the process framework. It receives the metadata of the customized visual module 102 output by the customized visual component 403 and supports directly moving and binding the customized visual module 102 to the process node to generate basic process framework metadata. The process canvas 504 supports zooming, panning, grid snapping, and full-screen display. The background, grid size, and color of the canvas can all be customized.

[0177] The node library provides three standardized types of process nodes: manual nodes, automatic nodes, and sub-process nodes. Each node has its own icon and attribute configuration panel, and supports dragging, copying, deleting, and batch selection of nodes. The binding of the customized visual module 102 to the process node is done by dragging and dropping. Simply drag the customized visual module 102 from the module list to the process node to complete the binding. After binding, a metadata association ID (uniquely identifying the binding relationship between the module and the node) is generated, realizing deep linkage between the module and the node. The generated basic process framework metadata includes node metadata, connection metadata, and binding relationship metadata, which are stored in the process metadata database.

[0178] The rule configuration component 502 provides a permission configuration unit 505 and a rule editing panel 506. The permission configuration unit 505 is the permission fine-grained configuration unit of the rule configuration component 502. Its core function is to support permission configuration at the field level, control level, and node level, so as to realize differentiated permission control of process-related resources for different roles.

[0179] The rule editing panel 506 is the core rule configuration interface of the rule configuration component 502. Its core function is to provide a visual configuration function for approval actions and workflow rules. It supports multi-condition combinations and logic editing, reads the field permission metadata output by the data model building component 401, and binds the controls and process rules of the customized visual module 102 through the permission configuration unit 505. The configured approval permissions are consistent with the access rule metadata of the permission unit 404 and form a linkage. The permission configuration unit 505 can configure the operation permissions of different roles on process nodes, customized visual module controls, and data model fields. The configuration results are synchronized to the permission control matrix of the permission unit 404 in real time to achieve linkage with the system's global permissions.

[0180] The rule editing panel 506 is divided into two areas: approval action configuration and workflow rule configuration. The approval action configuration supports the configuration of trigger conditions, execution scope, and feedback methods for core approval actions such as countersigning, additional signing, rollback, and rejection. The workflow rule configuration supports the configuration of rules for sequential workflow, branch workflow, parallel workflow, and conditional workflow. Conditional workflow supports multi-dimensional judgment conditions and logical combinations. All configurations generate structured rule metadata.

[0181] The closed-loop verification component 503 is the core verification component of the process module 500. This component uses a configurable rule engine (such as the Drools rule engine) to implement the verification logic, supports user-defined addition of verification rules and thresholds, and its core function is to automatically verify the integrity and legality of the process configuration to ensure that the process can run normally. The closed-loop verification component 503 receives the framework metadata output by the process configuration component 501 and the association metadata output by the rule configuration component 502, verifies the binding validity of the process nodes and the customized visual module 102, and the consistency of the association between the fields of the customized visual module 102 and the data model 201, and outputs the complete process metadata to the verification module 600. The verification process of this component is as follows: First, the process framework metadata and rule association metadata are received and parsed and preprocessed. Next, the following checks are performed sequentially: node attribute integrity verification, connection validity verification, node-module binding validity verification, module-data model association consistency verification, and approval action and workflow rule configuration legality verification. Then, a detailed verification report is generated, highlighting anomalies, their causes, and suggested modifications. Finally, if the verification passes, the process framework metadata, rule association metadata, and binding relationship metadata are integrated to generate complete process metadata, which is pushed to the verification module 600 in real time via a message queue. If the verification fails, a verification report is returned, prompting the user to make modifications.

[0182] The functional performance monitoring component 601 provides a test configuration unit 603 and a performance chart 604. The test configuration unit 603 is the test parameter configuration unit of the functional performance monitoring component 601. Its core function is to provide configuration functions for parameters such as test type, concurrency, and data volume, and to support the recording and import of automated test scripts.

[0183] Performance Chart 604 is a performance visualization unit for the functional performance monitoring component 601. It is implemented based on ECharts (a visualization chart library). Its core function is to display the collected performance indicators in real time. It supports multi-dimensional filtering and anomaly highlighting. It receives complete process metadata output by the closed-loop verification component 503. It simulates user operation to test the control response and process flow of the basic visual module 101 and customized visual module 102 of the first carrier 100. It collects indicators such as rendering time and data loading speed of the two types of visualization modules and compares them with preset thresholds to generate anomaly monitoring results. The test configuration unit 603 supports configuring test types (functional test, performance test, high concurrency test, stability test), test concurrency (selectable 10 / 50 / 100 / 200), number of tests (selectable 100 / 500 / 1000), test data volume (selectable 1000 / 5000 / 10000 records), and test duration (selectable 5 / 10 / 30 minutes). It supports recording and importing automated test scripts to achieve batch automated testing.

[0184] Performance Chart 604 displays collected performance metrics in real time in the form of line charts, bar charts, dashboards, pie charts, etc. It supports multi-dimensional filtering and viewing by time, module, and process node. When a metric exceeds a preset threshold, it is highlighted in red. At the same time, it generates anomaly monitoring results, including information such as abnormal metrics, abnormal values, thresholds, time of occurrence of anomalies, and abnormal links.

[0185] The revert and modification linkage component 602 is the core linkage component of the verification module 600 and is the key to realizing closed-loop optimization between the development state and the runtime state. Based on the anomaly monitoring results output by the functional performance monitoring component 601, the revert and modification linkage component 602 sends revert and modification instructions to the data model building component 401, the customized visualization component 403, and the process configuration component 501 respectively. It supports one-click jump to the corresponding visualization editing, model modification, or process configuration unit, receives the modified metadata, and triggers re-verification. After receiving the anomaly monitoring results from the functional performance monitoring component 601, the component first analyzes the cause of the anomaly through the anomaly root cause analysis algorithm (based on the decision tree model) to locate the module and component to which the anomaly belongs.

[0186] Then, a revert command containing anomaly location information (component ID, operation area), anomaly cause, and modification suggestions is generated and sent to the corresponding component via a message queue. One-click jump functionality is supported. Based on the front-end routing mechanism (such as VueRouter), clicking the jump button can directly locate the corresponding visual editing interface, data model modification interface, or process configuration interface, and highlight the anomaly element. After receiving the modified metadata, an incremental verification mechanism is automatically triggered to retest the modified steps until the anomaly is eliminated.

[0187] The deployment update module 700 receives qualified metadata output by the verification module 600, supports multi-mode deployment and online visual editing, and synchronizes the changed metadata of each module through an instant refresh mechanism. This enables incremental updates of the basic visual module 101, customized visual module 102 and process of the first carrier 100 without interrupting service. This module provides a visual deployment configuration interface, supports the selection of deployment environment (development environment, test environment, production environment) and deployment mode (multi-tenant, independent server, third-party PaaS platform), and configures parameters such as deployment server IP, port, memory quota, and disk quota.

[0188] It supports real-time viewing and export of deployment logs, which include deployment time, deployer, deployment content, deployment steps, execution results, error messages, etc. The online visual editing interface is completely consistent with the system's configuration editing interface, and supports online modification of deployed configurations. The instant refresh mechanism is the core of this module, which is achieved through metadata version control, cache invalidation, and incremental reloading of memory objects. It synchronizes the changed metadata of each module to achieve incremental updates without service interruption, and the update results are fed back to the deployment monitoring panel in real time.

[0189] The data display component 801 is the core display component of the extension module 800. This component provides unified data calling, permission control, and rendering engine services for the report configuration unit 107, large screen configuration unit 108, and WEB configuration unit 109. It supports dual display of real-time and offline data. Real-time data is directly called from the data model 201, and offline data is called from the data warehouse (such as the Hive data warehouse). It supports equipment monitoring linkage and can bind the visualization module with industrial equipment and IoT devices to realize real-time display of equipment status, data collection, and anomaly warning. When the equipment is abnormal, the warning display and multi-channel alarm of the visualization module are automatically triggered. The data display component 801 integrates the report configuration unit 107, large screen configuration unit 108, and WEB configuration unit 109 of the first carrier 100.

[0190] Among them, the report configuration unit 107 is a dedicated report configuration unit of the data display component 801. Its core function is to provide visual configuration functions for various types of reports, such as single-table, cross-table, grouped, and cross-report, and supports report preview, printing, and multi-format export. The large screen configuration unit 108 is a dedicated large screen configuration unit of the data display component 801. Its core function is to provide visual configuration functions for large screens in various scenarios such as industrial monitoring and park management, and supports real-time data refresh and anomaly warning. The WEB configuration unit 109 is a dedicated WEB application configuration unit of the data display component 801. Its core function is to provide visual configuration functions for single-page / multi-page WEB applications, and supports page routing, navigation menu configuration, and independent deployment. All three receive real-time data metadata output by the data model building component 401 to realize data visualization display and equipment monitoring linkage.

[0191] The access control component 802 provides an architecture configuration unit 803, a role assignment unit 804, and a prompting unit 805. The architecture configuration unit 803 is the organization and personnel management unit of the access control component 802. Its core function is to maintain the organizational structure and personnel information, and to support departmental level management and batch operations on personnel.

[0192] The role allocation unit 804 is the core unit for permission configuration of the permission control component 802. Its core function is to support the creation of custom roles and batch allocation of permissions, and to generate a permission control matrix. The prompt unit 805 is the unit for intercepting and prompting unauthorized operations of the permission control component 802. Its core function is to intercept unauthorized operations and display pop-up prompts through a dual mechanism of front-end interception and back-end verification. It receives access rule metadata output by the carrier configuration component 301, maintains organizational and personnel metadata through the architecture configuration unit 803, defines the access permissions of roles to the two types of visualization modules of the first carrier 100 through the role allocation unit 804, generates a permission control matrix, synchronizes it to the data display component 801 and the customized visualization component 403, and intercepts unauthorized operations and displays prompts through the prompt unit 805.

[0193] The architecture configuration unit 803 supports tree-shaped display and hierarchical management of the organizational structure, and supports the addition, editing, deletion, and movement of departments, as well as the batch addition / removal of personnel. Personnel information includes name, account, password, position, job level, department, and contact number. Passwords are encrypted and stored using MD5 (hash algorithm). The role assignment unit 804 supports the creation, editing, and deletion of custom roles, and supports the batch assignment of operation permissions for system menus, visualization modules, controls, process nodes, and data model fields by role. The configuration results generate a three-dimensional permission control matrix (role—control—operation), which is synchronized in real time to the permission unit 404 of the customized visual component 403 and the data display component 801 to achieve unified permission control across the entire system.

[0194] The 805 prompt unit adopts a dual permission protection mechanism of front-end interception and back-end verification. When the user triggers an operation, the front-end first performs permission verification, intercepts unauthorized operations, and displays unauthorized information through pop-ups, text prompts, etc. The back-end performs permission verification again when processing interface requests to prevent the front-end from bypassing permission interception. The prompt text, style, and method for unauthorized operations can all be customized.

[0195] Example 3

[0196] Reference Figures 1 to 19 This embodiment of the present invention provides a model-driven no-code configuration development method and system for smart fire protection applications. Targeting typical business scenarios of smart fire protection equipment monitoring and energy consumption management, this embodiment utilizes the no-code configuration development method and system to quickly build a smart fire protection management cloud platform, achieving full-process functions such as fire equipment status monitoring, energy consumption analysis, alarm management, and operation and maintenance control. Data access, visual configuration, process configuration, and deployment can be completed without writing code. The specific implementation is as follows: The first carrier 100 (a dedicated runtime container for the smart fire management cloud platform) is constructed. The first carrier 100 is a no-code configuration dedicated runtime container based on the Spring Cloud microservice architecture. It is the core runtime carrier and logical encapsulation unit for the visualization configuration function. Each first carrier 100 uniquely corresponds to a smart fire management cloud platform configuration project. The project is divided into five major directory structures: basic configuration, data model, visualization module, process configuration, and deployment management.

[0197] This container integrates four core engines: a metadata parsing engine, a configuration engine, an access control engine, and a module scheduling engine. It supports parallel deployment of multiple instances, and the instances are isolated from each other in terms of CPU, memory, and storage through K8s namespaces and independent Pods. Each instance is assigned a unique 32-bit alphanumeric instance ID, and service registration and discovery are achieved through Nacos. It supports elastic scaling of instances, ensures stable operation in high-concurrency device access scenarios, and provides a core carrier for independent operation and logical encapsulation of all smart fire protection business functions.

[0198] Access data source 200 (real-time operation data of fire-fighting equipment, energy consumption monitoring data, alarm event data, equipment operation and maintenance data, facility classification data, etc.) is compatible with IoT-collected data from various fire-fighting equipment such as smart power detectors, fire-fighting power supplies, fire doors, and NB-IoT gas sensors, as well as business data from energy consumption collection systems, alarm management systems, and operation and maintenance work order systems. Rapid access is achieved through a built-in standardized driver. Data source connection parameters are configured (including device gateway address, port, access account, encrypted password, etc., with the password stored using the AES-256 encryption algorithm). After connectivity verification via a heartbeat mechanism, a directional association is established between the first carrier 100 and the data source 200. The connectivity status is synchronized in real-time to the configured data source control 202, providing raw data support for subsequent data model construction and visualization.

[0199] Based on data source 200, a structured data model 201 is constructed. Data model 201 is the core data abstract model of the smart fire protection scenario, covering five major categories: fire protection equipment, energy consumption monitoring, alarm events, facility classification, and operation and maintenance work orders. It defines core fields such as equipment ID, status, location, energy consumption value, alarm type, and work order processing status, as well as inter-table association rules, clarifying the relationship between equipment and energy consumption data, and alarms and operation and maintenance work orders. After synchronizing data model 201 to the first carrier 100, the configuration engine built into the first carrier 100 parses the metadata of data model 201 and automatically constructs the basic visual module 101 covering the homepage dashboard, data monitoring page, energy consumption overview page, and energy consumption report page, realizing the standardized and visualized display of core smart fire protection data.

[0200] By using the customized visual component 403 of the model visual module 400, the basic visual module 101 is customized to form a customized visual module 102, adapting to the display needs of different business scenarios. In the homepage large screen scenario, a national fire equipment map location monitoring module, a project overview card module, and a facility classification statistics module are customized to form a national fire equipment map location monitoring module, a project overview card module, and a facility classification statistics module. The equipment locations are marked on the national map and abnormal locations are highlighted in red. At the same time, key indicators such as the number of unresolved alarms and the proportion of offline devices are highlighted. The quantity proportion is displayed according to facility types such as mini fire stations and fire trucks. Finally, they are spliced ​​together to form a one-stop monitoring visualization large screen.

[0201] In data monitoring scenarios, customized modules for equipment status filtering, equipment category tags, and equipment list tables are provided. These modules support filtering by equipment status and type, adding color markers to devices in different statuses, and providing pagination and keyword search functions to achieve refined monitoring and management of equipment. In energy consumption overview scenarios, customized modules for daily average load curves, peak load statistics, month-on-month analysis, and load trend bar charts are provided. These modules compare today's and yesterday's load curves, marking peak points and corresponding times, highlighting peak loads and their occurrence times, comparing multi-period energy consumption data trends in card format, displaying load distribution by time period, and marking average load lines to achieve multi-dimensional analysis of energy consumption data. In energy consumption reporting scenarios, customized modules for time-period energy consumption statistics reports, regional energy consumption summary, and report export are provided. These modules display energy consumption values ​​for each region and equipment by hour, automatically summarizing time-period energy consumption for each region and displaying the total row. Multi-format export buttons are added to support exporting energy consumption reports by day / month, enabling statistical accumulation and reuse of energy consumption data.

[0202] The configuration process (fire hazard handling process and equipment operation and maintenance process) binds the customized visual module 102 to the process nodes. The fire hazard handling process includes four stages: alarm reception, hazard dispatch, handling feedback, and closed-loop confirmation. It is bound to the alarm classification module and the equipment list module. When an equipment alarms, a hazard work order is automatically generated and transferred to the corresponding operation and maintenance personnel. After handling, the alarm status is updated and the closed loop is completed. The equipment operation and maintenance process includes four stages: fault reporting, dispatching repair work order, acceptance confirmation, and closed loop. It is bound to the equipment status module. When equipment is offline or malfunctions, an operation and maintenance work order is automatically generated. After repair, the equipment status is updated and synchronized to the large screen. The system performs matching degree verification on the interface parameters and data flow between the customized visual module 102 and the process nodes according to the preset rule model to ensure the connectivity of the process logic and the consistency of data.

[0203] The verification module 600 performs visual verification and optimization of the customized visual module 102 and the process: it simulates user operation test equipment status switching, alarm event triggering, energy consumption data update and other scenarios, collects performance indicators such as page rendering time, data loading speed and process response time, locates abnormal links based on monitoring results, and optimizes the configuration through incremental update until both functions and performance meet the standards.

[0204] The first carrier 100 is deployed in a multi-tenant deployment mode. The platform can be deployed in multiple environments and modified online through the deployment update module 700. It supports online adjustment of the layout of the visual module and process rules, triggers an instant refresh mechanism, and updates the configuration configuration synchronously without interrupting the service, so as to realize the dynamic iteration of the platform.

[0205] The platform's functionality is enhanced by utilizing the dedicated configuration units of extension module 800: Large screen configuration unit 108 is invoked to drag and drop the homepage components of customized visual module 102 to create a visual large screen for the smart fire management cloud platform; Report configuration unit 107 is invoked to generate daily, monthly, and annual energy consumption reports based on the energy consumption data model, supporting online preview, printing, and export in multiple formats; WEB configuration unit 109 is invoked to build the platform's WEB-side operation interface, supporting multi-terminal adaptation and access on PCs and tablets.

[0206] This embodiment rapidly completed the construction of a smart fire protection equipment monitoring and energy management platform through a no-code configuration development method and system. It fully demonstrates the application of core technical features such as the first carrier 100, data model 201, basic visual module 101, customized visual module 102, process, and extension module 800 in smart fire protection scenarios, and verifies the practicality and scalability of this embodiment in the fields of industrial Internet of Things and smart cities.

[0207] 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 model-driven, no-code configuration development method, characterized in that, include: Construct multiple parallel first carriers (100), each first carrier (100) has built-in functional modules for performing visual data processing and interface display, configures basic attributes and access rules, establishes a directional association with the data source (200), and stores all operations in the form of metadata; Based on the data source (200), a structured data model (201) is visually constructed, the core structure and inter-table association rules are defined and synchronized to the first carrier (100), and the configuration engine built into the first carrier (100) parses the metadata of the data model (201), thereby automatically constructing the basic visual module (101) and data processing services, and forming a customized visual module (102) through visual configuration customization. The field changes of the data model (201) are automatically synchronized to the basic visual module (101) and the associated controls of the customized visual module (102) of the first carrier (100) through the control linkage mechanism; The process is configured visually, the customized visual module (102) is bound to the process node and the business rules are configured. According to the preset rule model, the interface parameters and data flow direction between the customized visual module (102) and the process node are checked for matching degree to ensure the connectivity of the process logic. When configuring the process, the process framework is constructed by moving and connecting nodes. The customized visual module (102) bound to the process node automatically inherits the field permissions of the data model (201). The visibility and editability of the control of the customized visual module (102) are linked with the access rules of the first carrier (100). Different roles of users present differentiated views when viewing process nodes. Visual verification and optimization of the customized visual module (102) and process are carried out, and the operation performance indicators are monitored in real time. Based on the monitoring results, the preceding configuration links are adjusted in reverse. During the verification and optimization, simulate user operation to test the control response, data submission and smooth flow of the basic visual module (101) and customized visual module (102) of the first carrier (100), and collect performance indicators such as rendering time of the basic visual module (101), data loading speed of the customized visual module (102) and process response time; When the performance indicators are abnormal, priority is given to locating the binding status of controls in the customized visual module (102) and fields in the data model (201), as well as the association between process nodes and the customized visual module (102). When modifying abnormal links, the field adjustment of the data model (201) is automatically synchronized to the associated controls and corresponding nodes of the process of the customized visual module (102) through the control linkage mechanism. The access rule change of the first carrier (100) updates the control permission status of the basic visual module (101) and the customized visual module (102) in real time. After modification, it is re-verified until the functions and performance of the two types of visual modules meet the standards. Select multiple deployment modes to publish the first carrier (100), support online modification of configuration configuration and dynamic updates through an instant refresh mechanism; After online configuration modification, an instant refresh mechanism is triggered. Changes to the fields of the data model (201) or adjustments to the controls of the customized visual module (102) are automatically synchronized to the corresponding node view of the process. Modifications to the reused visual resources are synchronously updated to the configuration of all carriers that reference the visual resources.

2. The model-driven no-code configuration development method as described in claim 1, characterized in that: When constructing the first carrier (100), the basic attributes configured include carrier name and WEB application identifier. The access rules include role-based hierarchical permissions and operation permission control rules. The access rules are directly mapped to the control operation permissions of its built-in basic visual module (101) and customized visual module (102). The data source (200) supports mainstream relational databases, time-series databases and big data systems. After configuring connection parameters and verifying connectivity, an association is established. The connectivity status is synchronized to the configured data source control (202) in real time. The data source control (202) is the association configuration control of the data model (201). The first carrier (100) supports cross-carrier reuse of data tables, layout templates and functional components. After compatibility verification, the metadata of the reused resources can be directly moved to the view editing area (103) of the current carrier for quick adaptation. The view editing area (103) is the configuration operation area of ​​the first carrier (100).

3. The model-driven no-code configuration development method as described in claim 1 or 2, characterized in that: When visually constructing the data model (201), directly import the data table structure reused from the first carrier (100), define field attributes and constraints through the field configuration area (203) of the data model (201), and set the association type through the association configuration area (204); The basic visual module (101) synchronously generates basic operation views for adding, deleting, modifying and querying. Its layout structure is bound one by one to the core functions of the data processing service. The call results of the data processing service are displayed to the controls of the basic visual module (101) in real time. During the configuration of the customized visual module (102), it is implemented through the customized visual component (403) of the model visual module (400). The customized visual component (403) is the core execution component of the visualization function of the first carrier (100), which includes a classified control library, multiple layout tools and a multi-terminal preview unit (104). It supports control movement and positioning, attribute visualization configuration and event logic graphical editing. The multi-terminal effect is switched in real time through the multi-terminal preview unit (104), and the control elements automatically adapt to the size.

4. The model-driven no-code configuration development method as described in claim 3, characterized in that: The approval entity supports static designation and dynamic assignment. The dynamic assignment logic can call the query function of the data processing service to obtain personnel data. The query results are displayed for selection through drop-down control (105) or pop-up unit (106). The drop-down control (105) and pop-up unit (106) are both built-in interactive controls of the customized visual component (403). Encapsulate the core approval actions and flow rules. When the system verifies the integrity of the process, it simultaneously verifies the binding validity of the process nodes and the control of the customized visual module (102), and the consistency of the association between the fields of the customized visual module (102) and the data model (201).

5. The model-driven no-code configuration development method as described in claim 4, characterized in that: The deployment modes include multi-tenant, independent server and third-party PaaS platform deployment. When verifying the configuration integrity, the focus is on verifying the binding validity of the basic visual module (101) and the customized visual module (102) of the first carrier (100) and the data model (201), as well as the consistency of the association of cross-carrier reused visualization resources. After release, the supported reports, data dashboards and WEB configurations are all constructed through the dedicated configuration units of the extension module (800). The dedicated configuration units include the report configuration unit (107), the dashboard configuration unit (108) and the WEB configuration unit (109). All three are extension units of the visualization function of the first carrier (100). They support the movable configuration of column fields and statistical dimensions, provide template library and movable layout, drag and drop to draw on-site monitoring views, and directly call the real-time data of the data model (201). Their access permissions are consistent with the access rules of the first carrier (100).

6. A model-driven, no-code configuration development system, characterized in that: Based on the model-driven no-code configuration development method as described in any one of claims 1 to 5, include, The carrier module (300) is used to visually construct the first carrier (100), configure basic attributes, access rules and data source association parameters, support cross-carrier resource reuse, generate and store relevant metadata, and its output permission metadata and resource metadata are synchronized to the visualization-related modules. The model visualization module (400) receives metadata from the carrier module (300), including a data model building component (401), a basic visualization generation component (402), and a customized visualization component (403), which are used to build a data model (201), automatically generate a basic visualization module (101) for the first carrier (100), and provide data processing services and customized visualization modules (102), supporting multi-terminal adaptation and real-time preview. The process module (500) receives the visualization metadata of the model visualization module (400) and the permission metadata of the carrier module (300), including the process configuration component (501), the rule configuration component (502) and the closed-loop verification component (503), which are used to realize the binding of the customized visualization module (102) with the process node and the rule configuration, and automatically verify and generate process metadata; The verification module (600) receives metadata from each module, including the functional performance monitoring component (601) and the feedback linkage component (602), for functional testing, process flow testing and performance monitoring of the basic visual module (101) and customized visual module (102) of the first carrier (100), to locate abnormal links and support iterative verification after modification; The deployment and update module (700) receives metadata from each module and is used for configuring multiple deployment modes, online configuration visualization modification, and real-time refresh updates. It is the core module for system deployment and updates. The extension module (800) receives the visualization metadata of the model visualization module (400) and the permission metadata of the carrier module (300), including the data display component (801) and the permission control component (802), which are used to provide extended data visualization display and permission control functions.

7. The model-driven no-code configuration development system as described in claim 6, characterized in that: The carrier module (300) includes a carrier configuration component (301), a data source access component (302), and a resource reuse component (303). The carrier configuration component (301) collects and generates metadata of the first carrier (100), and the access rule metadata defined therein is synchronized to the permission unit (404) of the model visualization module (400). The permission unit (404) is a built-in functional unit of the customized visualization component (403). The data source access component (302) adapts to mainstream data source types, configures connection parameters and verifies connectivity, and generates connection status metadata that is synchronized in real time to the data source control (202) of the model visualization module (400). The resource reuse component (303) provides a cross-carrier retrieval unit (304), which supports keyword search and classification filtering of data tables, layout templates and functional components. The output reused resource metadata can be directly called by the data model construction component (401) and the customized visual component (403).

8. The model-driven no-code configuration development system as described in claim 6 or 7, characterized in that: The data model building component (401) provides a field configuration area (203) and an association configuration area (204) for the data model (201), receives connection status metadata from the data source access component (302), and can call the reuse data table of the resource reuse component (303) to generate metadata for the data model (201). The basic visual generation component (402) automatically generates the basic visual module (101) and data processing service metadata of the first carrier (100) based on the metadata call template library of the data model (201). The permission attributes of its controls are linked with the access rule metadata of the permission unit (404). The customized visual component (403) provides a categorized control library, multiple layout tools, an attribute panel (405), and a multi-terminal preview unit (104). It receives field metadata from the data model building component (401), adjusts control styles and edits event logic through the attribute panel (405), and synchronizes the generated customized visual module (102) metadata to the process module (500).

9. The model-driven no-code configuration development system as described in claim 8, characterized in that: The process configuration component (501) provides a process canvas (504) and a node library, receives metadata of the customized visual module (102) of the customized visual component (403), supports directly moving and binding the customized visual module (102) to the process node, and generates basic process framework metadata. The rule configuration component (502) provides a permission configuration unit (505) and a rule editing panel (506), reads the field permission metadata of the data model building component (401), and binds the controls and process rules of the customized visual module (102) through the permission configuration unit (505). Its approval permission is consistent with the access rule metadata of the permission unit (404) to form a linkage. The closed-loop verification component (503) receives the framework metadata of the process configuration component (501) and the associated metadata of the rule configuration component (502), verifies the binding validity of the process node and the customized visual module (102), the consistency of the fields of the customized visual module (102) and the data model (201), and outputs the complete process metadata to the verification module (600).

10. The model-driven no-code configuration development system as described in claim 9, characterized in that: The functional performance monitoring component (601) provides a test configuration unit (603) and performance charts (604), receives complete process metadata from the closed-loop verification component (503), simulates the control response and process flow of the basic visual module (101) and customized visual module (102) of the user operation test first carrier (100), collects the rendering time, data loading speed and other indicators of the two types of visual modules and compares them with preset thresholds to generate abnormal monitoring results; The revert and modification linkage component (602) sends revert and modification instructions to the data model building component (401), the customized visualization component (403), and the process configuration component (501) based on the anomaly monitoring results. It supports one-click jump to the corresponding visualization editing, model modification, or process configuration unit, receives the modified metadata, and triggers re-verification. The deployment update module (700) receives qualified metadata from the verification module (600), supports multi-mode deployment and online visual editing, and synchronizes the changed metadata of each module through an instant refresh mechanism, so as to realize incremental updates of the two types of visual modules and processes of the first carrier (100) without interrupting the service.

11. The model-driven no-code configuration development system as described in claim 10, characterized in that: The data display component (801) integrates the report configuration unit (107), large screen configuration unit (108) and WEB configuration unit (109) of the first carrier (100). All three receive real-time data metadata from the data model construction component (401) to realize the linkage between data visualization display and equipment monitoring. The permission control component (802) provides an architecture configuration unit (803), a role allocation unit (804), and a prompting unit (805). It receives access rule metadata from the carrier configuration component (301), maintains organizational and personnel metadata through the architecture configuration unit (803), defines the access permissions of roles to the two types of visualization modules of the first carrier (100) through the role allocation unit (804), generates a permission control matrix, synchronizes it to the data display component (801) and the customized visualization component (403), and intercepts unauthorized operations and pops up prompts through the prompting unit (805).

Images