Metadata envelope protocol for heterogeneous devices and dynamic conversion method thereof

Abstract

This invention discloses a metadata envelope protocol and its dynamic conversion method for heterogeneous devices, relating to the field of data interaction technology between the Internet of Things (IoT) and heterogeneous devices. The method includes: defining a metadata envelope protocol to encapsulate the original messages from heterogeneous devices into a standardized envelope structure containing a metadata header and payload. The metadata header includes at least message identifier, timestamp, message direction, client identifier, and service identifier fields. Based on a configuration-driven dynamic conversion engine, configuration text is parsed using a finite state automaton to construct a configuration model containing a common script, named script, and rule chains. The rule chains in the configuration model consist of conditional expressions, target topics, and output templates. The conditional expressions are compiled and executed using the Aviator expression engine, and the output template supports two placeholder replacement mechanisms: JSONPath path extraction and script evaluation. A multi-level caching system is used to implement recursive routing from client identifier to product identifier, object model identifier, and finally to the converted configuration. The cache uses a double-checked locking lazy loading and version number comparison update strategy to ensure consistency. The metadata envelope protocol and dynamic conversion method proposed in this invention achieve protocol-independent access and format adaptive conversion of heterogeneous device messages, reducing the access cost of adding new device types and improving the data interoperability capabilities of the IoT platform.

Description

Technical Field

[0001] This invention belongs to the field of Internet of Things and heterogeneous device data interaction technology, specifically involving a metadata envelope protocol for heterogeneous devices and its dynamic conversion method. Background Technology

[0002] With the rapid development of IoT technology, smart devices are widely used in smart campuses, industrial control, and other fields. A large number of heterogeneous devices from different manufacturers and using different protocols are connected to IoT platforms, resulting in diverse data message formats, inconsistent field naming conventions, and significant differences in data encoding methods. Achieving protocol-independent access and adaptive format conversion for heterogeneous device messages has become a core technical challenge in the construction of IoT platforms.

[0003] Current mainstream heterogeneous device data access solutions mainly suffer from the following pain points: First, hard-coded adaptation methods have poor scalability. Traditional solutions require writing independent conversion code modules for each device type. The conversion logic is tightly coupled with the device protocol. When adding a new device type, the core code needs to be modified and redeployed, resulting in long development cycles, high maintenance costs, and code bloat leading to decreased system stability.

[0004] Second, there is a lack of a unified message encapsulation protocol. The original messages from different devices lack standardized metadata descriptions. IoT platforms cannot obtain routing information such as device identifiers, message direction, and service types without parsing the message body, resulting in message distribution relying on deep parsing, long processing links, and high latency.

[0005] Third, the transformation rules are tightly coupled with the runtime. Existing solutions embed transformation rules into business logic as Java code. Rule changes require recompilation and deployment, making hot updates impossible. Furthermore, the expressive power of the rules is limited by the characteristics of programming languages, making it impossible for non-technical personnel to participate in rule configuration, thus reducing business response speed.

[0006] Fourth, the caching and routing strategies are inadequate. Obtaining device conversion configurations typically involves multi-level queries (device → product → object model → service configuration). Without an efficient caching mechanism, each message conversion requires multiple remote calls, becoming a performance bottleneck in high-throughput scenarios. Furthermore, the lack of version control for cache updates may lead to the continued use of expired configurations, causing data inconsistency issues.

[0007] Fifth, insufficient conditional routing capabilities. Existing solutions often perform the same conversion process on all device packets, failing to perform conditional judgments and differentiated routing based on specific field values ​​in the packet content. This results in unnecessary conversion overhead and cannot support flexible distribution of different services from the same device to different downstream systems.

[0008] Therefore, there is an urgent need for a metadata envelope protocol and dynamic conversion method that can achieve protocol-independent access, adaptive format conversion, configuration-driven extensibility, and efficient and consistent caching. Summary of the Invention

[0009] The technical problem to be solved by this invention is to propose a metadata envelope protocol for heterogeneous devices and its dynamic conversion method, which can realize protocol-independent access and format adaptive conversion of heterogeneous device messages, reduce the access cost of new device types through configuration driving, improve message processing throughput through multi-level caching, realize differentiated distribution through conditional routing, and improve the data interoperability of IoT platforms.

[0010] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: This invention proposes a metadata envelope protocol for heterogeneous devices and its dynamic conversion method, comprising the following steps: S1. Define a metadata envelope protocol to encapsulate the original messages from heterogeneous devices into a standardized envelope structure. The envelope structure includes a metadata header and a payload. The metadata header includes at least the message identifier msgId, timestamp ts, message direction dir, client identifier clientId, and service identifier serviceId fields. The payload carries the original device message data.

