Business rule management method, event processing method and event processing platform

CN123020642APending Publication Date: 2026-10-30SHENZHEN BAICHUAN SECURITY TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202611091134.8
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-07-22
Publication Date
2026-10-30

AI Technical Summary

Technical Problem

[0007]随着事件信息处理所涉及的设备及告警动作的不断丰富,现有技术只能支持单一告警动作或单一生态设备处理的单一事件驱动服务,已经难以满足人们日益增长的个性化需求

Benefits of technology

[0030]通过基于事件信息和预设格式的业务规则确定目标事件驱动服务,能够实现事件处理的规则化路由,使得对应于不同事件驱动服务的事件信息能够被动态分发至对应的事件驱动服务,进而可以有效避免由单一事件驱动服务处理所有事件信息所导致的性能瓶颈,并降低因该单一事件驱动服务故障而影响整体事件处理链路的风险;同时,当业务场景变化时,仅需调整业务规则即可改变事件路由策略,能够提升系统的可扩展性,进而可以满足用户对业务规则的个性化需求或定制化需求。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN123020642A_ABST
    Figure CN123020642A_ABST
Patent Text Reader

Abstract

The present disclosure provides a business management method, an event processing method and an event processing platform thereof. The event processing method comprises: obtaining event information reported by an event source; determining a target event-driven service from an event-driven service based on the event information and a pre-stored business rule in a preset format; sending the event information to the target event-driven service to enable the target event-driven service to respond to the event information. Through the above implementation, various event information can be efficiently processed, and good compatibility and scalability are achieved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This disclosure relates to the field of security data processing, and in particular to a business management method, an event handling method, and an event handling platform thereof. Background Technology

[0002] In existing technologies, IoT (Internet of Things) devices, such as cameras, doorbells, and various sensors, can monitor changes in the surrounding environment in real time and trigger alarm actions when the detected changes meet preset conditions.

[0003] Alarm actions may include various types, such as push notifications or linked notifications.

[0004] The types of push notifications may include those from third-party ecosystems using public protocols, such as emails, SMS messages, or notifications containing only plain text information sent to a specified device; or push notifications from proprietary ecosystems using private protocols, such as emails, SMS messages, or notifications containing both plain text information and attached images sent to a specified device, or emails, SMS messages, or notifications containing both plain text information and audio information sent to a specified device.

[0005] The linkage types can include direct action triggering between devices, such as a change in the state of one device directly controlling the action performed by another device; they can also include scenario-based linkage, where multiple devices are simultaneously triggered to perform a series of coordinated actions based on a preset "scenario mode". Furthermore, the devices associated with the linkage type can include both third-party ecosystem devices and proprietary ecosystem devices.

[0006] Different third-party ecosystem devices may use different public protocols, and different proprietary ecosystem devices may use different private protocols.

[0007] As the number of devices and alarm actions involved in event information processing continues to increase, existing technologies can only support single alarm actions or single event-driven services handled by a single ecosystem device, which is no longer sufficient to meet people's growing personalized needs.

[0008] Therefore, there is an urgent need to provide an event processing method or platform that can efficiently process various event information. Summary of the Invention

[0009] To address the aforementioned technical problems, this disclosure provides a business management method, an event handling method, and an event handling platform that can efficiently process various event information and has good compatibility and scalability.

[0010] This disclosure provides an event processing method, the method comprising: acquiring event information reported by an event source; determining a target event-driven service from event-driven services based on the event information and pre-stored business rules in a preset format; and sending the event information to the target event-driven service to cause the target event-driven service to respond to the event information.

[0011] Optionally, the business rules include business types, different event-driven services correspond to business rules supporting different business types, the event information corresponds to at least one business rule, and determining the target event-driven service from the event-driven services based on the event information and pre-stored business rules in a preset format includes: determining the business type corresponding to the event information based on the event information and the business rules; and determining the target event-driven service from the event-driven services based on the business type.

[0012] Optionally, the event information includes first feature information, the business rule includes second feature information, and determining the business type corresponding to the event information based on the event information and the business rule includes: obtaining the first feature information in the event information; determining the business rule as a target business rule when the second feature information matches the first feature information in the business rule; and determining the business type in the target business rule as the business type corresponding to the event information.

[0013] Optionally, the business rule includes device information and subscription event information of the event source, the first feature information includes a first key value, and the second feature information includes a second key value generated based on the device information and the subscription event information. The step of determining the business rule as the target business rule when the second feature information matches the first feature information in the business rule includes: parsing the device information and subscription event information of the event source from the event information; generating the first key value based on the device information and the subscription event information; and determining the business rule as the target business rule when the second key value matches the first key value in the business rule.

[0014] This disclosure also provides a business rule management method, the method comprising: obtaining a first business rule and / or obtaining a second business rule from other services; parsing the first business rule and / or the second business rule, and converting them into business rules in a preset format; storing the business rules in the preset format to a data storage service, so as to determine a target event-driven service for responding to the event information from an event-driven service based on event information reported by an event source and the business rules.

[0015] Optionally, the method further includes: parsing the first business rule to obtain the event source and its subscribed events; generating a channel configuration instruction based on the event source and the subscribed events; sending the channel configuration instruction to the event source to activate the reporting channel of the event source corresponding to the subscribed events, wherein after the reporting channel is activated, the event source only reports the event information that satisfies the subscribed events.

[0016] Optionally, parsing the first business rule and / or the second business rule and converting it into a business rule of a preset format includes: parsing the first business rule and / or the second business rule; performing deduplication processing on the parsed first business rule and / or the second business rule; and converting the deduplicated first business rule and / or the second business rule into a business rule of the preset format; wherein, the deduplication processing includes deleting business rules in the first business rule and / or the second business rule that have the same event source, subscribed event, executor, and execution action.

[0017] This disclosure also provides an event processing service platform, the platform comprising: a data access layer for receiving event information reported by event sources; a data storage service for storing business rules in a preset format; and an event scheduling service for communicating with the data access layer and the data storage service, for obtaining the event information received by the data access layer, determining a target event-driven service from event-driven services based on the event information and the business rules in the preset format in the data storage service, and sending the event information to the target event-driven service so that the target event-driven service responds to the event information.

[0018] Optionally, the platform further includes the event-driven service, which communicates with the event scheduling service to receive the event information sent by the event scheduling service and respond to the event information according to the business rules corresponding to the event information.

[0019] Optionally, the event-driven service includes a first event-driven service and a second event-driven service, the second event-driven service communicating with the first event-driven service, wherein: the second event-driven service is used to generate a second business rule in response to a user's second configuration operation; the first event-driven service is used to generate a first business rule in response to a user's first configuration operation, obtain the second business rule generated by the second event-driven service, parse the first business rule and / or the second business rule, convert them into business rules in a preset format, and then store them in the data storage service.

[0020] Optionally, the data access layer includes data access nodes and a data caching component that communicate with each other. The data access nodes are used to receive the event information reported by the event source, and the data caching component is used to receive and cache the event information sent by the data access nodes. The event scheduling service communicates with the data caching component to obtain the event information from the data caching component.

[0021] Alternatively, the event scheduling service may read and process the event information sequentially based on the order in which the timestamps generated by the event information are generated.

