A retry callback method, apparatus, computing device, and storage medium

Abstract

The application discloses a retry callback method and device, a computing device and a storage medium. The method comprises the following steps: listening to whether there is to-be-executed data; if the to-be-executed data is listened to, generating corresponding demand data according to the to-be-executed data; calling a preset interface, so as to push the demand data to a demand side through the preset interface; if the calling fails, generating the demand data again according to a retry strategy and calling the preset interface, so as to push the demand data to the demand side.

Description

Technical Field

[0001] This invention relates to the field of Internet technology, and in particular to a retry callback method, apparatus, computing device, and storage medium. Background Technology

[0002] With the continuous development of internet technology, online business models have become more diversified, gradually forming a type of rights and benefits aggregation platform to realize various cross-industry cooperation businesses online (such as mobile phone top-ups, membership card sales, etc.). Users no longer need to install various applications on their smartphones to purchase goods; instead, the aforementioned rights and benefits aggregation platform meets their daily needs.

[0003] The service providers of aggregation functions operate extremely complex systems behind the scenes to support seamless integration and efficient operation between various businesses. They enrich the aggregation functions through cooperation with third parties and traffic swapping. Once the cooperation is established, a series of system integrations are inevitable. If the initial integration fails due to network or internal system issues, and it is necessary to push some data to a third party, a retry callback system is required to attempt a re-pushing after the system integration is successful.

[0004] Currently, there are two common retry callback solutions. The first is to use the Spring Retry component under the Spring framework (a lightweight inversion of control and aspect-oriented programming container framework) for retry callbacks, such as re-pushing when order push fails. This is suitable for small teams with little collaboration and simple business logic. However, this solution can easily lead to mutual intrusion between systems, making decoupling difficult. Furthermore, since retries exist within the Spring container, system releases may pause retries, preventing critical node data from being properly transmitted back to third parties. This is not conducive to the division of labor and parallel development in large teams.

[0005] The second approach involves building a retry callback system. This system is responsible for handling retries and collecting retry execution data, storing it in a database. Each retry execution data point is pushed to the third party at a default interval. By scheduling retries, the push is completed until the push is successful. While the above solution decouples the overall system and utilizes a database to store relevant data, it inevitably requires adding callback methods for retries to meet different third-party needs. This increases the complexity between systems, and subsequent troubleshooting requires checking multiple system logs.

[0006] Therefore, a new retry callback method is needed to optimize the above processing. Summary of the Invention

[0007] Therefore, the present invention provides a retry callback scheme in an attempt to solve or at least alleviate the problems mentioned above.

[0008] According to one aspect of the present invention, a retry callback method is provided, comprising the following steps: first, listening for any pending data; if pending data is detected, generating corresponding demand data based on the pending data; calling back a preset interface to push the demand data to the demand party through the preset interface; if the callback fails, regenerating the demand data according to the retry strategy and calling back the preset interface to push the demand data to the demand party.

[0009] Optionally, the retry callback method according to the present invention further includes: receiving basic data sent by the business system and storing it; associating the basic data with corresponding execution information to convert the basic data into data to be executed, wherein the execution information includes execution status, execution parameters, execution return value and execution count.

[0010] Optionally, in the retry callback method according to the present invention, the business system integrates a retry function and sends basic data through a predefined communication message body.

[0011] Optionally, in the retry callback method according to the present invention, the data to be executed includes an order number, an order type, and an order channel. The step of generating corresponding demand data based on the data to be executed includes: finding the corresponding business type based on the order type and the order channel; querying order-related data based on the order number and the business type and assembling it to generate demand data.

[0012] Optionally, in the retry callback method according to the present invention, the retry strategy includes performing a retry callback once every preset retry time interval within a retry count threshold until the callback is successful.

[0013] Optionally, the retry callback method according to the present invention further includes changing the retry strategy. The step of changing the retry strategy includes: changing the retry time interval to change the retry strategy.

[0014] Optionally, in the retry callback method according to the present invention, the step of regenerating the demand data and calling back the preset interface to push the demand data to the demand party according to the retry strategy includes: within the retry number threshold, regenerating the demand data according to the data to be executed every preset retry time interval, calling back the preset interface to push the demand data to the demand party through the preset interface, and updating the execution information according to the callback result until the callback is successful.