[0011] S2. Construct a configuration-driven dynamic transformation engine that parses configuration text using a finite state automaton to generate a configuration model object EJTConfigModel containing common scripts, a set of named scripts, and a rule chain.

[0012] S3. Define rule chains in the configuration model. Each rule consists of a condition expression, a list of target topics (kafkaTopic), and an output template. The condition expression is pre-compiled and executed using the Aviator expression engine. The output template supports two placeholder replacement mechanisms: path{JSONPath expression} for path extraction and script{script name} for script evaluation.

[0013] S4. Establish a multi-level cache routing system. The client identifier clientId is mapped to the product identifier productId through the client-product cache, then to the thing model identifier thingModelId through the product-thing model cache, and finally to the corresponding direction dir conversion configuration model through the thing model-service cache.

[0014] S5. After receiving the envelope-formatted message, the conversion engine extracts the clientId, serviceId, and dir fields from the metadata header, obtains the conversion configuration model through multi-level caching routing, executes the common script to initialize the runtime environment, traverses the rule chain to perform condition matching and template rendering, and sends the rendering result to the target topic list specified by the matching rule.

[0015] In more detail, the definition of the metadata envelope protocol in step S1 is as follows: the envelope structure is represented in JSON format, with an outer layer containing two top-level keys: metadata and payload. The metadata field is defined as follows: msgId is a string-type unique message identifier used for message tracking and deduplication; ts is a long integer timestamp, accurate to milliseconds, representing the message generation time; dir is a string enumeration type, with values ​​of up or down, where up represents an uplink message from the device and down represents a downlink command from the platform; clientId is a string-type client identifier, corresponding to the device connection identifier in the MQTT protocol; serviceId is a string-type service identifier, identifying the specific object model service provided or requested by the device; realMqttTopic is a string type, recording the actual MQTT topic path subscribed to or published by the device; the payload field carries the original message data of heterogeneous devices, and its internal structure varies depending on the device protocol and vendor definition, without standardized constraints.

[0016] In step S2, the specific steps for parsing the configuration text using a finite state automaton are as follows: Define seven parsing state enumerations (NORMAL, PUBLIC_SCRIPT, NAMED_SCRIPT, IN_RULE, CONDITION, KAFKA_TOPIC, TEMPLATE), scan the configuration text line by line, skip comment lines, match delimiter lines and end markers using pre-compiled regular expressions, identify the start and end of blocks, parse the content of each block into the corresponding script object or rule field, and use the end markers of the KAFKA_TOPIC and TEMPLATE states to fall back to IN_RULE to support the parsing of nested sub-blocks within the rule block.

[0017] In step S3, the ScriptModel parsing process is as follows: matching the path{JSONPath expression} placeholders through pre-compiled regular expressions, compiling each JSONPath expression into a JSONPath object and establishing a mapping relationship with the automatically generated parameter names, replacing all path{...} placeholders in the original script text with the corresponding parameter names, and then calling AviatorEvaluator.compile() for pre-compilation; the ScriptModel execution process is as follows: traversing the JSONPath mapping list to extract values ​​from the source JSON and storing them in the environment variable mapping env, calling the compiled expression to execute and returning the evaluation result.

[0018] Meanwhile, in step S3, the RuleModel template rendering uses pre-compiled regular expressions to match two types of placeholders: path{JSONPath expression} and script{script name}. For path type placeholders, the value is extracted from the JSONPathModel object obtained from the global jsonPathMap. For script type placeholders, the ScriptModel object is obtained from the scripts mapping table and evaluated. The result is serialized into a JSON string to replace the original placeholder position.

[0019] In step S4, the multi-level cache routing system is implemented as follows: The first-level cache uses clientId as the key and employs a double-checked locking lazy loading strategy to obtain the product identifier from Redis and updates it by comparing the version number; the second-level cache uses productId as the key and lazy-loads it by remotely calling Feign to obtain the object model identifier; the third-level cache uses thingModelId:serviceId as the key and lazy-loads it to obtain the upstream and downstream EJT conversion configurations and parse them into configuration model objects, returning the corresponding configuration according to the message direction; CacheHelper, as the cache facade class, maintains three sets of ConcurrentHashMaps, providing a unified routing method and cache update and deletion interface, and is driven by Kafka consumers for five cache operation types.

[0020] In step S5, the message processing and distribution process of the transformation engine is as follows: messages are consumed in batches from the JSON_TRANSFORM topic of Kafka, parsed into JSONObjects, and then the EJTExecuteEngine.transform() method is called to extract the routing fields from the metadata, obtain the configuration model through caching, execute the common script to initialize the runtime environment, traverse the rule chain to perform condition matching and template rendering, and encapsulate the rendering result into a SendKafkaMessage object to be asynchronously sent to the Kafka target topic list specified by the matching rule.