[0022] Optionally, the business rules include subscription events and the priorities of the subscription events. The first event-driven service establishes a mapping relationship between the subscription events and priorities and stores it in the data storage service. The data access node communicates with the data storage service through the first event-driven service and obtains the mapping relationship. After receiving the event information, the data access node determines the priority of the subscription event corresponding to the event information based on the mapping relationship, appends the priority to the event information, and sends it to the data caching component for caching. The data caching component sorts the event information based on the timestamp of the event information and the priority. The event scheduling service schedules the event information according to the order of the timestamps of the event information, and when there is a high-priority event information, the high-priority event information is scheduled first.

[0023] Alternatively, the event processing platform may be deployed on network nodes and / or edge nodes.

[0024] Alternatively, the network node may include a cloud server.

[0025] Alternatively, the edge node may include a network video recorder and / or a hub.

[0026] Alternatively, the event source may include a hardware device and / or software system with networking capabilities, the hardware device may include an event processing service platform, and the software system may include a business system, middleware, a database, and / or a software interface.

[0027] Alternatively, the event processing service platform may include sensor devices, smart meters, cameras, doorbells, location tags, wearable devices, smart home appliances, smart office equipment, and / or vehicle terminals.

[0028] This disclosure also provides a computer-readable storage medium including instructions that, when loaded on a processor, cause the processor to perform the steps of any of the communication methods provided in this disclosure.

[0029] The business management methods, incident handling methods, and incident handling platform disclosed herein have the following beneficial effects:

[0030] By determining the target event-driven service based on event information and pre-formatted business rules, rule-based routing of event processing can be achieved. This allows event information corresponding to different event-driven services to be dynamically distributed to the corresponding services, effectively avoiding performance bottlenecks caused by a single event-driven service handling all event information and reducing the risk of affecting the entire event processing chain due to the failure of a single event-driven service. At the same time, when business scenarios change, only the business rules need to be adjusted to change the event routing strategy, which can improve the scalability of the system and thus meet users' personalized or customized needs for business rules. Attached Figure Description

[0031] Figure 1 This is a flowchart of an embodiment of the business rules management method disclosed herein;

[0032] Figure 2 This is a flowchart of another embodiment of the business rules management method disclosed herein;

[0033] Figure 3 This is a flowchart of an embodiment of the event handling method disclosed herein;

[0034] Figure 4 This is a flowchart of another embodiment of the event handling method disclosed herein;

[0035] Figure 5 This is a flowchart of another embodiment of the event handling method disclosed herein;

[0036] Figure 6 This is a schematic diagram of the structure of an embodiment of the event handling service system disclosed herein;

[0037] Figure 7 This is a schematic diagram of another embodiment of the event handling service system disclosed herein;

[0038] Figure 8 This is a schematic diagram of another embodiment of the event handling service system disclosed herein;

[0039] Figure 9 This is a schematic diagram of another embodiment of the event handling service system disclosed herein;

[0040] Figure 10 This is a schematic diagram of another embodiment of the event handling service system disclosed herein. Detailed Implementation

[0041] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0042] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, components, features, and elements with the same names in different embodiments of this disclosure may have the same meaning or different meanings, the specific meaning of which must be determined by its interpretation in that specific embodiment or further in conjunction with the context of that specific embodiment.

[0043] It should be understood that although the steps in the flowcharts of the embodiments of this disclosure are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some of the steps in the figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least a portion of the sub-steps or stages of other steps.

[0044] It should be noted that step designations such as 101 and 102 are used in this document to more clearly and concisely describe the corresponding content, and do not constitute a substantial restriction on the order. When implementing this document, those skilled in the art may execute 102 first and then 101, etc., but these should all be within the protection scope of this disclosure.

[0045] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this disclosure. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0046] The methods disclosed herein include those concerning the management and utilization of business rules.

[0047] In some embodiments, this disclosure provides a business rule management method, which can be executed by an event processing service platform, more specifically by a first event-driven service within that platform, see reference. Figure 1 The method may include:

[0048] 101, Obtain the first business rule.

[0049] The first business rule is generated by the first event-driven service in response to the user's first configuration operation. This first business rule can be a custom business rule within a proprietary ecosystem. It can include linkage rules and push rules. When it is a linkage rule, the first event-driven service can perform a validity check on the linkage rule. This check can include, for example, verifying the binding relationship of linked devices and verifying the device linkage capability.

[0050] Verifying the binding relationship of linked devices can include checking whether the event source and executor associated with the linkage rule are controlled within the same network space. The same network space can include physical network connection, logical domain connection, spatial location connection, or authentication authorization connection. Physical network connection can mean that the devices are connected to the same router and have the same IP subnet. Logical domain connection can mean that the devices belong to the same WLAN, VPN, or gateway. Spatial location connection can mean that the devices are marked with the same user ID, the same household, or the same room. Authentication authorization connection can mean that the devices hold valid tokens issued by the same authentication authority and have a mutual trust relationship.

[0051] Verifying the linkage capability of devices may include, for example, verifying whether the actuators associated with the linkage rules have the corresponding action capabilities.

[0052] Furthermore, the term "acquisition" as used in this disclosure can include both active acquisition and passive acquisition.

[0053] 102, Obtain the second business rule.

[0054] The second business rule is generated by the second event-driven service in response to the user's second configuration operation. The second business rule can be a business rule defined in a third-party ecosystem.

[0055] 103. Parse the first business rule and / or the second business rule, and convert the parsed first business rule and / or the second business rule into a business rule in a preset format.

[0056] Specifically, the original first business rule is converted into a first business rule of a preset format, and / or the original second business rule is converted into a second business rule of a preset format. 103 may include formatting the parsed first and / or second business rules to generate business rules of a preset format.

[0057] The first event-driven service is a service within the user-owned ecosystem. Users can programmatically define this service, and its business logic can be generated by users through scripts, rules, or workflows. Custom business rules can be configured through programming the first event-driven service. The second event-driven service can be either within the user-owned ecosystem or a third-party ecosystem. If the second event-driven service is from a third-party ecosystem, it is typically invoked through standard interfaces (such as APIs or SDKs). Users cannot program its business logic; they can only configure pre-defined business rules through the second event-driven service.

[0058] Since the first event-driven service is an internal service that can be programmably defined by the user within its own ecosystem, the first business rule generated by the first event-driven service can be configured to be a business rule in a preset format, or it can be configured to generate a business rule that is not in a preset format.

[0059] When the second event-driven service is also a user-programmable internal service within a proprietary ecosystem, the second business rules generated by the second event-driven service can be configured to be business rules in a preset format. Alternatively, the second business rules generated by the second event-driven service can be configured not to be business rules in a preset format. When the second event-driven service is an external service within a third-party ecosystem that is not user-programmable, the second business rules generated by it are typically not business rules in a preset format.

[0060] When there are business rules in the first business rule and the second business rule that do not conform to the preset format, you can use 103 to parse the business rules that do not conform to the preset format, and then format the parsed business rules to generate business rules in the preset format.

[0061] In section 103, the business rule can be parsed to generate an intermediate structure representation. Then, based on a preset format template or format requirements, this intermediate structure representation can be converted into a business rule in a preset format. The intermediate structure representation can be understood as a structured internal data object obtained after parsing the original information, which is independent of the original syntax and retains only the core semantic logic.

