Event processing method and device and electronic equipment

Abstract

Embodiments of the invention disclose an event processing method and apparatus, and an electronic device, which can accurately record a processing state of an event and realize tracking of an event processing progress. The event processing method comprises the following steps: receiving and storing a business event produced by an event producer through a business queue, and providing the business event for an event consumer through the business queue; receiving and storing an execution result of the business event returned by the event consumer through a state queue; consuming the state queue, and determining a processing state corresponding to the business event based on an obtained execution result; and calling back the processing state of the business event to the event producer based on preset callback configuration information.

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 functions such as tracking the progress of event processing. Therefore, a solution that can track the progress of event processing is urgently needed. Summary of the invention

[0003] The purpose of the embodiments of this specification is to provide an event processing method, device and electronic device, which can accurately record the processing status of an event and track the progress of event processing.

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

[0005] In a first aspect, an event processing method is provided, comprising:

[0006] Receiving and storing business events generated by event producers through business queues, and providing the business events to event consumers through the business queues;

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

[0008] Consume the status queue and determine the processing status corresponding to the business event based on the acquired execution result;

[0009] Based on the predetermined callback configuration information, the processing status of the business event is called back to the event producer.

[0010] In a second aspect, an event processing device is provided, comprising:

[0011] A first sending unit receives and stores a business event generated by an event producer through a business queue, and provides the business event to an event consumer through the business queue;

[0012] A first receiving unit receives and stores the execution result of the business event returned by the event consumer through a state queue;

[0013] A state recording unit consumes the state queue and determines a processing state corresponding to the business event based on the acquired execution result;

[0014] The callback unit is used to call back the processing status of the business event to the event producer based on predetermined callback configuration information.

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

[0016] Processor; and

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

[0018] Receiving and storing business events generated by event producers through business queues, and providing the business events to event consumers through the business queues;

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

[0020] Consume the status queue and determine the processing status corresponding to the business event based on the acquired execution result;

[0021] Based on the predetermined callback configuration information, the processing status of the business event is called back to the event producer.

[0022] 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:

[0023] Receiving and storing business events generated by event producers through business queues, and providing the business events to event consumers through the business queues;

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

[0025] Consume the status queue and determine the processing status corresponding to the business event based on the acquired execution result;

[0026] Based on the predetermined callback configuration information, the processing status of the business event is called back to the event producer.

[0027] In the scheme of the embodiments of the present specification, the event middleware receives and stores the business events generated by the event producer through the business queue, and provides the business events to the event consumer through the business queue so that the event consumer can execute the event; receives and stores the execution results of the business events returned by the event consumer through the status queue, and then consumes the status queue, and determines the processing status of the corresponding business event based on the obtained execution results, thereby tracking the processing progress of the business event according to the processing status of the business event; further, it also provides a flexible and available configuration for the event processing status callback, and performs the callback of the event processing status based on the predetermined callback configuration information, which can meet the event producer's diverse callback requirements for the event processing status; in addition, the transmission of business events through the business queue and the transmission of the processing status of business events through the status queue can realize asynchronous transmission of business events and their processing status, which is beneficial to improving the processing capability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] 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:

[0029] Figure 1 A schematic diagram of an implementation environment involved in the embodiments of this specification;

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

[0031] Figure 3 A flowchart of an event processing method provided for another embodiment of the present specification;

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

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

[0034] 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.

[0035] As mentioned above, existing message middleware, such as Kafka, Rocket MQ, etc., simply provide a channel for message transmission, and lack functions such as tracking the progress of event processing. Based on this, the embodiment of this specification provides an event processing solution, in which the event middleware receives and stores the business events produced by the event producer through the business queue, and provides business events to the event consumer through the business queue, so that the event consumer can execute the event; receives and stores the execution results of the business events returned by the event consumer through the status queue, and then consumes the status queue, and determines the processing status of the corresponding business event based on the obtained execution results, thereby tracking the processing progress of the business event according to the processing status of the business event; calling back the processing status of the business event to the event producer of the business event, so that the event producer can be informed of the processing progress of the business event, and provide strong support for the business scenarios where the event producer is concerned about the processing progress of the business event. In addition, it also provides flexible and available configuration for event processing status callback, and performs callback of event processing status based on predetermined callback configuration information, which can meet the diverse callback requirements of event producers for business event processing status; in addition, business events are transmitted through business queues and the processing status of business events is transmitted through status queues, which can realize asynchronous transmission of business events and their processing status, thereby helping to improve the processing capability of the system.

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