[0021] This invention also proposes a metadata envelope protocol for heterogeneous devices and its dynamic conversion system, which includes: a metadata envelope encapsulation module, a configuration parsing module, a script compilation and execution module, a multi-level cache routing module, and a message conversion and distribution module.

[0022] Furthermore, the present invention also proposes an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method described above.

[0023] The present invention further proposes a computer-readable storage medium on which a computer program is stored, which, when executed by a processor, implements the method described above.

[0024] The present invention adopts the above technical solution and has the following beneficial effects compared with the prior art: (1) Protocol-independent access: The heterogeneous device packets are uniformly encapsulated through the metadata envelope protocol. The platform can obtain the metadata information required for routing without parsing the packet body, thus realizing the protocol independence of device access. When adding a new device type, only the envelope mapping rules need to be configured, without modifying the core code.

[0025] (2) Configuration-driven transformation: Transformation rules are defined through EJT configuration text. A combination mechanism of finite state automaton parsing, Aviator expression engine execution, JSONPath path extraction and template rendering is adopted to realize the externalization and hot update of transformation logic. Non-technical personnel can adjust the transformation behavior by modifying the configuration text without redeploying the service.

[0026] (3) Conditional routing distribution: The conditional expressions in the rule chain support flexible judgment based on the device message field. The matching rule can specify different target topic lists to realize differentiated distribution of the same device message to multiple downstream systems.

[0027] (4) Efficient caching routing: The multi-level caching system optimizes the configuration retrieval of each message from multiple remote calls to direct memory read through ConcurrentHashMap and double-checked lock lazy loading strategy, which significantly improves message processing throughput; the version number comparison update strategy ensures the consistency between the cache and the data source.

[0028] (5) Pre-compilation execution optimization: The Aviator expression engine completes pre-compilation during the configuration parsing stage and executes bytecode directly at runtime, avoiding the overhead of repeated compilation for each message; JSONPath objects are also pre-compiled and cached in the global mapping table during the parsing stage, and only the eval operation is performed at runtime. Attached Figure Description

[0029] Figure 1 This is an overall flowchart of a metadata envelope protocol for heterogeneous devices and its dynamic conversion method provided in an embodiment of the present invention.

[0030] Figure 2 This is a schematic diagram of the metadata envelope protocol provided in an embodiment of the present invention.

[0031] Figure 3 The state transition diagram for parsing the configuration text finite state automaton provided in the embodiments of the present invention.

[0032] Figure 4 This is a schematic diagram illustrating the ScriptModel compilation and execution mechanism provided in an embodiment of the present invention.

[0033] Figure 5 This is a schematic diagram of the RuleModel template rendering mechanism provided in an embodiment of the present invention.

[0034] Figure 6 This is a schematic diagram of the structure of a multi-level caching routing system provided in an embodiment of the present invention.

[0035] Figure 7 This is a flowchart illustrating the processing of a message conversion engine provided in an embodiment of the present invention. Detailed Implementation

[0036] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. The following embodiments are used to illustrate the present invention, but are not intended to limit the scope of the present invention.

[0037] This embodiment provides a metadata envelope protocol for heterogeneous devices and its dynamic conversion method, such as Figure 1 As shown, it includes the following steps: Step S1: Define the metadata envelope protocol.

[0038] The metadata envelope protocol defined in this invention encapsulates raw messages from heterogeneous devices into a standardized envelope structure, such as... Figure 2 As shown. The envelope structure is represented in JSON format, with two top-level keys: metadata and payload. The metadata field carries the device's metadata information, and its structure is defined as follows: msgId: A unique message identifier of type string, generated using UUID or the Snowflake algorithm, used for message tracking and deduplication. In the code implementation, it corresponds to the msgId field of the Metadata class.

[0039] `ts`: A long integer timestamp, accurate to milliseconds, representing the moment the message was generated. In the code implementation, it corresponds to the `ts` field of the `Metadata` class.

[0040] `dir`: A string enumeration type, with values ​​of either "up" or "down". "Up" represents an uplink message from the device (device → platform), while "down" represents a downlink command from the platform (platform → device). In the code implementation, this corresponds to the `dir` field of the `Metadata` class.

[0041] `clientId`: A string-type client identifier, corresponding to the device connection identifier (ClientID) in the MQTT protocol, uniquely identifying a connected device instance in the IoT platform. In the code implementation, it corresponds to the `clientId` field of the `Metadata` class.

