Equipment and application data rapid configuration and release method, system and platform

Abstract

The invention discloses a method, a system and a platform for quickly configuring and releasing equipment and application data, and the method comprises the following steps: constructing a configuration database in a configuration environment, and receiving input data of different dimensions according to preset role division and authority; configuring multiple stages of operating environments, respectively setting database configurations corresponding to the operating environments, and establishing a connection channel between the configuration platform and each operating environment database; in response to the development synchronization instruction, synchronizing the target data in the configuration database to the development environment through the connection channel; receiving a test application, and synchronizing the database data of the corresponding development environment to the test environment for testing after the test application passes the examination and approval of the first examination and approval node; and receiving the release application, and locking the current data snapshot of the test environment and synchronizing the current data snapshot to the database of the formal environment after the release application is approved by the second approval node. According to the method, the release threshold can be reduced, development resources are saved, agile iteration is realized, and the safety and reliability of the system are improved.

Description

Technical Field

[0001] This invention belongs to the field of Internet of Things and computer data processing technology, and specifically relates to a method, system and platform for rapid configuration and release of device and application data. Background Technology

[0002] With the rapid development of Internet of Things (IoT) technology, an increasing number of smart devices are connecting to IoT platforms. In real-world business scenarios, there are frequent needs for new device integration or functional iterations of existing devices. For example, newly integrated devices may have the same software functionality as existing devices, differing only in appearance or local hardware interfaces; or, existing devices may require adjustments to some application configurations, such as the UI and onboarding documentation. During the integration of new devices into the IoT platform, there are often situations where newly integrated devices differ from existing devices only in appearance or local hardware functionality, but have the same software functionality. There are also situations where basic application data configuration modifications are needed for existing devices.

[0003] In existing technical solutions, implementing access, deployment, or data modification for a device typically involves collaboration across multiple stages and different roles. Specifically, the device's basic product information is usually configured by the device developers, the device's object model information is configured by the IoT platform developers, and the application business data of the device on mobile devices or terminals is configured by the product manager.

[0004] However, the existing device and application data publishing process has the following shortcomings: Different configuration data is entered by personnel with different functions in their respective dimensions, lacking effective correlation and a unified management process. Due to the lack of systematic coordination between different personnel, errors, conflicts, or missing key information in the configuration data are easily caused, seriously affecting the quality of device deployment.

[0005] Currently, data deployment primarily relies on technical personnel. After configuration data is entered, IoT platform developers typically need to write or execute database scripts to manually synchronize the data from the development environment to the test environment. Only after successful verification can the data be deployed to the production environment. This approach prevents non-technical personnel (such as product managers and operations staff) from independently completing the deployment process, increasing communication and manpower costs and reducing the efficiency of business iteration.

[0006] Publishing data by manually executing scripts lacks strict process control and version management. If the script is written incorrectly or the execution environment is chosen inappropriately, it can easily disrupt the stability of the online environment and make it difficult to trace the fault and roll back quickly. Summary of the Invention

[0007] This invention provides a method, system, and platform for rapid configuration and release of device and application data, aiming to solve problems such as the lack of effective correlation and unified management processes, high communication and labor costs, and insufficient stability of the online environment in existing technologies.

[0008] To address the aforementioned technical problems, this invention proposes a method for rapid configuration and publication of device and application data, comprising the following steps: A configuration database is built in the configuration environment, and data from different business dimensions is received and stored according to the preset role division and permissions. Configure multi-level operating environments, set the database configuration for each operating environment, and establish a connection channel between the configuration platform and the database of each operating environment. In response to the development synchronization command, the target data in the configuration database is synchronized to the database in the development environment through the connection channel for joint debugging and testing; After the development environment integration is completed, a test application is received; after the first approval node approves the application, the database data of the corresponding development environment is synchronized to the database of the test environment for testing. After the test environment passes the test, the release application is received; after the second approval node approves it, the current data snapshot of the test environment is locked and synchronized to the database of the production environment.

[0009] Preferably, when synchronizing the current data snapshot to the production environment database, the method further includes the following steps: When data is published to the production environment, a version log file containing the published content is automatically generated for version rollback or difference comparison.

[0010] Preferably, the generation and application of the version record file includes: Record all version data for each release to the production environment in JSON format; In response to a version comparison command, retrieve JSON data from two different versions, perform a differential comparison, and identify the data changes.

