An automated rule processing method, system, and related devices

Abstract

An embodiment of the present application discloses an automated rule processing method, system and related devices, which can be specifically applied to fields such as the Internet of Things. Among them, an automated rule processing system includes a service module, a service processing module and a common module. The common module includes a pre-constructed event registration framework, and the event registration framework includes an event factor instance information table. The method includes: obtaining factor instance information of a target automated rule from the event factor instance information table in the common module through the service module; the factor instance information of the target automated rule includes one or more trigger conditions for triggering a target action; obtaining device information of each of the M devices through the service module, where each of the M devices is a device that meets the one or more trigger conditions; and executing the target action on the M devices through the service processing module. It can reduce the coupling between modules, reduce the code complexity, and improve the independent deployment ability of the modules.

Description

Technical Field

[0001] This application relates to the field of Internet of Things technology, and in particular to an automated rule processing method, system, and related devices. Background Art

[0002] The business scenarios faced by the Internet of Things - Business Support System (IOT - BSS) are different from the traditional business scenarios facing the "Internet of People". In the traditional business scenarios facing the "Internet of People", users, as independent individuals, have the need for self - management and can drive connections by themselves to obtain services. However, in the business scenarios faced by IOT - BSS, the interconnection of a large number of "things" requires the management of "things" to be automated and intelligent. Among them, the automated rule management module is particularly important. The automated rule management module belongs to the Customer Relationship Management (CRM) system. CRM will be integrated with other systems to complete the processing of automated rules. The involved interaction parties include components such as the Order Management (OM) module, Customer Management (CM) module, interaction management module, and billing external components. When the interaction component reports a rule to the automated rule execution module through the event mechanism, after receiving the corresponding message, the automated rule execution module processes the corresponding rule and performs subsequent actions.

[0003] In the Internet of Things scenario of the Business Enabling System (BES), a large number of devices need to be uniformly and automatically managed, which requires configuring a large number of rules for automatic management. Based on the existing implementation of the current BES, the reporting and receiving of rules can be achieved through the Business Event event mechanism provided by the platform. However, there are problems such as strong interactivity, high coupling degree, and poor independence between the automated rule management module and other modules.

[0004] Since each module needs to maintain a certain degree of independence, therefore, how to ensure that the coupling between modules is zero when using the automated rule ability is an urgent problem to be solved. Summary of the Invention

[0005] Embodiments of this application provide an automated rule processing method, system, and related devices, which can effectively eliminate the coupling between modules, reduce the code complexity, and improve the independent deployment ability of modules.

[0006] In a first aspect, an embodiment of the present application provides an automated rule processing method, which is applied to an automated rule processing system. The automated rule processing system includes a service module, a service processing module, and a common module. The common module includes a pre-built event registration framework, and the event registration framework includes an event factor instance information table. The method includes: obtaining, by the service module, factor instance information of a target automated rule from the event factor instance information table in the common module; the factor instance information of the target automated rule includes one or more trigger conditions for triggering a target action; obtaining, by the service module, device information of each of M devices, where each of the M devices meets the one or more trigger conditions, and M is an integer greater than or equal to 1; and performing, by the service processing module, the target action on the M devices.

[0007] Through the method provided in the first aspect, an event registration framework for automated rules can be pre-built in the common module. The event registration framework can include an event factor instance information table, and the event factor instance information table can include factor instance information of multiple automated rules. When performing automated rule processing, the service module can obtain the factor instance information of the current target automated rule (for example, it can include one or more trigger conditions for triggering the target action corresponding to the target automated rule) from the event factor instance information table, then query the devices that meet the conditions through the service module, and then perform the target action corresponding to the target automated rule (such as sending an email, sending a text message, or suspending the traffic service of the device, etc.) on the device through the service processing module. Thus, a triggering of an automated rule and the execution of an action are completed, that is, an automated rule is consumed. Therefore, compared with the prior art in which the service module can only query the factor instance information of the target automated rule by calling the interface of the automated rule management module, resulting in a strong coupling between the service module and the automated rule management module and greatly reducing the independence of the modules. In the embodiment of the present application, when obtaining the factor instance information, the service module does not need to call the interface of the automated rule management module, realizing the decoupling between the service module and the automated rule management module.

[0008] In a possible implementation manner, the automated rule processing system further includes an automated rule management module; the method further includes: when the automated rule processing system performs automated rule processing, configuring, by the automated rule management module, the target automated rule, generating the factor instance information of the target automated rule and the target action, and transmitting the factor instance information of the target automated rule to the event factor instance information table in the common module.

