CN113743879A - 一种自动化规则处理方法、系统以及相关设备 - Google Patents

Abstract

本申请实施例公开了一种自动化规则处理方法、系统以及相关设备，具体可以应用于物联网等领域。其中，一种自动化规则处理系统包括业务模块、业务处理模块和公共模块，公共模块包括预先构建的事件注册框架，事件注册框架包括事件因子实例信息表；该方法包括：通过业务模块从公共模块中的事件因子实例信息表中获取目标自动化规则的因子实例信息；目标自动化规则的因子实例信息包括用于触发目标动作的一个或多个触发条件；通过业务模块获取M个设备各自的设备信息，M个设备中的每一个设备为符合所述一个或多个触发条件的设备；通过业务处理模块对所述M个设备执行所述目标动作。可以减少模块之间的耦合，降低代码复杂度，提高模块的独立部署能力。

Description

一种自动化规则处理方法、系统以及相关设备

技术领域

本申请涉及物联网技术领域，尤其涉及一种自动化规则处理方法、系统以及相关设备。

背景技术

物联网业务支撑系统(Internet of Things-Business Support System，IOT-BSS)所面向的业务场景，不同于传统面向“人联网”的业务场景，在传统面向“人联网”的业务场景下，用户作为独立的个体，具备自我管理的诉求，可以自己驱动联系进行服务。但是，在IOT-BSS所面向的业务场景中，大量“物”的互联，要求对“物”的管理能够实现自动化、智能化，其中涉及的自动化规则管理模块便显得尤为重要。自动化规则管理模块属于客户关系管理(Customer Relationship Management，CRM)系统，CRM会和其他系统进行集成，完成自动化规则的处理，涉及到的交互方会有订单管理(Order Management，OM)模块、客户管理(Customer Management，CM)模块、交互管理模块以及计费外部件等各个部件。当交互部件通过事件机制上报规则给自动化规则执行模块，自动化规则执行模块接收到相应消息后，处理对应规则，并执行后续动作。

商业使能系统(Business Enabling System，BES)物联网场景下，需要对大量设备进行统一的自动化管理，这就需要配置大量的规则进行自动管理。基于当前BES的已有实现，规则的上报和接收可以通过平台提供的Business Event事件机制实现，但自动化规则管理模块与其他模块之间会存在交互性较强，耦合程度较高，独立性较差的问题。

由于各模块需要保持一定的独立性，因此，如何保证在使用自动化规则能力时各模块之间耦合性为零，是亟待解决的问题。

发明内容

本申请实施例提供一种自动化规则处理方法、系统以及相关设备，可以有效消除模块之间的耦合，降低代码复杂度，提高模块的独立部署能力。

第一方面，本申请实施例提供了一种自动化规则处理方法，应用于自动化规则处理系统，所述自动化规则处理系统包括业务模块、业务处理模块和公共模块，所述公共模块包括预先构建的事件注册框架，所述事件注册框架包括事件因子实例信息表；所述方法包括：通过所述业务模块从所述公共模块中的所述事件因子实例信息表中获取目标自动化规则的因子实例信息；所述目标自动化规则的因子实例信息包括用于触发目标动作的一个或多个触发条件；通过所述业务模块获取M个设备各自的设备信息，所述M个设备中的每一个设备为符合所述一个或多个触发条件的设备，M为大于或者等于1的整数；通过所述业务处理模块对所述M个设备执行所述目标动作。

通过第一方面提供的方法，可以预先在公共模块中构建自动化规则的事件注册框架，该事件注册框架中可以包括事件因子实例信息表，该事件因子实例信息表中可以包括多个自动化规则各自的因子实例信息。在进行自动化规则处理时，可以通过业务模块从该事件因子实例信息表中获取本次目标自动化规则的因子实例信息(例如可以包括用于触发该目标自动化规则对应的目标动作的一个或多个触发条件)，然后通过该业务模块查询到符合条件的设备，再通过业务处理模块对该设备执行该目标自动化规则对应的目标动作(例如为发送邮件，发送短信或者暂停该设备的流量服务等等)，至此，便完成了一次自动化规则的触发以及动作执行，也即消费了一条自动化规则。由此，对比现有技术中，业务模块只能通过调用自动化规则管理模块接口，进而从自动化规则管理模块中查询得到目标自动化规则的因子实例信息，导致业务模块与自动化规则管理模块之间存在强耦合，大大降低了模块独立性的方案而言。本申请实施例在获取因子实例信息时，业务模块无需调用自动化规则管理模块的接口，实现了业务模块与自动化规则管理模块之间的解耦。

在一种可能的实现方式中，所述自动化规则处理系统还包括自动化规则管理模块；所述方法还包括：当所述自动化规则处理系统进行自动化规则处理时，通过所述自动化规则管理模块配置所述目标自动化规则，生成所述目标自动化规则的因子实例信息以及所述目标动作，并传输所述目标自动化规则的因子实例信息至所述公共模块中的所述事件因子实例信息表。

在本申请实施例中，当该自动化规则处理系统需要进行自动化规则处理时，可以首先通过自动化规则管理模块配置该目标自动化规则(例如当用户有利用自动化规则管理设备的需求时，可以根据自己的实际需求通过自动化规则管理模块配置一个或多个自动化规则，该目标自动化规则可以为其中的一个)，生成该目标自动化规则的因子实例信息以及该目标自动化规则所要执行的目标动作。然后，该自动化规则管理模块还可以将生成的因子实例信息传输至公共模块预先构建的事件因子实例信息表中，供业务模块或者其他模块查询使用。由此，当业务模块需要获取目标自动化规则的因子实例信息时，可以直接从公共模块的事件因子实例信息表中获取，实现了业务模块与自动化规则管理模块之间的解耦。

在一种可能的实现方式中，所述业务模块未设置调用所述自动化规则管理模块接口的相应代码，所述方法还包括：若所述自动化规则处理系统不进行自动化规则处理，则不执行所述通过所述自动化规则管理模块配置所述目标自动化规则，生成所述目标自动化规则的因子实例信息以及所述目标动作，并传输所述目标自动化规则的因子实例信息至所述公共模块中的所述事件因子实例信息表的步骤。

在本申请实施例中，由于业务模块可以直接从事件因子实例信息表中获取目标自动化规则的因子实例信息，因此业务模块中无需设置调用自动化规则管理模块接口的相应代码，大大降低了代码复杂度，减少了工作量和系统负担。当该自动化规则处理系统不需要进行自动化规则处理时，该自动化规则管理模块也无需进行自动化规则配置，并将生成的因子实例信息传输至事件因子实例信息表中。进一步的，在该自动化规则处理系统不需要进行自动化规则处理时，则可以不部署自动化规则管理模块。由此，对比现有技术中由于业务模块中固定了调用自动化规则管理模块接口的代码，而在不需要进行自动化规则处理时也必须要连带部署自动化规则管理模块(现有技术中，当最终编译过程中检查到在业务模块中固定了调用自动化规则管理模块接口的代码，却又没有部署自动化规则管理模块时，会进行报错处理，从而无法顺利完成编译)而言，本申请实施例实现了业务模块的独立部署，避免了部署多余模块给系统工作所增加的负担，降低了系统的启动时间。

在一种可能的实现方式中，所述自动化规则处理系统还包括消息队列处理模块，所述事件注册框架还包括事件规格定义表；所述方法还包括：通过所述业务模块从所述事件规格定义表中获取所述目标自动化规则的主题信息，并基于所述主题信息、所述目标自动化规则的因子实例信息以及所述M个设备各自的设备信息生成对应的第一主题消息；通过所述业务模块发送所述第一主题消息至所述消息队列处理模块。

在本申请实施例中，业务模块可以从预先构建的事件规格定义表(例如可以包括多个自动化规则各自的主题信息)中获取目标自动化规则的主题信息，然后基于该主题信息、因子实例信息以及M个设备各自的设备信息生成对应的第一主题消息，并发送该第一主题信息至消息队列处理模块。由此，对比现有技术中，将目标自动化规则的主题信息固定在业务模块的代码中，业务模块只能从自身的代码中获取目标自动化规则的主题信息的方案而言，本申请实施例明显降低了业务模块自身的代码复杂度。并且，当主题信息需要进行修改或者扩展时，可以直接在事件规格定义表中进行修改，不用改动每个业务模块的底层代码，从而实现了主题信息的一键修改，增强了主题信息的可维护性和扩展性。

在一种可能的实现方式中，所述方法还包括：通过所述自动化规则管理模块侦听所述第一主题消息，并根据所述第一主题消息查询得到所述目标动作；通过所述自动化规则管理模块，基于所述主题信息、所述目标动作以及所述M个设备各自的设备信息生成对应的第二主题消息，并发送所述第二主题消息至所述消息队列处理模块。

在本申请实施例中，可以通过自动化规则管理模块侦听该第一主题消息，并根据该第一主题消息查询得到事先配置该目标自动化规则时生成的该目标自动化规则的目标动作，然后基于该主题信息、目标动作以及M个设备各自的设备信息生成对应的第二主题消息，并发送第二主题消息至消息队列处理模块，以用于后续对该M个设备执行该目标动作。

在一种可能的实现方式中，所述通过所述业务处理模块对所述M个设备执行所述目标动作，包括：通过所述业务处理模块侦听所述第二主题消息，并根据所述第二主题消息分别对所述M个设备执行所述目标动作。

