CN116149811A

CN116149811A - Task processing method and device, electronic equipment and computer readable medium

Info

Publication number: CN116149811A
Application number: CN202211694212.5A
Authority: CN
Inventors: 吴路
Original assignee: Beijing Jingdong Tuoxian Technology Co Ltd
Current assignee: Beijing Jingdong Tuoxian Technology Co Ltd
Priority date: 2022-12-28
Filing date: 2022-12-28
Publication date: 2023-05-23

Abstract

The application discloses a task processing method, a task processing device, electronic equipment and a computer readable medium, and relates to the technical field of electronic commerce platforms; acquiring a corresponding receiving channel identifier, a receiving method identifier and a receiving party identifier based on the event identifier, and further generating an event release task; determining the type of the receiving method according to the receiving method identifier; based on the type of the receiving method, executing the event issuing task, receiving the returned task execution state identification, and updating the state of the event issuing task based on the task execution state identification. The method is compatible with continuous expansion and deep service fusion of multiple systems, supports different protocols and unified access of different systems, improves the cooperative performance of the systems, reduces the transformation cost for realizing the cooperation between the systems, and can improve the service processing efficiency.

Description

Task processing method and device, electronic equipment and computer readable medium

Technical Field

The present disclosure relates to the technical field of electronic commerce platforms, and in particular, to a task processing method, a task processing device, an electronic device, and a computer readable medium.

Background

In the cooperative scene between multi-store access and business of the physical examination center, the single-store system and the platform-based system are not capable of flexibly cooperating with the physical examination center in a unified area due to lack of unified management of business processes among stores. While a system for providing Software-as-a-Service (SaaS) through a network can realize store-by-store management, because Service logic is often isolated by tenants, realizing regional collaboration requires great reconstruction cost and has low processing efficiency on services.

Disclosure of Invention

In view of this, the embodiments of the present application provide a task processing method, apparatus, electronic device, and computer readable medium, which can solve the problem that different systems in the existing area cannot be flexibly coordinated, so that a great modification cost is required for realizing area coordination, and the processing efficiency of the service is low.

To achieve the above object, according to one aspect of the embodiments of the present application, there is provided a task processing method, including:

responding to the triggering of the subscription event, and acquiring a corresponding event identifier;

acquiring a corresponding receiving channel identifier, a receiving method identifier and a receiving party identifier based on the event identifier, and further generating an event release task;

determining the type of the receiving method according to the receiving method identifier;

based on the type of the receiving method, executing the event issuing task, receiving the returned task execution state identification, and updating the state of the event issuing task based on the task execution state identification.

Optionally, performing the event publication task includes:

acquiring an event release task list corresponding to the event identifier;

calling an event management thread, and periodically polling each task in a task list;

in response to detecting that there is a task not executing, executing the compensation call process, calling and executing the detected task not executing.

Optionally, determining the type of the receiving method according to the receiving method identifier includes:

responding to the receiving method identification as a first preset identification, and determining that the type of the receiving method is a hypertext transfer protocol;

and responding to the receiving method identification as a second preset identification, and determining the type of the receiving method as a message queue.

Optionally, acquiring the corresponding receiving channel identifier, the receiving method identifier and the receiving party identifier based on the event identifier includes:

acquiring a corresponding list based on the event identification;

and determining a corresponding receiving channel identifier, a receiving method identifier and a receiving party identifier according to the list.

Optionally, based on the type of the receiving method, performing an event publishing task includes:

responding to the receiving method type being a hypertext transfer protocol, sending an event release task to a receiver corresponding to a receiver identifier, and receiving task execution result information returned by the receiver;

and acquiring a callback address corresponding to the receiving channel identifier, and executing an event callback process based on the task execution result information and the callback address.

Optionally, updating the state of the event publication task based on the task execution state identification includes:

in response to the task execution status identification corresponding to an executed completion, the status of the event publication task is updated to completed.

Optionally, after updating the state of the event publication task based on the task execution state identification, the method further comprises:

generating notification information based on the updated state of the event issuing task;

and sending notification information to an event publisher corresponding to the triggered subscription event.

In addition, the application also provides a task processing device, which comprises:

the acquisition unit is configured to respond to the subscription event to be triggered and acquire a corresponding event identifier;

the task generating unit is configured to acquire a corresponding receiving channel identifier, a receiving method identifier and a receiving party identifier based on the event identifier, so as to generate an event release task;

a reception method type determining unit configured to determine a reception method type based on the reception method identification;

and the execution unit is configured to execute the event issuing task based on the type of the receiving method, receive the returned task execution state identification and update the state of the event issuing task based on the task execution state identification.

Optionally, the execution unit is further configured to:

acquiring an event release task list corresponding to the event identifier;

Optionally, the reception method type determining unit is further configured to:

Optionally, the task generating unit is further configured to:

acquiring a corresponding list based on the event identification;

Optionally, the execution unit is further configured to:

Optionally, the task processing device further comprises a notification unit configured to:

In addition, the application also provides a task processing electronic device, which comprises: one or more processors; and a storage device for storing one or more programs which, when executed by the one or more processors, cause the one or more processors to implement the task processing method as described above.

In addition, the application also provides a computer readable medium, on which a computer program is stored, which when executed by a processor, implements the task processing method as described above.

One embodiment of the above invention has the following advantages or benefits: the method comprises the steps of responding to a subscription event to be triggered, and obtaining a corresponding event identifier; acquiring a corresponding receiving channel identifier, a receiving method identifier and a receiving party identifier based on the event identifier, and further generating an event release task; determining the type of the receiving method according to the receiving method identifier; based on the type of the receiving method, executing the event issuing task, receiving the returned task execution state identification, and updating the state of the event issuing task based on the task execution state identification. The method is compatible with continuous expansion and deep service fusion of multiple systems, supports different protocols and unified access of different systems, improves the cooperative performance of the systems, reduces the transformation cost for realizing the cooperation between the systems, and can improve the service processing efficiency.

Further effects of the above-described non-conventional alternatives are described below in connection with the embodiments.

Drawings

The drawings are included to provide a better understanding of the present application and are not to be construed as unduly limiting the present application. Wherein:

FIG. 1 is a schematic diagram of the main flow of a task processing method provided according to one embodiment of the present application;

FIG. 2 is a schematic diagram of the main flow of a task processing method provided according to one embodiment of the present application;

FIG. 3 is a schematic view of an application scenario of a task processing method according to an embodiment of the present application;

FIG. 4 is a schematic view of an application scenario of a task processing method according to an embodiment of the present application;

FIG. 5 is a schematic diagram of the main units of a task processing device according to an embodiment of the present application;

FIG. 6 is an exemplary system architecture diagram in which embodiments of the present application may be applied;

fig. 7 is a schematic diagram of a computer system suitable for use in implementing the terminal device or server of the embodiments of the present application.

Detailed Description

Exemplary embodiments of the present application are described below in conjunction with the accompanying drawings, which include various details of the embodiments of the present application to facilitate understanding, and should be considered as merely exemplary. Accordingly, one of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the present application. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness. It should be noted that, in the technical solution of the present disclosure, the related aspects of collecting, updating, analyzing, processing, using, transmitting, storing, etc. of the personal information of the user all conform to the rules of the related laws and regulations, and are used for legal purposes without violating the public order colloquial. Necessary measures are taken for the personal information of the user, illegal access to the personal information data of the user is prevented, and the personal information security, network security and national security of the user are maintained.

Fig. 1 is a schematic diagram of main flow of a task processing method according to an embodiment of the present application, and as shown in fig. 1, the task processing method includes:

step S101, responding to the subscription event to be triggered, and acquiring a corresponding event identification.

In this embodiment, an execution body (for example, a server) of the task processing method may detect whether a subscription event is triggered in real time by means of wired connection or wireless connection, and acquire a corresponding event identifier when detecting that the subscription event is triggered. The event may be an event for modifying the price of the package, or an event for issuing a message. The embodiment of the application does not specifically limit the event type corresponding to the event identifier.