[0009] In an embodiment of the present application, when the automated rule processing system needs to perform automated rule processing, it may first configure the target automated rule through the automated rule management module (for example, when the user has a need to utilize the automated rule management device, one or more automated rules can be configured through the automated rule management module according to the user's actual needs, and the target automated rule can be one of them), generate factor instance information of the target automated rule and the target action to be executed by the target automated rule. Then, the automated rule management module can also transmit the generated factor instance information to the event factor instance information table pre-constructed by the common module for query use by the service module or other modules. Thus, when the service module needs to obtain the factor instance information of the target automated rule, it can directly obtain it from the event factor instance information table of the common module, realizing decoupling between the service module and the automated rule management module.

[0010] In a possible implementation manner, the service module does not set the corresponding code for calling the interface of the automated rule management module, and the method further includes: if the automated rule processing system does not perform automated rule processing, then do not execute the steps of configuring the target automated rule through the automated rule management module, generating the factor instance information of the target automated rule and the target action, and transmitting the factor instance information of the target automated rule to the event factor instance information table in the common module.

[0011] In an embodiment of the present application, since the service module can directly obtain the factor instance information of the target automated rule from the event factor instance information table, there is no need to set the corresponding code for calling the interface of the automated rule management module in the service module, greatly reducing the code complexity, workload and system burden. When the automated rule processing system does not need to perform automated rule processing, the automated rule management module also does not need to perform automated rule configuration and transmit the generated factor instance information to the event factor instance information table. Further, when the automated rule processing system does not need to perform automated rule processing, the automated rule management module can be not deployed. Thus, compared with the prior art where the code for calling the interface of the automated rule management module is fixed in the service module and the automated rule management module must be deployed together even when automated rule processing is not required (in the prior art, when it is checked during the final compilation process that the code for calling the interface of the automated rule management module is fixed in the service module but the automated rule management module is not deployed, an error handling will be performed, thus preventing smooth compilation), the embodiment of the present application realizes the independent deployment of the service module, avoids the burden added to the system operation by deploying redundant modules, and reduces the system startup time.

[0012] In a possible implementation, the automated rule processing system further includes a message queue processing module, and the event registration framework further includes an event specification definition table; the method further includes: obtaining, by the service module, the topic information of the target automated rule from the event specification definition table, and generating a corresponding first topic message based on the topic information, the factor instance information of the target automated rule, and the device information of each of the M devices; and sending, by the service module, the first topic message to the message queue processing module.

[0013] In an embodiment of the present application, the service module can obtain the topic information of the target automated rule from a pre-constructed event specification definition table (for example, including the topic information of multiple automated rules respectively), then generate a corresponding first topic message based on the topic information, the factor instance information, and the device information of each of the M devices, and send the first topic information to the message queue processing module. Thus, compared with the solution in the prior art where the topic information of the target automated rule is fixed in the code of the service module and the service module can only obtain the topic information of the target automated rule from its own code, the embodiment of the present application significantly reduces the code complexity of the service module itself. Moreover, when the topic information needs to be modified or extended, it can be directly modified in the event specification definition table without modifying the underlying code of each service module, thereby realizing one-key modification of the topic information and enhancing the maintainability and extensibility of the topic information.

[0014] In a possible implementation, the method further includes: listening, by the automated rule management module, to the first topic message, and querying the target action according to the first topic message; and generating, by the automated rule management module, a corresponding second topic message based on the topic information, the target action, and the device information of each of the M devices, and sending the second topic message to the message queue processing module.

[0015] In an embodiment of the present application, the automated rule management module can listen to the first topic message, query the target action of the target automated rule generated when configuring the target automated rule in advance according to the first topic message, then generate a corresponding second topic message based on the topic information, the target action, and the device information of each of the M devices, and send the second topic message to the message queue processing module for performing the target action on the M devices subsequently.

[0016] In a possible implementation, performing the target action on the M devices by the service processing module includes: listening, by the service processing module, to the second topic message, and performing the target action on each of the M devices according to the second topic message.

[0017] In an embodiment of the present application, the service module can obtain the device information and the target action included in the second topic message by listening to the second topic message, so that the service processing module can perform the target action corresponding to the target automation rule on the M devices that meet the factor instance information of the target automation rule (for example, send a reminder text message or a reminder email to a device that has ordered a certain product and the product is about to expire, etc.). It realizes the reasonable deployment of each functional module in the automation rule processing and improves the action execution efficiency of the automation rule.

[0018] In a possible implementation manner, the method further includes: registering, by the service module, an event specification definition of the target automation rule in the event specification definition table and filling in a module identifier corresponding to the service module.

[0019] In an embodiment of the present application, the event specification definition of the target automation rule can be registered in the event specification definition table by the service module, and the module identifier corresponding to the service module can be filled in, so as to perform the processing of the target automation rule. For example, it includes obtaining the factor instance information of the target automation rule from the event factor instance information table, querying devices that meet the conditions, and obtaining the topic information of the target automation rule from the event specification definition, etc. In this way, whenever other modules or a new service module wants to use the automation rule capability, they only need to register their own modules in the event rule definition table, without having to redeploy the automation rule management module repeatedly, realizing the decoupling between modules, enhancing the independent scalability of each module, there are no redundant modules in the system, and the startup time is reduced. In addition, the service module does not need to fixedly call the relevant code of the automation rule management module interface and the topic information of the target automation rule, greatly reducing the code complexity.

[0020] In a second aspect, an automation rule processing system provided by an embodiment of the present application includes a service module, a service processing module, and a common module. The common module includes a pre-constructed event registration framework, and the event registration framework includes an event factor instance information table. The service module is used to obtain factor instance information of a target automation rule from the event factor instance information table in the common module. The factor instance information of the target automation rule includes one or more trigger conditions for triggering a target action. The service module is further used to obtain device information of each of the M devices, and each device in the M devices is a device that meets the one or more trigger conditions, where M is an integer greater than or equal to 1. The service processing module is used to perform the target action on the M devices.

[0021] In a possible implementation manner, the automated rule processing system further includes an automated rule management module; when the automated rule processing system performs automated rule processing, the automated rule management module is configured to configure the target automated rule, generate factor instance information of the target automated rule and the target action, and transmit the factor instance information of the target automated rule to the event factor instance information table in the common module.

[0022] In a possible implementation manner, the business module does not set the corresponding code for calling the interface of the automated rule management module; if the automated rule processing system does not perform automated rule processing, the automated rule management module is not used to configure the target automated rule, generate factor instance information of the target automated rule and the target action, and transmit the factor instance information of the target automated rule to the event factor instance information table in the common module.

[0023] In a possible implementation manner, the automated rule processing system further includes a message queue processing module, and the event registration framework further includes an event specification definition table; the business module is further configured to obtain the topic information of the target automated rule from the event specification definition table, and generate a corresponding first topic message based on the topic information, the factor instance information of the target automated rule, and the device information of each of the M devices; the business module is further configured to send the first topic message to the message queue processing module.

[0024] In a possible implementation manner, the automated rule management module is further configured to listen for the first topic message and query the target action according to the first topic message; the automated rule management module is further configured to generate a corresponding second topic message based on the topic information, the target action, and the device information of each of the M devices, and send the second topic message to the message queue processing module.

[0025] In a possible implementation manner, the business processing module is specifically configured to listen for the second topic message and execute the target action on each of the M devices according to the second topic message.

[0026] In a possible implementation manner, the business module is further configured to register the event specification definition of the target automated rule in the event specification definition table and fill in the module identifier corresponding to the business module.

[0027] In a third aspect, a server provided in an embodiment of the present application may include the automated rule processing system according to any one of the above second aspects.

[0028] Fourth aspect, a server provided by an embodiment of the present application. The server may include a processor and a memory. The processor may be configured to support the server to implement corresponding functions in the automated rule processing method provided in the first aspect. The memory is coupled to the processor and may be used to store necessary program instructions and data of the server. The server may further include a communication interface for the server to communicate with other devices or communication networks.

[0029] Fifth aspect, an embodiment of the present application provides a computer-readable storage medium. The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, it implements the automated rule processing method described in any one of the above first aspects.

[0030] Sixth aspect, an embodiment of the present application provides a computer program. The computer program includes instructions, and when the computer program is executed by a computer, it enables the computer to execute the automated rule processing method described in any one of the above first aspects.

[0031] Seventh aspect, an embodiment of the present application provides a chip system. The chip system includes the automated rule processing system described in any one of the above second aspects and is used to implement the functions involved in the automated rule processing method described in any one of the above first aspects. In a possible design, the chip system further includes a memory for storing necessary program instructions and data of the automated rule processing method. The chip system may be composed of chips or may include chips and other discrete devices. Description of the Drawings

[0032] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the embodiments of the present application or the background technology will be described below.

[0033] Figure 1 It is a schematic diagram of the steps of an automated rule processing method in the prior art.

[0034] Figure 2 It is a schematic diagram of the system architecture of an automated rule processing method provided by an embodiment of the present application.

[0035] Figure 3 It is a schematic diagram of the structure of a server provided by an embodiment of the present application.

[0036] Figure 4 It is a schematic diagram of the structure of an automated rule processing system provided by an embodiment of the present application.

[0037] Figure 5 It is a schematic diagram of an application scenario of an automated rule processing method provided by an embodiment of the present application.

[0038] Figures 6a - 6c These are a set of interface schematic diagrams provided by an embodiment of the present application.

[0039] Figure 7 This is a flowchart of an automated rule processing method provided by an embodiment of the present application.

[0040] Figure 8 This is a flowchart of another automated rule processing method provided by an embodiment of the present application.

[0041] Figure 9 This is a schematic structural diagram of an automated rule processing system provided by an embodiment of the present application.

[0042] Figure 10 This is a schematic structural diagram of a server provided by an embodiment of the present application. Detailed implementation manners

[0043] Next, the embodiments of the present application will be described in conjunction with the accompanying drawings in the embodiments of the present application.

[0044] The terms "first", "second", "third", "fourth", etc. in the description, claims, and accompanying drawings of the present application are used to distinguish different objects, rather than to describe a specific order. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but optionally further includes steps or units not listed, or optionally further includes other steps or units inherent to these processes, methods, products, or devices.

[0045] Referring to "embodiment" herein means that a specific feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the present application. The phrase appears in various places in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment mutually exclusive with other embodiments. Those skilled in the art will explicitly and implicitly understand that the embodiments described herein can be combined with other embodiments.

[0046] As used in this specification, terms such as "component", "module", "system", etc. are used to represent computer-related entities, hardware, firmware, combinations of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, an execution thread, a program, and / or a computer. By way of illustration, an application running on a terminal device and the terminal device can both be components. One or more components can reside in a process and / or an execution thread, and the components can be located on one computer and / or distributed between two or more computers. In addition, these components can execute from various computer-readable media storing various data structures. The components can communicate, for example, through local and / or remote processes according to a signal having one or more data packets (such as data from two components interacting with another component between a local system, a distributed system, and / or a network, such as through the Internet interacting with other systems through a signal).

[0047] First, some terms used in this application are explained to facilitate understanding by those skilled in the art.

[0048] 1. Automation rules, which help customers manage multiple devices in the Internet of Things. The main application scenarios of automation rules are:

[0049] (1) Changes in the tariff plan or status of the Subscriber Identity Module (SIM): status changes such as testable, activated, deactivated, and expired;

[0050] (2) Security events: changes in the International Mobile Equipment Identity (IMEI);

[0051] (3) Subscription management: reaching or approaching the subscription deadline;

[0052] (4) Usage monitoring: usage thresholds, connection behaviors, etc., generally referring to the threshold of traffic usage (such as 50M, 10G, or 20G, etc.) and the mobile network connection situation (such as whether to connect to the mobile network, and for example, the connection situation of 3G, 4G, or 5G, and whether the mobile network connection is stable, etc.).

[0053] Among them, the Automation Rule Management (ARM) module is mainly used to manage the triggering, reporting, receiving, execution, and subsequent action processing of automation rules (such as sending text messages and emails after the execution of automation rules). Among them, the automation rule management module mainly completes:

[0054] (1) Lifecycle management of automation rules, including creation, suspension, deletion, etc. of automation rules;

[0055] (2) Receive trigger event messages of automation rules and perform post-trigger operations according to the definitions of automation rules;

[0056] (3) Distribution of automation rules. Different rules have corresponding rule execution systems or modules. Therefore, after creating a rule, it is necessary to synchronously distribute the rule information to the corresponding execution system or module;

[0057] (4) Record the log information of the rules, including the triggered rule information (the log information mainly records "when the rule was triggered by whom").

[0058] 2. Message Queue is an important component in a distributed system and is a container for storing messages during the message transmission process. By using a message queue, requests can be processed asynchronously, thereby alleviating the pressure on the system. Among them, queue messages and topic messages are two common message passing models. In the embodiments of this application, the method of sending topic messages to the message queue processing module and other modules listening for topic messages to obtain corresponding information is adopted.

[0059] In the Internet of Things system, different automation rule instances can be created for each device according to different application scenarios. Among them, the devices in the Internet of Things system can be, for example, terminal devices such as smartphones, tablets, laptops, desktop computers, etc., or robots or other possible Internet of Things devices of artificial intelligence, and so on. Generally, an Internet of Things device can often be bound to a card. For example, a smartphone can be bound to a SIM card. In some possible implementation manners, a SIM card can also be regarded as a device. For example, a smartphone supporting dual SIM cards can be regarded as two devices after binding two SIM cards, and so on. The embodiments of this application do not make specific limitations on this. The automation rule management module includes three important elements, namely: (1) Trigger (i.e., the specific description of the event): What is the automation rule event; (2) Filter (i.e., factor): What triggers the execution of the automation rule action; (3) Action: What action will the automation rule perform. These three points constitute the core of the automation rule. When the trigger condition is met, the devices that meet the conditions are screened out through the filter and the corresponding actions are executed. For example, for the goods ordered by the device (such as a data package, etc.), the customer can set an automation rule. When the goods are about to expire, an action (such as sending a text message or sending an email) can be triggered to help the customer manage the device.

[0060] As shown in Table 1, it is an example of setting typical automation rules. The factor 1, factor 2, and actions in Table 1 can all be configured by the customer through the front-end page and archived in the factor instance and action instance in the database by the automation rule management module respectively. Usually, only the configuration framework of specific rules is given on the front end, such as the configuration templates for product expiration and traffic reaching the threshold. The customer only needs to perform relevant configurations for the factor instance and action instance through the template. The automation rules that meet the conditions will be triggered.

[0061] Table 1

[0062] Trigger Factor 1 Factor 2 Action Product Expiration OfferingId = 232342 beforeExpire = 5 sendEmail Traffic Reaches Set Threshold Device Status = 2 Threshold: 10M Suspend Device

[0063] As shown in Table 1, the triggering and action execution of the automation rules for product expiration and traffic reaching the threshold are described as follows:

[0064] (1) For the device with the offering ID of 232342, an email (sendEmail) is sent to the specified email address (such as the email address bound to the device or the email address pre-set by the customer) 5 days before the expiration of the product (beforeExpire).

[0065] (2) For the device with the device status of 2, such as an activated and valid device, when the traffic used by the device reaches the 10M threshold (Threshold), operations such as pausing the device can be performed, such as stopping the traffic service of the device and prohibiting the device from using traffic anymore.

[0066] To facilitate the understanding of the embodiments of the present application, the technical problems specifically to be solved by the present application are further analyzed and proposed. In the prior art, regarding the triggering and execution technologies of automation rules, there are various technical solutions, and the following is an example of a commonly used solution.

[0067] Solution 1: By calling the interface of the automation rule management module, query the factor instance information of the target automation rule, and query the devices that meet the conditions according to the factor instance information, so as to perform the actions corresponding to the target automation rule on the devices.

[0068] Please refer to Figure 1 , Figure 1 is a schematic diagram of the steps of an automation rule processing method in the prior art. As Figure 1As shown, the business module therein is the business trigger party, that is, it is responsible for triggering the automation rules. Generally, this process can be achieved by creating a scheduled task. When the scheduled task is executed, the business module can query the factor instance information of the target automation rule corresponding to this scheduled task for this time by calling the interface of the automation rule management module. Then, it queries the device information that meets the conditions (that is, the device information that conforms to this factor instance information, such as the identification codes of one or more SIM cards or the IMEI of a smart phone, etc.), and then sends the factor instance information and the device information to the message queue through the topic message. The automation rule management module can obtain the above factor instance information and device information by listening to this topic message to perform subsequent actions. Optionally, this business module can specifically be a customer management module, an order management module, or other modules that can trigger automation rules, etc.

[0069] As Figure 1 shown, this method may include the following steps S101 - step S109:

[0070] Step S101, the automation rule management module configures the target automation rule, generates the factor instance information and action instance information of the target automation rule, and archives this factor instance information and action instance information. For example, they can be respectively archived in the factor instance and action instance of the database. Optionally, this factor instance information can, for example, include "OfferingId = 232342" and "beforeExpire = 5" as shown in Table 1, and this action instance information can, for example, be "sendEmail" as shown in Table 1. Among them, instantiation is the process of concretizing the abstract concept classes (such as "factor" and "action") into the physical objects of this class (such as factor instances like "OfferingId = 232342" and action instances like "sendEmail"). Optionally, the customer can configure the target automation rule through the configuration interface provided by the front end (such as the configuration interface displayed by relevant application software or websites that can be used to create, edit, and delete automation rules, etc.), and fill in the corresponding factor instances and action instances according to their own needs. Optionally, the user can configure multiple automation rules according to their actual needs through this automation rule management module, and respectively generate their own factor instance information and action instance information, etc., which will not be elaborated here.

[0071] Step S102: The business module calls the interface of the automated rule management module to query the factor instance information of the target automated rule. Optionally, the business module can trigger the scanning and detection of the target automated rule at a fixed time every day according to a pre-set scheduled task, that is, start to call the interface of the automated rule management module to query the factor instance information of the target automated rule. Optionally, multiple scheduled tasks can also be set to perform the scanning and detection of different automated rules at the same time or at different times every day, and the factor instance information of multiple different automated rules can be queried respectively, etc. The embodiments of the present application do not make specific limitations on this.

[0072] Step S103: The business module constructs a query condition according to the factor instance information of the target automated rule and queries the device information that conforms to the factor instance information.

[0073] Step S104: The business module sends a topic message (this topic message includes device information and factor instance information) to the message queue processing module.

[0074] Step S105: The automated rule management module listens for the topic message.

[0075] Step S106: The automated rule management module parses the message body according to the topic message to obtain the device information, factor instance information, and the topic corresponding to the target automated rule. The automated rule management module queries the action instance information of the target automated rule according to this topic. Optionally, the factor instance information and other information of the target automated rule can also be queried according to this topic, etc.

[0076] Step S107: The automated rule management module sends a topic message (this topic message includes device information and action instance information) to the message queue processing module.

[0077] Step S108: The business processing module listens for the topic message.

[0078] Step S109: The business processing module parses the message body according to the topic message to obtain the device information and action instance information. The business processing module performs corresponding action processing on the device corresponding to the device information according to this action instance information. For example, send a reminder text message to the mobile phone number corresponding to the device, or send a reminder email to a specified email address, etc.

[0079] In summary, there are two disadvantages in the above-mentioned Solution 1 in the prior art, which are specifically as follows:

[0080] (1) When the rule reporting is triggered by the business module during execution, the business module needs to call the interface of the automated rule management module to query the factor instance information of the automated rule from the automated rule management module. At this time, there is a coupling relationship between modules, and the business module needs to depend on the automated rule management module. In terms of positioning, the automated rule management module and the business module are modules at the same level and should not have a dependency relationship. Moreover, the process of calling the interface to query the factor instance information will significantly affect the efficiency of obtaining the factor instance information, and thus affect the overall efficiency of automated rule processing. At the same time, there are multiple different environments in the multi-business scenarios of BES (such as different operator environments of mobile, telecom, and unicom, etc.). After using the automated rule capability, the automated rule management module needs to be deployed simultaneously in each environment. However, when the automated rule capability is not used, there is actually no need to deploy the automated rule management module. However, in the prior art, since the corresponding code for calling the interface of the automated rule management module is fixed in the business module, and the automated rule management module must also be deployed when automated rule processing is not required (in the prior art, when it is checked during the final compilation that the code for calling the interface of the automated rule management module is fixed in the business module but the automated rule management module is not deployed, an error handling will be performed, resulting in the failure to complete the compilation smoothly). At this time, the business module lacks the ability to be independently deployed, the code complexity becomes higher, and the deployment of useless modules will also increase the environment startup time. For other modules at the same level that want to use the automated rule capability, the same problem exists, and the reusability is low.

[0081] (2) When the automated rule is triggered (that is, when the device information that meets the factor instance information is queried), the business module needs to send an automated rule consumption event (that is, the above-mentioned topic message) to the message queue. For different automated rules, the automated rule management module needs to define different Topics. When the Topic is modified or extended, all modules that reuse the automated rule capability (such as business modules like the customer management module and the order management module, etc.), the Topic of the file for sending events also needs to be modified synchronously, and the maintainability is poor.

[0082] In summary, the business module of the above-mentioned Solution 1 must query the corresponding factor instance information by calling the interface of the automated rule management module, resulting in low query efficiency, which greatly affects the overall efficiency of automated rule processing. There is a tight coupling between the business module and the automated rule management module. Therefore, to solve the problems in the current automated rule processing technology that do not meet the actual business requirements, the technical problems to be actually solved in this application include the following aspects: Based on the principle of decoupling independent modules, business modules such as the customer management module cannot directly depend on and reference the services of the peer automated rule management module. Therefore, the event definitions (i.e., topics) and factor instance information required for business reporting cannot be directly obtained from the automated rule management. Additionally, the topic of the automated rule may be modified, and the business module needs to obtain it flexibly when obtaining the topic, rather than being fixed in the code of the business module. Therefore, at this time, it is necessary to solve the tight coupling problem between the business module and the automated rule management module, as well as the problem that the topic of the automated rule cannot be modified and extended with one key.

[0083] Please refer to Figure 2 , Figure 2 which is a schematic diagram of the system architecture of an automated rule processing method provided by an embodiment of this application. As Figure 2 shown, the system architecture may include a server 100a and multiple Internet of Things devices, specifically including Internet of Things devices 200a, 200b, 200c, and 200d. A communication connection may be established between the server 100a and the Internet of Things devices 200a, 200b, 200c, and 200d in a wireless network manner. Among them, the Internet of Things devices 200a, 200b, 200c, and 200d may be Internet of Things devices of the same user or Internet of Things devices of different users. Among them, an automated rule processing system capable of implementing corresponding automatic rule capabilities may be configured in the server 100a. Among them, in automated rule processing, the triggering and reporting, and receiving and execution of automated rules are in the form of events and are transmitted and processed through a message queue between the rule production triggering end (each business module such as the customer management module and the order management module) and the rule consumption execution end (the automated rule management module, the business processing module, etc.). The rule production triggering end mainly completes triggering an automated rule event and reporting information to the automated rule management module when the business meets a certain condition; the automated rule management module at the rule consumption execution end is mainly responsible for the definition and management of rules, including rule classification, action coding, execution conditions, execution actions, action execution filtering conditions, message template definition, etc. After receiving the rule event, it parses the content of the event message, judges whether the execution action condition is met, and executes the corresponding action of the automated rule.

[0084] Optionally, please refer to Figure 3 , Figure 3FIG. 0 is a schematic diagram of the structure of a server provided in an embodiment of the present application. Hereinafter, the embodiment will be specifically described by taking the server 100a as an example. It should be understood that the server 100a may have more or fewer components than those shown in Figure 3 and may combine two or more components, or may have different component configurations. Figure 3 The various components shown in can be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and / or application specific integrated circuits. As Figure 3 shown, the server 100a may include an automated rule processing system 30, a wireless communication system 31, a power management module 32, a battery 33, and a computer system 34.

[0085] Please refer to Figure 4 , Figure 4 FIG. 13 is a schematic diagram of the structure of an automated rule processing system provided in an embodiment of the present application. As Figure 4 shown, the automated rule processing system 30 may include a business hall portal 301 and a service processing module 302 at the same level, and may further include an automated rule management module 303 at another level, as well as service modules such as a customer management module 304 and an order management module 305. In addition, it may further include a message queue processing module 306 and a common module 307 at other levels. Optionally, in some possible embodiments, the automated rule processing system 30 may include more, fewer, or even different components than those shown in Figure 4 . For example, when the automated rule processing system 30 does not perform automated rule processing, the automated rule management module 303 may not be deployed. The automated rule processing system 30 may also perform other service processing, such as shutting down a device or canceling a number based on a user's corresponding operation. Another example is that when the automated rule processing system 30 does not perform order management, the order management module 305 may not be deployed, and so on. The embodiments of the present application do not make specific limitations in this regard. As Figure 4 shown, the automated rule processing system 30 may also be a multi-module decoupling framework based on event registration under IOT-BSS.

[0086] Among them, the business hall portal (Portal) 301 provides an interface for managing rule instances (including factor instances and action instances of automated rules). The main functions of the business hall portal 301 include:

[0087] (1) Rule instance list query interface: When the default page is loaded, all the automated rules created for the corresponding user are queried and displayed in the form of a list;

[0088] (2) Rule instance editing interface: This page can complete the modification, suspension, and deletion of the rule instance;

[0089] (3) Rule instance creation interface: This page provides the function of creating a rule instance. To create a rule instance, one needs to select a trigger (i.e., select an automation rule, such as reminder for product expiration or reminder for traffic usage reaching the threshold, etc.) and instantiate the corresponding parameters, select a filter (i.e., factor) and instantiate the corresponding parameters (such as selecting the factor of product identification and instantiating its product identification as the specific "232342"), select an operation and instantiate the corresponding parameters (such as selecting the operation of sending an email and instantiating its specific email address as "71xx894@xx.com"), and so on;

[0090] (4) Deletion of rule instances: One or more rule instances can be deleted through the "Delete" menu;

[0091] (5) Triggered rule instance query interface: When the default page is loaded, it queries all the triggered rule instance data of the corresponding user within a rule cycle, and the results are displayed in the form of a list.

[0092] Among them, the business processing module 302 mainly completes the specific execution of the action instances of the automation rules (such as sending a reminder email to the specified email address, etc.).

[0093] Among them, the automation rule management module 303, its main functions include:

[0094] (1) Lifecycle management of automation rules, including rule creation, suspension, and deletion;

[0095] (2) Issuance of automation rules. Different rules have corresponding rule execution systems or modules. Therefore, after a rule is created, the rule information needs to be synchronized to the corresponding execution system or module. For example, in the embodiment of the present application, the automation rule management module 303 can, after the automation rule is configured, synchronize the generated factor instance information to the event factor instance information table pre-constructed by the common module for the business module to directly obtain the corresponding factor instance information therefrom;

[0096] (3) Receive the trigger event message of the automation rule and perform the operation after triggering according to the rule definition;

[0097] (4) Record the log information of the rule, including the triggered rule information (this log information mainly records "when the rule was triggered by whom").

[0098] Among them, the customer management module 304 is responsible for customer management and trigger reporting of rules. Generally, the automation rules related to customers and devices will be triggered by the customer management module 304.

[0099] Among them, the order management module 305 is responsible for order management and triggering and reporting of rules. It is at the same level as the customer management module 304. Generally, automated rules related to orders are triggered by the customer management module 304. Among them, the customer management module 304 and the order management module 305 can be collectively referred to as business modules.

[0100] Among them, the Common module 306 is a provider of other common capabilities such as the event registration framework capability. For example, in the embodiment of the present application, an event registration framework can be pre-constructed in the Common module 306. The event registration framework can include an event specification definition table and an event factor instance information table for business modules such as the customer management module 304 and the order management module 305 to directly obtain the topic information and factor instance information of the automated rules respectively, and so on.

[0101] Among them, the message queue processing module 307 processes the triggering, reporting, receiving, and execution of rules in the form of events through the message queue. Optionally, the functions of each module in the above-mentioned automated rule processing system 30 can be implemented by one or more processors, and each of all or part of the modules in the above-mentioned automated rule processing system 30 can have its own processor.

[0102] The wireless communication system 31 can communicate wirelessly with one or more devices directly or via a communication network. The wireless communication system 31 can communicate through various wireless communication methods such as, but not limited to, the second-generation mobile communication network (2G), 3G, 4G, 5G, etc., and can also be Wireless-Fidelity (WIFI), Dedicated Short Range Communications (DSRC), etc., or can be a wired communication mode connected by a data cable, etc. Its main function is to query the status and relevant information of each device. For example, it can include the commodity information and commodity status ordered by each device, and can also include the traffic usage and remaining tariff situation of the device, etc., and perform corresponding actions on devices that meet the conditions. For example, send a reminder email for an upcoming expiration of a commodity to the mailbox of a device that has ordered a certain commodity that is about to expire, or stop the traffic service of a device whose traffic usage reaches a set threshold, and so on.

[0103] Among them, the power management module 32 is used to connect the automated rule processing system 30, the wireless communication system 31, the battery 33, and the computer system 34. The power management module 32 receives the input from the battery 33 and supplies power to the automated rule processing system 30, the wireless communication system 31, the computer system 34, etc.

[0104] Some or all of the functions of server 100a are controlled by computer system 34. Computer system 34 may include at least one processor 341 that executes instructions 343 stored in a non-transitory computer-readable medium such as memory 342. Computer system 34 may also be a plurality of computing devices that control individual components or subsystems of server 100a in a distributed manner.

[0105] Processor 341 can be any conventional processor, such as a commercially available CPU. Optionally, the processor can be a special-purpose device such as an ASIC or other hardware-based processor. Processor 341 may include one or more processing units. For example, processor 110 may include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Among them, different processing units can be independent devices or integrated in one or more processors. Among them, the controller can be the nerve center and command center of server 100a. The controller can generate operation control signals according to the instruction operation code and timing signals to complete the control of fetching and executing instructions. Although Figure 3 The functional diagram shows the processor and the memory, but those of ordinary skill in the art should understand that the processor or memory may actually include multiple processors or memories that are not stored in the same physical enclosure. For example, the memory can be a hard disk drive or other storage medium located in an enclosure different from computer system 34. Therefore, the reference to a processor or memory will be understood to include a reference to a collection of processors or memories that may or may not operate in parallel. Different from using a single processor to execute the steps described herein, for example, some components in the automated rule processing system 30 may each have its own processor, and the processor only performs calculations related to component-specific functions.

[0106] A memory can also be provided in the processor 341 for storing instructions and data. In some embodiments, the memory in the processor 341 can be a cache memory. This memory can store the instructions or data that the processor 341 has just used or recycled. If the processor 341 needs to use the instruction or data again, it can directly call it from the said memory. This avoids the repeated access of instructions or data, reduces the waiting time of the processor 341, and thus can greatly improve the operation efficiency of the system.

[0107] In some embodiments, the processor 341 can include one or more interfaces. The interfaces can include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0108] It can be understood that the interface connection relationships between the modules illustrated in the embodiments of the present application are only illustrative descriptions and do not constitute a structural limitation on the server 100a. In other embodiments of the present application, the server 100a can also adopt different interface connection methods from those in the above embodiments, or a combination of multiple interface connection methods.