在本申请实施例中，业务模块可以通过侦听该第二主题消息，得到该主第二题消息所包含的设备信息和目标动作，从而可以通过业务处理模块对符合该目标自动化规则的因子实例信息的该M个设备执行该目标自动化规则对应的目标动作(例如向订购了某一商品，且该商品即将到期的设备发送一条提醒短信或者一封提醒邮件，等等)。实现在自动化规则处理中，各个功能模块的合理部署，提高自动化规则的动作执行效率。

在一种可能的实现方式中，所述方法还包括：通过所述业务模块在所述事件规格定义表中注册所述目标自动化规则的事件规格定义，填写所述业务模块对应的模块标识。

在本申请实施例中，可以通过业务模块在事件规格定义表中注册该目标自动化规则的事件规格定义，并填写该业务模块对应的模块标识，即可进行该目标自动化规则的处理，例如包括从事件因子实例信息表中获取该目标自动化规则的因子实例信息，并查询符合条件的设备，以及从事件规格定义中获取该目标自动化规则的主题信息等等。如此，每当其他模块或者一个新的业务模块想要使用自动化规则能力时，都只需要在该事件规则定义表中进行本模块的注册即可，无需再重复部署自动化规则管理模块，实现了模块之间的解耦，各模块的独立扩展性增强，系统中不存在多余模块，启动时间降低。此外，业务模块中无需固定调用自动化规则管理模块接口的相关代码以及该目标自动化规则的主题信息，大大降低了代码复杂度。

第二方面，本申请实施例提供的一种自动化规则处理系统，包括业务模块、业务处理模块和公共模块，所述公共模块包括预先构建的事件注册框架，所述事件注册框架包括事件因子实例信息表；所述业务模块，用于从所述公共模块中的所述事件因子实例信息表中获取目标自动化规则的因子实例信息；所述目标自动化规则的因子实例信息包括用于触发目标动作的一个或多个触发条件；所述业务模块，还用于获取M个设备各自的设备信息，所述M个设备中的每一个设备为符合所述一个或多个触发条件的设备，M为大于或者等于1的整数；所述业务处理模块，用于对所述M个设备执行所述目标动作。

在一种可能的实现方式中，所述自动化规则处理系统还包括自动化规则管理模块；当所述自动化规则处理系统进行自动化规则处理时，所述自动化规则管理模块，用于配置所述目标自动化规则，生成所述目标自动化规则的因子实例信息以及所述目标动作，并传输所述目标自动化规则的因子实例信息至所述公共模块中的所述事件因子实例信息表。

在一种可能的实现方式中，所述业务模块未设置调用所述自动化规则管理模块接口的相应代码；若所述自动化规则处理系统不进行自动化规则处理，则所述自动化规则管理模块，不用于配置所述目标自动化规则，生成所述目标自动化规则的因子实例信息以及所述目标动作，并传输所述目标自动化规则的因子实例信息至所述公共模块中的所述事件因子实例信息表的步骤。

在一种可能的实现方式中，所述自动化规则处理系统还包括消息队列处理模块，所述事件注册框架还包括事件规格定义表；所述业务模块，还用于从所述事件规格定义表中获取所述目标自动化规则的主题信息，并基于所述主题信息、所述目标自动化规则的因子实例信息以及所述M个设备各自的设备信息生成对应的第一主题消息；所述业务模块，还用于发送所述第一主题消息至所述消息队列处理模块。

在一种可能的实现方式中，所述自动化规则管理模块，还用于侦听所述第一主题消息，并根据所述第一主题消息查询得到所述目标动作；所述自动化规则管理模块，还用于基于所述主题信息、所述目标动作以及所述M个设备各自的设备信息生成对应的第二主题消息，并发送所述第二主题消息至所述消息队列处理模块。

在一种可能的实现方式中，所述业务处理模块，具体用于侦听所述第二主题消息，并根据所述第二主题消息分别对所述M个设备执行所述目标动作。

在一种可能的实现方式中，所述业务模块，还用于在所述事件规格定义表中注册所述目标自动化规则的事件规格定义，填写所述业务模块对应的模块标识。

第三方面，本申请实施例提供的一种服务器，该服务器中可以包括上述第二方面中任意一项所述自动化规则处理系统。

第四方面，本申请实施例提供的一种服务器，该服务器可以包括处理器和存储器，处理器可以被配置为支持该服务器实现第一方面提供的自动化规则处理方法中相应的功能，存储器与处理器耦合，可以用于保存该服务器必要的程序指令和数据。该服务器还可以包括通信接口，用于该服务器与其他设备或通信网络通信。

第五方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，该计算机程序被处理器执行时实现上述第一方面中任意一项所述的自动化规则处理方法。

第六方面，本申请实施例提供了一种计算机程序，该计算机程序包括指令，当该计算机程序被计算机执行时，使得计算机可以执行上述第一方面中任意一项所述的自动化规则处理方法。

第七方面，本申请实施例提供了一种芯片系统，该芯片系统包括上述第二方面中任意一项所述的自动化规则处理系统，用于实现上述第一方面中任意一项所述的自动化规则处理方法所涉及的功能。在一种可能的设计中，所述芯片系统还包括存储器，所述存储器，用于保存自动化规则处理方法必要的程序指令和数据。该芯片系统，可以由芯片构成，也可以包含芯片和其他分立器件。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对本申请实施例或背景技术中所需要使用的附图进行说明。

图1是现有技术中的一种自动化规则处理方法的步骤示意图。

图2是本申请实施例提供的一种自动化规则处理方法的系统架构示意图。

图3是本申请实施例提供的一种服务器的结构示意图。

图4是本申请实施例提供的一种自动化规则处理系统的结构示意图。

图5是本申请实施例提供的一种自动化规则处理方法的应用场景示意图。

图6a-图6c是本申请实施例提供的一组界面示意图。

图7是本申请实施例提供的一种自动化规则处理方法的流程示意图。

图8是本申请实施例提供的另一种自动化规则处理方法的流程示意图。

图9是本申请实施例提供的一种自动化规则处理系统的结构示意图。

图10是本申请实施例提供的一种服务器的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例进行描述。

本申请的说明书和权利要求书及所述附图中的术语“第一”、“第二”、“第三”和“第四”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

在本说明书中使用的术语“部件”、“模块”、“系统”等用于表示计算机相关的实体、硬件、固件、硬件和软件的组合、软件、或执行中的软件。例如，部件可以是但不限于，在处理器上运行的进程、处理器、对象、可执行文件、执行线程、程序和/或计算机。通过图示，在终端设备上运行的应用和终端设备都可以是部件。一个或多个部件可驻留在进程和/或执行线程中，部件可位于一个计算机上和/或分布在2个或更多个计算机之间。此外，这些部件可从在上面存储有各种数据结构的各种计算机可读介质执行。部件可例如根据具有一个或多个数据分组(例如来自与本地系统、分布式系统和/或网络间的另一部件交互的二个部件的数据，例如通过信号与其它系统交互的互联网)的信号通过本地和/或远程进程来通信。

首先，对本申请中的部分用语进行解释说明，以便于本领域技术人员理解。

1、自动化规则，帮助客户管理物联网中的多个设备，自动化规则主要的应用场景：

(1)用户识别模块(Subscriber Identity Module，SIM)资费计划或状态变化：可测试、已激活、已停用和失效等状态变化；

(2)安全事件：国际移动设备标识(International Mobile Equipment Identity，IMEI)变更；

(3)订购管理：达到或接近订购期限；

(4)用量监控：用量阈值、连接行为等，一般指流量使用的阈值(例如为50M、10G或者20G等)以及移动网络连接情况(例如为是否连接移动网络，又例如3G、4G或者5G的连接情况，以及移动网络的连接是否稳定等情况)。

其中，自动化规则管理(Automation Rule Management，ARM)模块，主要用于管理自动化规则的触发、上报、接收、执行以及后续动作的处理(比如自动化规则执行完后的发短信、发邮件等)。其中，自动化规则管理模块主要完成：

(1)自动化规则的生命周期管理，包括自动化规则的新建、暂停和删除等；

(2)接收自动化规则的触发事件消息，并且根据自动化规则的定义执行触发后的操作；

(3)自动化规则的下发，不同的规则，具有相应的规则执行系统或模块，因此在创建规则后，需要将规则信息同步下发到对应的执行系统或模块；

(4)记录规则的日志信息，包括被触发的规则信息(日志信息主要记录“规则何时被谁触发”)。

2、消息队列(Message Queue)，是分布式系统中重要的组件，是在消息的传输过程中保存消息的容器。通过使用消息队列，可以异步处理请求，从而缓解系统的压力。其中，队列(Queue)消息和主题(Topic)消息为两种常见的消息传递模型。本申请实施例中采取向消息队列处理模块发送主题消息，其他模块侦听主题消息，获取相应信息的方式。

物联网系统中可以针对每个设备，根据不同的应用场合，创建不同的自动化规则实例。其中，物联网系统中的设备例如可以为智能手机、平板电脑、笔记本电脑、台式电脑等终端设备，也可以为机器人或者其他可能的人工智能的物联网设备，等等。一般情况下，一个物联网设备往往可以对应绑定一张卡，例如一个智能手机可以绑定一张SIM卡。在一些可能的实施方式中，还可以将一张SIM卡作为一个设备，例如支持双卡双待的智能手机在绑定两张SIM卡后也可以看做两个设备，等等，本申请实施例对此不作具体限定。自动化规则管理模块中包括三个重要的要素，分别为：(1)触发器(也即事件的具体描述)：是什么自动化规则事件；(2)筛选器(也即因子)：是什么触发了自动化规则的动作执行；(3)动作：自动化规则将执行什么样的动作。该三点构成了自动化规则的核心，当满足触发器条件时，通过过滤器筛选出符合条件的设备，执行相应的动作。例如，设备订购的商品(比如流量套餐等等)，客户可以设置一个自动化规则，当商品快要到期的时候，可以触发一个动作(比如发送短信或者发送邮件)，帮助客户管理设备。