Step S102, acquiring a corresponding receiving channel identifier, a receiving method identifier and a receiving party identifier based on the event identifier, and further generating an event release task.

Specifically, acquiring the corresponding receiving channel identifier, receiving method identifier and receiving party identifier based on the event identifier comprises the following steps:

based on the event identification, a corresponding list is obtained, which may be, for example, a subscription list. Subscription list may contain subscription event information, receiver information, and association relationship information of the subscription event information and the receiver information. The recipient information may include a receiving channel identification, a receiving method identification, and a recipient identification.

The corresponding receiving channel identifier, for example JSQD (acronym for receiving channel), the corresponding receiving method identifier, for example JSFF (acronym for receiving method), and the corresponding receiving party identifier, for example JJS (acronym for receiving party) are searched for from the list. In particular, the receiving identity may also carry an additional item which characterizes the way the data transmission takes place. In particular, the additional item may identify http for the hypertext transfer protocol or MQ for the message queue.

Step S103, determining the type of the receiving method according to the receiving method identification.

The execution body may determine the reception method type from an additional item in the reception method identification. For example, when the additional item is a hypertext transfer protocol identifier http, the corresponding receiving method type is a hypertext transfer protocol, i.e. the receiving party receives the message via the hypertext transfer protocol. When the additional item is a message queue identifier, the MQ is used for receiving the message, and the corresponding receiving method type is a message queue, namely, a receiver receives the message through the message queue.

Specifically, determining the type of the receiving method according to the receiving method identifier includes: responding to the receiving method identifier as a first preset identifier, wherein the first preset identifier can be http, and determining that the type of the receiving method is a hypertext transfer protocol; in response to the receiving method identity being a second preset identity, which may be, for example, an MQ, it is determined that the receiving method type is a message queue.

Step S104, executing the event issuing task based on the receiving method type, receiving the returned task execution state identification, and updating the state of the event issuing task based on the task execution state identification.

Specifically, based on the type of the receiving method, executing the event issuing task includes: responding to the receiving method type being a hypertext transfer protocol, sending an event release task to a receiver corresponding to a receiver identifier, and receiving task execution result information returned by the receiver; and acquiring a callback address corresponding to the receiving channel identifier, and executing an event callback process based on the task execution result information and the callback address.

If the reception method type is hypertext transfer protocol http, where http is a simple request-response protocol, it runs on top of TCP. It specifies what messages the client might send to the server and what responses get, calls the callback address registered by the listener, informs the listener to perform the task, and converts the call return information into message ack, acknowledge character, which is an acknowledgement character, a transmission class control character that the receiving station sends to the sending station in data communication. Indicating that the transmitted data has been acknowledged with no errors. In the TCP/IP protocol, if the receiving party successfully receives the data, an ack data is replied, and the corresponding task state is modified to be that the data is sent.

If the type of the data receiving method is a message queue MQ, sending MQ message to inform the listener, monitoring the return message of the event, or judging whether the task is successfully executed according to callback information of the listener, and correspondingly modifying the task state.

Specifically, updating the state of the event publication task based on the task execution state identification includes: in response to the task execution status identification corresponding to an executed completion, the status of the event publication task is updated to completed.

Specifically, after updating the state of the event publication task based on the task execution state identification, the method further includes: generating notification information based on the updated state of the event issuing task; and sending notification information to an event publisher corresponding to the triggered subscription event.

For example, the execution body may periodically poll the event task execution progress by calling an event management thread, and if there is an event that has a task that is not executed, make a compensation call; if all tasks of an event decomposition have been performed to completion, the event state is marked as completed and the event publisher is notified. The event publisher may be, for example, a user that triggers a subscription event.