[0037] First, an exemplary description is given of the implementation environment involved in the embodiments of this specification.

[0038] See also Figure 1 The implementation environment involved in the embodiments of this specification includes event middleware and applications.

[0039] Among them, the event middleware uses the event delivery mechanism to realize the business event delivery between different applications, and maintains the delivery and storage and forwarding mechanism of business events. Specifically, the event middleware can add the event consumer to the event consumer list of the subscribed event according to the event subscription request of the event consumer, and when the event producer triggers the business event, the event message of the business event is sent to the event consumer in the event consumer list, so that the event consumer who subscribes to the event executes the business event. For example, the business event that the event consumer requests to subscribe to is the data of the synchronized data source. When the event producer detects that the data of the data source has changed, it will trigger the corresponding business event and publish the business event to the event middleware based on the data change information of the data source. The event middleware then sends the business event to the event consumer who subscribes to the business event, and the event consumer synchronizes the data of the target object based on the received business event.

[0040] Furthermore, the event middleware has functions such as channel application, event definition, event log, consumption log and notification template, etc. These functions can be configured by relevant personnel through the control interface of the event middleware or directly set in the code of the event middleware, and this specification embodiment does not specifically limit this. The configuration information of the above functions can be stored in the configuration library, 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 configured based on the configuration information.

[0041] Through the channel application function, the event middleware can create one or more event channels and use different event channels to transmit event messages of different events.

[0042] The event definition function can unify the formats of event messages for different business events, making it easier for event consumers to format and parse business events.

[0043] Through the event log function, the event middleware can record business events and the processing status of business events. Specifically, the event middleware can determine the processing status of business events based on the execution results of business events returned by event consumers, and store business events and the processing status of business events in the event library.

[0044] Through the subscription log function, the event middleware can record and maintain the event consumer list of different business events, so that when the event producer triggers a business event, the business event is sent to the event consumer in the event consumer list of the business event, completing the transmission of the business event between the event producer and the event consumer.

[0045] Through the notification template function, the event middleware can send business events to event consumers of business events and call back the processing status of business events to event producers of business events based on notification templates.

[0046] Applications can act as event producers and publish business events to event middleware. Specifically, applications can trigger events in response to user operations, and generate business events based on event parameters (such as event name, attributes, and content) of business events according to predetermined event definitions, and send events to business queues through the event publishing interface (Application Programming Interface, API) provided by the event middleware, thus completing the publishing of business events. Of course, business events can also be published on a scheduled basis.

[0047] Applications can also act as event consumers and subscribe to events from event middleware. After receiving an event, the application executes the event. Specifically, the application can retrieve the subscribed business event from the business queue through the event subscription interface provided by the event middleware, and call the corresponding processing function to execute the business event based on the event parameters carried in the business event, thereby completing the subscription and consumption of the business event.

[0048] Furthermore, when acting as an event consumer, the application can also return the execution result of the business event to the business queue or a separately created status queue. The event middleware is responsible for recording the processing status of the business event based on the execution result of the business event, and delivering the processing status of the business event to the application that initiated the business event (ie, the event producer), thereby completing the event callback.

[0049] Furthermore, the application can publish and subscribe to business events through the corresponding software development kit (SDK). In addition, when publishing or subscribing to business events, business event filtering and permission control can be performed.

[0050] Based on the above implementation environment, the embodiment of this specification provides an event processing solution. The technical solution provided by the embodiment of this specification is described in detail below in conjunction with the accompanying drawings.

[0051] Please refer to Figure 2 , is a flow chart of an event processing method provided by an embodiment of this specification, the method can be Figure 1 The event middleware in is executed. Figure 2 As shown, the method comprises the following steps:

[0052] S202, receiving and storing business events generated by event producers through business queues, and providing business events to event consumers through business queues.

[0053] Among them, by providing business events to event consumers, event consumers can execute the business events. Business events can carry event parameters of business events, such as but not limited to the name, attributes and content of business events. Event consumers can call corresponding event functions to process business events (i.e., execute business events) based on the event parameters carried in business events, obtain corresponding execution results and return the execution results to event middleware.

[0054] like Figure 3 As shown, in S202, by adding the business event to the business queue, the event consumer of the business event obtains the event message from the business queue, so that the event middleware can use the asynchronous transmission mechanism to transmit the business event, thereby improving the processing capability of the system.

[0055] S204, receiving and storing the execution result of the business event returned by the event consumer through the state queue.

[0056] The execution result of the business event may include, for example, but is not limited to, at least one of the following: successful processing, failed processing, and need to retry.

[0057] like Figure 3 As shown, in S204, the processing status of the business event is added to the status queue so that the consumer of the status queue obtains the processing status of the business event from the status queue and stores it in the event library, so that the event middleware can use an asynchronous transmission mechanism to transmit the business event, thereby improving the processing capability of the system.

[0058] S206: Consume the status queue and determine the processing status of the business event based on the acquired execution result.

[0059] In the embodiments of this specification, the processing status of a business event may include but is not limited to at least one of the following states: successful processing, failed processing, retry required, and timeout unprocessed, etc., wherein successful processing means that the business event is executed successfully; failed processing means that the business event fails to execute; retry required means that the business event is re-executed by the specified event consumer; timeout unprocessed 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 processing 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 for retry according to the retry time interval.

[0060] Specifically, if the execution result of the target business event is obtained, the execution result is used as the processing status of the target business event, and the execution result includes at least one of the following: successful processing, failed processing, and need to be retried. If the execution result of the target business event is still not obtained when the timeout period of the target business event arrives, the processing status of the target business event is determined to be timeout and unprocessed. Among them, the target business event refers to any business event to be consumed.

[0061] For example, if the execution result of a business event indicates that the business event is processed successfully, then the processing status of the business event can be determined as successful processing; if the execution result of a business event indicates that the business event is processed unsuccessfully, then the processing status of the business event can be determined as failed processing; 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, then the processing 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, then the processing status of the business event can be determined as needs to be retried.

[0062] In order to enable the event producer to know the processing progress of the triggered event, after the above S206, the event processing method provided in the embodiment of this specification further includes:

[0063] S208: Based on the predetermined callback configuration information, the processing status of the business event is called back to the event producer.

[0064] The callback configuration information can be pre-set by the event producer according to actual needs. For example, the event producer can specify the event consumer, callback type, sub-callback type, callback status, and timeout period in the callback configuration information. In specific implementation, the callback configuration information can be stored in the configuration library. The event middleware can directly read the callback configuration information from the configuration library when needed, and call back the processing status of the business event based on the callback configuration information.

[0065] As an implementation method, the callback configuration information may include a specified event consumer identifier. The execution result of the business event returned by the event consumer to the event middleware may carry the identifier of the event consumer itself, that is, the execution result of the business event carries the identifier of the event consumer that executed the business event. Accordingly, based on the predetermined callback configuration information, the processing status of the consumed event is called back to the event producer, including: comparing the event consumer identifier carried in the execution result of the consumed event with the specified event consumer identifier. If the comparison is consistent, the processing status of the business event is called back to the event producer. As a result, the event producer can selectively learn about the processing progress of the business event by the event consumer it is concerned about.

[0066] As an implementation, the callback configuration information may include a callback type, wherein the callback type is used to indicate whether to trigger the callback and the number of times the callback is triggered. Accordingly, based on the predetermined callback configuration information, the processing status of the business event is called back to the event producer, including: if the callback type is to trigger a callback once, then when the execution result returned by the event consumer of the business event is received for the first time, the processing status determined based on the execution result is called back to the event producer; if the callback type is to trigger the callback each time, then each time the execution result returned by the event consumer of the business event is received, the processing status determined based on the execution result is called back to the event producer.