[0042] `serviceId`: A string-type service identifier that identifies the specific object model service provided or requested by the device, such as temperature reading service or switch control service. In the code implementation, it corresponds to the `serviceId` field of the `Metadata` class.

[0043] `realMqttTopic`: A string type that records the actual MQTT topic path subscribed to or published by the device, used for message backtracking and debugging. In the code implementation, it corresponds to the `realMqttTopic` field of the `Metadata` class.

[0044] The payload field carries the raw message data from heterogeneous devices. Its internal structure varies depending on the device protocol and manufacturer definition, and is not subject to standardized constraints. The core idea of ​​the envelope protocol is that the platform can complete message routing and transformation configuration lookup based on metadata without parsing the payload. The payload is only extracted and reconstructed by JSONPath expressions during the template rendering stage of the transformation engine.

[0045] Step S2: Build a configuration-driven dynamic conversion engine.

[0046] This invention uses EJT (Easy JSON Transform) configuration text as the declaration carrier for transformation rules, and parses the configuration text using a Finite State Automaton (FSA) to generate a configuration model object EJTConfigModel. The syntax structure of the configuration text is as follows: --- public# Public script block (optional) path{$.payload.temperature}>30# Aviator expression --- end --- script normalizeTemp# Named script block path{$.payload.temp} * 1.0 + 273.15 --- end --- rule# rule block --- condition# Conditional expression path{$.metadata.dir} == "up --- end --- kafkaTopic# Target Topic List ["topic-alert", "topic-storage"] --- end --- template# Output template {"alert":path{$.payload.temperature},"unit":"K", "kValue":script{normalizeTemp}} --- end --- end like Figure 3 As shown, the parsing process of the finite state automaton is implemented by the EJTConfigParser class. Seven parsing state enumerations, ParseState, are defined: NORMAL (normal state), PUBLIC_SCRIPT (public script parsing), NAMED_SCRIPT (named script parsing), IN_RULE (rule block wait), CONDITION (conditional parsing), KAFKA_TOPIC (target topic parsing), and TEMPLATE (template parsing).

[0047] The parser scans the configuration text line by line, skipping comment lines that begin with / / . It matches named script start tags in the format of script name using the precompiled regular expressions SCRIPT_NAME_PATTERN, general start tags in the format of blockName using START_PATTERN, and end tags in the format of end using END_PATTERN.

[0048] The state transition rules are as follows: When in the NORMAL state and `--- public` is detected, the system enters the PUBLIC_SCRIPT state; when `--- rule` is detected, a new RuleModel object is created and the system enters the IN_RULE state. When in the IN_RULE state and `--- condition` is detected, the system enters the CONDITION state; when `--- kafkaTopic` is detected, the system enters the KAFKA_TOPIC state; and when `--- template` is detected, the system enters the TEMPLATE state. `---end` in the KAFKA_TOPIC and TEMPLATE states causes the state to revert to IN_RULE to support the parsing of nested sub-blocks within the rule block. `---end` in other blocks causes the state to revert to NORMAL. The content line of each block is appended to the StringBuilder buffer. When `---end` is encountered, the saveBuffer method is called to save the buffer content to the corresponding model field according to the current state.

[0049] After parsing, an EJTConfigModel object is generated, which contains four core fields: global jsonPathMap (JSONPath expression mapping), publicScript (public script), scripts (named script mapping table), and rules (rules list).

[0050] Step S3: Define the rule chain and script compilation and execution mechanism.

[0051] like Figure 4 As shown, the compilation and execution mechanism of ScriptModel includes two stages: parsing and running.

[0052] Parsing Phase: The `ScriptModel.parse()` method receives the script text and matches all `path{JSONPath expression}` placeholders using the pre-compiled regular expression `JSON_PATH_PATTERN`. For each matched `JSONPath` expression, it calls `JSONPath.of()` to compile it into a `JSONPath` object, generating parameter names `p0`, `p1`, ..., `pN`, and constructing a `JSONPathParam` record (containing `paramName` and `jsonPath`) which is then stored in the `jsonPaths` list. Simultaneously, it replaces the `path{...}` placeholders in the original script text with the corresponding parameter names, and calls `AviatorEvaluator.compile()` to pre-compile the replaced text into an `Aviator Expression` object, which is stored in the `compiledScript` field.

[0053] The execution phase has two modes: The `executeAndGetEnv` method is used for public scripts. It iterates through the `jsonPaths` list, calls `jsonPath.eval(sourceJson)` to extract values ​​from the source JSON, stores the parameter names and extracted values ​​in the `env` mapping, calls `compiledScript.execute(env)` to execute the expression, and returns the complete `env` mapping for subsequent rules to share; The `execute` method is used for conditional expressions and named scripts. It is executed based on a copy of the public `env` (`new HashMap<>(env)`) to avoid environment pollution between rules and returns the expression evaluation result.

