Event processing method and device and electronic equipment

Abstract

The embodiment of the invention discloses an event processing method and device and electronic equipment. The event processing method comprises the following steps: receiving and storing a business event through a business queue, and providing the business event for an event consumer through the business queue; the business event comprises a source event and a sub-event triggered according to the source event; receiving and storing an execution result of the business event returned by the event consumer through a state queue; and consuming the state queue, and determining the execution state of the source event based on the obtained execution result of the source event and / or the execution result of the corresponding sub-event.

Description

Technical Field

[0001] This document relates to the field of computer technology, and in particular to an event processing method, device and electronic device. Background Art

[0002] Events between different applications are usually transmitted through message middleware. Existing message middleware, such as Kafka and Rocket MQ, simply provide a channel for message transmission and lack the function of tracking event status in event cascade scenarios.

[0003] Therefore, there is an urgent need for a solution that can track the event status in event cascade scenarios. Summary of the invention

[0004] The embodiments of this specification aim to provide an event processing method, device and electronic device for accurately tracking the event status in an event cascade scenario.

[0005] In order to achieve the above purpose, the embodiments of this specification adopt the following technical solutions:

[0006] In a first aspect, an event processing method is provided, which is applied to event middleware, and the method comprises:

[0007] Receiving and storing business events through a business queue, and providing the business events to event consumers through the business queue; the business events include source events and sub-events triggered by the source events;

[0008] Receive and store the execution result of the business event returned by the event consumer through the state queue;

[0009] The state queue is consumed, and the execution state of the source event is determined based on the acquired execution result of the source event and / or the execution result of the corresponding sub-event.

[0010] In a second aspect, an event processing device is provided, which is applied to event middleware, and the device includes:

[0011] A processing unit, configured to receive and store business events through a business queue, and provide the business events to event consumers through the business queue; the business events include source events and sub-events triggered by the source events;

[0012] A storage unit, used for receiving and storing the execution result of the business event returned by the event consumer through a state queue;

[0013] The consumption unit is used to consume the state queue and determine the execution state of the source event based on the acquired execution result of the source event and / or the execution result of the corresponding sub-event.

[0014] According to a third aspect, an electronic device is provided, including:

[0015] Processor; and

[0016] a memory arranged to store computer executable instructions which, when executed, cause the processor to:

[0017] Receiving and storing business events through a business queue, and providing the business events to event consumers through the business queue; the business events include source events and sub-events triggered by the source events;

[0018] Receive and store the execution result of the business event returned by the event consumer through the state queue;

[0019] The state queue is consumed, and the execution state of the source event is determined based on the acquired execution result of the source event and / or the execution result of the corresponding sub-event.

[0020] In a fourth aspect, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores one or more programs, and when the one or more programs are executed by an electronic device including a plurality of application programs, the electronic device performs the following operations:

[0021] Receiving and storing business events through a business queue, and providing the business events to event consumers through the business queue; the business events include source events and sub-events triggered by the source events;

[0022] Receive and store the execution result of the business event returned by the event consumer through the state queue;

[0023] The state queue is consumed, and the execution state of the source event is determined based on the acquired execution result of the source event and / or the execution result of the corresponding sub-event.

[0024] The solution of the embodiments of this specification develops an event middleware with a unified external interface and rich event-based communication mechanism. The event middleware receives and stores business events through a business queue, including source events and sub-events triggered by the source events, and provides business events to event consumers through the business queue, thereby realizing event cascade processing. On this basis, the event middleware receives and stores the execution results of business events returned by event consumers through a status queue, and determines the execution status of the source event based on the execution results of the source event and / or the execution results of the corresponding sub-events obtained by consuming the status queue, thereby tracking the event status in the event cascade scenario. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] The drawings described herein are used to provide a further understanding of this specification and constitute a part of this specification. The illustrative embodiments and descriptions of this specification are used to explain this specification and do not constitute an improper limitation on this specification. In the drawings:

[0026] Figure 1 A schematic diagram of an implementation environment involved in an event processing method provided for one or more embodiments of this specification;

[0027] Figure 2 A flowchart of an event processing method provided for one embodiment of this specification;

[0028] Figure 3 A schematic diagram of the structure of an event processing device provided for one embodiment of this specification;

[0029] Figure 4 A schematic diagram of the structure of an electronic device provided for one embodiment of the present specification. DETAILED DESCRIPTION

[0030] In order to make the purpose, technical solutions and advantages of this specification clearer, the technical solutions of this specification will be clearly and completely described below in combination with the specific embodiments of this specification and the corresponding drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this document.

[0031] The terms "first", "second", etc. in this specification and claims are used to distinguish similar objects, and are not used to describe a particular order or precedence. It should be understood that the terms used in this way can be interchanged where appropriate so that the embodiments of the present application are implemented in a sequence other than those illustrated or described herein. In addition, "and / or" in this specification and claims means at least one of the connected objects, and the character " / " generally means that the objects associated with each other are in an "or" relationship.