[0067] As an implementation method, the callback configuration information may include a sub-callback type, and the processing status of the business event includes the processing status of the sub-events contained in the business event. Accordingly, based on the predetermined callback configuration information, the processing status of the business event is called back to the event producer, including: if the sub-callback type is to trigger the callback after all sub-events are processed, then when the processing status of all sub-events contained in the business event is successfully processed, the processing status of the business event is called back to the event producer; if the sub-callback type is to trigger the callback after a single sub-event is processed, then when the processing status of a single sub-event contained in the business event is successfully processed, the processing status of the single sub-event is called back to the event producer. In this way, the event producer can learn about the processing progress of the sub-events contained in the produced business event, thereby improving the flexibility of the event processing status callback.

[0068] As an implementation, the callback configuration information may include a callback status, and the callback status includes at least one of the following statuses: successful processing, failed processing, and timeout and unprocessed. Accordingly, based on the predetermined callback configuration information, the processing status of the business event is called back to the event producer, including: when the processing status of the business event is the same as the callback status, the processing status of the business event is called back to the event producer. Thus, the event producer can be informed of the processing status it is concerned about.

[0069] It should be noted that the above callback of the processing status of the business event can be executed while the processing status of the business event is determined based on the execution result of the business event, so that the event producer can be informed of the processing progress of the produced business event in a timely manner.

[0070] Of course, the above callback of the processing status of the business event can also be executed when the business event times out and is not processed. Specifically, as an implementation method, the callback configuration information can also include a timeout period, wherein the timeout period can be set according to actual needs, for example, the timeout period can be set to a smaller value, or, when there is no need to care whether the business event times out and is not processed, the timeout period can be set to a sufficiently large value. Accordingly, before the event middleware calls back the processing status of the business event to the event producer, it can monitor whether the unprocessed time of the business event reaches the timeout period, and if so, the processing status of the business event is called back to the event producer. In this way, flexible control of the timing of the processing status callback can be achieved.

[0071] It should be noted that, in actual applications, the callback configuration information of different business events may be the same or different, and may be set according to actual needs. The embodiments of this specification do not make specific limitations on this.

[0072] Through the event processing method provided in the embodiment of this specification, the event middleware receives and stores the business events produced by the event producer through the business queue, and provides the business events to the event consumer through the business queue, so that the event consumer can execute the event; receives and stores the execution results of the business events returned by the event consumer through the status queue, and then consumes the status queue, and determines the processing status of the corresponding business event based on the obtained execution results, thereby tracking the processing progress of the business event according to the processing status of the business event; the processing status of the business event is called back to the event producer of the business event, so that the event producer can know the processing progress of the business event, and provide strong support for the business scenarios where the event producer is concerned about the progress of the event processing. In addition, it also provides a flexible and available configuration for the event processing status callback, and the event processing status callback is performed based on the predetermined callback configuration information, which can meet the event producer's diversified callback requirements for the event processing status; in addition, the business event is transmitted through the business queue and the processing status of the business event is transmitted through the status queue, which can realize the asynchronous transmission of the business event and its processing status, thereby helping to improve the processing capability of the system.

[0073] In addition, Figure 2 Corresponding to the event processing method shown, the embodiment of this specification also provides an event processing device. Figure 4 4 is a schematic diagram of the structure of an event processing device 400 provided in an embodiment of the present specification. The device 400 can be applied to event middleware. The device 400 includes:

[0074] A first sending unit 410 receives and stores a business event generated by an event producer through a business queue, and provides the business event to an event consumer through the business queue;

[0075] A first receiving unit 420 receives and stores the execution result of the business event returned by the event consumer through a state queue;

[0076] A state recording unit 430 consumes the state queue and determines a processing state corresponding to the business event based on the acquired execution result;

[0077] The callback unit 440 is used to call back the processing status of the business event to the event producer based on predetermined callback configuration information.

[0078] Optionally, the status recording unit 430 is specifically used for:

[0079] If the execution result of the target business event is obtained, the execution result will be used as the processing status of the target business event, and the execution result includes at least one of the following: successful processing, failed processing, and retry required; if the execution result of the target business event is still not obtained when the timeout period of the target business event arrives, the processing status of the target business event is determined to be timeout and unprocessed.

[0080] Optionally, the callback configuration information includes a specified event consumer identifier, and the execution result of the business event carries the event consumer identifier that executes the business event;

[0081] The callback unit compares the event consumer identifier carried in the execution result of the business event with the designated event consumer identifier; if the comparison is consistent, the processing status of the business event is called back to the event producer.

[0082] Optionally, the callback configuration information includes a callback type;

[0083] The callback unit, if the callback type is to trigger a callback once, will call back the processing status of the business event to the event producer when the execution result returned by the event consumer of the business event is received for the first time; if the callback type is to trigger a callback each time, will call back the processing status of the business event to the event producer each time the execution result returned by the event consumer of the business event is received.

[0084] Optionally, the callback configuration information includes a sub-callback type, and the processing status of the business event includes the processing status of the sub-events included in the business event;

[0085] The callback unit, if the sub-callback type is to trigger the callback after all sub-events are processed, then when the processing status of all sub-events included in the business event is successful, the processing status of the business event will be called back to the event producer; if the sub-callback type is to trigger the callback after a single sub-event is processed, then when the processing status of a single sub-event included in the business event is successful, the processing status of the single sub-event will be called back to the event producer.

[0086] Optionally, the callback configuration information includes a callback status, and the callback status includes at least one of the following statuses: successful processing, failed processing, and timeout and unprocessed;

[0087] The callback unit calls back the processing status of the business event to the event producer when the processing status of the business event is the same as the callback status.

[0088] Optionally, the callback configuration information also includes a timeout period;

[0089] The callback unit also monitors whether the unprocessed time of the business event reaches the timeout time before calling back the processing status of the business event to the event producer, if the processing status of the business event is timeout and unprocessed; when the unprocessed time of the business event reaches the timeout time, the processing status of the business event is called back to the event producer.

[0090] In the event processing device provided in the embodiment of the present specification, the event middleware receives and stores the business events generated by the event producer through the business queue, and provides the business events to the event consumer through the business queue so that the event consumer can execute the event; receives and stores the execution results of the business events returned by the event consumer through the status queue, and then consumes the status queue, and determines the processing status of the corresponding business event based on the obtained execution results, thereby tracking the processing progress of the business event according to the processing status of the business event; further, it also provides a flexible and available configuration for the event processing status callback, and performs the callback of the event processing status based on the predetermined callback configuration information, which can meet the event producer's diverse callback requirements for the event processing status; in addition, the transmission of business events through the business queue and the transmission of the processing status of business events through the status queue can realize asynchronous transmission of business events and their processing status, which is beneficial to improving the processing capability of the system.

[0091] 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.

[0092] Figure 5 This is a schematic diagram of the structure of an electronic device according to an embodiment of this specification. Figure 5 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.

[0093] 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 5 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.

[0094] 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.

[0095] 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:

[0096] Receiving and storing business events generated by event producers through business queues, and providing the business events to event consumers through the business queues;

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

[0098] Consume the status queue and determine the processing status corresponding to the business event based on the acquired execution result;

[0099] Based on the predetermined callback configuration information, the processing status of the business event is called back to the event producer.

[0100] The above is as in this manual Figure 2The 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.

[0101] 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.

[0102] 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.

[0103] 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:

[0104] Receiving and storing business events generated by event producers through business queues, and providing the business events to event consumers through the business queues;

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

[0106] Consume the status queue and determine the processing status corresponding to the business event based on the acquired execution result;

[0107] Based on the predetermined callback configuration information, the processing status of the business event is called back to the event producer.

[0108] 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.

[0109] 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.

[0110] 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.

[0111] 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.

[0112] 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.

[0113] 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 generated by event producers through business queues, and providing the business events to event consumers through the business queues; Receive and store the execution result of the business event returned by the event consumer through the state queue; Consume the status queue and determine the processing status corresponding to the business event based on the acquired execution result; Based on the predetermined callback configuration information, the processing status of the business event is called back to the event producer.