[0054] like Figure 5 As shown, the RuleModel template rendering mechanism is implemented by the executeAndGetJSONString method. This method uses the pre-compiled regular expression PLACEHOLDER_PATTERN to match the path{...} and script{...} placeholders in the template. For path type placeholders, the corresponding JSONPathModel object is obtained from the global jsonPathMap of EJTConfigModel, and getObject(sourceJson) is called to extract the value from the source JSON. For script type placeholders, the corresponding ScriptModel object is obtained from the scripts mapping table, and execute(env, sourceJson) is called to evaluate the script. The extracted or evaluated objects are serialized into JSON strings using JSON.toJSONString(), and the original placeholder positions are replaced using Matcher.appendReplacement and quoteReplacement. Null values ​​are replaced with the string "null". Conditional matching is implemented by the needTransform method. If the condition is empty, a default match is made; otherwise, the conditional expression is evaluated, and a successful match is achieved when the result is not null and has a boolean value of true.

[0055] In addition, EJTAviatorFunctions registers four types of built-in functions with AviatorEvaluator in the static initialization block: __fn_concat (string concatenation), __fn_toUpperCase (capital conversion), __fn_size (collection size), and __fn_index (list index retrieval), which expands the expressive power of the script.

[0056] Step S4: Establish a multi-level caching routing system.

[0057] like Figure 6As shown, the multi-level caching routing system consists of the CacheHelper facade class and a three-level cache container. It uses ConcurrentHashMap to store cache container instances and uses putIfAbsent to ensure concurrency safety.

[0058] The first-level cache, `ClientProductIdCacheContainer`, encapsulates a `ClientProductIdCache` object using `clientId` as the key. It employs a double-checked locking (DCL) lazy loading strategy: on the first call to `getProductId()`, if `clientProductIdCache` is null, a second check is performed within the synchronized block, and the `BELONG_PRODUCT_ID` and `PRODUCT_VERSION` fields are retrieved in batches from `RedisHash` to construct the cache object. During updates, version numbers are compared; updates are only performed if the new data's version number is greater than the local version number, preventing old data from overwriting new data.

[0059] The second-level cache, `ProductInfoCacheContainer`, encapsulates `ProductInfoCache` objects using `productId` as the key. It also employs a DCL lazy loading strategy. On the first access, it remotely calls the product service via `ProductFeignClient` to query the product's object model identifier `thingModelId`, and caches the query result. The update strategy is also based on version number comparison.

[0060] The third-level cache, ThingModelServiceCacheContainer, encapsulates ThingModelServiceScriptCache objects using the combination of thingModelId and serviceId as keys. On the first access, it remotely calls the object model service via ThingModelFeignClient to retrieve the uplink and downlink EJT conversion configuration texts, and calls EJTConfigParser.parse() to parse them into upEJTConfigModel and downEJTConfigModel respectively. When getEJTConfigModel(dir) is called, it returns the uplink configuration model if the dir field value is up, and the downlink configuration model if it is down.

[0061] CacheHelper provides a unified `getEJTConfigModel(clientId, serviceId, dir)` method, which routes the three-level cache sequentially: clientId → productId → thingModelId → EJTConfigModel. It also provides cache update methods (`updateClientProductIdCache`, `updateProductThingModelIdCache`, `updateThingModelServiceCache`) and deletion methods (`removeClientProductIdCache`, `removeThingModelServiceCache`), driven by the `CacheUpdateConsumer` consuming the Kafka `EJT_CACHE_UPDATE` topic. CacheUpdateConsumer parses the type field of the IotCacheUpdateMessage message and dispatches it to the corresponding cache operation: UPDATE_CLIENT_PRODUCT_ID_CACHE updates the client product cache, UPDATE_PRODUCT_THING_MODEL_ID_CACHE updates the product model cache, UPDATE_THING_MODEL_SERVICE_CACHE updates the product model service cache, REMOVE_CLIENT_PRODUCT_ID_CACHE deletes the client product cache, and REMOVE_THING_MODEL_SERVICE_CACHE deletes the product model service cache.

[0062] Step S5: Message processing and distribution of the conversion engine.

[0063] like Figure 7 As shown, the message transformation engine's processing flow is completed collaboratively by three core classes: JSONTransformConsumer, EJTExecuteEngine, and EJTConfigModel.