The embodiment acquires the corresponding event identification by responding to the triggering of the subscription event; acquiring a corresponding receiving channel identifier, a receiving method identifier and a receiving party identifier based on the event identifier, and further generating an event release task; determining the type of the receiving method according to the receiving method identifier; based on the type of the receiving method, executing the event issuing task, receiving the returned task execution state identification, and updating the state of the event issuing task based on the task execution state identification. The method is compatible with continuous expansion and deep service fusion of multiple systems, supports different protocols and unified access of different systems, improves the cooperative performance of the systems, reduces the transformation cost for realizing the cooperation between the systems, and can improve the service processing efficiency.

Fig. 2 is a main flow diagram of a task processing method according to an embodiment of the present application, and as shown in fig. 2, the task processing method includes:

step S201, responding to the subscription event to be triggered, and acquiring a corresponding event identification.

The subscription event may be an event triggered when the program is executing abnormally. When the subscription event is triggered, the acquired event identifier may be the number of the event or the name of the event, which is not specifically limited in the embodiment of the present application.

Step S202, acquiring a corresponding receiving channel identifier, a receiving method identifier and a receiving party identifier based on the event identifier, and further generating an event release task.

The receiving channel identifies the name or number or the like of the channel used to characterize the result of the execution of the receiving task. The channel may be, for example, an app, applet, etc.

Step S203, according to the receiving method identification, the type of the receiving method is determined.

Step S204, an event release task list corresponding to the event identification is obtained.

There may be multiple tasks per event. The execution body may obtain an event publication task list corresponding to each event identification. The tasks in the list may be sequentially executed in series or asynchronously executed, and the execution mode of the tasks in the event release task list is not particularly limited in the embodiment of the present application.

Step S205, calling an event management thread, and periodically polling each task in a task list;

in step S206, in response to detecting that there is a task not executed, the compensation calling process is executed, and the detected task not executed is called and executed.

And compensating the call, and re-polling and calling the unexecuted task to improve the success rate of task execution. The event management thread periodically polls the execution progress of the event task, and if the event is not executed, compensation calling is carried out; if all tasks of an event decomposition have been performed to completion, the event state is marked as completed and the event publisher is notified.

Step S207, receiving the returned task execution status identification, and updating the status of the event publishing task based on the task execution status identification.

For example, when the task execution state is identified as Y, the state of the corresponding event issuing task may be completed, and when the task execution state is identified as N, the state of the corresponding event issuing task may be failed.

According to the embodiment of the application, the offline store system is realized through an event mechanism, interaction cooperation of the foreground system and the platform middle station capability is compatible with continuous expansion and deep service fusion of multiple stores, and unified access of different protocols and different systems is supported.

Fig. 3 is an application scenario diagram of a task processing method according to an embodiment of the present application. The task processing method is applied to the platform internal capacity and the event interaction scene between offline stores. As shown in fig. 3, taking interaction among a physical examination center foreground, a platform internal capability, a physical examination event management center and an offline store system access port as an example, firstly, a C-terminal applet, a PC operation terminal and a doctor workstation perform event interaction with the physical examination event management center through the physical examination center foreground, and store events, physical examination package events, order events, physical examination reservation events, channel registration, event release and event subscription in the physical examination event management center perform event interaction with a functional implementation middle stage between the platform internal capability respectively. By way of example, the functional implementation platform may include a retail platform, a scientific platform, a health platform, and the like, and the functional implementation platform is not specifically limited in the embodiments of the present application. And the self-body physical examination store, the acquisition store/chain and the allied physical examination center are added into the physical examination event management center through the off-line store system to perform event interaction. Therefore, the method is compatible with continuous expansion and deep service fusion of multiple systems, supports different protocols and unified access of different systems, and improves the cooperative performance among the systems.