2. The method according to claim 1, characterized in that The above-mentioned determining the processing status corresponding to the business event based on the acquired execution result includes: If the execution result of the target business event is obtained, the execution result is used as the processing status of the target business event, and the execution result includes at least one of the following: successful processing, failed processing, and need to retry; If the execution result of the target business event is not obtained when the timeout period of the target business event arrives, it is determined that the processing status of the target business event is timeout and unprocessed.

3. The method according to claim 1, characterized in that The callback configuration information includes a specified event consumer identifier, and the execution result of the business event carries the event consumer identifier that executes the business event; The calling back the processing status of the business event to the event producer based on the predetermined callback configuration information includes: Comparing the event consumer identifier carried in the execution result of the business event with the designated event consumer identifier; If the comparison is consistent, the processing status of the business event is called back to the event producer.

4. The method according to claim 1, characterized in that The callback configuration information includes a callback type; The calling back the processing status of the business event to the event producer based on the predetermined callback configuration information includes: If the callback type is to trigger a callback once, when the execution result returned by the event consumer of the business event is received for the first time, the processing status of the business event is called back to the event producer; If the callback type is a callback triggered each time, then each time the execution result returned by the event consumer of the business event is received, the processing status of the business event is called back to the event producer.

5. The method according to claim 1, characterized in that The callback configuration information includes a sub-callback type, and the processing status of the business event includes the processing status of the sub-events included in the business event; The calling back the processing status of the business event to the event producer based on the predetermined callback configuration information includes: If the sub-callback type is to trigger a callback after all sub-events are processed, then when the processing status of all sub-events included in the business event is successfully processed, the processing status of the business event is called back to the event producer; If the sub-callback type is to trigger a callback after a single sub-event is processed, when the processing status of a single sub-event included in the business event is successfully processed, the processing status of the single sub-event is called back to the event producer.

6. The method according to claim 1, characterized in that The callback configuration information includes a callback status, and the callback status includes at least one of the following statuses: successful processing, failed processing, and timeout and unprocessed; The calling back the processing status of the business event to the event producer based on the predetermined callback configuration information includes: When the processing status of the business event is the same as the callback status, the processing status of the business event is called back to the event producer.

7. The method according to claim 6, characterized in that The callback configuration information also includes a timeout period; Before calling back the processing status of the business event to the event producer, the method further includes: If the processing status of the business event is timeout, monitoring whether the unprocessed time of the business event reaches the timeout time; The calling back the processing status of the business event to the event producer includes: When the unprocessed time of the business event reaches the timeout period, the processing status of the business event is called back to the event producer.

8. An event processing device, comprising: A first sending unit receives and stores a business event generated by an event producer through a business queue, and provides the business event to an event consumer through the business queue; A first receiving unit receives and stores the execution result of the business event returned by the event consumer through a state queue; A state recording unit consumes the state queue and determines a processing state corresponding to the business event based on the acquired execution result; The callback unit is used to call back the processing status of the business event to the event producer based on predetermined callback configuration information.

9. An electronic device, comprising: processor; as well as a memory arranged to store computer executable instructions which, when executed, cause the processor to: Receiving and storing business events generated by event producers through business queues, and providing the business events to event consumers through the business queues; Receive and store the execution result of the business event returned by the event consumer through the state queue; Consume the status queue and determine the processing status corresponding to the business event based on the acquired execution result; Based on the predetermined callback configuration information, the processing status of the business event is called back to the event producer.

10. A computer-readable storage medium storing one or more programs, which, when executed by an electronic device including a plurality of application programs, causes the electronic device to perform the following operations: Receiving and storing business events generated by event producers through business queues, and providing the business events to event consumers through the business queues; Receive and store the execution result of the business event returned by the event consumer through the state queue; Consume the status queue and determine the processing status corresponding to the business event based on the acquired execution result; Based on the predetermined callback configuration information, the processing status of the business event is called back to the event producer.

Images