如表1，是典型的自动化规则的设置实例。表1中的因子1、因子2和动作都可以由客户通过前台页面进行配置，并由自动化规则管理模块分别归档在数据库的因子实例和动作实例中。通常情况下，前台只给出具体规则的配置框架，如商品到期、流量达到阈值的配置模板，客户只需通过模板进行因子实例和动作实例的相关配置即可。满足条件的自动化规则就会被触发。

表1

触发器	因子1	因子2	动作
				商品到期	OfferingId＝232342	beforeExpire＝5	sendEmail
流量达到设定阈值	设备状态＝2	Threshold：10M	暂停设备

如表1所示，下面对商品到期以及流量到达阈值的自动化规则的触发和动作执行进行描述，具体如下：

(1)订购了商品标识(OfferingId)为232342的设备，在其商品到期前(beforeExpire)5天发送一封邮件(sendEmail)到指定的邮箱(例如可以为该设备绑定的邮箱，或者也可以是客户事先设置的邮箱)；

(2)设备状态为2的设备，例如为已激活的有效设备，当该设备所使用的流量达到10M阈值(Threshold)时，可以对该设备进行暂停操作，例如停止该设备的流量服务，禁止该设备再使用流量，等等。

为了便于理解本申请实施例，进一步分析并提出本申请所具体要解决的技术问题。在现有技术中，关于自动化规则的触发以及执行技术，包括多种技术方案，以下示例性的列举如下常用的一种方案。

方案一：通过调用自动化规则管理模块接口，查询目标自动化规则的因子实例信息，并根据该因子实例信息查询符合条件的设备，从而对该设备执行该目标自动化规则对应的动作。

请参阅图1，图1是现有技术中的一种自动化规则处理方法的步骤示意图。如图1所示，其中的业务模块为业务触发方，也即负责自动化规则的触发，其过程一般可以通过创建定时任务，该定时任务执行时，业务模块可以通过调用自动化规则管理模块的接口，从而向自动化规则管理模块查询得到本定时次任务对应的目标自动化规则的因子实例信息。然后，查询得到满足条件的设备信息(也即符合该因子实例信息的设备信息，比如一个或多个SIM卡的标识代码或者智能手机的IMEI，等等)，再将因子实例信息与设备信息通过主题消息发送给消息队列。自动化规则管理模块可以通过侦听该主题消息，得到上述因子实例信息与设备信息，以执行后续动作。可选地，该业务模块具体可以为客户管理模块、订单管理模块或者其他可触发自动化规则的模块，等等。

如图1所示，该方法可以包括以下步骤S101-步骤S109：

步骤S101，自动化规则管理模块配置目标自动化规则，生成目标自动化规则的因子实例信息和动作实例信息，并将该因子实例信息和动作实例信息进行归档。例如可以分别归档在数据库的因子实例和动作实例中。可选地，该因子实例信息例如可以包括如表1所示的“OfferingId＝232342”和“beforeExpire＝5”，该动作实例信息例如可以为表1所示的“sendEmail”。其中，实例化是将抽象的概念类(例如“因子”和“动作”)，具体到该类实物的过程(例如为“OfferingId＝232342”等因子实例和“sendEmail”等动作实例)。可选地，客户可以通过前台提供的配置界面(比如可以用于创建、编辑和删除自动化规则的相关应用软件或者网站等等所显示的配置界面)进行目标自动化规则的配置，按照自己的需求填写相应的因子实例以及动作实例。可选地，用户可以根据自己的实际需求通过该自动化规则管理模块配置多个自动化规则，分别生成各自的因子实例信息和动作实例信息，等等，此处不再进行赘述。

步骤S102，业务模块调用自动化规则管理模块接口，查询得到目标自动化规则的因子实例信息。可选地，业务模块可以根据预先设置的定时任务，每日定时触发目标自动化规则的扫描检测，也即开始调用自动化规则管理模块接口，查询得到目标自动化规则的因子实例信息的步骤。可选地，还可以通过设置多个定时任务，每日同时或者不同时进行不同自动化规则的扫描检测，分别查询得到多个不同自动化规则的因子实例信息，等等，本申请实施例对此不作具体限定。

步骤S103，业务模块根据目标自动化规则的因子实例信息构造查询条件，查询得到符合因子实例信息的设备信息。

步骤S104，业务模块发送topic消息(该topic消息包含设备信息和因子实例信息)至消息队列处理模块。

步骤S105，自动化规则管理模块侦听topic消息。

步骤S106，自动化规则管理模块根据topic消息，解析消息体，得到设备信息、因子实例信息以及该目标自动化规则对应的topic。自动化规则管理模块根据该topic查询得到该目标自动化规则的动作实例信息，可选地，还可以根据该topic查询得到该目标自动化规则的因子实例信息和其他信息，等等。

步骤S107，自动化规则管理模块发送topic消息(该topic消息包含设备信息和动作实例信息)至消息队列处理模块。

步骤S108，业务处理模块侦听topic消息。

步骤S109，业务处理模块根据topic消息，解析消息体，得到设备信息和动作实例信息。业务处理模块根据该动作实例信息，对设备信息中对应的设备进行相应动作的处理。例如向该设备对应的手机号发送提醒短信，或者向指定的邮箱发送提醒邮件，等等。

综上所述，上述现有技术中的方案一存在两个缺点，具体如下：

(1)由业务模块触发规则上报执行时，业务模块需要调用自动化规则管理模块接口，以向自动化规则管理模块查询自动化规则的因子实例信息，此时模块与模块间存在耦合关系，业务模块需要依赖于自动化规则管理模块。从定位来说，自动化规则管理模块与业务模块是同层级的模块，不应存在依赖关系。并且，调用接口再进行因子实例信息查询的过程明显会大大影响获取因子实例信息的效率，进而影响自动化规则处理的整体效率。与此同时，BES的多业务场景存在多个不同的环境(例如移动、电信和联通等不同的运营商环境)，在使用了自动化规则能力后，在每一个环境都得同时部署自动化规则管理模块，但若没有用到自动化规则能力时，其实是无须部署自动化规则管理模块的。但是，现有技术中，由于业务模块中已固定了调用自动化规则管理模块接口的相应代码，而在不需要进行自动化规则处理时也必须要连带部署自动化规则管理模块(现有技术中，当最终编译过程中检查到在业务模块中固定了调用自动化规则管理模块接口的代码，却又没有部署自动化规则管理模块时，会进行报错处理，从而无法顺利完成编译)，此时，业务模块独立部署能力缺失，代码复杂度变高，并且无用的模块部署还会导致环境启动时间增加。对于其他想使用自动化规则能力的同层级模块来说，也存在同样问题，复用性低。

(2)自动化规则触发时(也即查询得到符合因子实例信息的设备信息时)，业务模块需要向消息队列发送自动化规则消费事件(也即上述的topic消息)。对于不同的自动化规则，自动化规则管理模块需要定义不同的Topic，当Topic存在修改或扩展时，所有复用自动化规则能力的模块(例如客户管理模块和订单管理模块等业务模块)，其发送事件的文件Topic，也需要同步进行修改，可维护性差。

综上，上述方案一的业务模块必须通过调用自动化规则管理模块接口查询得到相应的因子实例信息，查询效率低，大大影响了自动化规则处理的整体效率，业务模块与自动化规则管理模块之间存在紧耦合。因此，为了解决当前自动化规则处理技术中不满足实际业务需求的问题，本申请实际要解决的技术问题包括如下方面：基于独立模块解耦的原则，客户管理模块等业务模块不能直接依赖引用平级的自动化规则管理模块的服务，因此对于业务上报需要的事件定义(也即topic)和因子实例信息不能直接从自动化规则管理获取。另外，自动化规则的topic会存在修改的可能，业务模块获取topic的时候需要灵活获取，不能在业务模块的代码中固定。故，此时需要解决业务模块与自动化规则管理模块之间的紧耦合性问题，以及自动化规则的topic不能一键修改和扩展的问题。

请参阅图2，图2是本申请实施例提供的一种自动化规则处理方法的系统架构示意图。如图2所示，该系统架构可以包括服务器100a和多个物联网设备，具体可以包括物联网设备200a、200b、200c和200d。服务器100a与物联网设备200a、200b、200c和200d之间可以通过无线网络的方式建立通信连接。其中，物联网设备200a、200b、200c和200d可以为同一用户的物联网设备，也可以为不同用户的物联网设备。其中，该服务器100a内可以配置有实现相应自动规则能力的自动化规则处理系统。其中，自动化规则处理中，自动化规则的触发上报、接收执行是以事件的方式，通过消息队列在规则生产触发端(客户管理模块、订单管理模块等各业务模块)和规则消费执行端(自动化规则管理模块、业务处理模块等)进行传递处理的。规则生产触发端主要完成当业务满足某一条件时，触发自动化规则事件，上报信息给自动化规则管理模块；规则消费执行端的自动化规则管理模块主要负责规则的定义及管理，包括规则的分类、动作编码、执行条件、执行动作、动作执行过滤条件、消息模板定义等等。在接收到规则事件后，解析事件消息内容，判断满足执行动作条件，执行自动化规则相应的动作。