[0062] The intermediate structure of a business rule includes at least a trigger description, which may include one or more of the following: event source, subscribed event (i.e., trigger condition), and subscribed event type. Taking a linkage rule as an example, the structured internal data object represented by the intermediate structure may include one or more of the following: trigger description, execution action description, linkage binding relationship, filtering and transformation rules, and metadata. The execution action description may include one or more of the following: target event-driven service, executor, execution action, and action parameters. The linkage binding relationship may include association type and execution constraints. The association type may include one-to-one, one-to-many, or many-to-one trigger execution relationships, and the execution constraints may include parallel or serial execution order. The filtering and transformation rules may include data mapping and filtering conditions. Data mapping may include, for example, how data generated by the event source (such as device ID, temperature value) is filled into the parameter bits of the action (such as "{device name}" in the event notification content). Filtering conditions may include, for example, whether additional conditions need to be judged after the trigger condition is met (such as "linkage is only executed when the user level is VIP"). Metadata may include one or more of rule identifiers, status control, and exception handling. Rule identifiers may include rule ID, name, and / or version, etc. Status control may include one or more of enable / disable, priority, and effective time window, etc. Exception handling may include one or more of retry policies, timeouts, and degradation schemes when an action fails to execute.

[0063] 104, Store business rules in a preset format.

[0064] Pre-formatted business rules can be persisted to a data storage service, which includes a rules database, such as a MySQL database.

[0065] The above 101 to 104 can achieve standardized and unified management of the first business rules generated by services under the proprietary ecosystem, as well as the second business rules generated by services under the proprietary ecosystem or third-party ecosystem, which can effectively avoid the problem of chaotic management of different business rules.

[0066] In some embodiments, the first event-driven service can perform deduplication on business rules, that is, retain only one and delete redundant and duplicate business rules. Duplicate business rules refer to those business rules that have the same event source, subscribed event, executor, and execution action. This deduplication process can be performed in step 103 or step 104. In step 103, at least after parsing business rules that do not conform to the preset format, all business rules can be deduplicated first, and then the deduplicated business rules can be converted. In step 104, duplicate and redundant business rules in the preset format business rules are deduplicated. Through deduplication, the same event can be prevented from triggering the same action multiple times, avoiding resource waste and equipment malfunction. For example, the first business rule is to turn on fan 1 when temperature sensor 1 detects that the temperature reaches 30°C; the second business rule is also to turn on fan 1 when temperature sensor 1 detects that the temperature reaches 30°C; by deduplicating, the first event-driven service retains only one business rule, such as the first business rule or the second business rule, which can prevent the same event from triggering the same action multiple times.

[0067] In some embodiments, a first event-driven service responds to event information associated with a first business rule, and a second event-driven service responds to event information associated with a second business rule. When the second event-driven service is a service within a third-party ecosystem, this disclosure does not specifically discuss how the second event-driven service implements its response to event information. See also... Figure 2 The business rule management method executed by the first event-driven service may also include:

[0068] 201. Parse the first business rule to obtain the event source and its subscribed events.

[0069] 202, Configuration instructions for generating channels based on event sources and subscribed events.

[0070] 203. Send a channel configuration command to the event source to activate the reporting channel of the event source corresponding to the subscribed event.

[0071] Once the reporting channel is activated, the event source will only report event information that meets the requirements of the subscribed event.

[0072] By using commands 201-203, which send channel configuration instructions to the event source to open the reporting channel corresponding to the subscribed event, the event source only reports event information that users care about. Compared with the existing technology where the event source reports all event information and filters out the event information related to the subscribed event through a set intermediate service, this not only has better real-time performance, but also reduces resource consumption such as traffic and power consumption because the event source does not need to report irrelevant event information. It is especially suitable for battery-based event sources or data-based event sources such as cellular networks.

[0073] This disclosure also provides an event handling method, which mainly relates to a business rule scheduling method. This method can be executed by an event handling service platform, and more specifically by an event scheduling service within that platform. See reference [link to relevant documentation]. Figure 3 The method may include:

[0074] 301, Receive event information reported by the event source.

[0075] This event information typically includes event information associated with the subscribed event.

[0076] Event sources and actuators come in various types and typically possess networking capabilities to enable communication with the event processing platform described later. They can usually operate within a local area network (LAN) or wide area network (WAN). Event sources can include hardware devices, software systems, and time devices. Taking a hardware device as an example, the event source can sense changes in physical devices or their physical states. Taking a software system as an example, the event source can sense changes in software operation, data status, or business processes. Taking a time device as an example, the event source can sense changes in time.

[0077] For example, when the event source is a hardware device, it can include IoT (Internet of Things) devices. IoT devices include, but are not limited to, sensor devices, smart meters, cameras, doorbells, location tags, wearable devices, smart home appliances, smart office equipment, vehicle terminals, industrial controllers, and other terminal devices with data acquisition and / or data transmission capabilities. Taking sensor devices as an example, sensor devices can be used to collect environmental data, such as temperature, humidity, pressure, acceleration, and light intensity. These sensor devices can be smart sensors with built-in microcontrollers and communication modules, capable of directly reporting data over a network. Sensor devices can also be traditional sensors, connected to a gateway via wired or wireless means, with the gateway reporting the data collected by the sensor.

[0078] For example, when the event source is a software system, it can include business systems, middleware, databases, software interfaces, etc. For instance, when the event source is a business system or middleware, it can sense operations or state changes generated by the business system or middleware. For instance, when the event source is a database, it can sense database state changes, such as when the database is subjected to CRUD operations. For instance, when the event source is a network event source, it can sense interactions and operations performed by front-end or end-users on the network.

[0079] An actuator can perform defined actions and may include hardware devices or software systems. When an actuator includes hardware devices, it may also include the aforementioned IoT devices, such as the sensor devices, smart meters, cameras, doorbells, location tags, wearable devices, smart home appliances, smart office equipment, vehicle terminals, industrial controllers, and other terminal devices with data acquisition and / or data transmission capabilities. When an actuator includes software systems, it may also include the aforementioned business systems, middleware, databases, and software interfaces. In some embodiments, the identities of the event source and the actuator can be interchanged.

[0080] 302. Based on event information and pre-stored business rules in a preset format, determine the target event-driven service from the event-driven services.

[0081] Pre-stored business rules in a preset format refer to business rules in a preset format stored in the data storage service. The data storage service may include a rule database and a rule cache. The rule database stores business rules in a preset format, and the rule cache stores information associated with these business rules. The first event-driven service can determine the target event service based on the information related to the business rules in the preset format stored in the rule database or the rule cache. When determining the event based on the rule cache, the query or access speed is faster.

[0082] For the same subscribed event from the same event source, a user can configure multiple business rules. In this disclosure, "multiple" can include two or more. These multiple business rules may be configured to be processed by one event-driven service or by multiple event-driven services. Therefore, it is necessary to determine one or more event-driven services corresponding to the event information as the target event-driven service based on the event information and pre-stored business rules in a preset format.

[0083] 303, Send the event information to the target event-driven service so that the target event-driven service responds to the subscribed event.

[0084] By employing the aforementioned steps 301 to 303, subscribed events can be accurately distributed to appropriate event-driven services for execution or service. Specifically, by determining the target event-driven service based on event information and pre-formatted business rules, rule-based routing of event processing can be achieved. This allows event information corresponding to different event-driven services to be dynamically distributed to their respective services, effectively avoiding performance bottlenecks caused by a single event-driven service handling all event information and reducing the risk of impacting the entire event processing chain due to the failure of that single service. Furthermore, when business scenarios change, only the business rules need to be adjusted to change the event routing strategy, improving system scalability and thus meeting users' personalized or customized needs for business rules.