[0015] According to another aspect of the present invention, a retry callback device is provided, comprising a listening module, a generation module, a callback module, and a retry module. The listening module is adapted to monitor whether there is data to be executed; the generation module is adapted to generate corresponding demand data based on the data to be executed when it detects data to be executed; the callback module is adapted to call back a preset interface to push the demand data to the demand party through the preset interface; and the retry module is adapted to, when the callback fails, call the generation module to regenerate the demand data according to a retry strategy and call back the preset interface through the callback module to push the demand data to the demand party.

[0016] According to another aspect of the present invention, a computing device is provided, comprising: at least one processor; and a memory storing program instructions, wherein the program instructions are configured to be executed by the at least one processor, the program instructions including instructions for performing the retry callback method as described above.

[0017] According to another aspect of the present invention, a readable storage medium storing program instructions is provided, which, when read and executed by a computing device, causes the computing device to perform the retry callback method as described above.

[0018] According to the retry callback scheme of the present invention, if data to be executed is detected, corresponding demand data is generated based on the data to be executed, and a preset interface is called back to push the demand data to the demand party through the preset interface. If the callback fails, the demand data is regenerated and the preset interface is called back according to the retry strategy to push the demand data to the demand party, thus realizing a compensation mechanism when the interface callback fails.

[0019] In the above technical solution, the data to be executed is generated based on the basic data sent by the business system. For the business system, it only needs to transmit the basic data according to the pre-defined communication message body, without needing to worry about how to handle retry callbacks. By highly refining and abstracting cross-system interface calls, the error retry support function is separated from the business system, making the two completely decoupled, allowing for independent deployment without mutual interference, thus improving development efficiency and system stability. Furthermore, the retry strategy can be changed as needed, ensuring the accuracy of data exchange between cross-industry partners. Attached Figure Description

[0020] To achieve the foregoing and related objectives, certain illustrative aspects are described herein in conjunction with the following description and accompanying drawings. These aspects indicate various ways in which the principles disclosed herein may be practiced, and all aspects and their equivalents are intended to fall within the scope of the claimed subject matter. The foregoing and other objectives, features, and advantages of this disclosure will become more apparent from the following detailed description, taken in conjunction with the accompanying drawings. Throughout this disclosure, the same reference numerals generally refer to the same parts or elements.

[0021] Figure 1 A structural block diagram of a computing device 100 according to an embodiment of the present invention is shown;

[0022] Figure 2 A flowchart of a retry callback method 200 according to an embodiment of the present invention is shown; and

[0023] Figure 3 A schematic diagram of a retry callback device 300 according to an embodiment of the present invention is shown. Detailed Implementation

[0024] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0025] Figure 1 A structural block diagram of a computing device 100 according to an embodiment of the present invention is shown.

[0026] like Figure 1 As shown, in the basic configuration 102, the computing device 100 typically includes system memory 106 and one or more processors 104. Memory bus 108 can be used for communication between processor 104 and system memory 106.

[0027] Depending on the desired configuration, processor 104 can be any type of processor, including but not limited to: microprocessor (UP), microcontroller (UC), digital information processor (DSP), or any combination thereof. Processor 104 may include one or more levels of cache such as L1 cache 110 and L2 cache 112, processor core 114, and registers 116. Example processor core 114 may include an arithmetic logic unit (ALU), floating-point unit (FPU), digital signal processing core (DSP core), or any combination thereof. Example memory controller 118 may be used with processor 104, or in some implementations, memory controller 118 may be an internal part of processor 104.

[0028] Depending on the desired configuration, system memory 106 can be any type of memory, including but not limited to volatile memory (such as RAM), non-volatile memory (such as ROM, flash memory, etc.), or any combination thereof. System memory 106 may include operating system 120, one or more applications 122, and program data 124. In some embodiments, application 122 may be arranged to execute instructions on the operating system using program data 124 by one or more processors 104.

[0029] The computing device 100 also includes a storage device 132, which includes a removable storage device 136 and a non-removable storage device 138.