[0011] Preferably, the data synchronization in the production environment is configured to: prohibit direct data synchronization from the configuration database, and only allow synchronization of data originating from the test environment that has been approved.

[0012] Preferably, the entered data specifically includes: Basic equipment information, including product model, software model, software product model, and equipment model data; Equipment model data, including equipment function definitions, attribute definitions, and event handling mechanisms; Application business data, including automation function configuration, product network configuration and reset process configuration, service data configuration, new user guide configuration and button layout configuration.

[0013] Preferably, the process of receiving and storing data from different business dimensions further includes steps for access control and logging: Create a role table, divide operation permissions into menu permissions and button permissions, and divide data permissions into dimensions of individual, department, specific department, and all-employee visibility; By using custom annotations to mark the operation interface, and using interceptors to parse the current operation account information, the operation content, account, and time are stored in the operation log table.

[0014] Preferably, the configuration method for the first approval node and the second approval node is as follows: A fixed approval process is built using a workflow engine, and only personnel configuration permissions are granted for approval nodes; Configure a notification mechanism to send notifications to designated approvers via instant messaging, email, or SMS when the process reaches the approval node.

[0015] Preferably, the specific execution logic for locking the current data snapshot of the test environment and synchronizing it to the database of the production environment is as follows: Determine whether the data to be released has already been approved in the test or pre-production environment; If the approval is not granted, the operation will be rejected. If approved, data synchronization will be performed, and each approved data snapshot will be limited to being released to the production environment only once.

[0016] Preferably, after taking a snapshot of the current data and synchronizing it to the production environment database, the method implements the following control policy for data modification permissions in the configuration database: If the data being published is basic device information, modification of the published version is prohibited. If the published data is application business data, it is allowed to be modified in the configuration database. The modified data needs to be synchronized again from the configuration database to the development environment database, the test environment database, and the production environment database.

[0017] On the other hand, the present invention also proposes a rapid configuration and release system for device and application data, characterized in that the system is used to implement the rapid configuration and release method as described in the first aspect of the present invention, including: The configuration database building module is used to build a configuration database in the configuration environment. Based on the preset role division and permissions, it receives and stores the input data from different business dimensions. The environment channel management module is used to configure multi-level operating environments, set the database configuration for each operating environment, and establish a connection channel between the configuration platform and the database of each operating environment. A development synchronization module is used to respond to development synchronization commands and synchronize the target data in the configuration database to the database in the development environment through the connection channel for joint debugging and testing. The test workflow module is used to receive test requests after the development environment integration is completed; after the first approval node approves the request, it synchronizes the database data of the corresponding development environment to the database of the test environment for testing. The official release module is used to receive release requests after the test environment has passed the test; after the second approval node approves the request, it locks the current data snapshot of the test environment and synchronizes it to the database of the production environment.

[0018] A third aspect of the present invention also provides an Internet of Things (IoT) device and application data configuration and publishing platform, the platform comprising: The configuration management layer is used to provide the configuration environment and configuration database, receive and store IoT data such as basic device information, device model data and application business data, and control the data entry according to preset role permissions; The environment flow control layer is used to configure multi-level operating environments, including development, testing and production environments, and their corresponding database connection channels. It controls the flow of configuration data based on a preset approval process to ensure that data is synchronized in an orderly and controlled manner from development and testing to the production environment. The version and backtracking layer is used to lock the current data snapshot of the test environment when data is synchronized to the database of the production environment, and automatically generate version record files to support version backtracking and difference comparison functions; The data security release layer is used to implement policies that prohibit direct synchronization of data from the configuration database to the production environment. It only allows the synchronization of data snapshots that have been approved from the test environment and limits the number of times each approved data snapshot can be released. The permissions and logging layer is used to establish role permission tables and operation log tables, and to control permissions and record logs for all operations during the data configuration and publishing process.

[0019] Compared with the prior art, the present invention has the following technical effects: 1. The rapid configuration and deployment method proposed in this invention decouples the input of basic device information, object models, and application business data from the underlying code development. For new devices with the same functionality but different hardware / appearance, or existing devices that only require adjustments to application configuration, relevant personnel do not need to write code or rely on technical personnel to execute complex database scripts; deployment can be completed simply through platform configuration. This greatly lowers the deployment threshold, saves development resources, and enables agile iteration.

[0020] 2. The rapid configuration and deployment method proposed in this invention replaces the traditional manual SQL script deployment method by establishing a connection channel between the configuration platform and various operating environments. The automated synchronization mechanism avoids online incidents caused by human error. Simultaneously, the system enforces a data flow path from development to testing to production, ensuring data consistency across different environments and preventing environment configuration drift issues.