[0109] In some embodiments, the memory 342 can contain instructions 343 (e.g., program logic), and the instructions 343 can be executed by the processor 342 to perform various functions of the server 100a, including those described above. The memory 342 can also contain additional instructions, including instructions for sending data to, receiving data from, interacting with, and / or controlling the automation rule processing system 30 and the wireless communication system 31, etc.

[0110] In addition to instruction 343, the memory 342 can also store data, such as device information (e.g., International Mobile Equipment Identity, i.e., mobile phone serial number, and also e.g., SIM card number, etc.) and device status (e.g., product information ordered by each device, product status, and remaining fees of each device, etc.) of one or more devices of each user in the Internet of Things system, and so on.

[0111] It can be understood that the server 100a can have more or fewer components than those Figure 3 shown in the figure, can combine two or more components, or can have different component configurations. The various components shown in the figure can be implemented in hardware, software, or a combination of hardware and software including one or more signal processing and / or application specific integrated circuits.

[0112] The following will be combined with Figure 2 、 Figure 3 and Figure 4Elaborate in detail on the technical solution proposed in this application. This application proposes an automated rule processing method, which can be applied to an automated rule processing system. In this application, an event registration framework is pre-constructed in the common module 306 of the automated processing system 30. This event registration framework can include an event specification definition table and an event factor instance information table. After configuring the automated rules through the automated rule management module 303 to generate corresponding factor instance information and action instance information, the automated rule management module 303 can transmit the factor instance information to the event factor instance information table in the common module 306. This event factor instance information table can include the factor instance information of multiple automated rules respectively. The event specification definition table can include the topic information of multiple automated rules respectively (that is, topic, which is the full name of the event of the automated rule, the full name with the package path in the definition file, globally unique, used to uniquely determine its corresponding automated rule and used for triggering subsequent automated rules). Thus, when the user configures the target automated rule according to their own needs through the interface provided by the front end (for example, for a device that has ordered a product with the product identifier 232342, send a reminder text message about the upcoming expiration of the product to the mobile phone number bound to the device five days before the expiration of the product) and sets the corresponding scheduled task (for example, schedule the detection of the target automated rule at 8:00 every morning). The customer management module 304 in the automated rule processing system 30 can, when the scheduled task is triggered at the scheduled time, query the factor instance information of the target automated rule from the event factor instance information table in the common module 306 (for example, including "product identifier 232342" and "five days before the expiration of the product"); then, the customer management module 304 can query the device information (such as the International Mobile Equipment Identity, that is, the mobile phone serial number, SIM card number, or mobile phone number or other device information, etc.) of one or more devices (such as Internet of Things devices 200a and 200b) that meet the conditions according to the factor instance information. Optionally, if no devices that meet the conditions are queried in this scheduled task (for example, the date when this scheduled task is executed is 20 days before the expiration of the product, etc.), then this task can be terminated and the subsequent steps are not executed. Wait for the next scheduled task to be triggered, etc., and details will not be elaborated here. After the customer management module 304 queries the device information of one or more devices that meet the conditions, the customer management module 304 can obtain the topic information of the target automated rule from the event specification definition table in the common module 306, and then generate a corresponding topic message according to the topic information, factor instance information, and device information of the target automated rule that meet the conditions, and send the topic message to the message queue processing module 307.Then, the automated rule management module 303 can obtain the topic information, factor instance information, and device information that meet the conditions of the automated rule by listening to the topic message and parsing the message body, and query the action instance information of the target automated rule based on the topic information. Then, the automated rule management module 303 can generate a corresponding topic message based on the topic information, action instance information, and device information that meet the conditions of the target automated rule, and send the topic message to the message queue processing module 307. Then, the service processing module 302 can obtain the topic information, action instance information, and device information that meet the conditions of the target automated rule by listening to the topic message and parsing the message body, so that the service processing module 302 can execute the action instance on the one or more devices that meet the conditions (for example, sending a reminder message that a commodity is about to expire to the IoT devices 200a and 200b respectively, etc.). Thus, the triggering and action execution of the target automated rule are completed, that is, the target automated rule is consumed.