[0032] Some concept descriptions:

[0033] Event: A method of communication between computer program units, involving event producers and event consumers. Event producers publish events immediately when something happens; events are transmitted in channels, and consumers can immediately receive events and respond. The same event can be received by multiple consumers. For example, when the underlying data changes, the view used to display this data can be notified immediately through the event mechanism and refresh the view display.

[0034] Event status: When an event is not processed by the consumer, the event status is "unprocessed"; when an event is not processed by the consumer for a set period of time, the event status is "timeout and unprocessed"; after the event is processed by the consumer, the consumer return value can be "successful", "skipped", "abnormal", "delayed retry", etc. The above event statuses are called the current event status.

[0035] Event cascade: After event A is processed, event B is automatically triggered based on the configuration, which is called event cascade triggering.

[0036] Multi-level event cascade: After the cascade-triggered event is processed, a new event is triggered, which is called multi-level event cascade triggering. For example, after event A is processed, event B is automatically triggered based on the configuration; after event B is processed, event C is automatically triggered based on the configuration.

[0037] Source event: In a cascading event, event A can trigger event B. Event A is called the "source event" of event B.

[0038] Event splitting: When a source event cascades to trigger multiple events, it is called event splitting.

[0039] Event merging: The scenario where multiple source events trigger a cascade event is called event merging.

[0040] As described in the background technology, existing message middleware, such as Kafka, Rocket MQ, etc., simply provides a channel for message transmission and lacks the function of tracking and processing the cascade relationship between different events.

[0041] In view of this, the embodiments of this specification aim to propose an event processing solution. By developing an event middleware with a unified external interface and rich event-based communication mechanisms, the event middleware receives and stores business events through a business queue, including source events and sub-events triggered by the source events, and provides business events to event consumers through the business queue, thereby realizing event cascade processing; on this basis, the event middleware receives and stores the execution results of business events returned by event consumers through a status queue, and determines the execution status of the source event based on the acquired execution results of the source event and / or the execution results of the corresponding sub-events by consuming the status queue, thereby tracking the event status in the event cascade scenario.

[0042] The technical solutions provided by the embodiments of this specification are described in detail below in conjunction with the accompanying drawings.

[0043] In order to enable those skilled in the art to better understand the event handling solutions provided by the embodiments of this specification, the implementation environment involved in the event handling solutions provided by the embodiments of this specification is first described. Please refer to the figure, which is a schematic diagram of the implementation environment involved in the event handling solutions provided by one or more embodiments of this specification. Figure 1 As shown, the implementation environment includes event producers, event consumers, event middleware and native middleware.

[0044] Among them, event producers and event consumers are located in the user layer. Event producers are used to publish business events, and event consumers are used to consume business events. Event producers and event consumers access the event middleware through the external interface provided by the event middleware. In actual applications, event producers and event consumers can be various business systems located in the user layer, such as a monitoring system for monitoring device status, an attendance system for recording personnel attendance, and a clearing system for clearing transaction data. Taking the monitoring system as an example, when the monitoring system detects that a certain device has failed, it can act as an event producer and send a business event to the event middleware to indicate the device failure.

[0045] The native middleware may adopt various message middleware commonly used in the art, such as Kafka, Rocket MQ, etc. The native middleware includes at least one topic for storing and delivering messages. In the embodiments of this specification, the native middleware may include a business queue and a status queue, wherein the business queue is used to deliver business events, and the status queue is used to deliver the execution status and / or execution results of the business events.

[0046] Due to various reasons in the actual application environment, event producers cannot directly send business events to the business queue of the native middleware, and event consumers cannot directly consume business events in the business queue of the native middleware, resulting in the inability to effectively transmit events between event producers and event consumers. Based on this, a middleware system with a unified external interface and rich event-based communication mechanism is developed on the basis of the native middleware, namely event middleware.

[0047] The event middleware is the core system of this solution. It has the function of docking with event producers and event consumers, and also has the function of docking with native middleware. The event middleware can receive business events published by event producers and write them into the business queue of the native middleware. It also provides business events to event consumers of business events for event consumers to perform corresponding processing. In a distributed scenario, communication between different systems (that is, producers and consumers at the user layer, event producers and event consumers in the event middleware) is realized through the event middleware, making the event communication mechanism have the characteristics of low coupling and strong flexibility.