[0021] 3. The rapid configuration and deployment method proposed in this invention establishes an approval mechanism based on a workflow engine and implements a strict data source control strategy. Specifically for production environments, the system's underlying logic prohibits direct data synchronization from the configuration source, allowing only the synchronization of data snapshots from the test environment that have been approved. This prevents unverified data or temporarily modified dirty data from entering the production environment, improving the system's security and reliability.

[0022] 4. The rapid configuration and deployment method proposed in this invention decouples the work interfaces and data permissions of different roles such as device developers, platform developers, and product managers through granular role-based access control, making multi-department collaboration processes clearer and more standardized. Simultaneously, by combining full-process operation log recording and a JSON-formatted version snapshot mechanism, the system can record detailed information about every data change. When a fault occurs, maintenance personnel can quickly locate the cause of the problem through version difference comparison and support historical version rollback, improving system maintainability and fault response speed. Attached Figure Description

[0023] Figure 1 This is a flowchart illustrating the rapid configuration and deployment method described in this invention. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below in conjunction with specific embodiments of the present application and with reference to the accompanying drawings.

[0025] Example 1 This embodiment describes a method for rapidly configuring and publishing device and application data, such as... Figure 1 As shown, it includes the following steps one through five: Step 1: Build a configuration database in the configuration environment, and receive and store data from different business dimensions according to the preset role division and permissions.

[0026] The specific data entry in this step includes: Basic equipment information, including product model, software model, software product model, and equipment model data; Equipment model data, including equipment function definitions, attribute definitions, and event handling mechanisms; Application business data, including automation function configuration, product network configuration and reset process configuration, service data configuration, new user guide configuration and button layout configuration.

[0027] This step primarily completes the initialization of the configuration database, the construction of the role and permission system, and the structured entry of multi-dimensional business data. This step is the foundation for the subsequent automated flow of data between different environments. The specific implementation process is as follows: steps S11 to S13: S11: Configuring the Environment and Building the Database First, deploy a configuration environment within a physically or logically isolated intranet environment. Within this environment, build a configuration database as the sole source repository for all device and application data. This database stores product data that has not yet been released or is currently being iterated, and is physically or logically decoupled from subsequent development, testing, and production environment databases to ensure the purity of the source data.

[0028] S12: Establish a role-based division of labor and access control mechanism To address the issues of fragmented configurations and unclear responsibilities in traditional development, this embodiment establishes a refined permission management system.

[0029] Role Definitions: The system pre-defines multiple roles, including device developers (responsible for basic hardware information), platform developers (responsible for object models and technical configuration), product managers (responsible for application business data), and testers / administrators.

[0030] In terms of permissions, this includes functional permissions and data permissions; Functional permissions are further divided into menu permissions (which pages a user can see) and button permissions (which operations a user can perform, such as adding, synchronizing, and approving).