[0064] The JSONTransformConsumer consumes messages in batches from the Kafka JSON_TRANSFORM topic, processing each message record as follows: First, it parses the message string into a JSONObject, then calls the EJTExecuteEngine.transform(jsonObject) method to perform the transformation and obtain a List. <sendkafkamessage>The result list. For each SendKafkaMessage in the result list, iterate through its kafkaTopic list and call KafkaTemplate.send(kafkaTopic, sendKafkaMessage.getMessage()) to send the message asynchronously, logging sending failures through the whenComplete callback.

[0065] The execution flow of the EJTExecuteEngine.transform() method is as follows: First, the message's metadata field is deserialized into a metadata object, and the three routing fields clientId, serviceId, and dir are extracted; then, cacheHelper.getEJTConfigModel(clientId, serviceId, dir) is called to obtain the EJTConfigModel configuration model through multi-level cached routing; finally, EJTConfigModel.executeAndGetJSONString(message) is called to perform the transformation and return the result list.

[0066] The execution flow of the `EJTConfigModel.executeAndGetJSONString()` method is as follows: First, the `executeAndGetEnv(sourceJson)` method of the public script is executed to extract the JSONPath parameter value from the source JSON and execute the Aviator expression to generate a public environment variable mapping `env`. If the public script is null, an empty mapping is used. Then, the `rules` list is traversed, and `needTransform(env, sourceJson)` is called for each rule to perform condition matching—if the condition is null, a default match is made; otherwise, the condition expression is evaluated. For rules that are successfully matched, `executeAndGetJSONString(jsonPathMap, scripts, env, sourceJson)` is called to render the template, generate a JSON string result, encapsulate it into a `SendKafkaMessage` (where `kafkaTopic` is the list of target topics for the rule, and `message` is the rendered result) and add it to the result list. Finally, it is asynchronously distributed to downstream systems via `KafkaTemplate`.

[0067] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.< / sendkafkamessage>

Claims

1. A metadata envelope protocol for heterogeneous devices and its dynamic conversion method, characterized in that, include: S1. Define a metadata envelope protocol to encapsulate the original messages of heterogeneous devices into a standardized envelope structure. The envelope structure includes a metadata header and a payload. The metadata header includes at least the message identifier msgId, timestamp ts, message direction dir, client identifier clientId, and service identifier serviceId fields. The payload carries the original device message data. S2. Construct a configuration-driven dynamic transformation engine, which parses configuration text through a finite state automaton to generate a configuration model object EJTConfigModel containing common scripts, a set of named scripts, and a rule chain. S3. Define a rule chain in the configuration model. Each rule consists of a condition expression, a list of target topics (kafkaTopic), and an output template. The condition expression is pre-compiled and executed using the Aviator expression engine. The output template supports two placeholder replacement mechanisms: path{JSONPath expression} for path extraction and script{script name} for script evaluation. S4. Establish a multi-level cache routing system. The client identifier clientId is mapped to the product identifier productId through the client-product cache, then to the thing model identifier thingModelId through the product-thing model cache, and finally to the corresponding direction dir conversion configuration model through the thing model-service cache. S5. After receiving the envelope-formatted message, the conversion engine extracts the clientId, serviceId, and dir fields from the metadata header, obtains the conversion configuration model through multi-level caching routing, executes the common script to initialize the runtime environment, traverses the rule chain to perform condition matching and template rendering, and sends the rendering result to the target topic list specified by the matching rule.

2. The metadata envelope protocol for heterogeneous devices and its dynamic conversion method according to claim 1, characterized in that, In step S1, the metadata envelope protocol is specifically defined as follows: The envelope structure is represented in JSON format, with the outer layer containing two top-level keys: metadata and payload. The metadata field is structured as follows: msgId is a string representing a unique message identifier used for message tracking and deduplication; ts is a long integer timestamp, accurate to milliseconds, representing the message's generation time; dir is a string enumeration type, with values ​​of up or down, where up indicates an uplink message from the device and down indicates a downlink command from the platform; clientId is a string representing a client identifier, corresponding to the device connection identifier in the MQTT protocol; serviceId is a string representing a service identifier, identifying the specific object model service provided or requested by the device; realMqttTopic is a string recording the actual MQTT topic path subscribed to or published by the device. The payload field carries the original message data of heterogeneous devices. Its internal structure varies depending on the device protocol and manufacturer definition, and is not subject to standardization constraints.