[0113] In summary, based on the above technical problems that the present application actually aims to solve, the present application proposes an automated rule processing system (that is, a multi-module decoupling framework based on event registration). By using the event registration framework (including event specification definition table and event factor instance information table) pre-constructed by the common module to save the event definition (that is, topic) and the factor instance information of the rule, as a general configuration ability, it is provided for the customer management module and other business modules with similar scenarios in the future. The core lies in that for the scenario where multiple independent modules (referring to modules with different business functions, and there is no direct interaction between the modules, such as the customer management module and the automated rule management module) need to be integrated, based on the event registration (in the scenario of automated rules, the triggering of the rule is transmitted through message events, and the rule events are defined in the framework in advance, which is called event registration) framework, the coupling (also called inter-block connection, which is a measure of the degree of mutual connection between modules in the software system structure. The more connections between modules, the stronger its coupling, and at the same time, it indicates that its independence is worse (reducing the coupling can improve its independence). One of the criteria for dividing modules in software design is high cohesion and low coupling) between the derivative modules (business modules such as the customer management module and the order management module) and the source module (the automated rule management module) is reduced to zero, and the Topic of the automated rule message event (as mentioned above, the Business event is a notification for completing a specific behavior in the BES system, which is used for asynchronous decoupling between modules. The Topic is the theme, and the engine automatically generates an assistant message for interacting with the message queue processing module according to this configuration) is flexibly obtained, and the maintainability and scalability are enhanced.