[0030] The computing device 100 may also include a storage interface bus 134. The storage interface bus 134 enables communication from storage devices 132 (e.g., removable storage 136 and non-removable storage 138) to the basic configuration 102 via a bus / interface controller 130. At least a portion of the operating system 120, application 122, and program data 124 may be stored on the removable storage 136 and / or the non-removable storage 138, and loaded into system memory 106 via the storage interface bus 134 when the computing device 100 is powered on or when application 122 is to be executed, and executed by one or more processors 104.

[0031] The computing device 100 may also include an interface bus 140 that facilitates communication from various interface devices (e.g., output devices 142, peripheral interfaces 144, and communication devices 146) to the basic configuration 102 via a bus / interface controller 130. Example output devices 142 include a graphics processing unit 148 and an audio processing unit 150. They may be configured to facilitate communication with various external devices such as displays or speakers via one or more A / V ports 152. Example peripheral interfaces 144 may include a serial interface controller 154 and a parallel interface controller 156, which may be configured to facilitate communication with external devices such as input devices (e.g., keyboards, mice, pens, voice input devices, touch input devices) or other peripherals (e.g., printers, scanners, etc.) via one or more I / O ports 158. Example communication devices 146 may include a network controller 160, which may be arranged to facilitate communication with one or more other computing devices 162 via a network communication link through one or more communication ports 164.

[0032] A network communication link can be an example of a communication medium. A communication medium can typically be embodied in a modulated data signal, such as a carrier wave or other transmission mechanism, and can include any information delivery medium. A “modulated data signal” can be a signal whose data set, or its modifications, can be encoded as information within the signal. As a non-limiting example, a communication medium can include wired media such as wired networks or leased lines, and various wireless media including sound, radio frequency (RF), microwave, infrared (IR), or other wireless media. The term “computer-readable medium” as used herein can include both storage media and communication media.

[0033] The computing device 100 can be implemented as a personal computer, including desktop and laptop computer configurations. Of course, the computing device 100 can also be implemented as part of a small-sized portable (or mobile) electronic device, such as a cellular phone, digital camera, personal digital assistant (PDA), personal media player device, wireless network browsing device, personal head-mounted device, application-specific device, or a hybrid device that may include any of the above functions. It can even be implemented as a server, such as a file server, database server, application server, and web server. The embodiments of the present invention do not limit this.

[0034] In an embodiment of the present invention, computing device 100 is configured to execute retry callback method 200 according to the present invention. Application 122, arranged on an operating system, includes multiple program instructions for executing the retry callback method 200 of the present invention. These program instructions can instruct processor 104 to execute the retry callback method 200 of the present invention, so that computing device 100 performs a retry callback by executing the retry callback method 200 of the present invention.

[0035] According to one embodiment of the present invention, an application 122 arranged on an operating system includes a retry callback device 300, which contains multiple program instructions for executing the retry callback method 200 of the present invention, so that the retry callback method 200 of the present invention can be executed in the retry callback device 300.

[0036] Figure 2 A flowchart of a retry callback method 200 according to an embodiment of the present invention is shown. The retry callback method 200 can be executed in the retry callback device 300 of a computing device (e.g., the aforementioned computing device 100).

[0037] like Figure 2 As shown, method 200 begins with step S210. In step S210, it listens for data to be executed.

[0038] The data to be executed is generated based on the basic data sent by the business system. Therefore, according to one embodiment of the present invention, method 200 further includes receiving and storing the basic data sent by the business system. The basic data includes order number, order type, order channel, master order identifier, order status, and sub-order identifier.

[0039] The business system integrates a retry function and sends basic data through a pre-defined communication message body. In this implementation, the business system integrates the retry function with a single click using a POM (Project Object Model) file. The POM file includes version information of the dependent JAR (Java Archive) packages, effectively providing the interface functionality for the communication message body within the JAR packages. The business system only needs to call the interface methods within the JAR packages. After the business system integrates the retry function, it is packaged and deployed to the production server.

[0040] The communication message body is JSON (JavaScript Object Notation) serialized data of the underlying data. When a business system sends this underlying data using the communication message body, it is essentially transmitting the JSON-serialized underlying data. Therefore, upon receiving the JSON-serialized underlying data from the business system, it needs to be parsed to obtain the original underlying data before storing this data in the database. This database refers to a library for retry callbacks, typically deployed independently on a database server.