可选地，请参阅图3，图3是本申请实施例提供的一种服务器的结构示意图。下面以服务器100a为例对实施例进行具体说明。应该理解的是，服务器100a可以具有比图3中所示的更多的或者更少的部件，可以组合两个或多个的部件，或者可以具有不同的部件配置。图3中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。如图3所示，服务器100a可以包括自动化规则处理系统30、无线通信系统31、电源管理模块32、电池33和计算机系统34。

请参阅图4，图4是本申请实施例提供的一种自动化规则处理系统的结构示意图。如图4所示，该自动化规则处理系统30可以包括位于同一层级的营业厅门户301、业务处理模块302，还可以包括位于另一层级的自动化规则管理模块303，以及客户管理模块304、订单管理模块305等业务模块，此外，还可以包括位于其他层级的消息队列处理模块306和公共模块307。可选地，在一些可能的实施例中，该自动化规则处理系统30可以包括比图4所示更多或者更少甚至不同的部件，例如在该自动化规则处理系统30不进行自动化规则处理时，可以不部署自动化规则管理模块303，该自动化规则处理系统30也可以进行其他的业务处理，比如基于用户的相应操作对设备进行停机或者退号码等等。又例如，当该自动化规则处理系统30不进行订单管理时，可以不部署订单管理模块305，等等，本申请实施例对此不作具体限定。如图4所示，该自动化规则处理系统30也可以是IOT-BSS下基于事件注册的多模块解耦框架。

其中，营业厅门户(Portal)301，提供了规则实例(包括自动化规则的因子实例和动作实例)管理的界面，营业厅门户301的主要功能包括：

(1)规则实例列表查询界面：默认页面加载时查询对应用户下创建的所有的自动化规则，并以列表的形式展示；

(2)规则实例编辑界面：该页面可以完成对该规则实例的修改、暂停和删除；

(3)规则实例创建界面：该页面提供了创建一条规则实例的功能。要创建一条规则实例，需要选择一个触发器(也即选择一种自动化规则，例如为商品到期提醒或者流量使用到达阈值提醒等等)并实例化相应的参数，选择一个筛选器(也即因子)并实例化相应的参数(例如为选择商品标识这一因子，并实例化其商品标识为具体的“232342”)，选择一个操作并实例化相应的参数(例如为选择发送邮件这一操作，并实例化其具体的邮箱地址为“71xx894@xx.com”)，等等；

(4)规则实例的删除：通过“删除”菜单可以将一个或多个规则实例删除；

(5)已触发规则实例查询界面：默认页面加载时查询对应用户下所有在一个规则周期内已触发的规则实例数据，结果以列表的形式展示。

其中，业务处理模块302，主要完成自动化规则的动作实例的具体执行(例如发送提醒邮件到指定的邮箱，等等)。

其中，自动化规则管理模块303，其主要功能包括：

(1)自动化规则的生命周期管理，包括规则的新建、暂停、删除；

(2)自动化规则的下发，不同的规则，具有相应的规则执行系统或模块，因此在创建规则后，需要将规则信息同步到对应的执行系统或模块。例如，在本申请实施例中，自动化规则管理模块303可以在自动化规则配置完成后，将生成的因子实例信息同步至公共模块预先构建的事件因子实例信息表中，以供业务模块从中直接获取相应的因子实例信息；

(3)接收自动化规则的触发事件消息，并且根据规则的定义执行触发后的操作；

(4)记录规则的日志信息，包括被触发的规则信息(该日志信息主要记录“规则何时被谁触发”)。

其中，客户管理模块304，负责客户的管理，规则的触发上报。一般的，涉及到客户、设备相关的自动化规则会由客户管理模块304触发。

其中，订单管理模块305，负责订单的管理，规则的触发上报。与客户管理模块304同层级，一般涉及订单相关的自动化规则会由客户管理模块304触发。其中，客户管理模块304和订单管理模块305可以统一称之为业务模块。

其中，公共(Common)模块306，事件注册框架能力等其他公共能力提供者。例如，在本申请实施例中，可以在公共模块306中预先构建事件注册框架，该事件注册框架可以包括事件规格定义表和事件因子实例信息表，以供客户管理模块304和订单管理模块305等业务模块分别从中直接获取自动化规则的主题信息和因子实例信息，等等。

其中，消息队列处理模块307，规则的触发上报、接收执行是以事件的方式，通过消息队列进行传递处理的。可选地，上述自动化规则处理系统30中各个模块的功能可以由一个或多个处理器实现，上述自动化规则处理系统30中的全部或者部分模块每个都可以具有其自己的处理器。

其中无线通信系统31可以直接地或者经由通信网络来与一个或多个设备进行无线通信，无线通信系统31可以通过不限于第二代移动通信网络(2th generation mobilenetworks，2G)、3G、4G、5G等各种无线通信方式进行通信，也可以是无线保真技术(Wireless-Fidelity，WIFI)、专用短程通信技术(Dedicated Short RangeCommunications，DSRC)等等，也可以是通过数据线连接的有线通信模式，等等。其主要功能是查询各个设备的状态和相关信息等，例如可以包括各个设备订购的商品信息以及商品状态，还可以包括设备的流量使用情况、剩余资费情况等等，以及对符合条件的设备执行相应的动作。例如向订购了即将到期的某一商品的设备的邮箱发送一封商品即将到期的提醒邮件，又例如停止流量使用到达设定阈值的设备的流量服务，等等。

其中，电源管理模块32用于连接自动化规则处理系统30、无线通信系统31、电池33和计算机系统34。电源管理模块32接收电池33的输入，为自动化规则处理系统30、无线通信系统31和计算机系统34等供电。

服务器100a的部分或所有功能受计算机系统34控制。计算机系统34可包括至少一个处理器341，处理器341执行存储在例如存储器342这样的非暂态计算机可读介质中的指令343。计算机系统34还可以是采用分布式方式控制服务器100a的个体组件或子系统的多个计算设备。