[0048] In order to achieve the connection between multiple external event producers and event consumers, the event middleware is equipped with multiple system layer producers and multiple system layer consumers ( Figure 1 In the figure, only one system-level producer and one system-level consumer are used for illustration. Different system-level producers and system-level consumers are connected to different types of event producers and event consumers. Taking one system-level producer and one system-level consumer as an example, the system producer can receive the business events sent by the event producer and write them into the business queue of the native middleware; the system-level consumer can obtain the subscribed business events by consuming the business queue and provide them to the event consumer, and the event consumer processes the business event.

[0049] Furthermore, the event middleware also has functions such as event configuration, cascade event configuration, and event status tracking. These functions can be configured by relevant personnel through the console of the event middleware or directly set in the code in the middle of the event, and this specification does not limit this. The configuration information of the above functions can be stored in the configuration library as metadata, and then when a certain function needs to be used, the configuration information of the function can be directly read from the configuration library, and the function can be implemented based on the read configuration information. It is worth noting that the configuration library can be integrated in the event middleware, or it can exist independently of the event middleware, and this specification embodiment does not limit this.

[0050] The event configuration function can unify the formats of different business events, making it easier for event consumers to format and parse business events. Specifically, the event configuration function can set event parameters of business events, including but not limited to the name, format, attributes, attribute format, content, etc. of business events.

[0051] The cascade event configuration function can be used to configure at least one of the cascade events, trigger conditions, and trigger methods of business events. In common application scenarios, the event middleware forwards the business event published by the event producer to the event consumer that subscribes to the business event, and a closed loop is formed after being processed by the event consumer. For example, after a monitoring system as an event producer triggers an alarm event, the process ends after the fault handling system as an event consumer processes the alarm event. However, in special application scenarios, a business event may contain multiple subordinate events. When an event consumer processes a business event, it also needs to trigger a new business event, thus forming a cascade relationship between different business events. For example, a physical machine contains N virtual machines. After the monitoring system publishes a business event indicating "physical machine failure" (called business event A) to the event middleware, when the event middleware triggers the fault handling system as an event consumer to process business event A, it also needs to generate N business events indicating "virtual machine failure" (called business events B1,..., Bn) and trigger the corresponding event consumers to process these n new business events. The entire process ends only when these n new business events are processed.

[0052] The cascade relationship between these business events can be configured through the cascade event configuration function. After consuming a business event, the event middleware can also track the cascade relationship between the business event and other events based on the cascade event configuration information of the business event, and automatically trigger the cascade event of the business event based on the cascade relationship.

[0053] Through the event status tracking function, the event middleware can record the execution status, execution results and other information of the business event. Specifically, after the event status tracking function is turned on, the event middleware can also receive the execution results of the business event returned by the event consumer and write them into the status topic of the native middleware, and determine the execution status of the business event based on the execution results of the business event by consuming the status topic, and write the execution status of the business event into the status topic. Furthermore, in order to enable the event producer to know the execution progress of the business event and provide strong support for the business scenarios where the event producer is concerned about the progress of the business event processing, the event consumer can also call back at least one of the event status, event results, etc. of the business event to the event producer. In actual applications, the event status tracking function is closed by default. If the event status of a certain business event needs to be tracked, the event status tracking function for the business event can be set to be turned on in the event configuration function of the business event.

[0054] Based on the above implementation environment, the embodiments of this specification provide an event processing method, device, electronic device and storage medium. The technical solution provided by the embodiments of this specification is described in detail below in conjunction with the accompanying drawings.

[0055] S102, receiving and storing business events through a business queue, and providing business events to event consumers through the business queue.

[0056] Specifically, in the above S102, the business events may be received by the system layer producer and stored in the business queue, and the business queue may be consumed by the system layer consumer to provide the acquired business events to the event consumer.

[0057] In the embodiment of the present application, a business event includes a source event and a sub-event triggered by the source event.

[0058] In an optional implementation, the sub-event may be automatically triggered by the event code after the event consumer of the source event consumes the source event. Specifically, in the above S102, the source event may be received and stored through the service queue, and the source event may be provided to the event consumer of the source event through the service queue; further, the sub-event sent by the event consumer of the source event may be received and stored through the service queue, wherein the sub-event is generated by the event consumer of the source event through the event triggering toolkit (Software Development Kits, SDK) in the event code of the source event after the event consumer of the source event consumes the source event.

[0059] For example, the event producer sends business event A to the event middleware, the system-layer producer in the event middleware receives business event A and writes it into the business queue, and the system consumer consumes the business queue, obtains business event A and provides it to the event consumer of business event A, thereby realizing event transmission between the event producer and the event consumer; after consuming business event A, the event consumer will generate a cascaded sub-event B of business event A based on the event code of business event A through the event trigger toolkit and submit sub-event B to the event middleware. The system-layer producer receives sub-event B and writes it into the business queue. In this case, the event middleware can realize automatic processing of cascade events by providing sub-event B to the event consumer of sub-event B.

[0060] In actual applications, in order to achieve automatic and efficient triggering of cascading events, the code triggering method is suitable for business scenarios of event splitting and cascading, that is, scenarios where a source event cascades multiple sub-events. For example, the event code of business event A will configure the event parameters of its multiple cascaded sub-events B1~Bn respectively. After the event middleware provides business event A to the event consumer of business event A through the business queue, the event consumer will call the event trigger toolkit to generate sub-events B1~Bn based on the event parameters of the multiple sub-events B1~Bn configured in the event code of business event A and send them to the event middleware. In this way, the event middleware receives and stores business event A and all its cascaded sub-events through the business queue. In this case, the event middleware can realize the automatic processing of cascading events in the event splitting scenario by providing the subscribed sub-events to the event consumers of each sub-event respectively.

[0061] In addition, the business event contains event parameters of the business event, which may include but are not limited to the name, attributes, content and event identifier of the business event. Therefore, after the event middleware provides the business event to the event consumer, the event consumer can call the corresponding event function to process the business event based on the event parameters in the business event, obtain the event execution result and return it to the event middleware.

[0062] S104: Receive and store the execution result of the business event returned by the event consumer through the status queue.

[0063] Specifically, in the above S104, the execution result of the business event returned by the event consumer may be received by the system layer producer and stored in the state queue.

[0064] The execution result of a business event may include but is not limited to at least one of the following: successful execution, failed execution, and need to retry, etc. In the above S104, after providing the source event to the event consumer of the source event, the event middleware also receives and stores the execution result of the source event returned by the event consumer through the status queue; after providing the source event to the event consumer of the sub-event, the event middleware also receives and stores the execution result of the sub-event returned by the event consumer through the status queue.

[0065] S106: Consume the status queue and determine the execution status of the source event based on the acquired execution result of the source event and / or the execution result of the corresponding sub-event.

[0066] Specifically, in the above S106, the state queue may be consumed by a system layer consumer, and the execution state of the source event may be determined based on the acquired execution result of the source event and / or the execution result of the sub-event.

[0067] In the embodiments of this specification, the execution status of a business event may include but is not limited to at least one of the following states: successful execution, failed execution, retry required, and timeout not processed, etc., wherein successful execution means that the business event is executed successfully; failed execution means that the business event fails to execute; retry required means that the business event is re-executed by the specified event consumer; timeout not processed means that the business event is not executed by the event consumer within the predetermined time from the time it is sent to the event consumer. Furthermore, for the execution status of retry required, the event middleware can also record the retry time interval of the business event and the information of the event consumer that performs the retry, etc., so as to send the business event to the event consumer that performs the retry again for retry according to the retry time interval.

[0068] For example, if the execution result of a business event indicates that the business event is executed successfully, the execution status of the business event can be determined as successful execution; if the execution result of a business event indicates that the business event fails to execute, the execution status of the business event can be determined as processing failure; if the execution result returned by the event consumer is not received within a predetermined time from the time the business event is sent to the event consumer, the execution status of the business event can be determined as timeout and unprocessed; if the execution result of the business event indicates that the business event needs to be retried, the execution status of the business event can be determined as needs to be retried.

[0069] In the case where a business event is used as a source event, the execution state of the business event is related to the cascade type between the business event and the sub-events it triggers. Specifically, if the cascade type between the source event and the business event is event split cascade, that is, one source event cascade triggers multiple sub-events, then the execution state of the source event can be determined based on the execution results of all the sub-events of the source event cascade, or the execution state of the source event can be determined based on the execution state of the source event itself and the execution results of all the sub-events of the source event cascade. For example, sub-events B1~Bn are obtained based on the split trigger of business event A, then the execution status of business event A can be determined according to the execution results of each sub-event B1~Bn, for example, if the execution results of more than half of the sub-events in sub-events B1~Bn are successful, then the execution status of business event A is successful; or, the execution status of business event A can also be determined according to the execution result of business event A itself and the execution results of each sub-event B1~Bn, for example, if the execution status of business event A is successful and the execution results of more than half of the sub-events are successful, then the execution status of business event A is successful.

[0070] If the cascade mode between the source event and the business event is a conventional event cascade, that is, one source event cascade triggers one sub-event, or multiple source events cascade trigger the same sub-event (i.e., event merge cascade scenario), then the execution status of the source event can be determined according to the execution result of the source event itself. For example, if business event A cascades sub-event B, then the execution status of business event A is determined according to the execution result of business event A; if business events A1~Am cascade the same sub-event B, then the execution status of each business event A1~Am is determined by its own execution result.

[0071] In the embodiments of this specification, after determining the execution status of the source event, the sub-event can also be automatically triggered to the event consumer based on the execution status of the source event and the event middleware's own configuration information, and the event consumer processes the sub-event, thereby ensuring the continuous and automated operation of the business, thereby better meeting the business needs in various application scenarios. In actual applications, the cascading event information and event cascading methods of various types of business events can be pre-configured in the event middleware. Among them, the cascading event information of the business event is used to describe other events related to the business event and the cascading relationship between these events and the business event. For example, events related to business event A can include business event B and business event C, and the cascading relationship between these events is business event A->business event B->business event C.

[0072] The event cascade mode of business events is used to describe the cascade relationship between business events and their related events. Among them, the event cascade mode may include, for example, but is not limited to: conventional event cascade, event split cascade, and event merge cascade. Conventional event cascade means that the next level event of a source event cascade is one, for example: the next level event of the business event A cascade is business event B, then the business event A and business event B are the conventional event cascade, and business event A is the source event of business event B; event split cascade means that a source event cascade triggers multiple events, for example: the next level event of the business event A cascade includes business events B1~Bn, then the business event A and business events B1~Bn are event split cascade, and business event A is the source event of business events B1~Bn; event merge cascade means that multiple source events trigger a cascade event, for example: the next level event of the business event A1~An cascade is all business event B, then the business event A1~An is event merge cascade, and business events A1~An are all source events of business event B. Event merging cascades usually occur after event splitting cascades, that is, when a business event cascades multiple next-level events, multiple next-level events cascade the same next-level event.

[0073] In order to better meet the business needs in various application scenarios due to the different event cascade methods in different application scenarios, the event middleware can use different cascade triggering methods to provide sub-events to event consumers according to different event cascade methods.

[0074] Optionally, the cascade triggering method may include configuration triggering. Configuration triggering refers to configuring the triggering conditions of the next level event of the source event cascade in advance in the cascade event configuration information of the source event, such as triggering when the source event is abnormal, or triggering when the source event is completed, etc., and then, when the triggering conditions are met, triggering the event consumer subscribing to the next level event to consume the subscribed next level event from the event topic. Configuration triggering can be applied to the conventional event cascade method.

[0075] Specifically, for the configuration trigger mode, after the above S106, the event processing method provided in the embodiment of this specification may further include: if the execution state of the source event is consistent with the first target execution state pre-configured in the event middleware, providing the sub-event to the event consumer of the sub-event through the business queue. The first target execution state refers to the execution state used to trigger the sub-event.

[0076] For example, assuming that the cascaded sub-events of business event A include business event B, and the first target execution status includes source event execution exception and source event execution success, then if the execution status of business event A is exception or successful processing, business event B is obtained through the consumer business queue, and business event B is provided to the event consumer of business event B, and then the event consumer processes business event B. In this way, the automatic triggering of cascade events can be achieved.

[0077] Optionally, the cascade triggering method may also include event merging triggering, which means that when the next-level events of the cascade of multiple source events are the same, the execution status of all source events is comprehensively considered to determine whether to trigger the user layer consumer subscribing to the next-level event to process the subscribed next-level event. Event merging triggering may be applicable to the event merging cascading method.

[0078] Specifically, for the configuration trigger mode, the business events received and stored by the event middleware through the business queue also include specified events associated with the source event, wherein the specified events associated with the source event may include other events that determine whether to trigger the sub-events of the source event cascade.

[0079] After the above S106, the event processing method provided in the embodiment of this specification may also include: consuming the status queue, determining the execution status of the specified event based on the execution result of the specified event obtained; determining the merged execution status based on the execution status of the source event and the execution status of the specified event; if the merged execution status is consistent with the second target execution status pre-configured in the event middleware, providing the sub-event to the event consumer of the sub-event through the business queue.

[0080] Among them, the combined execution state is used to represent the overall execution state of the source event and the specified event. The second target execution state refers to the execution state that needs to be satisfied to trigger the sub-event, and can specifically include, for example, at least one of the following execution states: all successful, all abnormal, successful, abnormal, and half successful. Among them, all successful means that all related source events are successfully processed, all abnormal means that all related source events are abnormal, successful means that at least one of all related source events is successfully processed, abnormal means that at least one of all source events is abnormal, and half successful means that more than half of all source events of all source events are successfully processed.

[0081] For example, assuming that the specified events related to business event A1 include business events A2 and A3, the sub-event cascaded by business event A1 is business event B, and the second target execution status is half successful, then if the execution status of business event A1 and business event A2 are each successful, it can be determined that the combined execution status is successful, which is consistent with the second target execution status, and then business event B can be obtained through the consumer business queue, and business event B can be provided to the event consumer of business event B, and then the event consumer processes business event B.

[0082] More specifically, the designated event and the source event are obtained by splitting and triggering the same event. Accordingly, the business events received and stored by the event middleware through the business queue also include the upper-level events used to split and trigger the source event and the designated event.

[0083] For example, assume that the specified events related to business event B1 include business events B2 to Bn, and these business events are all triggered by the splitting of business event A, and the next-level events of the cascade of business events B1 to Bn are all business events C, and the second target execution status includes half success. If the execution status of more than half of the business events B1 to Bn is successful, it can be determined that the merged execution status is half success, which is consistent with the second target execution status, and then the business event C can be obtained through the consumer business queue, and the business event C is provided to the event consumer of business event C, and then the event consumer processes business event C. In this way, the automatic tracking and triggering of the parent-child-grandchild three-level cascade event in the scenario where the event is split first and then merged is formed.

[0084] Optionally, in order to track business events with a cascading relationship, the business event also includes a parent event identifier of the business event, wherein the parent event identifier of the business event is used to represent the upper-level event that triggers the business event. In this case, before consuming the status queue and determining the execution status of the specified event based on the execution result of the specified event obtained, the event processing method provided in the embodiment of this specification also includes: based on the parent event identifier contained in the source event, consuming the business queue, obtaining the business event containing the same parent event identifier, and obtaining the specified event.

[0085] It can be understood that since each business event carries the event identifier of its own cascaded upper-level event (i.e., the parent event identifier), by consuming the business queue based on the parent event identifier carried by the source event, the source event and its upper-level event, child events, and other events with the same upper-level event as the source event can be accurately obtained, thereby realizing the tracking of the cascade relationship between different business events.

[0086] Optionally, after the above S106, the event processing method provided in the embodiment of the present specification may also include: based on preset callback configuration information, calling back the execution status of the source event to the event producer of the source event; and / or consuming the status queue, determining the execution status of the sub-event based on the acquired execution result of the sub-event, and calling back the execution status of the sub-event to the event producer of the source event based on the preset callback configuration information.

[0087] The callback configuration information may include callback type, sub-callback type, callback status, and timeout event, etc. Each business event may have corresponding callback configuration information. The callback configuration information may be stored in a configuration library, and the event middleware may read the callback configuration information from the configuration library when necessary, and call back the execution status of the source event and / or the execution status of the sub-event based on the callback configuration information.

[0088] For example, the callback configuration information corresponding to the business event may include the event consumer identifier specified by the event producer of the business event, and the execution result returned by the event consumer to the event middleware may carry the identifier of the event consumer itself. In this case, after receiving the execution result of the source event, the event middleware may compare the execution result of the source event with the corresponding specified event consumer identifier. If the comparison is consistent, the execution status of the source event is called back to the event producer of the source event; and / or, after receiving the execution result of the sub-event, the event middleware may compare the execution result of the sub-event with the corresponding specified event consumer identifier. If the comparison is consistent, the execution status of the sub-event is called back to the event producer of the source event.

[0089] For another example, the callback configuration information may include a sub-callback type. In this case, if the source event cascades multiple sub-events, and the sub-callback type is to trigger the callback after all sub-events are processed, the event middleware will call back the execution status of each sub-event to the event producer of the source event when the execution status of multiple sub-events indicates that the execution is completed; if the sub-callback type is to trigger the callback after a single sub-event is processed, then when the execution status of any sub-event is successful, the execution status of the sub-event will be called back to the event producer of the source event. In this way, in the case of event cascades, the event producer of the source event can be informed of the processing progress of the next level of sub-events of the source event cascade produced, thereby improving the flexibility of the event execution status callback.

[0090] For another example, the callback configuration information may include a callback status, and the callback status includes at least one of the following statuses: successful execution, failed execution, and timeout unprocessed. In this case, the event middleware may call back the execution status of the source event to the event producer of the source event if the execution result of the source event is consistent with the callback status; and / or the event middleware may call back the execution status of the sub-event to the event producer of the source event if the execution status of the sub-event is consistent with the callback status.

[0091] It can be understood that by calling back the execution status of the source event and / or the execution status of the sub-event to the event producer of the source event, the event producer can learn the processing progress of the source event and its cascaded sub-events, providing strong support for business scenarios where the event producer is concerned about the event processing progress.

[0092] The event processing method provided by one or more embodiments of the present specification develops an event middleware with a unified external interface and rich event-based communication mechanism. The event middleware receives and stores business events through a business queue, including source events and sub-events triggered by the source events, and provides business events to event consumers through the business queue, thereby realizing event cascade processing. On this basis, the event middleware receives and stores the execution results of business events returned by event consumers through a status queue, and determines the execution status of the source event based on the acquired execution results of the source event and / or the execution results of the corresponding sub-events by consuming the status queue, thereby tracking the event status in the event cascade scenario.

[0093] In addition, Figure 2 Corresponding to the event processing method shown, the embodiment of this specification also provides an event processing device, which can be applied to event middleware. Figure 3 3 is a schematic diagram of the structure of an event processing device 300 provided in an embodiment of this specification, including:

[0094] The processing unit 310 is used to receive and store business events through a business queue, and provide the business events to event consumers through the business queue; the business events include source events and sub-events triggered by the source events;

[0095] The storage unit 320 is used to receive and store the execution result of the business event returned by the event consumer through a state queue;

[0096] The consumption unit 330 is used to consume the state queue and determine the execution state of the source event based on the acquired execution result of the source event and / or the execution result of the corresponding sub-event.

[0097] Optionally, the processing unit is specifically configured to:

[0098] Receiving and storing source events through the service queue, and providing the source events to event consumers of the source events through the service queue;

[0099] The business queue receives and stores sub-events sent by the event consumer of the source event, wherein the sub-events are generated by the event consumer of the source event by calling an event trigger toolkit in the event code of the source event when consuming the source event.

[0100] Optionally, the processing unit is also used to: after the consumer unit determines the execution status of the source event based on the acquired execution result of the source event and / or the execution result of the corresponding sub-event, if the execution status of the source event is consistent with the first target execution status pre-configured in the event middleware, then provide the sub-event to the event consumer of the sub-event through the business queue.

[0101] Optionally, the business event also includes a specified event associated with the source event;

[0102] The processing unit is further configured to: after the consumption unit determines the execution status of the source event based on the acquired execution result of the source event and / or the execution result of the corresponding sub-event, consume the status queue and determine the execution status of the designated event based on the acquired execution result of the designated event;

[0103] Determining a merged execution state based on the execution state of the source event and the execution state of the designated event;

[0104] If the combined execution state is consistent with the second target execution state preconfigured in the event middleware, the sub-event is provided to the event consumer of the sub-event through the service queue.

[0105] Optionally, the source event and the designated event are obtained by splitting and triggering the same event, and the service event also includes a higher-level event for splitting and triggering the source event and the designated event.

[0106] Optionally, the business event includes a parent event identifier of the business event, and the event identifier of the business event indicates a parent event used to trigger the business event;

[0107] The processing unit is also used for:

[0108] Before consuming the status queue and determining the execution status of the specified event based on the execution result of the specified event obtained, the business queue is consumed based on the parent event identifier contained in the source event to obtain the business event containing the same parent event identifier to obtain the specified event.

[0109] Optionally, the event processing device further includes:

[0110] A callback unit, configured to consume the state queue in the consumption unit, determine the execution state of the source event based on the acquired execution result of the source event and / or the execution result of the corresponding sub-event, and then call back the execution state of the source event to the event producer of the source event based on preset callback configuration information; and / or,

[0111] The state queue is consumed, the execution state of the sub-event is determined based on the acquired execution result of the sub-event, and the execution state of the sub-event is called back to the event producer of the source event based on preset callback configuration information.

[0112] Optionally, the event middleware includes a system layer producer and a system layer consumer;

[0113] The processing unit is specifically used to: receive business events through the system layer producer and store them in a business queue, and consume the business queue through the system layer consumer, and provide the acquired business events to the event consumer; the business event includes a source event and a sub-event triggered by the source event;

[0114] The storage unit is specifically used to: receive the execution result of the business event returned by the event consumer through the system layer producer and store it in the state queue;

[0115] The consumption unit is specifically used to: consume the state queue through the system layer consumer, and determine the execution state of the source event based on the acquired execution result of the source event and / or the execution result of the corresponding sub-event.

[0116] Obviously, the event processing device in the embodiment of this specification can be used as the above Figure 2 The execution body of the event handling method shown in Figure 2 The functions realized are as follows. Since the principles are the same, they will not be described here.

[0117] Figure 4 This is a schematic diagram of the structure of an electronic device according to an embodiment of this specification. Figure 4 At the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and a memory. The memory may include a memory, such as a high-speed random access memory (RAM), and may also include a non-volatile memory (non-volatile memory), such as at least one disk storage. Of course, the electronic device may also include hardware required for other services.

[0118] The processor, network interface and memory can be interconnected through an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 4 Only one bidirectional arrow is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0119] The memory is used to store the program. Specifically, the program may include a program code, and the program code includes a computer operation instruction. The memory may include a memory and a non-volatile memory, and provides instructions and data to the processor.