[0114] In summary, the IoT devices 200a, 200b, 200c, and 200d can be intelligent devices in the IoT system, such as smartphones, tablets, laptops, desktop computers, robots, and other devices. The embodiments of the present application do not make specific limitations thereto. Optionally, the IoT devices 200a, 200b, 200c, and 200d may include a SIM card interface for connecting to a SIM card. The SIM card can be inserted into or removed from the SIM card interface to achieve contact and separation from the IoT devices 200a, 200b, 200c, and 200d. In some embodiments, the IoT devices 200a, 200b, 200c, and 200d may adopt an eSIM, i.e., an embedded SIM card. The eSIM card can be embedded in the IoT devices 200a, 200b, 200c, and 200d and cannot be separated from them. The server 100a can be a single server with the above functions, a server cluster composed of multiple servers, or a cloud computing service center, etc. The embodiments of the present application do not make specific limitations thereto.

[0115] To facilitate the understanding of the embodiments of the present application, the following are exemplary scenarios applicable to an automated rule processing method in the present application, which may include the following scenarios.

[0116] Scenario 1: The user configures an automated rule according to their own needs to send a reminder email that the purchased product is about to expire to a specified email address five days before the expiration of the product ordered on their device.

[0117] Please refer to Figure 5 , Figure 5 which is a schematic diagram of an application scenario of an automated rule processing method provided by the embodiments of the present application. As Figure 5 shown, this application scenario includes a server and an IoT device ( Figure 5 taking a smartphone as an example in Figure 5(not shown in the figure), the multiple Internet of Things devices can be different devices of the same user in the Internet of Things system. For example, they can be two smartphones each bound to a SIM card, or a smartphone that is bound to two SIM cards simultaneously and supports dual standby, etc. The embodiments of the present application do not make specific limitations thereto. The Internet of Things device may include relevant memories, displays, processors, etc. Among them, the memory, display, and processor can perform data transmission through the system bus. Among them, the Internet of Things device and the server can perform data transmission through wireless communication methods such as Wi-Fi or mobile networks or wired communication methods such as data lines. Among them, the server can be configured with an automated rule processing system, and the automated rule processing system can include business modules (such as customer management modules and order management modules, etc.), business processing modules, automated rule management modules, and common modules, etc. The common module can include a pre-built event registration framework, and the event registration framework can include an event specification definition table and an event factor instance information table. Among them, the event specification definition table includes the topic information of each of the multiple automated rules, and the event factor instance information table includes the factor instance information of each of the multiple automated rules. In the embodiments of the present application, after the timing task of a certain automated rule is triggered by the business module, based on the automated rule processing system of the present application, and using an automated rule processing method in the present application, the factor instance information of the automated rule can be obtained from the event factor instance information table of the common module (for example, including "the product identifier is 232342" and "five days before the product expires" as shown in Figure 5 ), and the device information that meets the factor instance information can be queried, and the topic information of the automated rule (generally a string of characters) can be obtained from the event specification definition table of the common module, so that the final business processing module can execute the action instance of the automated rule on the device that meets the factor instance information (for example, Figure 5 ) sending a reminder email that the product is about to expire to the email box bound to the Internet of Things device). Optionally, for example, if the business module queries that all the Internet of Things devices of the user have ordered the product with the product identifier of 232342 and the products will all expire in five days, the final business processing module can send a reminder email that the product is about to expire to the email boxes bound to all the Internet of Things devices of the user respectively, etc., and details will not be elaborated here.

[0118] In the embodiments of the present application, when the user wants to configure corresponding automated rules to manage the automated rules of their Internet of Things devices, the operation process of the user on the terminal device can refer to Figures 6a - 6c , Figures 6a - 6c which is a set of interface schematic diagrams provided by the embodiments of the present application. Among them, the terminal device and the above-mentioned server can perform data transmission through wireless communication methods such as Wi-Fi or mobile networks or wired communication methods such as data lines. AsFigure 6a As shown, the terminal device displays an automated rule creation interface 401. Among them, the automated rule creation interface 401 may include an automated rule list listing multiple default automated rules (for example, it may include Figure 6a "Automated Rule - Commodity Expiration Reminder", "Automated Rule - Device Status Change Reminder", "Automated Rule - Traffic Threshold Reminder", "Automated Rule - Automatic Traffic Speed Limit", and "Automated Rule - Remaining Tariff Reminder" as shown). Among them, the automated rule creation interface 401 may also include creation controls for each of the multiple automated rules. For example, Figure 6a the creation control 402a for "Automated Rule - Commodity Expiration Reminder", the creation control 402b for "Automated Rule - Device Status Change Reminder", the creation control 402c for "Automated Rule - Traffic Threshold Reminder", the creation control 402d for "Automated Rule - Automatic Traffic Speed Limit", and the creation control 402e for "Automated Rule - Remaining Tariff Reminder" as shown. Optionally, the automated rule creation interface 401 may also include a custom automated rule control 403, a setting control 404, and other controls, etc. For example, as Figure 6a shown, when a user wants to create an automated rule for commodity expiration reminder to manage their Internet of Things devices, they can trigger the creation of the automated rule through an input operation 405 (such as clicking the creation control 402a). At this time, as Figure 6b shown, after the user clicks the creation control 402a, the terminal device displays the creation interface 406 for "Automated Rule - Commodity Expiration Reminder". Among them, the creation interface 406 for "Automated Rule - Commodity Expiration Reminder" may include a commodity identification input control 407, a number of days before commodity expiration input control 408, an email sending selection control 409a, a text message sending selection control 409b, an email address input control 410, and a creation control 411. As Figure 6b shown, the user can set the commodity identification, the number of days before commodity expiration, and the reminder operation according to their own needs in the creation interface 406 for "Automated Rule - Commodity Expiration Reminder", and if they choose to send an email, they need to set the email address. Optionally, the user can also select a suitable email template in the creation interface 406 for "Automated Rule - Commodity Expiration Reminder" ( Figure 6b not shown in the figure, and the email template may include content reminding the user that the ordered commodity is about to expire). For example, as Figure 6bAs shown, if the user has confirmed the completion of the configuration of "Automation Rule - Commodity Expiration Reminder", the user can complete the creation of "Automation Rule - Commodity Expiration Reminder" by input operation 412 (for example, clicking the creation control 410). During the process of creating an automation rule by the user through the above operation interface, the terminal device can establish a connection with the automation rule management module in the server, and complete the creation of the automation rule through the automation rule management module, generating corresponding factor instance information (for example, including Figure 6b "Commodity ID is 232341" and "5 days before the commodity expiration" shown) and action instance information (for example, Figure 6b "Send an email to the mailbox xxxxxxx@xx.com" shown). Then, the automation rule management module can archive the generated factor instance information and action instance information into the database, and transmit the factor instance information to the event factor instance information table of the public module. Thus, when the timing task of this automation rule is triggered, the business module can directly obtain the factor instance information of this automation rule from the event factor instance information table of the public module, without querying the factor instance information from the automation rule management module by calling the automation rule management module interface. Through an automation rule processing method and system provided by an embodiment of the present application, decoupling between the business module and the automation management module is achieved.