处理器341可以是任何常规的处理器，诸如商业可获得的CPU。可选地，该处理器可以是诸如ASIC或其它基于硬件的处理器的专用设备。处理器341可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processing unit，GPU)，图像信号处理器(image signalprocessor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signalprocessor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。其中，控制器可以是服务器100a的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。尽管图3功能性地图示了处理器、存储器，但是本领域的普通技术人员应该理解该处理器或存储器实际上可以包括不存储在相同的物理外壳内的多个处理器或存储器。例如，存储器可以是硬盘驱动器或位于不同于计算机系统34的外壳内的其它存储介质。因此，对处理器或存储器的引用将被理解为包括对可以或者可以不并行操作的处理器或存储器的集合的引用。不同于使用单一的处理器来执行此处所描述的步骤，例如自动化规则处理系统30中的一些组件每个都可以具有其自己的处理器，所述处理器只执行与特定于组件的功能相关的计算。

处理器341中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器341中的存储器可以为高速缓冲存储器。该存储器可以保存处理器341刚用过或循环使用的指令或数据。如果处理器341需要再次使用该指令或数据，可以从所述存储器中直接调用。避免了指令或数据的重复存取，减少了处理器341的等待时间，因而可以大大提高系统的运作效率。

在一些实施例中，处理器341可以包括一个或多个接口。接口可以包括集成电路(inter-integrated circuit，I2C)接口，集成电路内置音频(inter-integrated circuitsound，I2S)接口，脉冲编码调制(pulse code modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general-purposeinput/output，GPIO)接口，用户标识模块(subscriber identity module，SIM)接口，和/或通用串行总线(universal serial bus，USB)接口等。

可以理解的是，本申请实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对服务器100a的结构限定。在本申请另一些实施例中，服务器100a也可以采用与上述实施例中不同的接口连接方式，或多种接口连接方式的组合。

在一些实施例中，存储器342可包含指令343(例如，程序逻辑)，指令343可被处理器342执行来执行服务器100a的各种功能，包括以上描述的那些功能。存储器342也可包含额外的指令，包括向自动化规则处理系统30和无线通信系统31等发送数据、从其接收数据、与其交互和/或对其进行控制的指令。

除了指令343以外，存储器342还可以存储数据，例如物联网系统中的每个用户的一个或多个设备各自的设备信息(例如国际移动设备标识，也即手机串号，又例如SIM卡号等等)和设备状态(例如各个设备订购的商品信息、商品状态以及各个设备的剩余资费等)，等等。

可以理解的是，服务器100a可以具有比图3中所示的更多的或者更少的部件，可以组合两个或多个的部件，或者可以具有不同的部件配置。图中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。

下面将结合图2、图3和图4对本申请提出的技术方案进行详细阐述。本申请提出了一种自动化规则处理方法，可以应用于自动化规则处理系统，本申请在自动化处理系统30的公共模块306中预先构建了事件注册框架，该事件注册框架可以包括事件规格定义表和事件因子实例信息表。在通过自动化规则管理模块303配置自动化规则，生成对应的因子实例信息和动作实例信息后，自动化规则管理模块303可以将因子实例信息传输至公共模块306中的事件因子实例信息表中，该事件因子实例信息表可以包括多个自动化规则各自的因子实例信息。该事件规格定义表中可以包括多个自动化规则各自的主题信息(也即topic，是自动化规则的事件全名称，定义文件中带包路径的全名，全局唯一，用于唯一确定其对应自动化规则，并用于后续自动化规则的触发)。由此，当用户通过前台提供的界面根据自己的需求配置了目标自动化规则(例如为订购了商品标识为232342的商品的设备，在该商品到期前五天向该设备绑定的手机号发送一条商品即将到期的提醒短信)以及设置了对应的定时任务(例如为每天早上八点定时进行目标自动化规则的检测)后。该自动化规则处理系统30中的客户管理模块304可以在定时任务定时触发时，从公共模块306中的事件因子实例信息表中查询得到该目标自动化规则的因子实例信息(例如包括“商品标识为232342”以及“商品到期前五天”)；然后，客户管理模块304可以根据该因子实例信息查询得到符合条件的一个或多个设备(例如为物联网设备200a和200b)的设备信息(例如为国际移动设备标识，也即手机串号、SIM卡号或者手机号或者其他的设备信息，等等)。可选地，若本次定时任务没有查询得到符合条件的设备(例如执行本次定时任务时的日期是该商品到期前20天等等情况下)，则可以终止本次任务，不执行后续步骤，待下一次定时任务触发，等等，此处不再进行赘述。在客户管理模块304查询得到符合条件的一个或多个设备的设备信息后，客户管理模块304可以从公共模块306中的事件规格定义表中获取该目标自动化规则的主题信息，然后根据该目标自动化规则的主题信息、因子实例信息和符合条件的设备信息生成对应的主题消息，并发送该主题消息至消息队列处理模块307。然后，自动化规则管理模块303可以通过侦听该主题消息，解析消息体，得到自动化规则的主题信息、因子实例信息和符合条件的设备信息，并根据主题信息查询得到该目标自动化规则的动作实例信息。然后，自动化规则管理模块303可以基于该目标自动化规则的主题信息、动作实例信息和符合条件的设备信息生成对应的主题消息，并发送该主题消息至消息队列处理模块307。然后，业务处理模块302可以通过侦听该主题消息，解析消息体，得到该目标自动化规则的主题信息、动作实例信息和符合条件的设备信息，从而可以通过业务处理模块302对该一个或多个符合条件的设备执行该动作实例(例如为向物联网设备200a和200b分别发送一条商品即将到期的提醒短信，等等)。至此，完成了目标自动化规则的触发和动作执行，也即消费了该目标自动化规则。

综上所述，基于上述本申请实际要解决的技术问题，本申请提出了一种自动化规则处理系统(也即一种基于事件注册的多模块解耦框架)，通过公共模块预先构建的事件注册框架(包括事件规格定义表和事件因子实例信息表)保存事件定义(也即topic)和规则的因子实例信息，作为通用的配置能力，供客户管理模块以及后续有此类似场景的其他业务模块使用。其核心在于，对于多个独立模块(指业务功能各不相同的模块，各模块之间无直接交互，例如客户管理模块和自动化规则管理模块)需要集成的场景，基于事件注册(自动化规则场景下，规则的触发通过消息事件进行传递，将规则事件提前定义在框架中，称为事件注册)框架，将衍生模块(客户管理模块和订单管理模块等业务模块)与源模块(自动化规则管理模块)的耦合性(也叫块间联系，指软件系统结构中各模块间相互联系紧密程度的一种度量。模块间联系越多，其耦合性越强，同时表明其独立性越差(降低耦合性，可以提高其独立性)，软件设计中划分模块的一个准则就是高内聚低耦合)降为零，并且自动化规则消息事件的Topic(前文提到的商业事件(Business event)为BES系统中完成特定行为的一个通知，用于模块间的异步解耦。Topic为主题，引擎根据该配置自动生成与消息队列处理模块交互的助理消息。)定义灵活获取，维护扩展性增强。

综上所述，物联网设备200a、200b、200c和200d可以为物联网系统中的智能设备，例如为智能手机、平板电脑、笔记本电脑、台式电脑和机器人等等设备，本申请实施例对此不作具体限定。可选地，物联网设备200a、200b、200c和200d中可以包括SIM卡接口，用于连接SIM卡。SIM卡可以通过插入SIM卡接口，或从SIM卡接口拔出，实现和物联网设备200a、200b、200c和200d的接触和分离。在一些实施例中，物联网设备200a、200b、200c和200d可以采用eSIM，即：嵌入式SIM卡。eSIM卡可以嵌在物联网设备200a、200b、200c和200d中，不能和其分离。服务器100a可以是具备上述功能的一台服务器，也可以是由多台服务器组成的服务器集群，或者是一个云计算服务中心，等等，本申请实施例对此不作具体限定。

为了便于理解本申请实施例，以下示例性列举本申请中一种自动化规则处理方法所适用的应用场景，可以包括如下场景。

场景一，用户按照自己的需求配置自动化规则，在其设备订购的商品到期前五天，向指定邮箱发送商品即将到期的提醒邮件。

请参阅图5，图5是本申请实施例提供的一种自动化规则处理方法的应用场景示意图。如图5所示，该应用场景包括服务器和物联网设备(图5中以智能手机为例)，可选地，该应用场景还可以包括其他更多的物联网设备(图5中未示出)，该多个物联网设备可以为同一用户在物联网系统中的不同设备，例如可以为两部各自绑定一张SIM卡的智能手机，又例如可以为一部同时绑定两张SIM卡并双卡双待的智能手机，等等，本申请实施例对此不作具体限定。该物联网设备中可以包括相关存储器、显示器和处理器等。其中，存储器、显示器和处理器可以通过系统总线进行数据传输。其中，物联网设备和服务器可以通过Wi-Fi或移动网络等无线通信方式或者数据线等有线通信方式进行数据传输。其中，该服务器可以配置有自动化规则处理系统，该自动化规则处理系统可以包括业务模块(例如客户管理模块和订单管理模块等)、业务处理模块、自动化规则管理模块和公共模块，等等。该公共模块可以包括预先构建的事件注册框架，该事件注册框架可以包括事件规格定义表和事件因子实例信息表。其中，该事件规格定义表包括多个自动化规则各自的主题信息，该事件因子实例信息表包括多个自动化规则各自的因子实例信息。在本申请实施例中，在业务模块针对某一自动化规则的定时任务触发后，可以基于本申请的自动化规则处理系统，并利用本申请中的一种自动化规则处理方法从公共模块的事件因子实例信息表中获取自动化规则的因子实例信息(例如包括如图5所示的“商品标识为232342”以及“商品到期前五天”)，并查询得到符合该因子实例信息的设备信息，以及从公共模块的事件规格定义表中获取自动化规则的主题信息(一般为一串字符串)，以供最终业务处理模块对符合该因子实例信息的设备执行该自动化规则的动作实例(例如图5所示的向该物联网设备绑定的邮箱发送一封商品即将到期的提醒邮件)。可选地，例如，若业务模块查询得到该用户的所有物联设备均订购了商品标识为232342的商品，且五天后商品均会过期，则最终业务处理模块可以分别向该用户的所有物联网设备各自绑定的邮箱发送一封商品即将到期的提醒邮件，等等，此处不再进行赘述。

在本申请实施例中，当用户想要配置相应的自动化规则以对其物联网设备进行自动化规则管理时，用户对终端设备的操作过程可以参阅图6a-图6c，图6a-图6c是本申请实施例提供的一组界面示意图。其中，终端设备和上述服务器可以通过Wi-Fi或移动网络等无线通信方式或者数据线等有线通信方式进行数据传输。如图6a所示，终端设备显示了自动化规则创建界面401，其中，该自动化规则创建界面401可以包括列有多个默认自动化规则的自动化规则列表(例如可以包括图6a所示的“自动化规则-商品到期提醒”、“自动化规则-设备状态变更提醒”、“自动化规则-流量到达阈值提醒”、“自动化规则-流量自动限速”和“自动化规则-剩余资费提醒”)。其中，该自动化规则创建界面401还可以包括多个自动化规则各自的创建控件，例如图6a所示的“自动化规则-商品到期提醒”的创建控件402a、“自动化规则-设备状态变更提醒”的创建控件402b、“自动化规则-流量到达阈值提醒”的创建控件402c、“自动化规则-流量自动限速”的创建控件402d和“自动化规则-剩余资费提醒”的创建控件402e。可选地，该自动化规则创建界面401还可以包括自定义自动化规则控件403、设置控件404以及其他控件，等等。例如，如图6a所示，当用户想要创建一条商品到期提醒的自动化规则以管理其物联网设备时，可以通过输入操作405(例如为点击创建控件402a)触发自动化规则的创建。此时，如图6b所示，在用户点击了创建控件402a后，终端设备显示了“自动化规则-商品到期提醒”的创建界面406，其中，该“自动化规则-商品到期提醒”的创建界面406可以包括商品标识输入控件407、商品到期前天数输入控件408、发送邮件选择控件409a、发送短信选择控件409b、邮箱地址输入控件410和创建控件411。如图6b所示，用户可以根据自己的需求，在该“自动化规则-商品到期提醒”的创建界面406中对商品标识、商品到期前天数和提醒操作进行设置，以及若选择发送邮箱，则需对邮箱地址进行设置。可选地，用户还可以在该“自动化规则-商品到期提醒”的创建界面406中选择合适的邮件模板(图6b中未示出，该邮件模板比如可以包括提醒用户订购的商品即将到期的内容)。例如，如图6b所示，若用户已确认完成“自动化规则-商品到期提醒”的配置，用户可以通过输入操作412(例如为点击创建控件410)，完成“自动化规则-商品到期提醒”的创建。在用户通过上述操作界面进行自动化规则的创建过程中，终端设备可以与服务器中的自动化规则管理模块建立连接，通过自动化规则管理模块完成自动化规则的创建，生成对应的因子实例信息(例如包括图6b所示的“商品标识为232341”和“商品到期前5天”)和动作实例信息(例如为图6b所示的“发送邮件至邮箱xxxxxxx@xx.com”)。然后，自动化规则管理模块可以将生成的因子实例信息和动作实例信息归档至数据库中，并将因子实例信息传输至公共模块的事件因子实例信息表中。由此，当该自动化规则的定时任务触发后，业务模块可以直接从公共模块的事件因子实例信息表中获取该自动化规则的因子实例信息，而无需通过调用自动化规则管理模块接口，再向自动化规则管理模块查询因子实例信息。通过本申请实施例提供的一种自动化规则处理方法和系统，实现了业务模块与自动化管理模块之间的解耦。

进一步的，如图6c所示，终端设备显示了自动化规则管理界面413，其中，该自动化规则管理界面413可以包括设置控件414和多个已配置的自动化规则各自的编辑控件和删除控件。例如，如图6c所示的自动化规则1的编辑控件415a和删除控件415b、自动化规则2的编辑控件416a和删除控件416b，以及自动化规则3的编辑控件417a和删除控件417b，等等，此处不再进行赘述。用户可以根据自己的需求对已配置的自动化规则进行编辑(例如更改因子实例和动作实例等)和删除。例如，如图6c所示，用户可以通过输入操作418(例如为点击删除控件415)删除已配置的自动化规则1。由此，可以满足用户根据自身习惯或者要求管理自动化规则，从而进一步更好的管理其物联网设备的需求。

可选地，上述图6a-图6c的操作过程也可以通过图5中的物联网设备完成(也即该终端设备可以为上述图5中的物联网设备)。可选地，自动化规则的创建也可以由开发人员利用图5中的服务器或者与服务器连接的终端设备、计算机等等通过自动化规则处理系统中的自动化规则管理模块预先进行创建，从而可以为用户提供多样的可直接使用的自动化规则。

如上所述，该物联网设备可以为具备上述功能的智能手机、智能可穿戴设备、平板电脑、笔记本电脑、台式电脑和机器人等等，本申请实施例对此不作具体限定；该终端设备可以为具备上述功能的智能手机、智能可穿戴设备、平板电脑、笔记本电脑和台式电脑等等，本申请实施例对此不作具体限定；该服务器可以为具备上述功能的一台服务器，也可以是由多台服务器组成的服务器集群，或者是一个云计算服务中心，等等，本申请实施例对此不作具体限定。可以理解的是，本申请提供的一种自动化规则处理方法还可以应用于除上述的应用场景外的其他场景。

请参阅图7，图7是本申请实施例提供的一种自动化规则处理方法的流程示意图，该方法可应用于上述图2中所述的系统架构中，以及具体可应用于上述图2或图3所述的服务器100a以及图4所述的自动化规则处理系统中。其中的设备可以为图2所述的物联网设备200a、200b、200c和200d中的任意一个。下面结合附图7以执行主体为上述图2中的服务器100a为例进行描述。该方法可以包括以下步骤S701-步骤S703：

步骤S701，通过业务模块从公共模块中的事件因子实例信息表中获取目标自动化规则的因子实例信息；目标自动化规则的因子实例信息包括用于触发目标动作的一个或多个触发条件。

具体地，可以针对目标自动化规则创建一个定时任务(例如为每日中午十二点进行目标自动化规则检测，查询是否有该目标自动化规则的触发产生)，该定时任务执行时，可以通过业务模块从公共模块中的事件因子实例信息表中获取目标自动化规则的因子实例信息。可选地，该因子实例信息可以包括用户事先设置的用于触发目标动作(也即该目标自动化规则的动作实例，比如发送邮件到设备绑定的邮箱)的一个或多个触发条件(也即一个或多个因子实例，比如“商品标识为232341”和“商品到期前5天”)。可选地，该业务模块例如可以为上述图3中所述的客户管理模块304、订单管理模块305或者其他的业务模块，等等，本申请实施例对此不作具体限定。由此，对比现有技术中，业务模块只能通过调用自动化规则管理模块的接口，进而从自动化规则管理模块中查询得到目标自动化规则的因子实例信息，导致业务模块与自动化规则管理模块之间存在强耦合，大大降低了模块独立性的方案而言。本申请实施例在获取因子实例信息时，业务模块无需调用自动化规则管理模块的接口，实现了业务模块与自动化规则管理模块之间的解耦。

步骤S702，通过业务模块获取M个设备各自的设备信息，M个设备中的每一个设备为符合一个或多个触发条件的设备。

具体地，在业务模块从公共模块中的事件因子实例信息表中获取到目标自动化规则的因子实例信息后，可以通过业务模块根据该因子实例信息构造查询条件，查询得到符合该因子实例信息(也即符合该一个或多个触发条件)的M个设备的设备信息。可以理解的是，若本次定时任务中，未查询得到符合条件的设备，则不执行后续步骤，待下一次定时任务开始。

步骤S703，通过业务处理模块对M个设备执行目标动作。

具体地，在业务模块查询得到符合条件的M个设备后，最终可以通过业务处理模块对该M个设备执行该目标动作。例如可以为分别向该M个设备各自绑定的邮箱发送一封商品即将到期的提醒邮件，又例如可以为分别向该M个设备各自绑定的手机号码发送一条商品即将到期的提醒短信，等等。

请参阅图8，图8是本申请实施例提供的另一种自动化规则处理方法的流程示意图，该方法可应用于上述图2中所述的系统架构中，以及具体可应用于上述图2或图3所述的服务器100a以及图4所述的自动化规则处理系统中。其中的设备可以为图2所述的物联网设备200a、200b、200c和200d中的任意一个。下面结合附图8以执行主体为上述图4中的自动化规则处理系统中的各个模块为例进行描述。该方法可以包括以下步骤S801-步骤S812：

步骤S801，自动化规则管理模块配置目标自动化规则，生成目标自动化规则的因子实例信息和动作实例信息。

具体地，自动化规则管理模块可以进行自动化规则的生命周期管理，包括自动化规则的配置(也即自动化规则的创建)、暂停和删除，等等。自动化规则管理模块可以基于用户需求进行目标自动化规则配置，生成目标自动化规则的因子实例信息和动作实例信息(例如可以为上述图7对应的实施例中的目标动作，比如发送邮件到设备绑定的邮箱等等)，并将因子实例信息和动作实例信息归档至数据库中，此处不再进行赘述。

可选地，该自动化规则管理模块可以基于不同用户的不同需求配置多个自动化规则，并将生成的多个自动化规则各自的因子实例信息和动作实例信息归档至自动化规则管理模块的数据库中。例如，该目标自动化规则可以为商品到期提醒，则该目标自动化规则的因子实例信息可以包括“商品标识为232341”和“商品到期前5天”，该目标自动化规则的动作实例信息(也即上述图7对应的实施例中的目标动作)可以为发送商品即将到期的提醒邮件到指定的邮箱，比如满足该因子实例信息的设备(也即该设备订购了商品标识为232342的商品，且该商品5天后过期)所绑定的邮箱。

步骤S802，自动化规则管理模块传输目标自动化规则的因子实例信息至公共模块的事件因子实例信息表中。

具体地，可以在公共模块中预先构建事件注册框架，该事件注册框架可以包括事件因子实例信息表。自动化规则管理模块在配置完成目标自动化规则后，可以将生成的目标自动化规则的因子实例信息传输至公共模块的事件因子实例信息表中。可选地，自动化规则管理模块可以将生成的多个自动化规则各自的因子实例信息传输至该公共模块的事件因子实例信息表中，则该事件因子实例信息表可以包括多个自动化规则各自的因子实例信息。事件因子实例信息表如表2所示，其主要包括FACTOR_INSTACE(因子实例信息，比如表2所示的“OFFERID”:”20190020”)。其中，EVENT_TRIGGER_BUSI_CODE(事件触发业务编码)标记本条因子实例信息是哪个自动化规则事件的实例(例如可以为表2所示的BILLPLAN_EXPIRE)，其中，RULE_INST_ID(因子关联的规则实例标识)为该规则实例的唯一标识。

表2事件因子实例信息表

步骤S803，业务模块注册本模块的事件规格定义。

具体地，业务模块在公共模块的事件规格定义表中注册该目标自动化规则的事件规格定义，填写该业务模块对应的模块标识。事件规格定义表如表3所示，例如，一个新的业务模块——P模块，想要使用上述商品到期提醒的目标自动化规则，则该P模块需要在该事件规格定义表中进行注册，在SRC_MODULE_ID(事件源模块标识)一栏填写P模块的模块标识(例如表3所示的60105等字符串)，表示该P模块需要从事件因子实例信息表中获取该目标自动化规则的因子实例信息，以用于该自动化规则的触发。而该表中的其余大部分信息为商品到期提醒这一目标自动化规则的基本信息，无需特殊修改。其中，如表3所示，DEST_MODULE_ID(事件目标模块标识)为自动化规则管理模块的模块标识(例如为表3所示的60502等字符串)。因此，当任何业务模块想要使用事件规格定义表中的自动化规则时，一般情况下只需在事件规格定义表中注册本模块的事件规格定义，填写本模块的模块标识即可，而不需要再部署自动化规则管理模块，真正实现了各模块之间完全解耦的目的，极大程度上为多模块复用自动化规则提供了便利。

表3事件规格定义表

步骤S804，业务模块从事件因子实例信息表中获取目标自动化规则的因子实例信息。

具体地，业务模块可以直接从公共模块的事件因子实例信息表中获取目标自动化规则的因子实例信息。因此，业务模块无需调用自动化规则管理模块接口，再从自动化规则管理模块中查询目标自动化规则的因子实例信息。进一步的，由于业务模块中无需设置调用自动化规则管理模块接口的代码，因此在不需要进行自动化规则处理时，就可以不部署自动化规则管理模块。由此，对比现有技术中由于业务模块中固定了调用自动化规则管理模块接口的代码，而在不需要进行自动化规则处理时也必须要连带部署自动化规则管理模块(现有技术中，当最终编译过程中检查到在业务模块中固定了调用自动化规则管理模块接口的代码，却又没有部署自动化规则管理模块时，会进行报错处理，从而无法顺利完成编译)而言，本申请实施例实现了模块的独立部署。

步骤S805，业务模块获取符合目标自动化规则的因子实例信息的M个设备各自的设备信息。

具体地，步骤S805可以参考上述图7对应的实施例中的步骤S702，此处不再进行赘述。

步骤S806，业务模块从事件规格定义表中获取目标自动化规则的主题信息。

具体地，业务模块从公共模块的事件规格定义表中获取目标自动化规则的主题信息。可选地，该业务模块可以通过自身的源模块标识和事件触发业务编码查询得到该业务模块目标自动化规则的主题信息(例如表3所示的EVENT_NAME，为自动化规则事件的全名称)。由此，对比现有技术中，将目标自动化规则的主题信息固定在业务模块的代码中，业务模块只能从自身的代码中获取目标自动化规则的主题信息的方案而言，本申请实施例可以直接从事件规格定义表中获取目标自动化规则的主题信息，获取方式灵活，且明显降低了业务模块自身的代码复杂度。同时，当主题信息需要进行修改或者扩展时，可以直接在事件规格定义表中进行修改，不用改动每个业务模块的底层代码，从而实现了主题信息的一键修改，增强了主题信息的可维护性。

步骤S807，业务模块发送第一主题消息(包含设备信息和因子实例信息)。

具体地，业务模块基于目标自动化规则的主题信息、因子实例信息，以及查询到的符合该因子实例信息的M个设备各自的设备信息，生成对应的第一主题消息，并发送该第一主题消息至消息队列处理模块，待自动化规则管理模块消费。

步骤S808，自动化规则管理模块侦听第一主题消息。

具体地，自动化规则管理模块侦听该第一主题消息，接收到该第一主题消息后，解析消息体，得到对应的目标自动化规则的主题信息、因子实例信息，以及符合该因子实例信息的M个设备各自的设备信息。

步骤S809，自动化规则管理模块根据第一主题消息，查询得到目标自动化规则的动作实例信息。

具体地，自动化规则管理模块根据解析第一主题消息的消息体得到的主题信息，查询得到事先配置目标自动化规则时生成的目标自动化规则的动作实例信息，可选地，还可以根据该主题信息查询得到该目标自动化规则的其他信息等等。

步骤S810，自动化规则管理模块发送第二主题消息(包含设备信息和动作实例信息)。

具体地，自动化规则管理模块基于该目标自动化规则的主题信息、动作实例信息以及上述M个设备各自的设备信息，生成对应的第二主题消息，并发送该第二主题消息至消息队列处理模块。

步骤S811，业务处理模块侦听第二主题消息。

具体地，业务处理模块侦听该第二主题消息，接收到该第二主题消息后，解析消息体，得到对应的目标自动化规则的主题信息、动作实例信息，以及符合该目标自动化规则的因子实例信息的M个设备各自的设备信息。

步骤S812，业务处理模块根据目标自动化规则的动作实例信息，分别对M个设备进行相应动作的处理。

具体地，业务模块根据解析第一主题消息的消息体得到的动作实例信息，以及M个设备各自的设备信息，分别对该M个设备执行动作实例。例如，如上所述该目标自动化规则可以为商品到期提醒，则该业务处理模块(比如可以为上述的P模块)可以向该M个设备各自绑定的邮箱发送一封商品即将到期的提醒邮件。

可选地，若用户想要实现其他的自动化规则，例如为流量使用到达阈值时进行流量限速的自动化规则(该自动化规则的因子实例信息例如可以包括“设备状态为有效”和“流量使用达到10G阈值”，该自动化规则的动作实例信息例如可以为对满足该因子实例信息的设备进行流量限速)，则只要在负责流量监控的模块中进行配置即可。例如，K模块为检测设备流量的业务模块，其自动化规则处理的流程例如：当查询得到一个或多个有效设备(例如为未停机的设备)的流量使用超过10G阈值时，K模块执行规则上报，告知用户流量使用超过阈值，自动化规则管理模块收到K模块发送的规则实例，解析执行，发送流量限速的通知给业务处理模块，业务处理模块收到流量限速通知后，触发执行流量限速相关业务流程，限制该一个或多个有效设备的流量速度，等等，此处不再进行赘述。

综上所述，业务模块作为该目标自动化规则的注册者，无需调用自动化规则管理模块接口，查询该目标自动化规则的因子实例信息，业务模块只需要根据事件注册框架中的事件消费信息，执行相应的处理，并根据其提供的信息发布该事件的主题消息即可。自动化规则的注册者(业务模块)和消费者(自动化规则管理模块)之间并不知晓，使得他们相互之间是解耦的。同时，通过将自动化规则的主题信息注册在事件注册框架的事件规格定义表中，在发送主题消息时，只需根据条件查询事件规格定义表获取对应的主题信息。主题信息通过公共模块统一管理，方便维护；主题信息可随时进行变更而不用修改各模块的底层代码，扩展性增强。

与现有技术相比，本申请主要技术关键点在于事件注册框架(包括事件规格定义表和事件因子实例信息表)以及根据此框架实现多模块之间解耦和主题信息灵活配置的能力。本申请通过在公共模块中预先构建事件注册框架，并将规则事件注册到事件注册框架中，实现了各独立模块之间的解耦，独立模块可独立部署，扩展性增强；不存在多余模块，启动时间降低；并且通过从事件注册框架中获取自动化规则的主题信息，可维护性也增强。具体如下：

(1)现有技术中，业务模块需要向自动化规则管理模块查询自动化规则的因子实例信息，存在模块间的依赖，有耦合关系。本申请技术方案中，通过事件注册框架，注册事件规格定义，并将因子实例信息同步至框架的事件因子实例信息表中，模块与模块间的耦合已不存在。客户管理模块等业务模块可独立部署，无需附带自动化规则管理模块；另外，其他模块若想使用自动化规则能力时，同样也只需从框架中获取实例因子信息，而在其他不使用自动化规则能力的时候不用依赖自动化规则管理模块。各模块的独立扩展性增强。环境不存在多余模块，整个系统的启动时间降低。并且，事件注册框架可以被其他多个模块复用，从而达到零耦合和多复用的双重能力。

(2)现有技术中，自动化规则的主题信息固定在各模块的代码中。而在本申请的技术方案中，各模块将自动化规则的主题信息注册到事件注册框架中，该事件注册框架保存有各模块的事件规格定义。规则触发时，现有技术是直接从代码中获取固定的主题信息，并发送主题消息，而本申请是从事件注册框架的事件规格定义表中获取该自动化规则的主题信息。因此，后期维护只需维护事件注册框架，当自动化规则事件存在修改或者扩展时，例如需要修改或者扩展主题信息时，可以实现一键修改，而不用改动每个模块的底层代码，维护和扩展性增强。

需要说明的是，本申请旨在通过将有用信息同步至公共模块中，从而实现各模块之间解耦的目的。因此，本申请的技术方案，可以用于除自动化规则处理外的其他领域中需要解决多模块耦合的场景，可将业务的某部分数据信息同步至模块的公共部件中，从而达到解耦的目的；另外，其他领域中有用到消息队列的地方，也可将所有主题信息存于公共模块中，便于维护。

请参阅图9，图9是本申请实施例提供的一种自动化规则处理系统的结构示意图，该自动化规则处理装置可以应用于服务器。该自动化规则处理系统可以包括业务处理模块901、业务模块902和公共模块904，公共模块904包括预先构建的事件注册框架，事件注册框架包括事件因子实例信息表。其中，各个模块的详细描述如下。

业务模块902，用于从所述公共模块904中的事件因子实例信息表中获取目标自动化规则的因子实例信息；所述目标自动化规则的因子实例信息包括用于触发目标动作的一个或多个触发条件；

业务模块902，还用于获取M个设备各自的设备信息，所述M个设备中的每一个设备为符合所述一个或多个触发条件的设备，M为大于或者等于1的整数；

业务处理模块901，用于对所述M个设备执行所述目标动作。

在一种可能的实现方式中，该自动化规则处理系统还包括自动化规则管理模块903：

当所述自动化规则处理系统进行自动化规则处理时，自动化规则管理模块903，用于配置所述目标自动化规则，生成所述目标自动化规则的因子实例信息以及所述目标动作，并传输所述目标自动化规则的因子实例信息至所述公共模块904中的所述事件因子实例信息表。

在一种可能的实现方式中，该自动化规则处理系统还包括消息队列处理模块905，所述事件注册框架还包括事件规格定义表；所述业务模块902，还用于：

从所述事件规格定义表中获取所述目标自动化规则的主题信息，并基于所述主题信息、所述目标自动化规则的因子实例信息以及所述M个设备各自的设备信息生成对应的第一主题消息；

发送所述第一主题消息至所述消息队列处理模块905。

在一种可能的实现方式中，所述自动化规则管理模块903，还用于：

侦听所述第一主题消息，并根据所述第一主题消息查询得到所述目标动作；

基于所述主题信息、所述目标动作以及所述M个设备各自的设备信息生成对应的第二主题消息，并发送所述第二主题消息至所述消息队列处理模块905。

在一种可能的实现方式中，所述业务处理模块901，具体用于侦听所述第二主题消息，并根据所述第二主题消息分别对所述M个设备执行所述目标动作。

在一种可能的实现方式中，所述业务模块901，还用于在所述事件规格定义表中注册所述目标自动化规则的事件规格定义，填写所述业务模块对应的模块标识。

需要说明的是，本申请实施例中所描述的自动化规则处理装置中各功能单元的功能可参见上述图7中所述的方法实施例中步骤S701-步骤S703的相关描述和，还可以参见上述图8中所述的方法实施例中步骤S801-步骤S812的相关描述，此处不再进行赘述。

图9中每个模块可以以软件、硬件、或其结合实现。以硬件实现的单元可以包括逻辑电路、算法电路或模拟电路等。以软件实现的单元可以包括程序指令，被视为是一种软件产品，被存储于存储器中，并可以被处理器运行以实现相关功能，具体参见之前的介绍。

基于上述方法实施例以及装置实施例的描述，本申请实施例还提供一种服务器。请参阅图10，图10是本申请实施例提供的一种服务器的结构示意图，该服务器100至少包括处理器1001，输入设备1002、输出设备1003和计算机可读存储介质1004，该服务器100还可以包括其他通用部件，在此不再详述。其中，服务器100内的处理器1001，输入设备1002、输出设备1003和计算机可读存储介质1004可通过总线或其他方式连接。

处理器1001可以是通用中央处理器(CPU)，微处理器，特定应用集成电路(application-specific integrated circuit，ASIC)，或一个或多个用于控制以上方案程序执行的集成电路。该处理器1001可以包括一个或多个处理器，该处理器1001以及该服务器100内的其他部件可以构成本申请实施例提供的一种自动化规则处理系统。

该服务器100内的存储器1006可以是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)、只读光盘(Compact Disc Read-Only Memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器1006可以是独立存在，通过总线与处理器1001相连接。存储器1006也可以和处理器1001集成在一起。

计算机可读存储介质1004可以存储在服务器100的存储器1006中，所述计算机可读存储介质1004用于存储计算机程序，所述计算机程序包括程序指令，所述处理器1001用于执行所述计算机可读存储介质1004存储的程序指令。处理器1001(或称CPU(CentralProcessing Unit，中央处理器))是服务器100的计算核心以及控制核心，其适于实现一条或一条以上指令，具体适于加载并执行一条或一条以上指令从而实现相应方法流程或相应功能；在一个实施例中，本申请实施例所述的处理器1001可以用于进行自动化规则处理的一系列处理，包括：通过业务模块从公共模块中的事件因子实例信息表中获取目标自动化规则的因子实例信息；所述目标自动化规则的因子实例信息包括用于触发目标动作的一个或多个触发条件；通过所述业务模块获取M个设备各自的设备信息，所述M个设备中的每一个设备为符合所述一个或多个触发条件的设备，M为大于或者等于1的整数；通过所述业务处理模块对所述M个设备执行所述目标动作，等等。

需要说明的是，本申请实施例中所描述的服务器100中各功能单元的功能可参见上述图7中所述的方法实施例中步骤S701-步骤S703的相关描述和，还可以参见上述图8中所述的方法实施例中步骤S801-步骤S812的相关描述，此处不再赘述。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

本申请实施例还提供了一种计算机可读存储介质(Memory)，所述计算机可读存储介质是服务器中的记忆设备，用于存放程序和数据。可以理解的是，此处的计算机可读存储介质既可以包括服务器中的内置存储介质，当然也可以包括服务器所支持的扩展存储介质。计算机可读存储介质提供存储空间，该存储空间存储了服务器的操作系统。并且，在该存储空间中还存放了适于被处理器加载并执行的一条或一条以上的指令，这些指令可以是一个或一个以上的计算机程序(包括程序代码)。需要说明的是，此处的计算机可读存储介质可以是高速RAM存储器，也可以是非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器；可选地还可以是至少一个位于远离前述处理器的计算机可读存储介质。

本申请实施例还提供一种计算机程序，该计算机程序包括指令，当该计算机程序被计算机执行时，使得计算机可以执行任意一种自动化规则处理方法的部分或全部步骤。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可能可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置，可通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如上述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性或其它的形式。

上述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

上述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以为个人计算机、服务端或者网络设备等，具体可以是计算机设备中的处理器)执行本申请各个实施例上述方法的全部或部分步骤。其中，而前述的存储介质可包括：U盘、移动硬盘、磁碟、光盘、只读存储器(Read-OnlyMemory，缩写：ROM)或者随机存取存储器(RandomAccessMemory，缩写：RAM)等各种可以存储程序代码的介质。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (15)