[0041] Then, the corresponding execution information is associated with the basic data to transform it into data to be executed. The execution information includes the execution status, execution parameters, execution return value, and execution count. The execution status is essentially a marker for the basic data, corresponding to the status of the subsequent retry callback. The execution parameters are the relevant parameters when the retry callback is executed. The execution return value is the result of the retry callback, and the execution count is obviously the number of times the retry callback has been executed.

[0042] Then, proceed to step S220. If data to be executed is detected, generate the corresponding requirement data based on the data to be executed.

[0043] As shown above, the data to be executed is largely the same as the basic data, except that additional execution information is added. This data includes order number, order type, and order channel, but these are only the main order information and not all the information pushed to the requesting party. Therefore, it is necessary to retrieve the auxiliary information from the data to be executed, encapsulate it to obtain the required data, and then send it to the requesting party. Here, the requesting party can be understood as a collaborating third party.

[0044] According to one embodiment of the present invention, corresponding demand data can be generated based on the data to be executed in the following manner. In this embodiment, firstly, the corresponding business type is found based on the order type and order channel. Then, based on the order number and business type, order-related data is queried and assembled, for example, order-related data stored in a database can be read and assembled to generate demand data.

[0045] In step S230, a preset interface is called back to push the demand data to the demander. According to one embodiment of the present invention, the preset interface is a demander interface; by calling the demander interface, the demand data is pushed to the demander. Furthermore, regardless of whether the callback succeeds or fails, the execution information should be updated based on the callback result and stored in the database.

[0046] Finally, step S240 is executed. If the callback fails, the requirement data is regenerated and the preset interface is called back according to the retry strategy to push the requirement data to the requester.

[0047] According to one embodiment of the present invention, the retry strategy includes executing a retry callback once every preset retry time interval within a retry count threshold until the callback is successful. The retry count threshold is set to 5, indicating that no further retries will be initiated after 5 retry callbacks. The default retry time interval is 5 minutes, meaning that a retry callback is executed every 5 minutes. Changes in the retry time interval can cause changes in the retry strategy.

[0048] According to one embodiment of the present invention, method 200 further includes changing the retry strategy, specifically, changing the retry time interval to change the retry strategy. Typically, for different data to be executed, the retry strategy is adaptively modified to adjust the retry time interval based on data characteristics and specific scenarios, which better meets the requirements of practical applications.

[0049] According to one embodiment of the present invention, the requirement data can be regenerated and a preset interface can be called back according to a retry strategy to push the requirement data to the requester. In this embodiment, within a retry count threshold, the requirement data is regenerated based on the data to be executed every preset retry time interval, the preset interface is called back to push the requirement data to the requester through the preset interface, and the execution information is updated according to the callback result until the callback is successful.

[0050] For example, when a callback fails, provided that the number of retries does not exceed the retry threshold (i.e., no more than 5 retries), the corresponding requirement data is regenerated based on the data to be executed every preset retry time interval, such as 5 minutes. The requester interface is then called back to push the requirement data to the requester through the requester interface, and the execution information is updated based on the callback result until the callback succeeds.

[0051] According to another embodiment of the present invention, method 200 further includes: if the callback still fails after executing the retry strategy, an alarm message is sent to relevant personnel in the business system. The alarm message includes the order number, business type, execution parameters, and the address of the preset interface. In other words, when the number of retries reaches the retry threshold, retries are no longer initiated proactively. If further retries are desired, manual intervention is required to find the cause and manually push back the device.

[0052] During the execution of retry callbacks, execution records are generated based on the execution status. These records reflect relevant information about the retry callbacks, including order number, order status, business type, invocation method, execution time, execution status, number of executions, retry strategy, and component name. Furthermore, the execution records and retry strategies can be visualized through the interface for a more intuitive and easier viewing experience.

[0053] Figure 3 A schematic diagram of a retry callback device 300 according to an embodiment of the present invention is shown. The retry callback device 300 resides in a computing device (e.g., the aforementioned computing device 100). The retry callback device 300 performs a retry callback by executing the retry callback method 200 of the present invention.

[0054] like Figure 3 As shown, the retry callback device 300 includes a listening module 310, a generation module 320, a callback module 330 and a retry module 340 connected in sequence. The generation module 320 is also connected to the retry module 340.