[0085] In some embodiments, the event scheduling service and the first event-driven service can be integrated into one service. For example, they can be integrated into the event scheduling service or into the first event-driven service.

[0086] In some embodiments, such as Figure 4 As shown, 302, which refers to determining the target event-driven service from event-driven services based on event information and pre-stored business rules, can include:

[0087] 311. Based on event information and pre-stored business rules in a preset format, determine the business type corresponding to the event information.

[0088] Different event-driven services typically support business rules for different business types. When configuring business rules through any event-driven service, the configured business rules can usually record the business types supported by that event-driven service.

[0089] Event information can reflect information such as the event source and subscribed events. Based on the event source and subscribed events, the corresponding business type can be matched from the pre-stored business rules in a preset format.

[0090] Table 1 provides examples of several business rules.

[0091]

[0092] The table above illustrates that business rules 1-4 are different business rules. Business rules 1-3 represent the same event source and the same subscribed event, but with different executors, execution actions, and business types. Among them, doorbell 1 and camera 1 are devices under the proprietary ecosystem, while warning light 1 is a device under the third-party ecosystem; the cloud server can be a device under either the proprietary ecosystem or the third-party ecosystem.

[0093] Business rules 1 and 2 utilize event-driven services from a third-party ecosystem. The corresponding business types accurately indicate that these two business rules are supported by IFTTT and PUSH event-driven services, respectively. When cloud server 1 is a device within the proprietary ecosystem, business rules 3 and 4 utilize event-driven services from the proprietary ecosystem. The corresponding business types indicate that these two business rules are supported by NATIVE 1 and NATIVE 2 event-driven services, respectively. Typically, at least one event-driven service from the proprietary ecosystem can serve as the first event-driven service, while others serve as second event-driven services. For example, among NATIVE 1 and NATIVE 2 event-driven services, either NATIVE 1 or NATIVE 2 can be the first event-driven service, or both can be used as the first event-driven service. Event-driven services from third-party ecosystems, such as IFTTT and PUSH, can serve as second event-driven services.

[0094] For example, when the event information shows that the event source is doorbell 1 and the subscription event is triggering the doorbell button, at least in the business rules shown in Table 1, business rules 1-3 can be matched with the event information, and the corresponding business types that can be matched include IFTTT, PUSH and NATIVE 1.

[0095] 312. Based on this business type, identify the target event-driven service from the event-driven services.

[0096] There is a natural mapping relationship between business types and event-driven services. By identifying the business type, the target event-driven service corresponding to that business type can be determined from all event-driven services. For example, if the business types include IFTTT, PUSH, and NATIVE 1, then the target event-driven services can be identified as IFTTT event-driven service, PUSH event-driven service, and NATIVE 1 event-driven service, respectively.

[0097] In some embodiments, the event information reported by the event source can be converted into a specific format, such as JSON, so that some parameters in the event information and the business rules in the preset format can be specified as feature information. See also Figure 5 The aforementioned 311, namely, determining the business type corresponding to the subscribed event based on event information and pre-stored business rules, may include:

[0098] 321, Obtain the first characteristic information from the event information.

[0099] 322. When the second feature information in a business rule matches the first feature information in an event, the business rule is determined to be the target business rule.

[0100] 323. Determine that the business types included in the target business rules are the business types corresponding to this event information.

[0101] The converted event information includes event source device information and event status values. The pre-formatted business rules include event source device information and subscribed events, where each subscribed event corresponds to an event status value, a range of event status values, or other conditions that can evaluate the event status value. In some embodiments, the event source can communicate directly with the event processing platform; in this case, the event source device information includes the event source device ID. In some embodiments, the event source communicates with the event processing service platform through relay devices such as NVRs (Network Video Recorders) or hubs; in this case, the event source device information may further include a channel ID, i.e., the relay device ID. For example, this ID can be at least one of a device ID, a service ID, and an application ID. Taking the device ID as an example, the device ID can be the device's physical address or serial number; the device ID can be the IP address assigned to the device when it accesses the network; or the device ID can be a unique identifier assigned by the IoT platform when registering the device.

[0102] Let's take business rule 1 in Table 1 as an example. Assume doorbell 1 represents the event source device information. The event status value logically corresponding to the trigger doorbell button for the subscribed event typically includes 0 and 1, where 0 represents the doorbell button not being triggered and 1 represents the doorbell button being triggered. The first characteristic information of the event source includes at least the event source device information and the event status value. Furthermore, the second characteristic information of the business rule includes the event source device information and the subscribed event information. Specifically, when the doorbell button of doorbell 1 is triggered, the event status value is 1. The event information reported by the event source, i.e., doorbell 1, includes the event source device information (doorbell 1) and the event status value (1). Therefore, querying the first characteristic information in the second characteristic information corresponding to business rules 1-4 in Table 1 will match business rules 1-3. Therefore, it can be determined that business rules 1-3 are all target business rules.

[0103] It is evident that the first feature information in an event information generated by an event source may match the second feature information of multiple business rules. That is, the event information may be able to match multiple business rules at the same time. Therefore, the target business rule determined in 323 should include all business rules that match the first feature information of the event information.

[0104] In some embodiments, the information in the business rule may include a key value, which may be generated based on the aforementioned feature information, such as event information from a specified event source and subscription event information. The above-mentioned 322, that is, when a second feature information in a business rule is found to match the first feature information in the event information, determining that the business rule is the target business rule, may include:

[0105] A first key value is generated based on the first feature information. Then, a query is performed in a pre-stored business rule with a preset format to see if there is a business rule whose key value matches the first key value. By generating the first key value and matching it with the key values ​​in the pre-stored business rule with the preset format to achieve the query, it is not necessary to match the first feature information with each parameter involved in the feature information one by one, which can significantly improve the query efficiency.

[0106] In the above embodiments, the first key value is generated by an intermediate service, such as the data access layer or event scheduling service described later. This intermediate service can make full use of the computing power of the intermediate service, is easy to manage, and has a low overall hardware cost. It is especially suitable for use scenarios where some event sources, such as sensors, do not have data processing capabilities.

[0107] In other embodiments, the first key value can also be generated by the event source. For example, in 301, the event information reported by the event source includes the first key value generated by the event source based on the first feature information in the event information. Although there are hardware performance requirements because each event source needs to have a certain data processing capability, it can overcome the performance bottleneck of a single node by sharing tasks among multiple nodes, and adapt to the use scenario of massive concurrent devices.

[0108] This disclosure also provides an event service processing system. For example... Figure 6 As shown, the system includes an event processing service platform 10, and an event source 20, an actuator 30, and a user terminal 40 that are respectively connected to the event processing service platform 10.

[0109] See Figure 7The event processing service platform 10 may include a data access layer 11, a data storage service 12, and an event scheduling service 13, and may further include an event-driven service. The event-driven service may include a first event-driven service 14, and may further include a second event-driven service 15. An event source 20 is communicatively connected to the data access layer 11. After detecting an event and subscribing to it, the event source 20 reports the event information to the data access layer 11. The event scheduling service 13 is communicatively connected to both the data access layer 11 and the data storage service 12. The data storage service 12 stores business rules in a preset format. The event scheduling service 13 obtains event information from the data access layer 11 and, based on the event information and the preset format business rules in the data storage service 12, determines a target event-driven service from among the event-driven services. The event scheduling service 13 also communicates with the first event-driven service 14 and the second event-driven service 15 to send the event information to the target event-driven service, so that the target event-driven service responds to the event information.