1.一种自动化规则处理方法，其特征在于，应用于自动化规则处理系统，所述自动化规则处理系统包括业务模块、业务处理模块和公共模块，所述公共模块包括预先构建的事件注册框架，所述事件注册框架包括事件因子实例信息表；所述方法包括：

通过所述业务模块从所述公共模块中的所述事件因子实例信息表中获取目标自动化规则的因子实例信息；所述目标自动化规则的因子实例信息包括用于触发目标动作的一个或多个触发条件；

通过所述业务模块获取M个设备各自的设备信息，所述M个设备中的每一个设备为符合所述一个或多个触发条件的设备，M为大于或者等于1的整数；

通过所述业务处理模块对所述M个设备执行所述目标动作。

2.根据权利要求1所述的方法，其特征在于，所述自动化规则处理系统还包括自动化规则管理模块；所述方法还包括：

当所述自动化规则处理系统进行自动化规则处理时，通过所述自动化规则管理模块配置所述目标自动化规则，生成所述目标自动化规则的因子实例信息以及所述目标动作，并传输所述目标自动化规则的因子实例信息至所述公共模块中的所述事件因子实例信息表。

3.根据权利要求2所述的方法，其特征在于，所述自动化规则处理系统还包括消息队列处理模块，所述事件注册框架还包括事件规格定义表；所述方法还包括：

