Rule engine system and server

Abstract

The invention discloses a rule engine system and a server. The rule engine system specifically comprises an application layer, a rule engine layer and a task execution layer, the application layer is used for providing a logic interface for accessing the rule engine layer; the rule engine layer is used for managing service functions of rule instances and scheduling the task execution layer to execute thread tasks formed based on the rule instances; and the task execution layer is used for executing the thread tasks formed by the rule engine layer in parallel. According to the embodiment of the invention, the rule engine system is deployed in a layered manner, and the rule engine layer can call the task execution layer to enable the task execution layer to asynchronously process the task nodes, so that the problem of data congestion can be avoided, and the system performance of the rule engine system can be improved.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) technology, and particularly to a rule engine system and a server. Background Art

[0002] With the rapid development of Internet of Things (IoT) technology, more and more devices are connected to the IoT, generating a huge amount of data streams that need to be processed. In this context, the device rule engine, as the core component of the IoT platform, undertakes important tasks such as rule-based data processing, event response, and device management. However, the existing device rule engines generally use a synchronous method to process data streams, so when the data streams increase, there will be a situation of data stream congestion, which will in turn affect the performance of the device rule engine.

[0003] Therefore, the existing technology still needs to be improved. Summary of the Invention

[0004] The technical problem to be solved by this application is to provide a rule engine system and a server in view of the deficiencies of the existing technology.

[0005] To solve the above technical problem, in the first aspect of this application, a rule engine system is provided, where the rule engine system specifically includes: an application layer, a rule engine layer, and a task execution layer;

[0006] The application layer is used to provide a logical interface for accessing the rule engine layer;

[0007] The rule engine layer is used to manage the business functions of rule instances and schedule the task execution layer to execute the thread tasks formed based on the rule instances;

[0008] The task execution layer is used to execute the thread tasks formed by the rule engine layer in parallel.

[0009] For the rule engine system, the application layer includes:

[0010] A service interface layer, which is used to provide service interfaces;

[0011] A logic control layer, which is used to provide a control interface for the rule engine;

[0012] A service logic layer, which is used to provide a control interface for rule instances in the rule engine.

[0013] For the rule engine system, the control interface of the rule engine includes a rule editing control entry, a rule instance operation control entry, and a scenario linkage control entry.

[0014] For the rule engine system, the rule engine layer includes a parser, a converter, and a starter;

[0015] The parser is used to convert the rule data accessed by the rule engine system into rule instances;

[0016] The converter is used to convert the rule instances into thread tasks executable by the task execution layer;

[0017] The starter is used to control the start and stop of the thread tasks.

[0018] The rule engine system, wherein the rule engine layer further includes a publish-subscribe module, and the publish-subscribe module is used to interact with the event bus to publish the execution status of the thread tasks or subscribe to the events that trigger the task threads.

[0019] The rule engine system, wherein the conversion of the rule data accessed by the rule engine system into rule instances specifically includes:

[0020] Receiving rule data formed based on the user visual operation interface;

[0021] Obtaining the rule nodes included in the rule data, and establishing a node topology structure for each rule node based on the rule data, and determining rule instances based on the node topology structures of all rule nodes, wherein the node topology structure of each rule node includes the previous rule nodes and subsequent rule nodes of each rule node.

[0022] The rule engine system, wherein the conversion of the rule instances into thread tasks executable by the task execution layer specifically includes:

[0023] Obtaining the task categories of the rule nodes in the rule instances, and determining the task threads corresponding to each rule node based on the task categories of each rule node;

[0024] Generating node tasks for each rule node based on the task threads corresponding to each rule node, and associating the node tasks to convert the rule instances into thread tasks executable by the task execution layer.

[0025] The rule engine system, wherein the starter is also used to verify the thread tasks when starting the thread tasks, and start the thread tasks when the verification is passed.

[0026] The rule engine system, wherein the starter is also used to store the task snapshots of the thread tasks in the database, so as to use the task snapshots as the basis for changes to the thread tasks.