[0120] The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it, forming an event processing device at the logical level. The processor executes the program stored in the memory and is specifically used to perform the following operations:

[0121] Receiving and storing business events through a business queue, and providing the business events to event consumers through the business queue; the business events include source events and sub-events triggered by the source events;

[0122] Receive and store the execution result of the business event returned by the event consumer through the state queue;

[0123] The state queue is consumed, and the execution state of the source event is determined based on the acquired execution result of the source event and / or the execution result of the corresponding sub-event.

[0124] The above is as in this manual Figure 2 The method performed by the event processing device disclosed in the illustrated embodiment can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by an integrated logic circuit of hardware in the processor or an instruction in the form of software. The above processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The methods, steps and logic block diagrams disclosed in the embodiments of this specification can be implemented or executed. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. The steps of the method disclosed in the embodiments of this specification can be directly embodied as a hardware decoding processor for execution, or a combination of hardware and software modules in the decoding processor for execution. The software module can be located in a storage medium mature in the art such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.

[0125] It should be understood that the electronic device of the embodiment of this specification can implement the event processing device in Figure 2 Functions of the embodiments shown. Since the principles are the same, the embodiments of this specification will not be described in detail here.

[0126] Of course, in addition to software implementation, the electronic device of this specification does not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc., that is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0127] The embodiment of the present specification also provides a computer-readable storage medium, which stores one or more programs, wherein the one or more programs include instructions, which, when executed by a portable electronic device including a plurality of application programs, enable the portable electronic device to execute Figure 2 The method of the embodiment shown is specifically used to perform the following operations:

[0128] Receiving and storing business events through a business queue, and providing the business events to event consumers through the business queue; the business events include source events and sub-events triggered by the source events;

[0129] Receive and store the execution result of the business event returned by the event consumer through the state queue;

[0130] The state queue is consumed, and the execution state of the source event is determined based on the acquired execution result of the source event and / or the execution result of the corresponding sub-event.

[0131] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0132] In short, the above description is only a preferred embodiment of this specification and is not intended to limit the protection scope of this specification. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification shall be included in the protection scope of this specification.

[0133] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0134] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0135] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0136] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

Claims

1. An event processing method, characterized in that: Applied to event middleware, the method includes: Receiving and storing business events through a business queue, and providing the business events to event consumers through the business queue; the business events include source events and sub-events triggered by the source events; Receive and store the execution result of the business event returned by the event consumer through the state queue; The state queue is consumed, and the execution state of the source event is determined based on the acquired execution result of the source event and / or the execution result of the corresponding sub-event.

2. The method according to claim 1, characterized in that The receiving and storing the business event through the business queue, and providing the business event to the event consumer through the business queue, includes: Receiving and storing source events through the service queue, and providing the source events to event consumers of the source events through the service queue; The business queue receives and stores sub-events sent by the event consumer of the source event, wherein the sub-events are generated by the event consumer of the source event by calling an event trigger toolkit in the event code of the source event when consuming the source event.