通过所述业务模块从所述事件规格定义表中获取所述目标自动化规则的主题信息，并基于所述主题信息、所述目标自动化规则的因子实例信息以及所述M个设备各自的设备信息生成对应的第一主题消息；

通过所述业务模块发送所述第一主题消息至所述消息队列处理模块。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

通过所述自动化规则管理模块侦听所述第一主题消息，并根据所述第一主题消息查询得到所述目标动作；

通过所述自动化规则管理模块，基于所述主题信息、所述目标动作以及所述M个设备各自的设备信息生成对应的第二主题消息，并发送所述第二主题消息至所述消息队列处理模块。

5.根据权利要求4所述的方法，其特征在于，所述通过所述业务处理模块对所述M个设备执行所述目标动作，包括：

通过所述业务处理模块侦听所述第二主题消息，并根据所述第二主题消息分别对所述M个设备执行所述目标动作。

6.根据权利要求1-5任意一项所述的方法，其特征在于，所述方法还包括：

通过所述业务模块在所述事件规格定义表中注册所述目标自动化规则的事件规格定义，填写所述业务模块对应的模块标识。

7.一种自动化规则处理系统，其特征在于，包括业务模块、业务处理模块和公共模块，所述公共模块包括预先构建的事件注册框架，所述事件注册框架包括事件因子实例信息表；