[0119] Furthermore, as Figure 6c shown, the terminal device displays an automation rule management interface 413, where the automation rule management interface 413 may include a setting control 414 and editing controls and deletion controls for each of multiple configured automation rules. For example, as Figure 6c shown, the editing control 415a and deletion control 415b of automation rule 1, the editing control 416a and deletion control 416b of automation rule 2, and the editing control 417a and deletion control 417b of automation rule 3, etc., are not elaborated here. The user can edit (for example, change factor instances and action instances, etc.) and delete the configured automation rules according to their own needs. For example, as Figure 6c shown, the user can delete the configured automation rule 1 by input operation 418 (for example, clicking the deletion control 415). Thus, it can meet the user's need to manage automation rules according to their own habits or requirements, thereby further better managing their Internet of Things devices.

[0120] Optionally, the above Figures 6a - 6c operation process can also be completed by the Figure 5 Internet of Things device in (that is, the terminal device can be the Figure 5 Internet of Things device in). Optionally, the creation of the automation rule can also be done by developers using Figure 5The server in it, or terminal devices, computers, etc. connected to the server, are pre-created through the automated rule management module in the automated rule processing system, so as to provide users with a variety of directly usable automated rules.

[0121] As described above, the Internet of Things device can be a smart phone, a smart wearable device, a tablet computer, a notebook computer, a desktop computer, a robot, etc. with the above functions. The embodiments of the present application do not make specific limitations thereto; the terminal device can be a smart phone, a smart wearable device, a tablet computer, a notebook computer, a desktop computer, etc. with the above functions. The embodiments of the present application do not make specific limitations thereto; the server can be a single server with the above functions, or a server cluster composed of multiple servers, or a cloud computing service center, etc. The embodiments of the present application do not make specific limitations thereto. It can be understood that an automated rule processing method provided by the present application can also be applied to other scenarios except the above application scenarios.

[0122] Please refer to Figure 7 , Figure 7 is a schematic flowchart of an automated rule processing method provided by an embodiment of the present application. This method can be applied to the system architecture described above Figure 2 and can be specifically applied to the above Figure 2 or Figure 3 the server 100a described above and Figure 4 the automated rule processing system described above. The device therein can be Figure 2 any one of the Internet of Things devices 200a, 200b, 200c, and 200d described above. The following combines the appended Figure 7 Taking the server 100a in the above Figure 2 as an example for description. The method can include the following steps S701 - step S703:

[0123] Step S701, obtaining the factor instance information of the target automated rule from the event factor instance information table in the public module through the service module; the factor instance information of the target automated rule includes one or more trigger conditions for triggering the target action.

[0124] Specifically, a scheduled task can be created for the target automation rule (for example, to detect the target automation rule at 12:00 noon every day and query whether there is a trigger for the target automation rule). When the scheduled task is executed, the business module can obtain the factor instance information of the target automation rule from the event factor instance information table in the public module. Optionally, the factor instance information may include one or more trigger conditions (i.e., one or more factor instances, such as "product identifier is 232341" and "5 days before the product expires") set by the user in advance for triggering the target action (i.e., the action instance of the target automation rule, such as sending an email to the email address bound to the device). Optionally, the business module may be, for example, the customer management module 304, the order management module 305, or other business modules described above in Figure 3 The present application embodiment does not make specific limitations on this. Thus, compared with the prior art, the business module can only query the factor instance information of the target automation rule from the automation rule management module by calling the interface of the automation rule management module, resulting in strong coupling between the business module and the automation rule management module and greatly reducing the independence of the module. In the present application embodiment, when obtaining the factor instance information, the business module does not need to call the interface of the automation rule management module, realizing the decoupling between the business module and the automation rule management module.

[0125] Step S702: Obtain the device information of each of the M devices through the business module, where each of the M devices is a device that meets one or more trigger conditions.

[0126] Specifically, after the business module obtains the factor instance information of the target automation rule from the event factor instance information table in the public module, the business module can construct a query condition based on the factor instance information to query and obtain the device information of the M devices that meet the factor instance information (i.e., meet the one or more trigger conditions). It can be understood that if no device meeting the conditions is queried in this scheduled task, the subsequent steps are not executed, and wait for the next scheduled task to start.

[0127] Step S703: Execute the target action on the M devices through the business processing module.

[0128] Specifically, after the business module queries and obtains the M devices that meet the conditions, finally, the business processing module can execute the target action on the M devices. For example, it can be to send a reminder email for the upcoming expiration of the product to the email addresses bound to the M devices respectively, or it can be to send a reminder text message for the upcoming expiration of the product to the mobile phone numbers bound to the M devices respectively, and so on.

[0129] Please refer to Figure 8 , Figure 8is a flow chart of another automated rule processing method provided in an embodiment of the present application, which can be applied to the above Figure 2 The system architecture described in the above Figure 2 or Figure 3 The server 100a and Figure 4 In the automated rule processing system, the device can be Figure 2 Any one of the IoT devices 200a, 200b, 200c and 200d. Figure 8 The execution subject is the above Figure 4 The method may include the following steps S801-S812:

[0130] Step S801: The automation rule management module configures the target automation rule and generates factor instance information and action instance information of the target automation rule.

[0131] Specifically, the automation rule management module can perform life cycle management of automation rules, including configuration of automation rules (i.e., creation of automation rules), suspension and deletion, etc. The automation rule management module can configure target automation rules based on user needs, generate factor instance information and action instance information of the target automation rules (for example, the above-mentioned Figure 7 The target action in the corresponding embodiment, such as sending an email to a mailbox bound to a device, etc.), and archiving the factor instance information and the action instance information into a database, will not be described in detail here.