3. The metadata envelope protocol for heterogeneous devices and its dynamic conversion method according to claim 1, characterized in that, In step S2, the specific steps for parsing the configuration text using a finite state automaton are as follows: S201. Define a parsing state enumeration, which includes seven states: NORMAL (normal state), PUBLIC_SCRIPT (public script parsing state), NAMED_SCRIPT (named script parsing state), IN_RULE (rule block waiting state), CONDITION (conditional parsing state), KAFKA_TOPIC (target topic parsing state), and TEMPLATE (template parsing state). S202. Scan the configuration text line by line, skipping comment lines that begin with double forward slashes / / , and identify the start and end of blocks by matching the delimiter lines --- blockName and --- end markers using pre-compiled regular expressions; S203. When --- public is detected, enter the PUBLIC_SCRIPT state, append subsequent non-delimiter lines to the buffer until --- end is encountered, parse the contents of the buffer into a public script object ScriptModel and set it to the publicScript field of the configuration model; S204. When the script name is detected, enter the NAMED_SCRIPT state, parse the subsequent content into a named script object ScriptModel, and store it in the scripts mapping table of the configuration model with the name as the key. S205. When a --- rule is detected, a new RuleModel object is created and added to the rule list of the configuration model, and the process enters the IN_RULE waiting state. S206. In the IN_RULE state, upon detecting --- condition, enter the CONDITION state, parse the condition expression, and set it to the condition field of RuleModel; upon detecting --- kafkaTopic, enter the KAFKA_TOPIC state, parse it into a list of strings, and set it to the kafkaTopic field; upon detecting --- template, enter the TEMPLATE state, parse the template text, extract all JSONPath expressions of the form path{...} from the template, construct a JSONPathModel object, store it in the global jsonPathMap of the configuration model, and set it to the template field of RuleModel. The --- end flag for the S207, KAFKA_TOPIC and TEMPLATE states causes the state to fall back to IN_RULE, while the --- end flag for other blocks causes the state to fall back to NORMAL, supporting the parsing of nested sub-blocks within rule blocks; S208. When the file ends, if there is still unsaved content in the buffer, execute the fallback saving logic.

4. The metadata envelope protocol for heterogeneous devices and its dynamic conversion method according to claim 1, characterized in that, In step S3, the compilation and execution mechanism of the conditional expression is as follows: The ScriptModel parsing process is as follows: It matches the path{JSONPath expression} placeholders using pre-compiled regular expressions, compiles each JSONPath expression into a JSONPath object, establishes a mapping relationship with automatically generated parameter names p0, p1, ... pN, and stores them in the jsonPaths list; it replaces all path{...} placeholders in the original script text with the corresponding parameter names, calls AviatorEvaluator.compile() to pre-compile the replaced text, and generates an AviatorExpression object stored in the compiledScript field. The execution process of ScriptModel is as follows: iterate through the list of jsonPaths, call jsonPath.eval(sourceJson) for each JSONPathParam to extract the value from the source JSON, and store the parameter name and the extracted value in the environment variable mapping env; The compiled expression is executed by calling compiledScript.execute(env) and the result is returned. The executeAndGetEnv method of the public script returns the complete env map for subsequent rules to share. The conditional expression and the execute method of the named script are executed based on a copy of the public env and the result is returned.

5. The metadata envelope protocol for heterogeneous devices and its dynamic conversion method according to claim 1, characterized in that, In step S3, the rendering mechanism of the output template is as follows: RuleModel's template rendering uses pre-compiled regular expressions to match two types of placeholders: path{JSONPath expression} and script{script name}. For path type placeholders, the corresponding JSONPathModel object is retrieved from the global jsonPathMap of the configuration model, and getObject(sourceJson) is called to extract the value from the source JSON. For script type placeholders, the corresponding ScriptModel object is retrieved from the scripts mapping table of the configuration model, and execute(env, sourceJson) is called to evaluate the script. The extracted or evaluated value is serialized into a JSON string using JSON.toJSONString() and replaced with the original placeholder. If the value is null, it is replaced with the string null. Matcher.appendReplacement and quoteReplacement are used to ensure that no exceptions are caused by special characters during the replacement process.