Fig. 4 is a schematic application scenario diagram of a task processing method according to an embodiment of the present application. As shown in fig. 4, the event center receives an event issuing command, and further distributes a distributed id to an event, so as to obtain an event identifier, perform buffering on the event to obtain an event queue, store each event in the event queue, and mark the event as to-be-sent. Inquiring a subscriber list of the event, acquiring a receiving channel, a receiving method and receiver information of each subscriber, and generating an event publishing task. The generated event issuing task can be issued through each channel, and the corresponding channel can be determined according to the type of the receiving method. For example, channel 1 is associated with a receiving method type corresponding to a hypertext transfer protocol http event callback, channel 2 is associated with a receiving method type corresponding to a message queue event publication, and channel N is associated with a receiving method type corresponding to other message queue publications. When the event issuing task issues via the http event callback corresponding to the channel 1, the ack1 is returned when the event issuing task issues via the message queue event corresponding to the channel 2, when the event issuing task issues successfully, the ack2 is returned, and when the event issuing task issues via other message queues corresponding to the channel 3, the ack N is returned when the event issuing task issues successfully. The executing body may trigger a statistics event to make ack statistics and make a change in task state based on the counted acks. The publishing of the log queue and the publishing of the saved log are then performed. And finally, checking that the event release task is not missed based on the event task compensation polling, and ensuring the smooth and normal execution of each task.

Taking a new store access flow as an example, access channels are registered, and each access party corresponds to one access channel, which may be a SaaS system of a chain store or a single store system. The store is opened, the business dictionary based on store dimension synchronization is used, event messages of business dictionary change are registered, and corresponding interface capability is realized. And registering and monitoring the business event, and ensuring the corresponding business event to realize bidirectional intercommunication aiming at the business range of the store.

By way of example, taking the event stream of the front-end office initiating package price modification as an example, the event management center realizes the cooperative linkage of the business front-end office, the off-line store system and the middle-end office system based on an event mechanism, and realizes the unified management of business logic, and here, the front-end office modifying package sku price is illustrated as an example:

the foreground initiates modification of package sku price, queries the used store and package through the synchronous business dictionary, and issues event message a-applies for modification of C-terminal physical examination package price; the event management center monitors the event a and generates a corresponding event task; notifying each corresponding off-line store to modify the corresponding package price; informing the retail center to modify the corresponding sku price; the event management center monitors package price modification event feedback of off-line stores, and when all the store package prices are successfully modified, the event management center issues a message b-the off-line package price is modified; the event management center monitors retail mq, and when the price modification is completed, a message c is sent that the sku price of the retail center is modified; the event management center monitors the messages b and c, and when the feedback price modification is completed, the event d-sku price is sent to be completed synchronously; and the foreground monitors the message d and completes the modification of the sku price in the foreground database. The embodiment of the application provides a device and a process for realizing the intelligent coordination of business between stores by uniformly accessing different physical examination systems with low cost and performing on-line and off-line business depth fusion based on an event mechanism.

Fig. 5 is a schematic diagram of main units of a task processing device according to an embodiment of the present application. As shown in fig. 5, the task processing device 500 includes an acquisition unit 501, a task generation unit 502, a reception method type determination unit 503, and an execution unit 504.

The acquiring unit 501 is configured to acquire the corresponding event identifier in response to the subscription event being triggered.

The task generating unit 502 is configured to obtain a corresponding receiving channel identifier, a receiving method identifier and a receiving party identifier based on the event identifier, so as to generate an event release task.

The reception method type determining unit 503 is configured to determine the reception method type according to the reception method identification.

The execution unit 504 is configured to execute the event issuing task based on the type of the receiving method, receive the returned task execution status identification, and update the status of the event issuing task based on the task execution status identification.

In some embodiments, the execution unit 504 is further configured to: acquiring an event release task list corresponding to the event identifier; calling an event management thread, and periodically polling each task in a task list; in response to detecting that there is a task not executing, executing the compensation call process, calling and executing the detected task not executing.

In some embodiments, the reception method type determination unit 503 is further configured to: responding to the receiving method identification as a first preset identification, and determining that the type of the receiving method is a hypertext transfer protocol; and responding to the receiving method identification as a second preset identification, and determining the type of the receiving method as a message queue.