[0110] The target event-driven service may include a first event-driven service 14 and / or a second event-driven service 15. The target event-driven service can obtain the executor 30 and its corresponding execution action from the business rules corresponding to the event information. The target event-driven service can then control the executor 30 to execute the corresponding execution action to respond to the event information or the corresponding subscribed event. Typically, the target event-driven service can control the executor 30 to execute the corresponding execution action through its own driver 142. For example, based on the event information and the target business rules, the target event-driven service can obtain the executor 30 and its corresponding execution action, and then send the corresponding execution action to the executor 30 through the driver 142.

[0111] For example, taking the business rule 1 in the event information correspondence table 1 as an example, and the response of the IFTTT event-driven service, the IFTTT event-driven service can obtain that the actuator 30 is the warning light 1 and the execution action is the flashing of the light. Therefore, the IFTTT event-driven service can directly or indirectly control the warning light 1 to flash.

[0112] For example, taking the business rule 3 in the event information correspondence table 1 as an example, and the response of the NATIVE 1 event-driven service, the NATIVE 1 event-driven service can obtain that the executor 30 is camera 1 and the action to be performed is to start recording. Therefore, the NATIVE 1 event-driven service can directly or indirectly control camera 1 to start recording.

[0113] In some embodiments, the event scheduling service 13 can communicate directly with the data storage service 12. Alternatively, the event scheduling service 13 can communicate with the data storage service 12 via the first event-driven service 14, such as... Figure 7 As shown. In some embodiments, the business rules in the preset format stored in the data storage service 12 originate from the parsing and conversion of various business rules configured by the user through the user terminal 40 and instructing different event-driven services by the first event-driven service 14. In some embodiments, the first event-driven service 14 is also communicatively connected to the second event-driven service 15 to obtain the business rules configured through the second event-driven service 15, and to parse and convert them into business rules in the preset format.

[0114] In some embodiments, see Figure 8 The data access layer 11 includes a data access node 111 and a data caching component 112 that is communicatively connected to the data access node. The data access node 111 obtains event information from the event source 20 and stores it in the data caching component 112. Before storing the event information in the data caching component 112, the data access node 111 can format the event information, for example, by converting it into the JSON format described above, to facilitate subsequent data processing and analysis.

[0115] In some embodiments, the data caching component 112 can store event information for sequential processing by the event scheduling service 13, ensuring reliability. The data caching component 112 may include, for example, a message queue, such as KafkaMQ, RabbitMQ, or RocketMQ. In some embodiments, the event information stored in the data caching component 112 can be configured with an expiration period; expired and unprocessed event information can be deleted. In some embodiments, the event information stored in the data caching component 112 can be configured with an expiration period based on the priority of its corresponding subscribed event. High-priority event information can be configured with a longer expiration period, while low-priority event information can be configured with a shorter expiration period, ensuring that high-priority event information is processed reliably.

[0116] In some embodiments, see Figure 9 The first event-driven service 14 includes a parser 141 and a driver 142. The parser 141 can receive, parse, and transform the first and second business rules. Specifically, the parser 141 parses the first business rule to obtain the event source 20 and the subscribed event, and generates a channel configuration instruction based on the event source 20 and the subscribed event. After obtaining the channel configuration instruction, the driver 142 sends the instruction to the corresponding event source 20 to control the event source 20 to activate the reporting channel for the corresponding subscribed event.

[0117] The parser 141 of the first event-driven service 14 is further configured to obtain event information of subscription events related to the first business rule reported by the event source 20, parse the event information to determine the corresponding first business rule, and then generate a control instruction corresponding to the event information based on the first business rule. The control instruction includes an executor 30 and an execution action. The driver 142 of the first event-driven service 14 obtains the control instruction and sends it to the executor 30 to control the executor 30 to execute the corresponding execution action. The control instruction may further include action parameters; the driver 142 sends the control instruction to the executor 30 to control the executor 30 to execute the corresponding execution action according to the action parameters.

[0118] Of course, the second event-driven service 15 also includes a parser 141 and a driver 142, but both are mainly used to process the second business rules and their corresponding event information.

[0119] In some embodiments, the modules in the event processing service platform 10, such as the data access layer 11, event scheduling service 13, event-driven service, and data storage service 12, can be deployed on one or more computing nodes. The event-driven service mainly includes a first event-driven service 14 under its own ecosystem, and optionally, may also include a second event-driven service 15. These computing nodes can include one or more of network nodes and edge nodes. Among them, network nodes include cloud servers, and edge nodes include NVRs, hubs, or edge servers. For example, the data access layer 11, event scheduling service 13, first event-driven service 14, and data storage service 12 can be deployed on the same network node, such as on a cloud server. As another example, the data access layer 11, event scheduling service 13, first event-driven service 14, and data storage service 12 can be deployed on the same edge node, such as on an NVR or hub. In this case, it is suitable for low-latency, weak network scenarios.

[0120] Communication between event source 20, actuator 30, and computing nodes, as well as between computing nodes, can be achieved through wired or wireless connections. Wired connections are established via physical cables, such as Ethernet, USB, or industrial bus networks. Ethernet networks include twisted-pair cables or fiber optic cables, while industrial bus networks include CAN, RS-232, RS-485, or Modbus buses. Wireless connections are established via electromagnetic or light waves, and can include short-range wireless (such as Wi-Fi, Bluetooth, ZigBee, Thread, Z-Wave, NFC, or UWB), cellular mobile communication (such as 2G, 3G, 4G, 5G, NB-IoT (Narrowband Internet of Things), or LTE-M), or satellite communication.

[0121] In one example, when the data access layer 11, event scheduling service 13, first event-driven service 14 and data storage service 12 are deployed on the same computing node, the same network node or the same edge node, the event source 20, the executor 30 and the computing node can be wirelessly connected, such as through Wi-Fi, Bluetooth, ZigBee or cellular mobile communication.

[0122] In some embodiments, the data caching component 112 of the data access layer 11 can cache event information to transform sudden event receiving pressure into stable and predictable event processing traffic, thereby ensuring the stability and reliability of the entire event service processing system.

[0123] The event information generated by event source 20 includes a timestamp. Data caching component 112 can sort the event information according to the timestamp in chronological order. Within the same data caching component 112, when scheduling event information, event scheduling service 13 can read and process the event information sequentially from data caching component 112 according to the order of timestamps or the order in which data caching component 112 sorts the information. That is, the event information corresponding to an earlier subscribed event will be processed earlier.

[0124] In some embodiments, different subscribed event types may have different priorities. Different priorities typically indicate varying degrees of urgency or importance of the events, with higher-priority subscribed event types often requiring a faster response. When one or more event sources 20 monitor multiple subscribed event types, these events may occur simultaneously or sequentially within a very short interval, resulting in corresponding event information having the same or similar timestamps. If these event information with the same or similar timestamps are processed sequentially without considering their corresponding priorities, higher-priority event information may be delayed or not scheduled by the event scheduler. One reason for delayed or unscheduled scheduling may include delays in the event scheduling service 13, the event-driven service, or the executor 30 itself when processing or responding to event information, leading to delays or expiration of the event information. However, delayed or unscheduled scheduling of higher-priority event information can easily lead to undesirable risks. For example, event source 20 may detect a disaster, such as a fire, earthquake, or flood, but miss the optimal disaster avoidance opportunity because the event information is delayed or not scheduled.