[0027] The rule engine system, wherein the rule engine system further includes a data storage layer, asset control, and logging;

[0028] The data storage layer is used to store the execution data formed during the execution of thread tasks;

[0029] The asset control is used to utilize AOP aspect programming;

[0030] The log recording is used to write log information in the form of date rolling.

[0031] The second aspect of the present application provides a server, wherein the server deploys the rule engine system as described above.

[0032] Beneficial effects: Compared with the prior art, the present application provides a rule engine system and a server. The rule engine system specifically includes an application layer, a rule engine layer, and a task execution layer. The application layer is used to provide a logical interface for accessing the rule engine layer. The rule engine layer is used to manage the business functions of rule instances and schedule the task execution layer to execute the thread tasks formed based on the rule instances. The task execution layer is used to execute the thread tasks formed by the rule engine layer in parallel. In the embodiment of the present application, by deploying the rule engine system in layers, and the rule engine layer can call the task execution layer to enable the task execution layer to perform asynchronous processing on task nodes, thereby avoiding the problem of data congestion, and further improving the system performance of the rule engine system. Description of the Drawings

[0033] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0034] Figure 1 It is a principle block diagram of the rule engine system provided by the embodiment of the present application.

[0035] Figure 2 It is a principle block diagram of a specific embodiment of the rule engine system provided by the embodiment of the present application.

[0036] Figure 3 It is a schematic diagram of the rule pattern of the rule data input through the rule editing entry.

[0037] Figure 4 It is a principle block diagram of the server provided by the embodiment of the present application. Detailed Embodiments

[0038] The embodiments of the present application provide a rule engine system and a server. To make the objectives, technical solutions and effects of the present application clearer and more explicit, the following further describes the present application in detail with reference to the accompanying drawings and by way of examples. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0039] Those skilled in the art of the present technology can understand that unless specifically stated, the singular forms "a", "an", "the" and "said" used herein may also include the plural forms. It should be further understood that the term "including" used in the specification of the present application means the presence of the described features, integers, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or their groups. It should be understood that when we say that an element is "connected" or "coupled" to another element, it can be directly connected or coupled to other elements, or there may also be intermediate elements. In addition, the "connection" or "coupling" used herein may include wireless connection or wireless coupling. The phrase "and / or" used herein includes all or any unit and all combinations of one or more of the associated listed items.

[0040] Those skilled in the art of the present technology can understand that unless otherwise defined, all terms (including technical terms and scientific terms) used herein have the same meaning as the general understanding of those of ordinary skill in the art to which the present application belongs. It should also be understood that terms such as those defined in a general dictionary should be understood to have a meaning consistent with the meaning in the context of the prior art, and will not be interpreted with an idealized or overly formal meaning unless specifically defined as here.

[0041] It should be understood that the sequence numbers and magnitudes of the steps in this embodiment do not mean the order of execution. The execution order of each process is determined by its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

[0042] Through research, it is found that with the rapid development of the Internet of Things (IoT) technology, more and more devices are connected to the IoT, generating a huge amount of data streams that need to be processed. In this context, the device rule engine, as the core component of the IoT platform, undertakes important tasks such as rule-based data processing, event response, and device management. However, the existing device rule engines generally use a synchronous method to process data streams, so when the data streams increase, the situation of data stream congestion will occur, which will in turn affect the performance of the device rule engine.

[0043] To solve the above problems, an embodiment of the present application provides a rule engine system, which specifically includes an application layer, a rule engine layer, and a task execution layer; the application layer is used to provide a logical interface for accessing the rule engine layer; the rule engine layer is used to manage the business functions of rule instances and schedule the task execution layer to execute the thread tasks formed based on the rule instances; the task execution layer is used to execute the thread tasks formed by the rule engine layer in parallel. By hierarchically deploying the rule engine system in the embodiment of the present application, and the rule engine layer can call the task execution layer to enable the task execution layer to perform asynchronous processing on task nodes, thereby avoiding the problem of data blockage and improving the system performance of the rule engine system.

[0044] The following further describes the content of the application by describing the embodiments in conjunction with the accompanying drawings.