[0055] The listening module 310 can monitor whether there is data to be executed. The generation module 320, upon detecting data to be executed, generates corresponding requirement data based on that data. Subsequently, the callback module 330 can call back a preset interface to push the requirement data to the requester. The retry module 340, if the callback fails, can, according to a retry strategy, call the generation module 320 to regenerate the requirement data and, through the callback module 330, call back the preset interface to push the requirement data to the requester.

[0056] It should be noted that the listening module 310 is used to execute the aforementioned step S210, the generating module 320 is used to execute the aforementioned step S220, the callback module 330 is used to execute the aforementioned step S230, and the retry module 340 is used to execute the aforementioned step S240. The execution logic of the listening module 310, the generating module 320, the callback module 330, and the retry module 340 can be found in the detailed description of steps S210 to S240 in method 200 above, and will not be repeated here.

[0057] According to the retry callback scheme of this invention, if data to be executed is detected, corresponding demand data is generated based on the data to be executed, and a preset interface is called back to push the demand data to the demand party through the preset interface. If the callback fails, the demand data is regenerated and the preset interface is called back according to the retry strategy to push the demand data to the demand party. This realizes a compensation mechanism when the interface callback fails, and can be quickly and flexibly integrated into relevant systems that support cross-business cooperation needs.

[0058] In the above technical solution, the data to be executed is generated based on the basic data sent by the business system. For the business system, it only needs to transmit the basic data according to the pre-defined communication message body, without needing to worry about how to handle retry callbacks, thus ensuring system data consistency. Through highly refined and abstracted cross-system interface calls, the error retry function is separated from the business system. Neither party needs to understand any of the other's technical details, allowing for parallel development and separate deployment, reducing code coupling and interface call error rates, and improving development efficiency and system stability. Furthermore, the retry strategy can be changed as needed, and the retry strategy and execution records can be displayed intuitively through the interface, ensuring the accuracy of data exchange between cross-industry partners.

[0059] The various techniques described herein can be implemented in combination with hardware or software, or a combination thereof. Thus, the methods and apparatus of the present invention, or certain aspects or portions thereof, can take the form of program code (i.e., instructions) embedded in a tangible medium, such as a removable hard disk, USB flash drive, floppy disk, CD-ROM, or any other machine-readable storage medium, wherein when the program is loaded into and executed by a machine such as a computer, the machine becomes an apparatus for practicing the present invention.

[0060] When the program code is executed on a programmable computer, the computing device generally includes a processor, a processor-readable storage medium (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device. The memory is configured to store program code; the processor is configured to execute the retry callback method of the present invention according to instructions in the program code stored in the memory.

[0061] By way of example, and not limitation, readable media include readable storage media and communication media. Readable storage media stores information such as computer-readable instructions, data structures, program modules, or other data. Communication media generally embodies computer-readable instructions, data structures, program modules, or other data in the form of modulated data signals such as carrier waves or other transmission mechanisms, and includes any information delivery medium. Any combination of the above is also included within the scope of readable media.

[0062] In the specification provided herein, the algorithms and displays are not inherently related to any particular computer, virtual system, or other device. Various general-purpose systems can also be used with the examples of this invention. The required structure for constructing such systems is apparent from the above description. Furthermore, this invention is not directed to any particular programming language. It should be understood that the contents of the invention described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing the best mode of implementation of the invention.

[0063] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0064] Similarly, it should be understood that, in order to streamline this disclosure and aid in understanding one or more of the various aspects of the invention, in the above description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof. However, this method of disclosure should not be interpreted as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as reflected in the following claims, inventive aspects lie in fewer than all features of a single foregoing disclosed embodiment. Therefore, the claims following the detailed description are hereby expressly incorporated into this detailed description, wherein each claim itself is a separate embodiment of the invention.

[0065] Those skilled in the art will understand that modules, units, or components of the devices disclosed in the examples herein can be arranged in the devices described in this embodiment, or alternatively, can be located in one or more devices different from the devices in this example. The modules in the foregoing examples can be combined into a single module or, in addition, can be divided into multiple sub-modules.