[0125] In some embodiments, event source 20 can monitor events such as fire, explosion, earthquake, flood, mudslide, vehicle passage, people loitering, number of people, population density, items left behind, temperature, and humidity. Subscribed event types can correspond to the detection of events such as fire, explosion, earthquake, flood, mudslide, vehicle passage, people loitering, number of people, population density, items left behind, abnormal temperature, and abnormal humidity. For ordinary users, the priority of subscribed event types such as fire, explosion, earthquake, flood, and mudslide is higher than that of subscribed event types such as vehicle passage, people loitering, number of people, population density, items left behind, abnormal temperature, and abnormal humidity. Under the two-level priority classification, subscribed event types such as fire, explosion, earthquake, flood, and mudslide can be configured as high priority, while subscribed event types such as vehicle passage, people loitering, number of people, population density, items left behind, abnormal temperature, and abnormal humidity can be configured as low priority. This disclosure provides several methods to ensure that higher-priority subscribed event types are scheduled and processed more preferentially than lower-priority subscribed event types.

[0126] In some embodiments, the business rules themselves can be configured to include priorities corresponding to the subscription event types. Users can specify priorities for the subscription event types associated with the corresponding business rules when configuring business rules through the first event-driven service 14 or the second event-driven service 15. Business rules associated with subscription event types and their corresponding priorities can be processed by the first event-driven service 14 into business rules of a preset format, and then stored in the data storage service 12.

[0127] In some embodiments, the business rules themselves may not be configured to include the priority corresponding to the subscription event type. However, after configuring at least some business rules through the first event-driven service 14 or the second event-driven service 15, the user can specify the priority for the subscription event type associated with those at least some business rules. In one embodiment, the first event-driven service 14 can obtain business rules in a preset format from the data storage service 12, all of which are associated with subscription event types. The first event-driven service 14 can provide a user configuration interface that can receive the priority specified by the user for at least some subscription event types. The first event-driven service 14 can be configured to establish a mapping relationship between subscription event types and their corresponding priorities, and store the mapping relationship in the data storage service 12. Optionally, the mapping relationship may also include an event source, a subscription event type, and its corresponding priority.

[0128] This user configuration interface provides users with a variety of options for configuration. Users can configure the mapping relationship according to their actual needs, including the subscription event type and its corresponding priority, or the mapping relationship including the event source, the subscription event type and its corresponding priority.

[0129] For example, the user configuration interface can provide a list of business rules, where the event sources and / or subscription event types associated with each business rule can be displayed. Users can choose to configure priorities for at least a portion of the subscription event types associated with the business rules, or users can choose to configure priorities for at least a portion of the event sources and subscription event types associated with the business rules.

[0130] For example, the user configuration interface can provide a list of event sources, where each event source can be associated with an event source and / or a subscription event type. Users can choose to configure priorities for subscription event types associated with at least one event source. In some embodiments, different event sources or business rules may be associated with the same subscription event type, and users can specify different priorities for the same subscription event type corresponding to different event sources or business rules.

[0131] For example, the user configuration interface can provide a list of subscription event types. This means the interface can retrieve all subscription event types corresponding to all business rules, generate and display a list of subscription event types for user configuration. Users can specify the priority of at least some of the subscription event types in the list. In this configuration, users don't need to care about the business rules or event sources corresponding to the subscription event types; they only need to care about the subscription event types themselves, that is, specifying priorities based solely on the different considerations of the subscription event types themselves.

[0132] Users are not required to specify a priority for each subscription event type corresponding to each business rule or event source. Subscription event types that are not specified with a priority can be configured to low priority by default.

[0133] For example, priorities can be represented in various forms. When priorities are configured as a three-level category, they can be represented by words such as "high," "medium," and "low." Priorities can also be represented by characters such as "S," "A," and "B," which represent high, medium, and low, respectively. Priorities can also be represented by numbers such as "1," "2," and "3," or by a combination of characters such as "#1," "#2," and "#3," all of which represent high, medium, and low, respectively. In other embodiments, users can also configure more levels of priority according to actual needs. The more priority levels there are, the better it ensures that more important event information is scheduled or responded to first.

[0134] In some embodiments, the data access node 111 can communicatively connect to the first event-driven service 14. The data access node 111 can obtain the mapping relationship from the data storage service 12 through the first event-driven service 14. The data access node 111 can preset subscription event type judgment rules. After obtaining event information reported by the event source 20, the data access node 111 can determine the subscription event type corresponding to the event information based on at least one of the fields such as event source device information, event type, and event status value in the event information, combined with the subscription event type judgment rules. Furthermore, the data access node 111 can determine the priority of the event information based on the obtained mapping relationship and the determined subscription event type. After the data storage service 12 obtains the event information including the priority, it can sort the event information from high to low priority, and the event scheduling service 13 can prioritize the scheduling of event information with higher priority.

[0135] In some embodiments, to alleviate event processing pressure, multiple event scheduling services 13 and multiple data access layers 11 can be configured. The number of event scheduling services 13 and data access layers 11 can be the same. For example, the event scheduling service 13 includes a first event scheduling service 13 and a second event scheduling service 13, and the data access layer 11 includes a first data access layer 11 and a second data access layer 11. The first data access layer 11 is communicatively connected to the first event scheduling service 13, and the second data access layer 11 is communicatively connected to the second event scheduling service 13. Both the first and second data access layers 11 include mutually communicatively connected data access nodes 111 and data caching components 112. Multiple event sources 20, such as multiple IoT event sources 20, can be divided into multiple groups, for example, two groups, with one group of event sources 20 communicatively connected to the first data access layer 11 and the other group of event sources 20 communicatively connected to the second data access layer 11.

[0136] In some embodiments, event sources 20 can be grouped based on their attribute information. For example, event sources 20 can be grouped according to their type, such as hardware devices as one group, software systems as another, or cameras and doorbells as one group, and sensors as another. Alternatively, event sources 20 can be grouped according to their geographical location, such as by country or region, including network locations like IP addresses or spatial locations like GPS locations. Furthermore, event sources 20 can be grouped according to their quantity, such as dividing them into multiple groups on an even scale.

[0137] In some embodiments, when the data access layer 11, event scheduling service 13, and first event-driven service 14 are deployed on the same computing node—for example, on the same NVR, hub, or cloud server—at least one network channel may be available between the computing node and the executor 30. In some embodiments, more than two network channels may be available between the computing node and the executor 30, including wired and wireless network channels. In some embodiments, the computing node provides a first network channel and a second network channel. The first network channel has lower latency than the second network channel. Assuming event information has low, medium, and high priorities, when the event-driven service obtains event information and determines that it belongs to a high-priority event, it can select the first network channel from the first and second network channels to communicate with the executor 30. Conversely, when the event-driven service obtains event information and determines that it belongs to a medium or low-priority event, it can select the second network channel from the first and second network channels to communicate with the executor 30. By providing a low-latency network channel to high-priority event information, it is possible to ensure that high-priority event information is responded to more promptly. In some embodiments, the computing node and the event source 20 may also include at least one network channel, which may be the aforementioned wired network channel and wireless network channel, and will not be described again here.