[0132] Optionally, the automation rule management module can configure multiple automation rules based on different needs of different users, and archive the factor instance information and action instance information of each of the generated multiple automation rules into the database of the automation rule management module. For example, the target automation rule can be a product expiration reminder, then the factor instance information of the target automation rule can include "product ID is 232341" and "5 days before product expiration", and the action instance information of the target automation rule (that is, the above Figure 7 The target action in the corresponding embodiment may be to send a reminder email about the upcoming expiration of a product to a specified mailbox, such as the mailbox bound to the device that meets the factor instance information (ie, the device has ordered a product with a product identifier of 232342, and the product will expire in 5 days).

[0133] Step S802: the automation rule management module transmits the factor instance information of the target automation rule to the event factor instance information table of the common module.

[0134] Specifically, an event registration framework can be pre-built in the common module. The event registration framework can include an event factor instance information table. After the automated rule management module configures the target automated rule, it can transmit the factor instance information of the generated target automated rule to the event factor instance information table in the common module. Optionally, the automated rule management module can transmit the factor instance information of each of the multiple generated automated rules to the event factor instance information table in the common module, and then the event factor instance information table can include the factor instance information of each of the multiple automated rules. The event factor instance information table is shown in Table 2, which mainly includes FACTOR_INSTACE (factor instance information, such as "OFFERID": "20190020" shown in Table 2). Among them, EVENT_TRIGGER_BUSI_CODE (event trigger business code) marks which automated rule event this factor instance information belongs to (for example, it can be BILLPLAN_EXPIRE shown in Table 2), and among them, RULE_INST_ID (rule instance identifier associated with the factor) is the unique identifier of the rule instance.

[0135] Table 2 Event Factor Instance Information Table

[0136]

[0137] Step S803, the business module registers the event specification definition of this module.

[0138] Specifically, the business module registers the event specification definition of the target automation rule in the event specification definition table of the common module and fills in the module identifier corresponding to this business module. The event specification definition table is shown in Table 3. For example, a new business module, Module P, wants to use the above-mentioned target automation rule for commodity expiration reminder. Then Module P needs to register in this event specification definition table and fill in the module identifier of Module P (such as the string 60105 shown in Table 3) in the column of SRC_MODULE_ID (event source module identifier), indicating that Module P needs to obtain the factor instance information of the target automation rule from the event factor instance information table for triggering this automation rule. Most of the other information in this table is the basic information of the target automation rule for commodity expiration reminder and does not require special modification. As shown in Table 3, DEST_MODULE_ID (event target module identifier) is the module identifier of the automation rule management module (such as the string 60502 shown in Table 3). Therefore, when any business module wants to use the automation rule in the event specification definition table, generally, it only needs to register the event specification definition of its own module in the event specification definition table and fill in the module identifier of its own module, without the need to deploy the automation rule management module again, truly achieving the purpose of complete decoupling between modules and providing great convenience for multi-module reuse of automation rules to a large extent.

[0139] Table 3 Event Specification Definition Table

[0140]

[0141]

[0142] Step S804, the business module obtains the factor instance information of the target automation rule from the event factor instance information table.

[0143] Specifically, the service module can directly obtain the factor instance information of the target automation rule from the event factor instance information table of the common module. Therefore, the service module does not need to call the interface of the automation rule management module to query the factor instance information of the target automation rule from the automation rule management module. Further, since there is no need to set the code for calling the interface of the automation rule management module in the service module, the automation rule management module can be not deployed when automation rule processing is not required. Thus, compared with the prior art where the code for calling the interface of the automation rule management module is fixed in the service module and the automation rule management module must be deployed together even when automation rule processing is not required (in the prior art, when it is checked during the final compilation that the code for calling the interface of the automation rule management module is fixed in the service module but the automation rule management module is not deployed, an error handling will be performed, resulting in the failure to complete the compilation smoothly), the embodiment of the present application realizes the independent deployment of modules.

[0144] Step S805: The service module obtains the device information of each of the M devices that conform to the factor instance information of the target automation rule.

[0145] Specifically, step S805 can refer to step S702 in the corresponding Figure 7 embodiment, which will not be elaborated here.

[0146] Step S806: The service module obtains the theme information of the target automation rule from the event specification definition table.

[0147] Specifically, the service module obtains the theme information of the target automation rule from the event specification definition table of the common module. Optionally, the service module can query the theme information of the target automation rule of the service module through its own source module identifier and event trigger service code (for example, EVENT_NAME shown in Table 3, which is the full name of the automation rule event). Thus, compared with the prior art where the theme information of the target automation rule is fixed in the code of the service module and the service module can only obtain the theme information of the target automation rule from its own code, the embodiment of the present application can directly obtain the theme information of the target automation rule from the event specification definition table, with a flexible acquisition method and significantly reduced code complexity of the service module itself. At the same time, when the theme information needs to be modified or extended, it can be directly modified in the event specification definition table without modifying the underlying code of each service module, thus realizing one-key modification of the theme information and enhancing the maintainability of the theme information.

[0148] Step S807: The service module sends a first theme message (including device information and factor instance information).

[0149] Specifically, the business module generates a corresponding first topic message based on the topic information of the target automation rule, the factor instance information, and the device information of each of the M devices that meet the factor instance information queried, and sends the first topic message to the message queue processing module for consumption by the automation rule management module.

[0150] Step S808, the automation rule management module listens for the first topic message.

[0151] Specifically, the automation rule management module listens for the first topic message. After receiving the first topic message, it parses the message body to obtain the topic information of the corresponding target automation rule, the factor instance information, and the device information of each of the M devices that meet the factor instance information.

[0152] Step S809, the automation rule management module queries and obtains the action instance information of the target automation rule according to the first topic message.

[0153] Specifically, the automation rule management module queries and obtains the action instance information of the target automation rule generated when configuring the target automation rule in advance according to the topic information parsed from the message body of the first topic message. Optionally, other information of the target automation rule can also be queried according to the topic information, etc.

[0154] Step S810, the automation rule management module sends a second topic message (including device information and action instance information).

[0155] Specifically, the automation rule management module generates a corresponding second topic message based on the topic information, action instance information of the target automation rule, and the device information of each of the above M devices, and sends the second topic message to the message queue processing module.

[0156] Step S811, the business processing module listens for the second topic message.

[0157] Specifically, the business processing module listens for the second topic message. After receiving the second topic message, it parses the message body to obtain the topic information, action instance information of the corresponding target automation rule, and the device information of each of the M devices that meet the factor instance information of the target automation rule.

[0158] Step S812, the business processing module processes the corresponding actions on each of the M devices according to the action instance information of the target automation rule.

[0159] Specifically, the service module executes the action instances on the M devices respectively according to the action instance information obtained by parsing the message body of the first topic message and the device information of each of the M devices. For example, as described above, if the target automation rule can be a reminder for commodity expiration, the service processing module (such as the above-mentioned P module) can send a reminder email about the upcoming expiration of the commodity to the email boxes bound to each of the M devices.

[0160] Optionally, if the user wants to implement other automation rules, such as an automation rule for traffic throttling when the traffic usage reaches a threshold (the factor instance information of this automation rule can include, for example, "device status is valid" and "traffic usage reaches the 10G threshold", and the action instance information of this automation rule can be, for example, to throttle the traffic of the devices that meet this factor instance information), it can be configured only in the module responsible for traffic monitoring. For example, the K module is a service module for detecting device traffic, and its automation rule processing process is as follows: when it is queried that the traffic usage of one or more valid devices (such as devices that are not shut down) exceeds the 10G threshold, the K module executes rule reporting to inform the user that the traffic usage exceeds the threshold. The automation rule management module receives the rule instance sent by the K module, parses and executes it, and sends a traffic throttling notice to the service processing module. After receiving the traffic throttling notice, the service processing module triggers the execution of the traffic throttling related service process to limit the traffic speed of the one or more valid devices, etc., which will not be elaborated here.

[0161] In summary, as the registrant of the target automation rule, the service module does not need to call the interface of the automation rule management module to query the factor instance information of the target automation rule. The service module only needs to execute corresponding processing according to the event consumption information in the event registration framework and publish the topic message of this event according to the information it provides. The registrant (service module) and the consumer (automation rule management module) of the automation rule are unaware of each other, making them decoupled from each other. At the same time, by registering the topic information of the automation rule in the event specification definition table of the event registration framework, when sending the topic message, only query the event specification definition table according to the conditions to obtain the corresponding topic information. The topic information is uniformly managed by the common module, which is convenient for maintenance; the topic information can be changed at any time without modifying the underlying code of each module, enhancing the scalability.

[0162] Compared with the prior art, the main technical key points of this application lie in the event registration framework (including the event specification definition table and the event factor instance information table) and the ability to achieve decoupling between multiple modules and flexible configuration of topic information based on this framework. This application pre-constructs the event registration framework in the common module and registers the rule events into the event registration framework, thereby achieving decoupling between independent modules. The independent modules can be independently deployed, enhancing scalability; there are no redundant modules, reducing the startup time; and by obtaining the topic information of the automated rules from the event registration framework, the maintainability is also enhanced. Specifically as follows:

[0163] (1) In the prior art, the business module needs to query the factor instance information of the automated rules from the automated rule management module, resulting in dependencies between modules and a coupling relationship. In the technical solution of this application, through the event registration framework, the event specification definition is registered, and the factor instance information is synchronized to the event factor instance information table of the framework, eliminating the coupling between modules. Business modules such as the customer management module can be independently deployed without attaching the automated rule management module; in addition, when other modules want to use the automated rule capabilities, they only need to obtain the instance factor information from the framework and do not depend on the automated rule management module when not using the automated rule capabilities. The independent scalability of each module is enhanced. There are no redundant modules in the environment, reducing the startup time of the entire system. Moreover, the event registration framework can be reused by multiple other modules, thus achieving the dual capabilities of zero coupling and multiple reuse.

[0164] (2) In the prior art, the topic information of the automated rules is fixed in the code of each module. In the technical solution of this application, each module registers the topic information of the automated rules into the event registration framework, which stores the event specification definitions of each module. When the rule is triggered, in the prior art, the fixed topic information is directly obtained from the code and the topic message is sent, while in this application, the topic information of the automated rule is obtained from the event specification definition table of the event registration framework. Therefore, in later maintenance, only the event registration framework needs to be maintained. When there are modifications or extensions to the automated rule events, such as when the topic information needs to be modified or extended, it can be modified with one key without changing the underlying code of each module, enhancing the maintainability and scalability.

[0165] It should be noted that the purpose of this application is to achieve decoupling between modules by synchronizing useful information into the common module. Therefore, the technical solution of this application can be used in scenarios that require solving multi-module coupling in other fields besides automated rule processing. Some data information of the business can be synchronized to the common components of the module to achieve the purpose of decoupling; in addition, in other fields where message queues are used, all topic information can also be stored in the common module for easy maintenance.

[0166] Please refer to Figure 9 , Figure 9 which is a schematic structural diagram of an automated rule processing system provided by an embodiment of the present application. The automated rule processing device can be applied to a server. The automated rule processing system may include a service processing module 901, a service module 902, and a common module 904. The common module 904 includes a pre-built event registration framework, and the event registration framework includes an event factor instance information table. The detailed descriptions of each module are as follows.

[0167] The service module 902 is configured to obtain factor instance information of a target automated rule from the event factor instance information table in the common module 904; the factor instance information of the target automated rule includes one or more trigger conditions for triggering a target action;

[0168] The service module 902 is further configured to obtain device information of each of the M devices, where each of the M devices is a device that meets the one or more trigger conditions, and M is an integer greater than or equal to 1;

[0169] The service processing module 901 is configured to perform the target action on the M devices.

[0170] In a possible implementation, the automated rule processing system further includes an automated rule management module 903:

[0171] When the automated rule processing system performs automated rule processing, the automated rule management module 903 is configured to configure the target automated rule, generate the factor instance information of the target automated rule and the target action, and transmit the factor instance information of the target automated rule to the event factor instance information table in the common module 904.

[0172] In a possible implementation, the automated rule processing system further includes a message queue processing module 905, and the event registration framework further includes an event specification definition table; the service module 902 is further configured to:

[0173] Obtain the topic information of the target automated rule from the event specification definition table, and generate a corresponding first topic message based on the topic information, the factor instance information of the target automated rule, and the device information of each of the M devices;

[0174] Send the first topic message to the message queue processing module 905.

[0175] In a possible implementation, the automated rule management module 903 is further configured to:

[0176] Listen to the first topic message, and query the target action according to the first topic message;

[0177] Generate a corresponding second topic message based on the topic information, the target action, and the device information of each of the M devices, and send the second topic message to the message queue processing module 905.

[0178] In a possible implementation manner, the service processing module 901 is specifically configured to listen to the second topic message, and perform the target action on each of the M devices according to the second topic message.

[0179] In a possible implementation manner, the service module 901 is further configured to register an event specification definition of the target automation rule in the event specification definition table, and fill in the module identifier corresponding to the service module.

[0180] It should be noted that for the functions of the functional units in the automation rule processing device described in the embodiments of the present application, reference can be made to the relevant descriptions of steps S701 - S703 in the method embodiment described above, and reference can also be made to the relevant descriptions of steps S801 - S812 in the method embodiment described above. Details are not described herein again. Figure 7 In the above, and reference can also be made to the relevant descriptions of steps S801 - S812 in the method embodiment described above. Details are not described herein again. Figure 8 The relevant descriptions of steps S801 - S812 in the method embodiment described above are not repeated here.

[0181] Figure 9 Each module in the above can be implemented by software, hardware, or a combination thereof. The unit implemented by hardware can include a logic circuit, an algorithm circuit, or an analog circuit, etc. The unit implemented by software can include program instructions, which are regarded as a software product, stored in a memory, and can be run by a processor to implement related functions. For details, refer to the previous introduction.

[0182] Based on the descriptions of the above method embodiments and device embodiments, the embodiments of the present application further provide a server. Please refer to Figure 10 , Figure 10 FIG. is a schematic structural diagram of a server provided by an embodiment of the present application. The server 100 includes at least a processor 1001, an input device 1002, an output device 1003, and a computer-readable storage medium 1004. The server 100 may further include other general components, which are not described in detail here. Among them, the processor 1001, the input device 1002, the output device 1003, and the computer-readable storage medium 1004 in the server 100 can be connected by a bus or other means.

[0183] The processor 1001 may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of the above solution program. The processor 1001 may include one or more processors, and the processor 1001 and other components within the server 100 may constitute an automated rule processing system provided by the embodiments of the present application.

[0184] The memory 1006 within the server 100 may be a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM) or other types of dynamic storage devices that can store information and instructions, or may also be an Electrically Erasable Programmable Read-Only Memory (EEPROM), a Compact Disc Read-Only Memory (CD-ROM), or other optical disc storage, optical disc storage (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), magnetic disk storage media, or other magnetic storage devices, or any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 1006 may exist independently and be connected to the processor 1001 through a bus. The memory 1006 may also be integrated with the processor 1001.