In some embodiments, the task generating unit 502 is further configured to: acquiring a corresponding list based on the event identification; and determining a corresponding receiving channel identifier, a receiving method identifier and a receiving party identifier according to the list.

In some embodiments, the execution unit 504 is further configured to: responding to the receiving method type being a hypertext transfer protocol, sending an event release task to a receiver corresponding to a receiver identifier, and receiving task execution result information returned by the receiver; and acquiring a callback address corresponding to the receiving channel identifier, and executing an event callback process based on the task execution result information and the callback address.

In some embodiments, the execution unit 504 is further configured to: in response to the task execution status identification corresponding to an executed completion, the status of the event publication task is updated to completed.

In some embodiments, the task processing device further comprises a notification unit, not shown in fig. 5, configured to: generating notification information based on the updated state of the event issuing task; and sending notification information to an event publisher corresponding to the triggered subscription event.

The task processing method and the task processing device of the present application have a corresponding relationship in terms of implementation content, and therefore, the repetitive content will not be described.

Fig. 6 illustrates an exemplary system architecture 600 in which the task processing methods or task processing devices of embodiments of the present application may be applied.

As shown in fig. 6, the system architecture 600 may include

terminal devices

601, 602, 603, a network 604, and a server 605. The network 604 is used as a medium to provide communication links between the

terminal devices

601, 602, 603 and the server 605. The network 604 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others.

A user may interact with the server 605 via the network 604 using the

terminal devices

601, 602, 603 to receive or send messages, etc. Various communication client applications such as shopping class applications, web browser applications, search class applications, instant messaging tools, mailbox clients, social platform software, etc. (by way of example only) may be installed on the

terminal devices

601, 602, 603.

The

terminal devices

601, 602, 603 may be various electronic devices having a task processing screen and supporting web browsing, including but not limited to smartphones, tablets, laptop and desktop computers, and the like.

The server 605 may be a server providing various services, such as a background management server (by way of example only) providing support for subscription events triggered by users using the

terminal devices

601, 602, 603. The background management server can respond to the subscription event to be triggered to acquire a corresponding event identifier; acquiring a corresponding receiving channel identifier, a receiving method identifier and a receiving party identifier based on the event identifier, and further generating an event release task; determining the type of the receiving method according to the receiving method identifier; based on the type of the receiving method, executing the event issuing task, receiving the returned task execution state identification, and updating the state of the event issuing task based on the task execution state identification. The method is compatible with continuous expansion and deep service fusion of multiple systems, supports different protocols and unified access of different systems, improves the cooperative performance of the systems, reduces the transformation cost for realizing the cooperation between the systems, and can improve the service processing efficiency.

It should be noted that, the task processing method provided in the embodiment of the present application is generally executed by the server 605, and accordingly, the task processing device is generally disposed in the server 605.

It should be understood that the number of terminal devices, networks and servers in fig. 6 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

Referring now to fig. 7, there is illustrated a schematic diagram of a computer system 700 suitable for use in implementing the terminal device of an embodiment of the present application. The terminal device shown in fig. 7 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present application.

As shown in fig. 7, the computer system 700 includes a Central Processing Unit (CPU) 701, which can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) 702 or a program loaded from a storage section 708 into a Random Access Memory (RAM) 703. In the RAM703, various programs and data required for the operation of the computer system 700 are also stored. The CPU701, ROM702, and RAM703 are connected to each other through a bus 704. An input/output (I/O) interface 705 is also connected to bus 704.

The following components are connected to the I/O interface 705: an input section 706 including a keyboard, a mouse, and the like; an output section 707 including a Cathode Ray Tube (CRT), a liquid crystal credit authorization query processor (LCD), and the like, and a speaker, and the like; a storage section 708 including a hard disk or the like; and a communication section 709 including a network interface card such as a LAN card, a modem, or the like. The communication section 709 performs communication processing via a network such as the internet. The drive 710 is also connected to the I/O interface 705 as needed. A removable medium 711 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 710 as necessary, so that a computer program read therefrom is mounted into the storage section 708 as necessary.