3. The method according to claim 1, characterized in that After determining the execution status of the source event based on the acquired execution result of the source event and / or the execution result of the corresponding sub-event, the method further includes: If the execution state of the source event is consistent with the first target execution state pre-configured in the event middleware, the sub-event is provided to the event consumer of the sub-event through the service queue.

4. The method according to claim 1, characterized in that The business event also includes a specified event associated with the source event; After determining the execution status of the source event based on the acquired execution result of the source event and / or the execution result of the corresponding sub-event, the method further includes: Consuming the state queue, and determining the execution state of the specified event based on the obtained execution result of the specified event; Determining a merged execution state based on the execution state of the source event and the execution state of the designated event; If the combined execution state is consistent with the second target execution state preconfigured in the event middleware, the sub-event is provided to the event consumer of the sub-event through the service queue.

5. The method according to claim 4, characterized in that The source event and the designated event are obtained by splitting and triggering the same event, and the service event also includes a higher-level event used for splitting and triggering the source event and the designated event.

6. The method according to claim 5, characterized in that The business event includes a parent event identifier of the business event, and the event identifier of the business event indicates a parent event used to trigger the business event; Before consuming the status queue and determining the execution status of the specified event based on the acquired execution result of the specified event, the method further includes: Based on the parent event identifier contained in the source event, the service queue is consumed to obtain the service event containing the same parent event identifier, thereby obtaining the designated event.