[0066] Those skilled in the art will understand that modules in the device of the embodiments can be adaptively changed and placed in one or more devices different from that embodiment. Modules, units, or components in the embodiments can be combined into a single module, unit, or component, and further, they can be divided into multiple sub-modules, sub-units, or sub-components. Except where at least some of such features and / or processes or units are mutually exclusive, any combination can be used to combine all features disclosed in this specification (including the accompanying claims, abstract, and drawings) and all processes or units of any method or device so disclosed. Unless expressly stated otherwise, each feature disclosed in this specification (including the accompanying claims, abstract, and drawings) may be replaced by an alternative feature that serves the same, equivalent, or similar purpose.

[0067] Furthermore, those skilled in the art will understand that although some embodiments described herein include certain features but not others included in other embodiments, combinations of features from different embodiments are intended to be within the scope of the invention and form different embodiments. For example, in the following claims, any of the claimed embodiments can be used in any combination.

[0068] Furthermore, some of the embodiments described herein are methods or combinations of method elements that can be implemented by a processor of a computer system or by other means of performing the functions. Therefore, a processor having the necessary instructions for implementing the methods or method elements forms means for implementing the methods or method elements. Furthermore, the elements described herein in the apparatus embodiments are examples of means for implementing the functions performed by elements for the purposes of carrying out the invention.

[0069] As used herein, unless otherwise specified, the use of ordinal numbers such as “first,” “second,” “third,” etc., to describe ordinary objects merely indicates different instances of similar objects and is not intended to imply that the objects being described must have a given order in time, space, ordering, or any other manner.

[0070] Although the invention has been described with reference to a limited number of embodiments, those skilled in the art will understand from the foregoing description that other embodiments are conceivable within the scope of the invention described herein. Furthermore, it should be noted that the language used in this specification has been chosen primarily for readability and instructional purposes, and not for the purpose of interpreting or limiting the subject matter of the invention. Therefore, many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the appended claims. The disclosure of the invention is illustrative and not restrictive, and the scope of the invention is defined by the appended claims.

Claims

1. A retry callback method, comprising: Receive basic data sent by the business system and store it; The basic data is associated with corresponding execution information to transform it into data to be executed. The execution information includes execution status, execution parameters, execution return value, and execution count. The execution status corresponds to the status of the execution retry callback. The execution parameters are the relevant parameters when executing the retry callback. The execution return value is the result of executing the retry callback. The execution count is the number of times the retry callback has been executed. Listen for pending data, which includes order number, order type, and order channel; If the pending data is detected, corresponding requirement data is generated based on the pending data, including: finding the corresponding business type based on the order type and the order channel; querying and assembling order-related data based on the order number and the business type to generate requirement data; Callback to a preset interface to push the demand data to the demander through the preset interface; If the callback fails, the requirement data is regenerated and the preset interface is called back according to the retry strategy to push the requirement data to the requester. The retry strategy includes performing a retry callback once every preset retry time interval within the retry count threshold until the callback succeeds.

2. The method as described in claim 1, wherein, The business system integrates a retry function and sends the basic data through a pre-defined communication message body.

3. The method of claim 1, further comprising changing the retry strategy, wherein the step of changing the retry strategy includes: Change the retry time interval to modify the retry strategy.

4. The method according to any one of claims 1-3, wherein, The step of regenerating the demand data according to the retry strategy and calling back the preset interface to push the demand data to the demand party includes: Within the retry threshold, the required data is regenerated based on the data to be executed every preset retry time interval. The preset interface is called back to push the required data to the requester through the preset interface, and the execution information is updated according to the callback result until the callback is successful.

5. A retry callback device adapted to perform the method as described in any one of claims 1-4, the device comprising: The listening module is suitable for monitoring whether there is data to be executed; The generation module is adapted to generate corresponding requirement data based on the data to be executed when the data to be executed is detected. The callback module is adapted to call back a preset interface to push the demand data to the demander through the preset interface; The retry module is adapted to, when the callback fails, call the generation module to regenerate the requirement data according to the retry strategy and call back the preset interface through the callback module to push the requirement data to the requester.

6. A computing device, comprising: At least one processor; as well as A memory storing program instructions, wherein the program instructions are configured to be executed by the at least one processor, the program instructions including instructions for performing the method as described in any one of claims 1-4.

7. A readable storage medium storing program instructions that, when read and executed by a computing device, cause the computing device to perform the method as described in any one of claims 1-4.

Images