In particular, according to embodiments of the present disclosure, the processes described above with reference to flowcharts may be implemented as computer software programs. For example, embodiments disclosed herein include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method shown in the flowcharts. In such an embodiment, the computer program may be downloaded and installed from a network via the communication portion 709, and/or installed from the removable medium 711. The above-described functions defined in the system of the present application are performed when the computer program is executed by a Central Processing Unit (CPU) 701.

It should be noted that the computer readable medium shown in the present application may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium may include, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present application, however, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units involved in the embodiments of the present application may be implemented by software, or may be implemented by hardware. The described units may also be provided in a processor, for example, described as: a processor includes an acquisition unit, a task generation unit, a reception method type determination unit, and an execution unit. Wherein the names of the units do not constitute a limitation of the units themselves in some cases.

As another aspect, the present application also provides a computer-readable medium that may be contained in the apparatus described in the above embodiments; or may be present alone without being fitted into the device. The computer readable medium carries one or more programs which, when executed by one of the devices, cause the device to obtain a corresponding event identification in response to a subscription event being triggered; acquiring a corresponding receiving channel identifier, a receiving method identifier and a receiving party identifier based on the event identifier, and further generating an event release task; determining the type of the receiving method according to the receiving method identifier; based on the type of the receiving method, executing the event issuing task, receiving the returned task execution state identification, and updating the state of the event issuing task based on the task execution state identification.

According to the technical scheme of the embodiment of the application, the continuous expansion and the deep service fusion of multiple systems are compatible, different protocols are supported, unified access of different systems is realized, the cooperative performance among the systems is improved, the cooperative transformation cost among the systems is reduced, and the service processing efficiency can be improved.

The above embodiments do not limit the scope of the application. It will be apparent to those skilled in the art that various modifications, combinations, sub-combinations and alternatives can occur depending upon design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present application are intended to be included within the scope of the present application.

Claims

1. A method of task processing, comprising:

and executing the event release task based on the type of the receiving method, receiving a returned task execution state identifier, and updating the state of the event release task based on the task execution state identifier.

2. The method of claim 1, wherein the performing the event publication task comprises:

acquiring an event release task list corresponding to the event identifier;

invoking an event management thread to periodically poll each task in the task list;

3. The method of claim 1, wherein said determining a reception method type from said reception method identification comprises:

and responding to the receiving method identifier as a second preset identifier, and determining the type of the receiving method as a message queue.

4. The method of claim 1, wherein the obtaining the corresponding receiving channel identifier, receiving method identifier, and receiving party identifier based on the event identifier comprises:

acquiring a corresponding list based on the event identification;

5. The method of claim 1, wherein the performing the event publication task based on the reception method type comprises:

responding to the receiving method type being a hypertext transfer protocol, sending the event release task to a receiver corresponding to the receiver identifier, and receiving task execution result information returned by the receiver;

6. The method of claim 1, wherein updating the state of the event publication task based on the task execution state identification comprises:

and in response to the task execution status identification corresponding to the executed completion, updating the status of the event publication task to completed.

7. The method of claim 1, wherein after updating the status of the event publication task based on the task execution status identification, the method further comprises:

and sending the notification information to the event publisher corresponding to the triggered subscription event.

8. A task processing device, comprising:

a reception method type determining unit configured to determine a reception method type according to the reception method identification;

the execution unit is configured to execute the event issuing task based on the receiving method type, receive the returned task execution state identification, and update the state of the event issuing task based on the task execution state identification.

9. The apparatus of claim 8, wherein the execution unit is further configured to:

acquiring an event release task list corresponding to the event identifier;

10. The apparatus of claim 8, wherein the reception method type determination unit is further configured to:

11. A task processing electronic device, comprising:

one or more processors;

storage means for storing one or more programs,

when executed by the one or more processors, causes the one or more processors to implement the method of any of claims 1-7.

12. A computer readable medium, on which a computer program is stored, characterized in that the program, when being executed by a processor, implements the method according to any of claims 1-7.