所述业务模块，用于从所述公共模块中的所述事件因子实例信息表中获取目标自动化规则的因子实例信息；所述目标自动化规则的因子实例信息包括用于触发目标动作的一个或多个触发条件；

所述业务模块，还用于获取M个设备各自的设备信息，所述M个设备中的每一个设备为符合所述一个或多个触发条件的设备，M为大于或者等于1的整数；

所述业务处理模块，用于对所述M个设备执行所述目标动作。

8.根据权利要求7所述的系统，其特征在于，所述自动化规则处理系统还包括自动化规则管理模块；

当所述自动化规则处理系统进行自动化规则处理时，所述自动化规则管理模块，用于配置所述目标自动化规则，生成所述目标自动化规则的因子实例信息以及所述目标动作，并传输所述目标自动化规则的因子实例信息至所述公共模块中的所述事件因子实例信息表。

9.根据权利要求8所述的系统，其特征在于，所述自动化规则处理系统还包括消息队列处理模块，所述事件注册框架还包括事件规格定义表；

所述业务模块，还用于从所述事件规格定义表中获取所述目标自动化规则的主题信息，并基于所述主题信息、所述目标自动化规则的因子实例信息以及所述M个设备各自的设备信息生成对应的第一主题消息；

所述业务模块，还用于发送所述第一主题消息至所述消息队列处理模块。

10.根据权利要求9所述的系统，其特征在于，所述自动化规则管理模块，还用于侦听所述第一主题消息，并根据所述第一主题消息查询得到所述目标动作；

所述自动化规则管理模块，还用于基于所述主题信息、所述目标动作以及所述M个设备各自的设备信息生成对应的第二主题消息，并发送所述第二主题消息至所述消息队列处理模块。

11.根据权利要求10所述的系统，其特征在于，所述业务处理模块，具体用于侦听所述第二主题消息，并根据所述第二主题消息分别对所述M个设备执行所述目标动作。

12.根据权利要求7-11任意一项所述的系统，其特征在于，所述业务模块，还用于在所述事件规格定义表中注册所述目标自动化规则的事件规格定义，填写所述业务模块对应的模块标识。

13.一种服务器，其特征在于，包括处理器和存储器，所述处理器和存储器相连，其中，所述存储器用于存储程序代码，所述处理器用于调用所述程序代码，以执行如权利要求1至6任意一项所述的方法。

14.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，该计算机程序被处理器执行时实现上述权利要求1至6任意一项所述的方法。

15.一种计算机程序，其特征在于，所述计算机程序包括指令，当所述计算机程序被计算机执行时，使得所述计算机执行如权利要求1至6任意一项所述的方法。

Images