[0138] For example, this disclosure may provide an NVR that can integrate all or at least some of the functions of the event processing service platform 10. For instance, the NVR may integrate at least the event scheduling service 13, the first event-driven service 14, and the data storage service 12.

[0139] For example, this disclosure may provide a hub that integrates all or at least some of the functions of the event processing service platform 10. For instance, the hub may integrate at least the event scheduling service 13, the first event-driven service 14, and the data storage service 12.

[0140] In some embodiments, the event source 20 and the data access node 111 in the data access layer 11 can communicate using either a long connection or a short connection. When the event source 20 is an IoT device, and it is being powered externally (e.g., connected to mains power or connected to an energy storage device such as a power bank or solar panel), a long connection can be used between the event source 20 and the data access point. The advantage of a long connection is that when the event source 20 reports event information, there is less latency because multiple handshakes are not required. When the event source 20 relies solely on its internal battery for power, especially when the expected event trigger frequency is low (e.g., below a certain threshold), a short connection can be used between the event source 20 and the data access point. In such scenarios, the advantage of a short connection is that it saves energy, allowing the event source 20 to operate for a longer period. For example, when the event source 20 is a network camera deployed in the field, due to inconvenient power access and low event trigger frequency, using a short connection between the event source 20 and the data access point can extend the network camera's operating time.

[0141] The connection mode between event source 20 and data access point is configurable, including the aforementioned long connection and short connection. In some embodiments, the first event-driven service 14 can specify the connection mode in the first business rule according to user configuration operations, and / or the second event-driven service 15 can specify the connection mode in the second business rule according to user configuration operations. In some embodiments, the first event-driven service 14 and / or the second event-driven service 15 can automatically configure the connection mode in the corresponding business rule according to at least one of the power supply status of event source 20, the estimated trigger frequency of specified subscribed events, and the urgency level of specified subscribed events. Of course, the automatically configured connection mode can be re-specified by the user to meet the user's actual needs.

[0142] In some embodiments, the first event-driven service 14 generates a first business rule in response to a first configuration operation performed by a user through a user terminal 40, which may include a terminal device such as a mobile phone, tablet, personal digital assistant, or computer. The second event-driven service 15 generates a second business rule in response to a second configuration operation performed by a user through the user terminal 40. The first event-driven service 14 may include a storage service for storing the first business rule. The second event-driven service 15 may also include a storage service for storing the second business rule. The storage service may be an internal storage service of each event-driven service, or an external data storage service 12, or both.

[0143] The first event-driven service 14 acquires a first business rule it generates itself, and also acquires a second business rule generated from an external source, such as the second event-driven service 15. The first event-driven service 14 further parses at least one of the first and second business rules. The first event-driven service 14 further converts at least one of the parsed first and second business rules into a business rule of a preset format. This conversion process involves formatting the first and / or second business rules to generate a business rule of the preset format. The parsing and conversion by the first event-driven service 14 primarily targets business rules that are not initially in a preset format; these rules could be either the first or second business rule. For the sake of brevity, exemplary parsing and conversion processes that the first event-driven service 14 can implement are not described here; please refer to the preceding sections of this disclosure.

[0144] The first event-driven service 14 also stores business rules in a preset format to a storage service, such as the data storage service 12.

[0145] In some embodiments, when determining a target event-driven service, the first event-driven service 14 can determine the business type corresponding to the event information based on the event information and pre-stored business rules in a preset format. Then, since there is a natural mapping relationship between the pre-established business types and event-driven services, the first event-driven service 14 can determine the target event-driven service from the event-driven services based on the business type.

[0146] More specifically, when determining the business type corresponding to a subscribed event, the first event-driven service 14 can do so in the following way:

[0147] First, retrieve the first characteristic information from the event information. Then, in the business rules, query whether there exists a business rule whose second characteristic information matches the first characteristic information in the event information. If it exists, determine that this business rule is the target business rule; otherwise, determine that there is no target business rule in the business rules. After determining the target business rule, it can be determined that the business type included in the target business rule is the business type corresponding to the event information.

[0148] In some embodiments, see Figure 10The data storage service 12 can provide a rule database 121 and a rule cache 122. The rule database 121 is used to persistently store business rules in a preset format, such as using disk storage media. The rule cache 122 is used to store simplified information obtained by parsing the business rules in the preset format. This simplified information may include, for example, event source information, subscribed event information, and executor information corresponding to the event source information. The event source information may include, for example, event source 20, and the executor information may include, for example, the action subject and the execution action. The rule cache 122 can be stored using in-memory storage media, or it can be implemented using a Redis database, which has high read / write performance, rich data structures, and supports expiration policies and publish / subscribe capabilities. Adapting to the business rule cache 122 facilitates user querying and event identification. The event scheduling service 13 prioritizes reading data from the rule cache 122 during runtime, only accessing the rule database 121 when the cache misses. The configuration of the rule cache 122 can speed up the response to event information, essentially responding to the subscribed events corresponding to that event information.

[0149] The first event-driven service 14 can operate on the rule cache 122.

[0150] In some embodiments, data in the rule cache 122 may be lost when the data storage service 12 is powered off and restarted. The first event-driven service 14 loads all business rules from the rule database 121, parses these business rules, and then stores the simplified information obtained after parsing in the rule cache 122.

[0151] In some embodiments, when the data storage service 12 is running, the first event-driven service 14 can perform corresponding operations on the rule cache 122 based on the real-time changes in the business rules in the rule database 121. For example, when a new business rule is added to the rule database 121, the first event-driven service 14 does not operate on the rule cache 122. As another example, when a business rule is deleted or modified in the rule database 121, the first event-driven service 14 can synchronously parse the deleted or modified business rule to obtain the event source 20 associated with that business rule. Then, based on the obtained event source 20, the first event-driven service 14 can delete all simplified information associated with that event source 20 from the rule cache 122. This stops invalid business logic and prevents deleted or modified business rules in the rule database 121 from being incorrectly executed due to cache residue, thus preventing inconvenience to users.

[0152] In some embodiments, after the event scheduling service 13 obtains the event information reported by the event source 20, it searches the rule cache 122 through the first event-driven service 14. If the first event-driven service 14 finds the event source 20 in the rule cache 122, it updates the validity period of the simplified information associated with the event source 20. If the first event-driven service 14 does not find the event source 20 in the rule cache 122, it locks and rebuilds all caches associated with the event source 20 in the rule cache 122. This locking and rebuilding process may include: obtaining a distributed lock corresponding to the event source 20; loading all business rules associated with the event source 20 from the rule database 121; parsing these business rules to generate simplified information, writing it to the rule cache 122 and setting its validity period; and releasing the distributed lock. The first event-driven service 14 may also delete expired simplified information from the rule cache 122 according to the validity period of the set or updated simplified information. For example, the validity period may be configured to be valid for 30 days. Among them, by configuring timeliness, frequently used rules can be kept running to improve response efficiency, and less frequently used rules can be eliminated to free up resources.

[0153] All the above-described technical solutions can be combined in any way to form optional embodiments of this disclosure, and will not be described in detail here. Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0154] Therefore, embodiments of this disclosure provide a computer-readable storage medium storing a plurality of computer programs that can be loaded by a processor to execute steps in any of the communication methods provided in embodiments of this disclosure. For example, the computer program can execute the following steps:

[0155] Obtain event information reported by the event source; based on the event information and pre-stored business rules in a preset format, determine the target event-driven service from the event-driven services; send the event information to the target event-driven service so that the target event-driven service responds to the event information.

[0156] Therefore, embodiments of this disclosure provide a computer-readable storage medium storing a plurality of computer programs that can be loaded by a processor to execute steps in any of the communication methods provided in embodiments of this disclosure. For example, the computer program can execute the following steps:

[0157] Obtain a first business rule and / or a second business rule from other services; parse the first business rule and / or the second business rule, and convert them into business rules in a preset format; store the business rules in the preset format to a data storage service so that, based on the event information and business rules reported by the event source, the target event-driven service for responding to the event information can be determined from the event-driven services.

[0158] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0159] The storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0160] Since the computer program stored in the storage medium can execute the steps of any of the communication methods provided in the embodiments of this disclosure, the beneficial effects that any of the communication methods provided in the embodiments of this disclosure can achieve can be realized, as detailed in the preceding embodiments, and will not be repeated here.

[0161] This disclosure also provides an event processing service platform, including a memory and a processor. The memory stores a computer program, and the processor retrieves and runs the computer program from the memory, causing a device with a chip installed to perform the methods described in the various possible implementations above.

[0162] The steps in the method of this disclosure can be adjusted, combined, or deleted according to actual needs. The modules in the device of this disclosure can be combined, divided, or deleted according to actual needs.

[0163] The technical features of this disclosure can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this disclosure.

[0164] The foregoing has provided a detailed description of an event processing service platform and its communication method, as well as a computer-readable storage medium, provided by embodiments of this disclosure. Specific examples have been used to illustrate the principles and implementation methods of this disclosure. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this disclosure. At the same time, those skilled in the art will recognize that there will be changes in the specific implementation methods and application scope based on the ideas of this disclosure. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. An event handling method, characterized in that, The method includes: Obtain event information reported by the event source; Based on the event information and pre-stored business rules in a preset format, the target event-driven service is determined from the event-driven services; The event information is sent to the target event-driven service so that the target event-driven service responds to the event information.

2. The method according to claim 1, characterized in that, The business rules include business types, and different event-driven services correspond to business rules supporting different business types. Each event information corresponds to at least one business rule. The process of determining a target event-driven service from the event-driven services based on the event information and pre-stored business rules in a preset format includes: Based on the event information and the business rules, the business type corresponding to the event information is determined; Based on the business type, the target event-driven service is determined from the event-driven services.

3. The method according to claim 2, characterized in that, The event information includes first feature information, the business rule includes second feature information, and determining the business type corresponding to the event information based on the event information and the business rule includes: Obtain the first feature information from the event information; When the second feature information is found to match the first feature information in the business rule, the business rule is determined to be the target business rule. The business type in the target business rule is determined to be the business type corresponding to the event information.

4. The method according to claim 3, characterized in that, The business rule includes device information and subscription event information of the event source. The first feature information includes a first key value, and the second feature information includes a second key value generated based on the device information and subscription event information. When the second feature information matches the first feature information in the business rule, the business rule is determined to be the target business rule, including: The device information and subscribed event information of the event source are obtained by parsing the event information; The first key value is generated based on the device information and the subscription event information; When the second key value is found to match the first key value in the business rule, the business rule is determined to be the target business rule.

5. A business rule management method, characterized in that, The method includes: Obtain the first business rule and / or obtain the second business rule from other services; Parse the first business rule and / or the second business rule, and convert them into business rules in a preset format; The business rules in the preset format are stored in the data storage service so that, based on the event information reported by the event source and the business rules, a target event-driven service for responding to the event information can be determined from the event-driven service.

6. The method according to claim 5, characterized in that, The method further includes: Parse the first business rule to obtain the event source and its subscribed events; Based on the event source and the subscription event generation channel configuration instructions; The channel configuration instruction is sent to the event source to activate the reporting channel of the event source corresponding to the subscribed event. After the reporting channel is activated, the event source only reports the event information that satisfies the subscribed event.

7. The method according to claim 5, characterized in that, The step of parsing the first business rule and / or the second business rule and converting it into a business rule of a preset format includes: Parse the first business rule and / or the second business rule; The parsed first business rule and / or second business rule are deduplicated; Convert the deduplicated first business rule and / or second business rule into a business rule in the preset format; The deduplication process includes deleting business rules from the first business rule and / or the second business rule that have the same event source, subscribed event, executor, and execution action.

8. An event processing service platform, characterized in that, The platform includes: The data access layer is used to receive event information reported by event sources; Data storage service, used to store business rules in a preset format; An event scheduling service communicates with the data access layer and the data storage service to obtain the event information received by the data access layer. Based on the event information and the business rules in the data storage service in a preset format, it determines a target event-driven service from the event-driven services and sends the event information to the target event-driven service so that the target event-driven service responds to the event information.

9. The platform according to claim 8, characterized in that, The platform also includes the event-driven service, which communicates with the event scheduling service to receive the event information sent by the event scheduling service and respond to the event information according to the business rules corresponding to the event information.

10. The platform according to claim 9, characterized in that, The event-driven service includes a first event-driven service and a second event-driven service, wherein the second event-driven service communicates with the first event-driven service, and: The second event-driven service is used to generate a second business rule in response to a user's second configuration operation; the first event-driven service is used to generate a first business rule in response to a user's first configuration operation, obtain the second business rule generated by the second event-driven service, parse the first business rule and / or the second business rule, convert them into business rules in a preset format, and then store them in the data storage service.

11. The platform according to claim 8, characterized in that, The data access layer includes data access nodes and a data caching component that communicate with each other. The data access nodes are used to receive the event information reported by the event source, and the data caching component is used to receive and cache the event information sent by the data access nodes. The event scheduling service communicates with the data caching component to obtain the event information from the data caching component.

12. The platform according to claim 11, characterized in that, The event scheduling service reads and processes the event information sequentially based on the order in which the timestamps generated by the event information are generated.

13. The platform according to claim 11, characterized in that, The business rules include subscription events and their priorities. The first event-driven service establishes a mapping relationship between the subscription events and their priorities and stores it in the data storage service. The data access node communicates with the data storage service through the first event-driven service and obtains the mapping relationship. After receiving the event information, the data access node determines the priority of the subscription event corresponding to the event information based on the mapping relationship, appends the priority to the event information, and sends it to the data caching component for caching. The data caching component sorts the event information based on the timestamp and the priority. The event scheduling service schedules the event information according to the order of its timestamps, and prioritizes scheduling the event information with higher priority when a higher priority event information exists.

14. The platform according to claim 8, characterized in that, The event processing platform is deployed on network nodes and / or edge nodes.

15. The platform according to claim 14, characterized in that, The network nodes include cloud servers.

16. The platform according to claim 14, characterized in that, The edge nodes include network video recorders and / or hubs.

17. The platform according to claim 8, characterized in that, The event source includes hardware devices and / or software systems with network connectivity. The hardware devices include an event processing service platform, and the software systems include business systems, middleware, databases, and / or software interfaces.

18. The platform according to claim 17, characterized in that, The event processing service platform includes sensor devices, smart meters, cameras, doorbells, location tags, wearable devices, smart home appliances, smart office equipment, and / or vehicle terminals.

19. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes instructions that, when loaded on a processor, cause the processor to perform the method as described in any one of claims 1-7.