[0045] This embodiment provides a rule engine system, as Figure 1 and Figure 2 shown. The rule engine system includes an application layer 100, a rule engine layer 200, and a task execution layer 300. The application layer 100, the rule engine layer 200, and the task execution layer 300 are arranged in sequence from top to bottom. Among them, the application layer 100 is used to provide a logical interface for accessing the rule engine layer. The rule engine layer 200 is used to manage the business functions of rule instances and schedule the task execution layer 300 to execute the thread tasks formed based on the rule instances. The task execution layer 300 is used to execute the thread tasks formed by the rule engine layer 200 in parallel. By hierarchically deploying the rule engine system in the embodiment of the present application, and the rule engine layer can call the task execution layer to enable the task execution layer to perform asynchronous processing on task nodes, thereby avoiding the problem of data blockage and improving the system performance of the rule engine system.

[0046] The application layer 100 is used to provide a logical interface for accessing the rule engine layer. Among them, the application layer 100 includes a service interface layer, a logic control layer, and a business logic layer. The service interface layer, the logic control layer, and the business logic layer are arranged in sequence from top to bottom. The service interface layer is used to provide service interfaces, such as OpenAPI interfaces and basic service operation interfaces, etc. The logic control layer is used to provide a control interface for the rule engine. The control interface of the rule engine may include a rule editing control entry, a rule instance operation control entry, and a scenario linkage control entry. The business logic layer is used to provide a control interface for rule instances in the rule engine. Among them, the control interface for rule instances in the rule engine can receive rule instance start operations, rule instance stop operations, etc.

[0047] In the embodiments of the present application, rule data is introduced through the rule editing control entry, the rule data is modified through the rule instance operation control entry, and the super device is subjected to scenario orchestration through the scenario linkage control entry. In this way, the rule orchestration and scenario linkage of the business scenario can be realized. Moreover, in the scenario linkage, scenario orchestration can be performed for the super device to realize the scenario linkage triggered by multiple devices, meeting business scenarios such as executing relevant actions after the conditions of multiple sensor data are met.

[0048] In one implementation manner, the rule editing entry corresponds to the front-end rule visualization operation. As Figure 3 shown, the rule data formed by the front-end rule visualization operation may include a trigger part, a condition judgment part, and an action part. The trigger part is used to receive a trigger instruction. Among them, the trigger instruction can be formed by different trigger methods, and the trigger parameters corresponding to different trigger methods are different. Specifically, since the rule is applied in the Internet of Things scenario and generally interacts with devices, there are a small number of scenarios (such as single-device patrol inspection) that will be controlled by people. Therefore, the trigger methods can include device trigger methods and manual trigger methods. Among them, when the trigger method is a device trigger method, device-related information will be provided. The device-related information can be expressed as {identifier, action}. The identifier is the device identifier of the trigger device, and the action can be an attribute operation related to the object model (such as reading, writing, reporting, etc.), ability call, and event reporting, etc.; when the trigger method is a manual trigger method, the trigger request can be formed by clicking a preset button, that is, when the preset button is clicked, a trigger request sent to the rule editing entry will be formed.

[0049] The condition judgment part is used to perform condition judgment according to the data determined by the upstream trigger part. For example, whether the reported execution attribute value is greater than or less than a preset threshold, etc. At the same time, it is also used to adapt the operator according to the value type of the data determined by the upstream trigger part for the user to use when planning business rules.

[0050] For the action execution part, common operations in business include serial and parallel operations. During the execution process of the action execution part, further condition judgment processing (that is, executing the condition judgment part) may also exist. For example, in a conference room scenario including a controller, an air conditioner, and sensors, it can be required that after the air conditioner is turned on during the execution of the action, if the device replies that it is turned on successfully, then set the air conditioner temperature. At this time, a new condition judgment part will be nested in the action execution part of the page.

[0051] Furthermore, the rule data structure can be:

[0052]

[0053] In the triggering part, since there are manual triggering methods and device triggering methods, etc., it is necessary to form a general data structure applicable to each triggering method according to different triggering methods. The general data structure can be:

[0054]

[0055]

[0056] In the condition judgment part, different combinations will be adapted to meet the requirements of different triggering methods. Among them, the data structure of the condition judgment part can be expressed as:

[0057]

[0058] In the action execution part, actions are generally related to devices. Therefore, the data structure of the action execution part can be:

[0059]

[0060]

[0061] The rule engine layer 200 is used to manage the business functions of rule instances and schedule the task execution layer to execute the thread tasks formed based on the rule instances. The rule engine layer 200 includes a parser, a converter, and a starter; the parser is used to convert the rule data accessed to the rule engine system into rule instances; the converter is used to convert the rule instances into thread tasks executable by the task execution layer; the starter is used to control the start and stop of the thread tasks.

[0062] The preset rule template is a pre-set standard template. After receiving the rule data through the application layer, the received rule data will be converted into rule instances by the parser according to the preset rule template. Specifically, the main function of the parser is to convert the rule data formed by the user's visual operation interface into rule instances that the rule engine system can process. Among them, when converting the rule data into rule instances that the rule engine system can process, the node topology structure of each rule node in the rule data will be constructed according to the preset rule template, and the rule instances will be determined based on the node topology structure. Based on this, the conversion of the rule data accessed to the rule engine system into rule instances specifically includes:

[0063] Receiving the rule data formed based on the user's visual operation interface;

[0064] Obtain the rule nodes included in the rule data, and based on the rule data, establish the node topology structure of each rule node. Determine the rule instance based on the node topology structures of all rule nodes. Among them, the node topology structure of each rule node includes the preceding rule nodes and the succeeding rule nodes of each rule node.

[0065] Specifically, the rule data formed by the user visualization operation interface is received through the rule editing entry. The rule data includes a trigger part, a condition judgment part, and an action execution part. The rule nodes included in the rule data can be determined based on the action execution part in the rule data. For example, each action in the action execution part can be regarded as a rule node, etc. The association relationship of rule nodes refers to the execution sequence between rule nodes. Among them, the preceding rule node of a rule node refers to the rule node that is located before the rule node and connected to the rule node according to the execution sequence, and the succeeding rule node of a rule node refers to the rule node that is located after the rule node and connected to the rule node according to the execution sequence. That is to say, after receiving the rule data formed by the user visualization operation interface, the rule nodes can be determined based on the action execution part of the rule data, and then the preceding rule nodes and the succeeding rule nodes of each rule node can be determined according to the execution sequence of each action in the rule execution part. Then, based on the rule nodes and their corresponding preceding rule nodes and succeeding rule nodes, the topology structure corresponding to the rule nodes is constructed. Among them, the topology structure includes the node information of the rule nodes and the preceding rule nodes and the succeeding rule nodes. The preceding rule nodes are used as the input nodes corresponding to the rule nodes, and the succeeding rule nodes are used as the output nodes corresponding to the rule nodes.

[0066] Exemplarily, the preset template of the topology structure of rule nodes can be expressed as:

[0067]

[0068] That is to say, after obtaining the rule data, determine the node topology structure of each rule node according to the above preset rule template, and then use the set composed of the node topology structures of all rule nodes as the rule instance to convert the rule data into a rule instance. It should be noted that the preset rule template is a general rule template, and through this preset rule module, the rule data determined by different trigger methods can be converted into rule instances that can be processed by the rule engine system.

[0069] Further, the converter is used to convert the rule instance into a thread task executable by the task execution layer. That is to say, after the rule data is converted into a rule instance by the parser, the rule instance can be operated on by the converter for model tasks to convert the rule instance into a thread task executable by the task execution layer. Among them, when converting the rule instance into a thread task executable by the task execution layer, all rule nodes in the rule instance can be converted into a single thread task, that is, each rule node is processed sequentially through this thread task; or each rule node can be converted into a thread task, and each rule node is asynchronously processed through the thread task corresponding to each rule node.