[0031] Data permissions are divided into personal level (only view the data entered by the user), department level (view data of the user's own department), designated department level (cross-department collaboration), and all-user visible level.

[0032] For example, after logging in, device developers only have editing permissions for the device basic information module, and their data permissions are limited to viewing only their own department; while product managers have permissions for the application business data module.

[0033] S13: Input of multi-dimensional data Based on the above permission system, different roles concurrently or sequentially enter three types of core data into the configuration database: basic device information, device model data, and application business data.

[0034] For basic device data, device developers or product managers can enter the basic identification information of the devices through a web front-end interface or import it in batches using Excel templates. Specific fields include: product model (a unique number used to identify the device, such as "DoorBell-V1"), software model (identifying the device firmware version), software product model (a unique identifier for the same type of device on the platform, serving as the core key value for linking subsequent data), and device model.

[0035] For device model data, platform developers construct the device's physical model in the system based on the technical documentation provided by the device developer. Specific content includes: function definition, defining the device's capabilities (e.g., "unlock," "talk"); attribute definition, defining the device's status parameters (e.g., volume: 0-100, battery level: percentage); and event handling mechanism, defining the events reported by the device (e.g., someone ringing the bell, tamper alarm) and the corresponding server-side processing logic.

[0036] For application business data, product managers or platform developers configure the device's performance logic on mobile apps or terminals. This data is strongly correlated with the "software product model." Specific content includes: automation function configuration, defining which conditions or actions the device supports in smart scenarios (e.g., triggering a push notification when someone rings the bell); product network configuration and reset process, uploading a network configuration guide GIF and configuring the long-press duration text for the reset button; service data configuration, configuring the icon and service card style displayed on the app's homepage; and new user onboarding and button layout, configuring the onboarding overlay when a user binds the device for the first time, as well as the function mapping layout of physical buttons or on-screen buttons.

[0037] In a preferred embodiment of the present invention, this step of receiving and storing data from different business dimensions also includes steps of access control and logging: Create a role table, divide operation permissions into menu permissions and button permissions, and divide data permissions into dimensions of individual, department, specific department, and all-employee visibility; By using custom annotations to mark the operation interface, and using interceptors to parse the current operation account information, the operation content, account, and time are stored in the operation log table.

[0038] Specifically, for custom annotations, the developers defined a Java annotation called @LogOperation, which includes attributes such as the operation module and operation type.

[0039] For interceptor implementations, add this annotation to the backend Controller layer interface. The system is configured with AOP interceptors or Spring Interceptors.

[0040] When a user calls an input interface (such as saveDeviceInfo), the interceptor automatically captures the request, parses the Token in the request header to obtain the current operating account, captures the request parameters as the operation content, and records the system time. This information is asynchronously written to a separate sys_operation_log table. In the event of a configuration error, the administrator can directly query the log table to pinpoint which account modified which critical configuration at what time, thus quickly assigning responsibility and rolling back the changes.

[0041] Step two involves configuring a multi-level runtime environment, which includes at least a development environment, a testing environment, and a production environment. Database configurations are then set for each runtime environment, including database connection addresses, ports, and account information, establishing connection channels between the configuration platform and the databases of each runtime environment. This step primarily defines the target environment for deployment and lays the underlying communication links, achieving a trusted connection between the configuration platform (acting as the central control terminal) and the databases of each physically isolated business environment.

[0042] To adapt to different stages of the software lifecycle, the system presets or supports the addition of custom multi-level runtime environments. In this embodiment, four typical runtime environments are constructed: Development environment: Used by R&D personnel for code writing and integration testing, with frequent data changes, and is usually deployed on the intranet development network segment.

[0043] Testing environment: Used by testers to perform functional verification and bug reproduction; the data is relatively stable.

[0044] Pre-production environment: As the last line of defense before the official release, its network architecture and data volume simulate the real environment to verify the compatibility of configuration data.

[0045] Formal environment: A production environment that serves real users, deployed in the cloud or a high-security core network segment, with strict approval restrictions on data writing.

[0046] In the environment configuration module of the configuration platform, administrators configure the corresponding database connection information for each of the aforementioned environments. The system provides a visual form to receive the database IP address (or domain name), port number (e.g., 3306), database name, access account, and access password entered by the administrator. Considering that database account passwords are highly sensitive information, the system does not store them in plaintext in the configuration platform's database. The system uses the AES-256 symmetric encryption algorithm to encrypt the entered password before storing it in the configuration table (sys_env_config), and decrypts it in memory only at the moment a synchronization request is initiated, ensuring credential security.

[0047] In this embodiment, the connection channel is not a physically persistent long-lived connection, but rather a dynamic data source routing mechanism based on configuration information. The specific implementation logic is as follows: The configuration platform integrates JDBC drivers for mainstream databases (such as MySQL, Oracle, or PostgreSQL). To improve deployment efficiency, the system employs database connection pooling technology (such as Druid or HikariCP). After configuration, the system does not immediately establish all connections but provides a "commonality test" function. When an administrator clicks the test connection or the system executes a data synchronization command, the background service reads the encrypted information from the configuration table, decrypts it, and assembles it into a JDBC URL. The system then attempts to establish a connection using the assembled URL and the account password. If the connection succeeds, the environment is marked as online; if it fails, a specific error code is returned, prompting operations personnel to check network policies. For scenarios where the configuration platform is on an intranet while the production environment is on a public cloud, this connection channel may also include network layer mapping via SSH tunnels or VPN leased lines to ensure that data packets can securely cross network boundaries to reach the target database.

[0048] Step 3: Responding to the development synchronization command, the target data in the configuration database is synchronized to the database in the development environment via the connection channel for integration testing. This step mainly transforms the initially entered static data in the configuration platform into dynamic data that can be read and run by the application in the development environment. This step supports rapid iteration, allowing developers to modify and resynchronize multiple times during integration testing.

[0049] During the development and integration phase, developers log into the configuration platform and access the development synchronization module. The system interface displays a list of software product models already existing in the configuration database. Developers do not need to synchronize all data; instead, they can customize and select the target data to be debugged by checking boxes. For example, if a developer only modifies the button layout configuration of a switch panel, they only need to select the corresponding product model and application business data - button layout module, without needing to synchronize basic device information or object model data. When a developer clicks the "Synchronize to Development Environment" button, the front-end sends a development synchronization command to the back-end. This command carries a unique identifier (ID set) for the target data and an identifier for the target environment.

[0050] The backend service responds to the above instructions and executes the following data flow logic: Based on the ID in the instruction, the system queries and extracts the latest JSON or structured data from the configuration database. Then, the extracted data is converted into an executable SQL script for the target database, or assembled into a data packet of a specific format. During this process, the system automatically handles data relationships to ensure the integrity of parent and child table data. Next, the system calls the connection channel established in step two, using the pre-stored development environment database IP, port, and account to establish a temporary session. The converted data packet is then directly written to the development environment database. If data with the same name or ID already exists in the development environment, the system defaults to an overwrite strategy to ensure strict consistency between the development environment data and the configuration platform.

[0051] After data synchronization is complete, applications in the development environment (such as the development version of an app or a device emulator) directly connect to the development environment database and run. Developers can open the app and see the interface layout or new features they just modified in the configuration platform, without needing to recompile the code or restart the server. If configuration errors are found during integration testing, developers should not, and are not advised to, modify the configuration directly in the development environment database. Instead, they should return to the configuration platform, correct the corresponding data, save the corrections, and then click "Synchronize to Development Environment" again. The system will then re-execute the above extraction-overwrite process. This design ensures that the "configuration database" is always the single, reliable source of data, avoiding the problem of untraceable data loss due to temporary modifications to the development environment.

[0052] Considering that some development environments may be located on a completely offline intranet, this step also supports file-based synchronization: In response to the user's download command, the system packages the target data into an SQL file or a compressed package of a specific format. Developers download this file to their local machine, copy it to the development environment via USB flash drive or intranet file transfer tool, and manually import it into the database. This serves as a backup plan when the automated channel is unavailable.

[0053] Step four: After the development environment integration is completed, receive the test application. After approval by the first approval node, synchronize the corresponding database data from the development environment to the database of the test environment for testing. This step mainly realizes the controlled flow from development integration to formal testing. This step introduces an approval mechanism based on a workflow engine to ensure that only confirmed configuration data can be written to the test environment database.

[0054] Once developers have completed functional integration testing in the development environment and confirmed that the configuration data is correct, they can initiate a test submission request on the configuration platform. Developers select the software product model to be tested and click the "Submit Test" button. After receiving the request, the system automatically locks the currently selected configuration data snapshot. At this point, the system marks this batch of data as pending review. Before the review is completed, the system restricts arbitrary changes to this batch of data to ensure consistency between the approved content and the actual released content.

[0055] The configuration method for the first approval node is as follows: A workflow engine is used to build a fixed approval process, with only personnel configuration permissions granted for approval nodes. To achieve standardized process control, this embodiment integrates Activiti 6.0 (or other similar BPMN engines) as the core workflow component. The system solidifies the approval path in the underlying code or XML configuration to prevent operators from arbitrarily skipping approval steps or tampering with the process logic.

[0056] Configure a notification mechanism to send notifications to designated approvers via instant messaging, email, or SMS when the workflow reaches the approval node. When the test submission process reaches the first approval node, the workflow engine triggers the message notification service. Based on preset configurations, the system calls third-party API interfaces to send messages to designated approvers via WeChat / DingTalk, corporate email, or SMS.

[0057] After receiving the notification, the approver logs into the platform to view the application details. If the approval fails, the process terminates, and the system notifies the developers to make modifications. The developers need to correct the data in the configuration platform, re-execute step three (integration testing), and re-initiate the test submission. Once approved, the workflow engine automatically triggers a subsequent service task. This task calls the test environment connection channel established in step two to automatically synchronize the data packets in the pending approval status to the test environment database.

[0058] Step five: After the test environment passes testing, the release request is received. After approval by the second approval node, the current data snapshot of the test environment is locked and synchronized to the production environment's database. The configuration method for the second approval node is the same as that for the first approval node. This step is the final hurdle for data deployment. To ensure the absolute stability of the production environment, this step employs a source isolation and snapshot release technical architecture, strictly limiting the source and flow of data, and implementing differentiated post-release management strategies based on data type.

[0059] After testers complete full testing in the test or pre-production environment, they initiate a formal release request on the platform. The system reuses the workflow engine configuration from step four to initiate the second-level approval process. This second approval node is typically configured for a higher-level product director or operations manager. The system also sends approval notifications via WeChat, email, or SMS to ensure that the release action is known and authorized by management.

[0060] In this step, data synchronization in the production environment is configured to: prohibit direct data synchronization from the configuration database; only data originating from the test environment and approved is allowed. Although the system configures database connection information for the production environment, at the code logic level, the system prohibits the configuration database from directly initiating synchronization commands to the production environment database. The system only allows synchronization of data snapshots originating from the test environment or pre-production environment and marked as approved. Specifically, when a release command is triggered, the system verifies the source identifier of the data packet. If the source identifier points to the configuration database, the system throws an exception and intercepts the operation; only when the source identifier points to a snapshot of the test environment database is the operation allowed, thus eliminating the risk of inconsistencies between the tested and released versions due to temporary modifications.

[0061] The specific execution logic for locking the current data snapshot of the test environment and synchronizing it to the database of the production environment in this step is as follows: The system determines whether the data to be released has already been approved in the test or pre-production environment; it queries the metadata of the data to be released to determine whether it has the Status=APPROVED (approved) tag. If it has not been approved, the release operation is rejected. If approved, data synchronization is performed, and each approved data snapshot can only be released to the production environment once. Specifically, after approval, the system extracts the data snapshot generated in the test environment at the moment of approval and writes it to the production database through the connection channel to the production environment. Meanwhile, to prevent data overwrite risks caused by duplicate releases, the system implements a one-time consumption policy for each approved snapshot: once the data is successfully synchronized to the production environment, the system immediately marks the snapshot as Status=RELEASED. If the operator attempts to release the same version again, the system will detect this status mark, directly intercept it, and issue a warning.

[0062] Once the data is online, the system applies different modification permission control strategies based on the data's business attributes. In a preferred embodiment of the invention, after taking a snapshot of the current data and synchronizing it to the production environment's database, the method executes the following control strategy for data modification permissions in the configuration database: If the published data is basic device information, modification of the published version is prohibited. For basic device data such as product model and software model, once a publication record is generated, the system automatically locks the editing permissions of the corresponding record in the configuration database. If modifications are needed, users cannot directly modify the original record. The system will force users to create a new software product model and restart a completely new configuration process.

[0063] If the published data is application business data, modifications are allowed in the configuration database. Modified data must undergo a re-synchronization process across the configuration database, development environment database, test environment database, and production environment database. For application-layer data such as UI layout, onboarding, and network configuration processes, modifications are allowed in the configuration database (e.g., optimizing the onboarding text). After saving the changes, this data will not be automatically updated to the production environment. The system mandates that modified data undergo a complete synchronization process: step three (development synchronization), step four (testing workflow), and step five (production release). After successful testing, a re-application for release is submitted. Upon approval, a new version snapshot is generated and finally pushed to the production environment.

[0064] The specific synchronization process between the configuration database, development environment database, test environment database, and production environment database is as follows (steps three through five): Responding to the development synchronization command, the target data in the configuration database is synchronized to the development environment database through the automated connection channel for joint debugging and testing; after the development environment joint debugging is completed, a test application is received; after approval by the first approval node, the corresponding database data in the development environment is synchronized to the database in the test environment for testing; after the test environment test is passed, a release application is received; after approval by the second approval node, the current data snapshot of the test environment is locked and synchronized to the production environment database.

[0065] In one embodiment of the present invention, the method further includes the following steps when synchronizing the current data snapshot to the database in the production environment: When data is deployed to the production environment, a version log file containing the deployed content is automatically generated for version rollback or difference comparison. This step is primarily used to build a post-deployment data traceability system. The system records every change to the production environment through an immutable snapshot mechanism and provides visual comparison tools to help operations personnel quickly locate online failures caused by configuration changes.

[0066] The generation and application of the version record file include: Record all version data for each release to the production environment in JSON format; In response to a version comparison command, retrieve JSON data from two different versions, perform a differential comparison, and identify the data changes.

[0067] Once the formal release operation in step five is successfully executed (i.e., the data is successfully written to the production environment database), the system background asynchronously triggers a version recording task. The system performs cascading queries on all related data involved in this release. Using a JSON serialization tool, this structured data, scattered across multiple relational data tables, is converted into a full, nested JSON string. The system creates a new read-only record in the sys_version_log (version log table). This record contains: version number, publisher, release time, source environment identifier, and the large fields of the generated full JSON data mentioned above.

[0068] When online devices malfunction, such as the "Remote Unlock" button disappearing from the app after an upgrade of a certain access control machine, maintenance personnel can execute version comparison commands through the platform's version management module. They can select the current malfunctioning version (V2) and the previous normal version (V1) from the version list. The backend service retrieves the JSON data from both versions and uses a tree-structured difference comparison algorithm to recursively traverse and compare the JSON nodes. The system identifies the following three types of changes: Added: Key-value pairs or objects present in V2 but not in V1; Removed: Key-value pairs present in V1 but not in V2; Modified: The key is the same, but the value has changed. The system displays the comparison results in a highlighted format on the front end. For example, a two-column view or an inline comparison view can be used, with different colors used to identify the changed items.

[0069] Based on the comparison results above, operations and maintenance personnel can quickly locate the root cause of the problem. For example, through comparison, it was found that the attribute "unlock_button_visible":true" was removed under the appConfig node in version V2. Based on this, operations and maintenance personnel confirmed that the missing configuration caused the app buttons to disappear, rather than a code bug. Although this system prohibits direct modification of the production environment, in emergency situations, the system supports a "one-click rollback" function. This involves extracting a JSON snapshot of the previous normal version (V1), deserializing it into database SQL statements, and re-running the fast track from test environment verification to official release, restoring the production environment data to the V1 state, thereby restoring business operations in the shortest possible time.

[0070] Example 2 This embodiment is a rapid configuration and release system for device and application data. The system is characterized by implementing the rapid configuration and release method as described in Embodiment 1, including: The configuration database building module is used to build a configuration database in the configuration environment. Based on the preset role division and permissions, it receives and stores the input data from different business dimensions. The environment channel management module is used to configure multi-level operating environments, set the database configuration for each operating environment, and establish a connection channel between the configuration platform and the database of each operating environment. A development synchronization module is used to respond to development synchronization commands and synchronize the target data in the configuration database to the database in the development environment through the connection channel for joint debugging and testing. The test workflow module is used to receive test requests after the development environment integration is completed; after the first approval node approves the request, it synchronizes the database data of the corresponding development environment to the database of the test environment for testing. The official release module is used to receive release requests after the test environment has passed the test; after the second approval node approves the request, it locks the current data snapshot of the test environment and synchronizes it to the database of the production environment.

[0071] Example 3 This embodiment is an IoT device and application data configuration and publishing platform, the platform including: The configuration management layer is used to provide the configuration environment and configuration database, receive and store IoT data such as basic device information, device model data and application business data, and control the data entry according to preset role permissions; The environment flow control layer is used to configure multi-level operating environments, including development, testing and production environments, and their corresponding database connection channels. It controls the flow of configuration data based on a preset approval process to ensure that data is synchronized in an orderly and controlled manner from development and testing to the production environment. The version and backtracking layer is used to lock the current data snapshot of the test environment when data is synchronized to the database of the production environment, and automatically generate version record files to support version backtracking and difference comparison functions; The data security release layer is used to implement policies that prohibit direct synchronization of data from the configuration database to the production environment. It only allows the synchronization of data snapshots that have been approved from the test environment and limits the number of times each approved data snapshot can be released. The permissions and logging layer is used to establish role permission tables and operation log tables, and to control permissions and record logs for all operations during the data configuration and publishing process.

[0072] The above description is only a preferred embodiment of the present invention. It should be noted that those skilled in the art can make several modifications and improvements without departing from the inventive concept of the present invention, and these all fall within the protection scope of the present invention.

Claims

1. A device and a method for fast configuration and distribution of application data, characterized in that, The method comprises the following steps: configuring a configuration database in a configuration environment, receiving and storing input data of different business dimensions according to preset roles and permissions; configuring multiple levels of running environments, setting database configurations corresponding to each running environment, and establishing a connection channel between the configuration platform and the database of each running environment; in response to a development synchronization instruction, synchronizing target data in the configuration database to the database of the development environment through the connection channel for joint debugging and testing; after the joint debugging and testing of the development environment is completed, receiving a test application; after the first approval node is passed, synchronizing the database data of the corresponding development environment to the database of the test environment for testing; after the test environment test is passed, receiving a release application; after the second approval node is passed, locking the current data snapshot of the test environment and synchronizing it to the database of the formal environment.

2. The method of claim 1, wherein, When the current data snapshot is synchronized to the database of the formal environment, the method further comprises the following steps: when the data is released to the formal environment, automatically generating a version record file containing the release content for version backtracking or difference comparison; wherein the generation and application of the version record file comprises: recording the full version data released to the formal environment each time in JSON format; in response to a version comparison instruction, obtaining the JSON data of two different versions for differential comparison and identifying the data change items.

3. The method of claim 1, wherein, The data synchronization of the formal environment is configured to prohibit direct synchronization of data from the configuration database and only allow synchronization of data from the test environment that has passed the audit.

4. The method of claim 1, wherein, The input data specifically includes: device basic information, including product model, software model, software product model, and device model data; device model data, including function definition, attribute definition, and event handling mechanism of the device; application business data, including automation function configuration, product network configuration and reset process configuration, service data configuration, novice guide configuration, and key layout configuration.

5. The method of claim 1, wherein, The receiving and storing of input data of different business dimensions further comprises permission control and log recording steps: establish a role table, divide operation permissions into menu permissions and button permissions, and divide data permissions into personal, department, specified department, and full-employee visible dimensions; mark the operation interface with custom annotations, use interceptors to analyze the current operation account information, and store the operation content, account, and time in the operation log table.

6. The method of claim 1, wherein, The first approval node and the second approval node configuration method is: use a workflow engine to build a fixed approval process and only open personnel configuration permissions for the approval node; configure a notification mechanism to send notifications to designated approvers through instant messaging tools, emails, or SMS when the process flows to the approval node.

7. The method of claim 1, wherein, The specific execution logic of locking the current data snapshot of the test environment and synchronizing it to the database of the formal environment is: determine whether the current data to be released has passed the approval in the test environment or the pre-production environment; if not, refuse the release operation; if it passes the approval, perform data synchronization and limit each data snapshot that has passed the approval to be released to the formal environment only once.

8. The method of claim 1, wherein, The method performs the following control strategy on the data modification permission in the configuration database after synchronizing the current data snapshot to the database in the formal environment: If the published data is device basic information, modification on the published version is prohibited; If the published data is application business data, modification in the configuration database is allowed, and the modified data needs to re-execute the synchronization process of configuration database-development environment database-test environment database-formal environment database.

9. A device and application data fast configuration distribution system, characterized in that, The system is used to implement the method of any one of claims 1-8, comprising: A configuration database construction module is configured to construct a configuration database in a configuration environment, receive and store input data of different business dimensions according to a preset role division and permission; An environment channel management module is configured to configure multiple running environments, set the database configuration corresponding to each running environment, and establish a connection channel between the configuration platform and the database of each running environment; A development synchronization module is configured to synchronize target data in the configuration database to the database in the development environment through the connection channel in response to a development synchronization instruction, and perform joint debugging and testing; A test flow transfer module is configured to receive a test application after the joint debugging and testing in the development environment is completed, and synchronize the database data corresponding to the development environment to the database in the test environment for testing after the first approval node is passed; A formal release module is configured to receive a release application after the test in the test environment is passed, and lock the current data snapshot in the test environment and synchronize it to the database in the formal environment after the second approval node is passed.

10. An Internet of Things device and application data configuration publishing platform, characterized by, The platform comprises: A configuration management layer is configured to provide a configuration environment and a configuration database, receive and store Internet of Things data such as device basic information, device model data, and application business data, and control the input of data according to a preset role permission; An environment flow control layer is configured to configure multiple running environments including a development environment, a test environment, and a formal environment, and their corresponding database connection channels, and control the flow of configuration data based on a preset approval process to ensure the orderly and controlled synchronization of data from development, testing to the formal environment; A version and backtracking layer is configured to lock the current data snapshot in the test environment when the data is synchronized to the database in the formal environment, and automatically generate a version record file to support version backtracking and difference comparison functions; A data security release layer is configured to implement a strategy of prohibiting direct synchronization of data from the configuration database to the formal environment, allowing only synchronization of data snapshots from the test environment and approved, and limiting the number of releases of each approved data snapshot; A permission and log layer is configured to establish a role permission table and an operation log table, and perform permission control and log recording on all operations in the data configuration and release process.

Images