6. The metadata envelope protocol for heterogeneous devices and its dynamic conversion method according to claim 1, characterized in that, In step S4, the specific implementation of the multi-level caching routing system is as follows: The first-level cache is ClientProductIdCacheContainer, which uses clientId as the key and adopts a double-checked lock lazy loading strategy. On the first access, it retrieves the BELONG_PRODUCT_ID and PRODUCT_VERSION fields in batches from Redis Hash to construct a ClientProductIdCache object and updates the cache by comparing the version number. The second-level cache is ProductInfoCacheContainer, which uses productId as the key and adopts a double-checked lock lazy loading strategy. On the first access, the product service is remotely called via Feign to query the product's object model identifier, and the cache is updated by comparing the version number. The third-level cache is ThingModelServiceCacheContainer, which uses the combination of thingModelId:serviceId as the key and adopts a double-checked lock lazy loading strategy. On the first access, it remotely calls the thing model service through Feign to query the service's uplink and downlink EJT conversion configuration text, calls EJTConfigParser.parse() to parse it into EJTConfigModel objects, stores the uplink configuration in the upEJTConfigModel field, stores the downlink configuration in the downEJTConfigModel field, and returns the corresponding configuration model according to the message direction dir field. CacheHelper, as a caching facade class, maintains three sets of ConcurrentHashMaps to store the three-level cache containers respectively. It provides the getEJTConfigModel(clientId, serviceId, dir) method to sequentially route the three-level caches to obtain the final configuration model. It also provides cache update and deletion methods, driven by the Kafka cache update consumer CacheUpdateConsumer, and supports five cache operation types: UPDATE_CLIENT_PRODUCT_ID_CACHE, UPDATE_PRODUCT_THING_MODEL_ID_CACHE, UPDATE_THING_MODEL_SERVICE_CACHE, REMOVE_CLIENT_PRODUCT_ID_CACHE, and REMOVE_THING_MODEL_SERVICE_CACHE.

7. The metadata envelope protocol for heterogeneous devices and its dynamic conversion method according to claim 1, characterized in that, In step S5, the message processing and distribution process of the conversion engine is as follows: The JSONTransformConsumer consumes messages in batches from the JSON_TRANSFORM topic in Kafka. After parsing each message into a JSONObject, it calls the EJTExecuteEngine.transform() method to perform the transformation. EJTExecuteEngine extracts clientId, serviceId, and dir from the message's metadata field, obtains EJTConfigModel through CacheHelper routing, and calls EJTConfigModel.executeAndGetJSONString() to perform the transformation; When EJTConfigModel performs the transformation, it first executes the `executeAndGetEnv` method of the public script to initialize the runtime environment `env`. Then, it iterates through the rule list and calls `needTransform(env, sourceJson)` for each rule to perform condition matching. If the condition is empty, it matches by default; otherwise, it evaluates the conditional expression. If the result is not null and is true, the match is successful. For successfully matched rules, it calls `executeAndGetJSONString` to render the template, generates a JSON string result, and encapsulates it into a `SendKafkaMessage` object. The `kafkaTopic` field of the `SendKafkaMessage` object contains the list of target topics for the rule, and the `message` field contains the rendered result. The JSONTransformConsumer iterates through the list of transformation results, and for each kafkaTopic in each SendKafkaMessage, it calls KafkaTemplate.send() to send the message asynchronously, logging sending failures through the whenComplete callback.

8. The metadata envelope protocol for heterogeneous devices and its dynamic conversion method according to claim 1, characterized in that, It also includes a built-in function registration mechanism: EJTAviatorFunctions registers four types of built-in functions with AviatorEvaluator in the static initialization block: the concat function accepts variable arguments and concatenates the string representations of all arguments and returns them; The `toUpperCase` function converts the input string to uppercase and returns it; the `size` function returns the number of elements in a collection type parameter. The `index` function takes a list and an index as arguments and returns the value of the element at the specified position in the list. Built-in function names are registered with the __fn_ prefix to avoid conflicts with user-defined expressions.

9. A metadata envelope protocol for heterogeneous devices and its dynamic conversion system, characterized in that, include: The metadata envelope encapsulation module is used to encapsulate the raw messages from heterogeneous devices into a standardized envelope structure containing a metadata header and a payload. The metadata header must include at least the message identifier msgId, timestamp ts, message direction dir, client identifier clientId, and service identifier serviceId fields. The configuration parsing module is used to parse configuration text through a finite state automaton and generate a configuration model object EJTConfigModel containing a common script, a set of named scripts, and a rule chain. Each rule in the rule chain consists of a condition expression, a list of target topics, and an output template. The script compilation and execution module is used to precompile and execute the scripts in the configuration text. It maps device message fields to Aviator expression parameters by replacing JSONPath placeholders, and supports script calls in conditional expression evaluation and template rendering. The multi-level cache routing module is used to route the transformation configuration model to the corresponding object model service through a three-level cache based on the client identifier. The cache adopts a double-checked lock lazy loading and version number comparison update strategy to ensure data consistency. The message transformation and distribution module is used to consume envelope-formatted messages from the message queue, process them through the transformation engine, and then distribute the rendering results to the target topic list specified by the matching rules.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 8.

11. A computer-readable storage medium storing a computer program, characterized in that, The computer program is executed by the processor to perform the method of any one of claims 1 to 8.

Images