[0070] In the embodiment of the present application, thread tasks can be configured for the rule nodes according to their task types. Specifically, the conversion of the rule instance into a thread task executable by the task execution layer specifically includes:

[0071] Obtain the task categories of each rule node in the rule instance, and determine the task threads corresponding to each rule node based on the task categories of each rule node;

[0072] Generate node tasks for each rule node based on the task threads corresponding to each rule node, and associate the node tasks to convert the rule instance into a thread task executable by the task execution layer.

[0073] Specifically, the task type of each rule node can be determined according to the action to be performed by the rule node. Rule nodes of the same task type can be executed by the same type of thread task. That is to say, the differences between the thread tasks corresponding to the node tasks of the same task type are only the node association relationships (i.e., input nodes and output nodes) and configuration information of the rule nodes. Generate node tasks for each rule node based on the task threads corresponding to each rule node, and associate the node tasks through the rule id of the rule instance to determine the thread task corresponding to the rule instance. In addition, rule nodes of different task categories are implemented by different thread tasks, and the thread tasks configured in the task execution layer can be extended as the number of task categories increases. That is to say, the thread tasks in the task execution layer can be dynamically extended according to business needs.

[0074] Further, start to control the start and stop of the thread task. That is to say, the starter is mainly responsible for operating the thread task, receiving external instructions (Http requests), and starting and stopping the thread task. When starting, verification will be performed. After the verification passes, the corresponding thread task will be started, and the relevant task snapshot will be stored in the database as the basis for task changes. Also, after the rule data changes, new rule instances and thread tasks will be re-formed. At this time, the task list of the thread task will be compared with the task list in the snapshot, unnecessary thread tasks will be removed, and new thread tasks will be added. Only the incrementally changed thread tasks will be reloaded to improve the loading speed of the thread tasks. In addition, if the verification fails, a prompt will be given to the user. Among them, the data table structure of the task snapshot can be:

[0075]

[0076] comment 'Task snapshot table'.

[0077] In one implementation, the rule engine layer 200 further includes a publish-subscribe module, which is used to interact with the event bus to publish the execution status of the thread task or subscribe to the event that triggers the task thread. Specifically, after the thread task is started, a subscription to the specified conditional event will be formed. The event bus provides publish and subscribe interfaces. The publish-subscribe module will call the subscribe interface of the event bus to subscribe to the events required by the thread task after the thread task is started. When the thread task changes, the subscription will also be cancelled through the subscription module. In addition, when a conditional event occurs, the publish-subscribe module will receive the relevant subscription information and send the information to the corresponding thread task for thread task execution.

[0078] The task execution layer 300 is used to execute the node tasks of each rule node. It schedules the task execution layer 300 through a scheduler to parallelly execute the thread tasks of the rule nodes through the task execution layer 300 to achieve the parallel operation of different rule instances. Among them, for a rule instance, since there is an association relationship between the node tasks included in the rule instance, the task execution layer will execute each node task in sequence according to the association relationship between the node tasks. For task nodes without an association relationship, each task node can also be parallelly executed, thereby improving the execution efficiency of the task nodes.

[0079] In one implementation, the rule engine system further includes a data storage layer, asset control, and logging; the data storage layer is used to store the execution data formed during the execution of thread tasks, such as process data, log data, instance data, etc.; the asset control uses AOP aspect programming, which can be implemented through annotations; the logging is used to write log information in a date-rolling format, such as writing event trigger and rule trigger log information to ES in a date-rolling format. In addition, the rule instance can be in json format to support batch import / export of rule instances and batch enable / disable of rule instances.

[0080] In summary, this embodiment provides a rule engine system, which specifically includes an application layer, a rule engine layer, and a task execution layer; the application layer is used to provide a logical interface for accessing the rule engine layer; the rule engine layer is used to manage the business functions of rule instances and schedule the task execution layer to execute the thread tasks formed based on the rule instances; the task execution layer is used to execute the thread tasks formed by the rule engine layer in parallel. By deploying the rule engine system in layers in this application embodiment, and the rule engine layer can call the task execution layer to enable the task execution layer to perform asynchronous processing on task nodes, thus avoiding the problem of data congestion and improving the system performance of the rule engine system.