[0185] The computer-readable storage medium 1004 can be stored in the memory 1006 of the server 100. The computer-readable storage medium 1004 is used to store a computer program, and the computer program includes program instructions. The processor 1001 is used to execute the program instructions stored in the computer-readable storage medium 1004. The processor 1001 (or CPU (Central Processing Unit)) is the computing core and control core of the server 100, and is adapted to implement one or more instructions. Specifically, it is adapted to load and execute one or more instructions to implement the corresponding method flow or corresponding function. In one embodiment, the processor 1001 described in the embodiments of the present application can be used to perform a series of processes for automated rule processing, including: obtaining factor instance information of a target automated rule from an event factor instance information table in a common module through a service module; the factor instance information of the target automated rule includes one or more trigger conditions for triggering a target action; obtaining device information of each of the M devices through the service module, where each of the M devices is a device that meets the one or more trigger conditions, and M is an integer greater than or equal to 1; performing the target action on the M devices through the service processing module, and so on.

[0186] It should be noted that for the functions of each functional unit in the server 100 described in the embodiments of the present application, reference can be made to the relevant descriptions of steps S701 - S703 in the method embodiment described above Figure 7 and, reference can also be made to the relevant descriptions of steps S801 - S812 in the method embodiment described above Figure 8 and details are not described herein again.

[0187] In the above embodiments, the descriptions of each embodiment have their own emphases. For parts not detailed in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0188] An embodiment of the present application also provides a computer-readable storage medium (Memory). The computer-readable storage medium is a memory device in a server and is used to store programs and data. It can be understood that the computer-readable storage medium here can include both the built-in storage medium in the server and, of course, the extended storage medium supported by the server. The computer-readable storage medium provides a storage space, and this storage space stores the operating system of the server. Moreover, one or more instructions suitable for being loaded and executed by a processor are stored in this storage space, and these instructions can be one or more computer programs (including program codes). It should be noted that the computer-readable storage medium here can be a high-speed RAM memory or a non-volatile memory, such as at least one disk memory; optionally, it can also be at least one computer-readable storage medium located far from the aforementioned processor.

[0189] An embodiment of the present application also provides a computer program. This computer program includes instructions that, when executed by a computer, enable the computer to execute some or all of the steps of any one of the automated rule processing methods.

[0190] In the above embodiments, the descriptions of the respective embodiments have their own focuses. For the parts not detailed in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0191] It should be noted that for the foregoing method embodiments, for the sake of simple description, they are all expressed as a series of action combinations. However, those skilled in the art should know that the present application is not limited by the described action sequence, because according to the present application, certain steps may be performed in other sequences or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the present application.

[0192] In several embodiments provided by the present application, it should be understood that the disclosed device can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the above division of units is only a logical function division. In actual implementation, there can be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed coupling or direct coupling or communication connection to each other can be through some interfaces. The indirect coupling or communication connection of the device or unit can be in an electrical or other form.

[0193] The units described above as separate components may or may not be physically separated. The components shown as units may or may not be physical units, that is, they may be located in one place or distributed over multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0194] In addition, each functional unit in the embodiments of the present application can be integrated into a processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units.

[0195] If the above-mentioned integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc., specifically, the processor in the computer device) to execute all or part of the steps of the above-mentioned methods in the various embodiments of the present application. Among them, the aforementioned storage medium may include: USB flash drives, mobile hard disks, magnetic disks, optical disks, read-only memory (ROM), or random access memory (RAM), etc., various media that can store program codes.

[0196] As described above, the above embodiments are only used to illustrate the technical solutions of the present application, rather than 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 recorded 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 various embodiments of the present application.

Claims

1. An automated rule processing method, characterized in that An automated rule processing system applied to the Internet of Things. The automated rule processing system includes a service module, a service processing module, and a common module. The common module includes a pre-constructed event registration framework, and the event registration framework includes an event factor instance information table. The method includes: Obtaining, by the service module, factor instance information of a target automated rule from the event factor instance information table in the common module. The factor instance information of the target automated rule includes one or more trigger conditions for triggering a target action. Obtaining, by the service module, device information of each of M devices, where each of the M devices is an Internet of Things device that meets the one or more trigger conditions, and M is an integer greater than or equal to 1. Performing, by the service processing module, the target action on the M devices. The automated rule processing system further includes an automated rule management module. The method further includes: When the automated rule processing system performs automated rule processing, configuring, by the automated rule management module, the target automated rule, generating the factor instance information of the target automated rule and the target action, and transmitting the factor instance information of the target automated rule to the event factor instance information table in the common module. The automated rule processing system further includes a message queue processing module, and the event registration framework further includes an event specification definition table. The method further includes: Obtaining, by the service module, the topic information of the target automated rule from the event specification definition table, and generating a corresponding first topic message based on the topic information, the factor instance information of the target automated rule, and the device information of each of the M devices. Sending, by the service module, the first topic message to the message queue processing module. The method further includes: Listening, by the automated rule management module, to the first topic message, and querying the target action according to the first topic message. Generating, by the automated rule management module, a corresponding second topic message based on the topic information, the target action, and the device information of each of the M devices, and sending the second topic message to the message queue processing module.

2. The method according to claim 1, wherein The performing, by the service processing module, the target action on the M devices includes: Listening, by the service processing module, to the second topic message, and performing the target action on each of the M devices according to the second topic message.

3. The method according to any one of claims 1-2, characterized in that, The method further includes: Registering, by the service module, the event specification definition of the target automated rule in the event specification definition table, and filling in the module identifier corresponding to the service module.

4. An automated rule processing system applied to the Internet of Things, characterized in that, Including a service module, a service processing module, and a common module. The common module includes a pre-constructed event registration framework, and the event registration framework includes an event factor instance information table. The business module is used to obtain factor instance information of a target automation rule from the event factor instance information table in the public module; the factor instance information of the target automation rule includes one or more trigger conditions for triggering a target action. The business module is further used to obtain device information of each of the M devices, where each of the M devices is an Internet of Things device that meets the one or more trigger conditions, and M is an integer greater than or equal to 1. The service processing module is used to perform the target action on the M devices. The automation rule processing system further includes an automation rule management module. When the automation rule processing system performs automation rule processing, the automation rule management module is used to configure the target automation rule, generate the factor instance information of the target automation rule and the target action, and transmit the factor instance information of the target automation rule to the event factor instance information table in the public module. The automation rule processing system further includes a message queue processing module, and the event registration framework further includes an event specification definition table. The business module is further used to obtain the topic information of the target automation rule from the event specification definition table, and generate a corresponding first topic message based on the topic information, the factor instance information of the target automation rule, and the device information of each of the M devices. The business module is further used to send the first topic message to the message queue processing module. The automation rule management module is further used to listen for the first topic message and query the target action according to the first topic message. The automation rule management module is further used to generate a corresponding second topic message based on the topic information, the target action, and the device information of each of the M devices, and send the second topic message to the message queue processing module.

5. The system according to claim 4, characterized in that, The service processing module is specifically used to listen for the second topic message and perform the target action on the M devices respectively according to the second topic message.

6. The system according to any one of claims 4-5, characterized in that, The business module is further used to register the event specification definition of the target automation rule in the event specification definition table and fill in the module identifier corresponding to the business module.

7. A server, characterized in that, It includes a processor and a memory, the processor is connected to the memory, wherein the memory is used to store program code, and the processor is used to call the program code to execute the method according to any one of claims 1 to 3.

8. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 3 is implemented.

9. A computer program product, characterized in that, The computer program product includes instructions, and when the computer program product is executed by a computer, the computer is caused to execute the method according to any one of claims 1 to 3.

Images