7. The method according to claim 1, characterized in that After consuming the state queue and determining the execution state of the source event based on the acquired execution result of the source event and / or the execution result of the corresponding sub-event, the method further includes: Based on preset callback configuration information, calling back the execution status of the source event to the event producer of the source event; and / or, The state queue is consumed, the execution state of the sub-event is determined based on the acquired execution result of the sub-event, and the execution state of the sub-event is called back to the event producer of the source event based on preset callback configuration information.

8. The method according to claim 1, characterized in that The event middleware includes a system layer producer and a system layer consumer; The receiving and storing the business event through the business queue, and providing the business event to the event consumer through the business queue, includes: The system layer producer receives business events and stores them in a business queue, and the system layer consumer consumes the business queue and provides the acquired business events to the event consumer; the business event includes a source event and a sub-event triggered by the source event; The receiving and storing the execution result of the business event returned by the event consumer through the state queue includes: Receive the execution result of the business event returned by the event consumer through the system layer producer and store it in the status queue; The consuming of the state queue and determining the execution state of the source event based on the acquired execution result of the source event and / or the execution result of the corresponding sub-event includes: The state queue is consumed by the system layer consumer, and the execution state of the source event is determined based on the acquired execution result of the source event and / or the execution result of the corresponding sub-event.

9. An event processing device, characterized in that: Applied to event middleware, the device comprises: A processing unit, configured to receive and store business events through a business queue, and provide the business events to event consumers through the business queue; the business events include source events and sub-events triggered by the source events; A storage unit, used for receiving and storing the execution result of the business event returned by the event consumer through a state queue; The consumption unit is used to consume the state queue and determine the execution state of the source event based on the acquired execution result of the source event and / or the execution result of the corresponding sub-event.

10. An electronic device, characterized in that: include: processor; as well as a memory arranged to store computer executable instructions which, when executed, cause the processor to: Receiving and storing business events through a business queue, and providing the business events to event consumers through the business queue; the business events include source events and sub-events triggered by the source events; Receive and store the execution result of the business event returned by the event consumer through the state queue; The state queue is consumed, and the execution state of the source event is determined based on the acquired execution result of the source event and / or the execution result of the corresponding sub-event.

Images