[0081] Based on the above rule engine system, this application embodiment provides a server, as Figure 4 shown, the server deploys the rule engine system as described above. Exemplarily, the server includes at least one processor and a memory, and may further include a communication interface and a bus. Among them, the processor, the memory, and the communication interface can communicate with each other through the bus. The communication interface can transmit information. The processor can call the logical instructions in the memory to execute the functions of the above rule engine system.

[0082] In addition, when the logical instructions in the above memory are implemented in the form of software functional units and sold or used as an independent product, they can be stored in a computer-readable storage medium.

[0083] As a computer-readable storage medium, the memory can be set to store software programs and computer-executable programs, such as program instructions or modules corresponding to the methods in the embodiments of the present disclosure. The processor executes functional applications and data processing by running the software programs, instructions, or modules stored in the memory, that is, implements the methods in the above embodiments. The memory can include a program storage area and a data storage area. Among them, the program storage area can store an operating system and application programs required for at least one function; the data storage area can store data created according to the use of the server and the like. In addition, the memory can include high-speed random access memory and can also include non-volatile memory. For example, various media such as USB flash drives, mobile hard disks, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical discs that can store program codes can also be transient storage media.

[0084] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application and are not intended to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A rule engine system, characterized in that: The rule engine system specifically includes: an application layer, a rule engine layer and a task execution layer; The application layer is used to provide a logical interface for accessing the rule engine layer; The rule engine layer is used to manage the business functions of the rule instance and schedule the task execution layer to execute the thread tasks formed based on the rule instance; The task execution layer is used to execute the thread tasks formed by the rule engine layer in parallel.

2. The rule engine system according to claim 1, characterized in that: The application layer includes: Business interface layer, used to provide business interfaces; The logic control layer is used to provide a control interface for the rule engine; The business logic layer is used to provide a control interface for rule instances in the rule engine.

3. The rule engine system according to claim 2, characterized in that: The control interface of the rule engine includes a rule editing control entry, a rule instance operation control entry, and a scene linkage control entry.

4. The rule engine system according to claim 1, characterized in that: The rule engine layer includes a parser, a converter and an initiator; The parser is used to convert the rule data accessed into the rule engine system into a rule instance; The converter is used to convert the rule instance into a thread task executable by the task execution layer; The launcher is used to control the start and stop of the thread task.

5. The rule engine system according to claim 4, characterized in that: The rule engine layer also includes a publish-subscribe module, which is used to interact with the event bus to publish the execution status of the thread task or subscribe to the event that triggers the task thread.

6. The rule engine system according to claim 4, characterized in that: The converting the rule data accessing the rule engine system into a rule instance specifically includes: Receiving rule data formed based on a user visual operation interface; The rule nodes included in the rule data are obtained, and a node topology structure of each rule node is established based on the rule data. A rule instance is determined based on the node topology structure of all rule nodes, wherein the node topology structure of each rule node includes a preceding rule node and a subsequent rule node of each rule node.

7. The rule engine system according to claim 4, characterized in that: The step of converting the rule instance into a thread task executable by the task execution layer specifically includes: Obtaining a task category of each rule node in the rule instance, and determining a task thread corresponding to each rule node based on the task category of each rule node; A node task is generated for each rule node based on the task thread corresponding to each rule node, and the node tasks are associated to convert the rule instance into a thread task executable by the task execution layer.

8. The rule engine system according to claim 4, characterized in that: The initiator is further used to store the task snapshot of the thread task in a database, so as to use the task snapshot as a basis for changing the thread task.

9. The rule engine system according to claim 1, characterized in that: The rules engine system also includes a data storage layer, asset control and logging; The data storage layer is used to store the execution data generated during the execution of the thread task; The asset control is used to utilize AOP aspect programming; The log record is used to write log information in a date rolling form.

10. A server, characterized in that: The server deploys the rule engine system as described in any one of claims 1-9.

Images