Callback processing method and platform, device, storage medium and program product
By receiving and processing callback task requests from each business system on the callback processing platform, the unified management of callback strategies of multiple business systems is achieved, and the problems of repeated development and inconsistent strategies in the existing technology are solved, and the development efficiency and accuracy of business management are improved.
Patent Information
- Application Number
- CN202111652220.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2021-12-30
- Publication Date
- 2025-03-28
- Estimated Expiration
- 2041-12-30
AI Technical Summary
In the prior art, the system of each business party needs to implement and maintain its own callback processing logic, resulting in too much repeated development work and reducing development efficiency. Moreover, due to different coding styles, it is difficult to unify the callback strategy.
A method based on a unified callback processing platform is provided, through which the platform receives callback task requests from each business system and processes the requests, realizing unified management of callback policies of multiple business systems.
Reduce duplicate work in the development of callback processing logic, improve development efficiency, and realize unified management of callback strategies for different business systems, improving the efficiency and accuracy of callback business management.
Smart Images

Figure CN114327832B_ABST
Abstract
Description
Technical Field
[0001] The present disclosure relates to the field of computer technology, in particular to the field of callback processing technology, and specifically to a callback processing method, a callback processing platform, an electronic device, a computer-readable storage medium, and a computer program product. Background Art
[0002] In related technologies, a business party may have scenarios or requirements that require callbacks to certain other business party interfaces. However, at present, each business party system usually needs to implement and maintain its own callback processing logic for businesses involving callbacks, resulting in too much duplication of development work and reduced development efficiency. At the same time, due to personal coding styles and other reasons, the callback strategies involved in the callback process, such as callback failure retry strategies, are also different, making it difficult to achieve unification.
[0003] The methods described in this section are not necessarily methods that have been previously conceived or employed. Unless otherwise indicated, it should not be assumed that any method described in this section is considered to be prior art simply because it is included in this section. Similarly, unless otherwise indicated, the issues mentioned in this section should not be considered to have been recognized in any prior art. Summary of the invention
[0004] The present disclosure provides a callback processing method, a callback processing platform, an electronic device, a computer-readable storage medium, and a computer program product.
[0005] According to one aspect of the present disclosure, a callback processing method is provided, comprising: receiving a callback task request issued by a first business system through a callback processing platform, the callback task request carrying information related to a callback interface and a callback policy of the callback task, wherein the callback processing platform is connected to multiple business systems including the first business system, for providing unified management including callback policies for the multiple business systems; and processing the callback task according to the callback task request.
[0006] According to another aspect of the present disclosure, a callback processing platform is provided, including: a task receiving unit, configured to receive a callback task request issued by a first business system through the callback processing platform, the callback task request carrying information related to a callback interface and a callback policy of the callback task, wherein the callback processing platform is connected to multiple business systems including the first business system, and is used to provide unified management including callback policies for the multiple business systems; and a task processing unit, configured to process the callback task according to the callback task request.
[0007] According to another aspect of the present disclosure, an electronic device is provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and when the instructions are executed by the at least one processor, the at least one processor executes the above-mentioned callback processing method provided by the present disclosure.
[0008] According to another aspect of the present disclosure, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions, when executed by a computer, cause the computer to execute the above callback processing method provided by the present disclosure.
[0009] According to another aspect of the present disclosure, a computer program product is provided, including a computer program, wherein the computer program implements the above callback processing method provided by the present disclosure when executed by a processor.
[0010] According to one or more embodiments of the present disclosure, a unified callback processing platform can be set up to receive callback task requests issued by various business systems and perform corresponding processing on callback tasks corresponding to the callback task requests, wherein the callback processing platform can be connected to multiple business systems to provide unified management including callback strategies for the multiple business systems, thereby reducing a large amount of repetitive work in the callback processing logic development process and improving development efficiency. At the same time, unified management of callback strategies of different business systems can be achieved, thereby improving the efficiency and accuracy of callback business management, so as to provide users with more reliable unified callback task processing and business support.
[0011] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present disclosure, nor is it intended to limit the scope of the present disclosure. Other features of the present disclosure will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS
[0012] The accompanying drawings exemplarily illustrate the embodiments and constitute a part of the specification, and together with the text description of the specification, are used to explain the exemplary implementation of the embodiments. The embodiments shown are for illustrative purposes only and do not limit the scope of the claims. In all drawings, the same reference numerals refer to similar but not necessarily identical elements.
[0013] Figure 1 A flowchart of a callback processing method according to an exemplary embodiment of the present disclosure is shown;
[0014] Figure 2 A schematic diagram showing the state flow of a callback interface and a business system in a callback processing process according to an exemplary embodiment of the present disclosure is shown;
[0015] Figure 3 Another flow chart of a callback processing method according to an exemplary embodiment of the present disclosure is shown;
[0016] Figure 4 A schematic diagram of the structure of a callback processing platform according to an exemplary embodiment of the present disclosure is shown;
[0017] Figure 5 A block diagram of an electronic device according to an embodiment of the present disclosure is shown. DETAILED DESCRIPTION
[0018] The following is a description of exemplary embodiments of the present disclosure in conjunction with the accompanying drawings, including various details of the embodiments of the present disclosure to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those of ordinary skill in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope of the present disclosure. Similarly, for the sake of clarity and conciseness, the description of well-known functions and structures is omitted in the following description.
[0019] In the present disclosure, unless otherwise specified, the use of the terms "first", "second", etc. to describe various elements is not intended to limit the positional relationship, timing relationship, or importance relationship of these elements, and such terms are only used to distinguish one element from another element. In some examples, the first element and the second element may refer to the same instance of the element, and in some cases, based on the description of the context, they may also refer to different instances.
[0020] The terms used in the description of various examples in this disclosure are only for the purpose of describing specific examples and are not intended to be limiting. Unless the context clearly indicates otherwise, if the number of elements is not specifically limited, the element can be one or more. In addition, in this disclosure, "multiple" or similar quantitative terms refer to two or more. In addition, the term "and / or" used in this disclosure covers any one of the listed items and all possible combinations.
[0021] In the related technology, the business party may have scenarios or requirements that require callbacks to certain other business party interfaces. For example, the business party may have scenarios or requirements that require calling the target interface for sending SMS messages to push messages to the big data platform. However, at present, each business party system usually needs to implement and maintain its own callback processing logic for businesses involving callbacks, resulting in too much duplication of development work and reduced development efficiency. At the same time, due to personal coding style and other reasons, the callback strategies involved in the callback process, such as callback failure retry strategies, are also different, making it difficult to achieve unification.
[0022] In order to solve the above problems, the present disclosure provides a callback processing method based on a unified callback processing platform, wherein the callback processing platform can be connected to multiple business systems to provide unified management including callback strategies for the multiple business systems. Since the callback task requests issued by each business system can be received through the unified callback processing platform and the callback tasks corresponding to the callback task requests can be processed accordingly, a large amount of repetitive work in the callback processing logic development process can be reduced, and development efficiency can be improved. At the same time, unified management of callback strategies of different business systems can be achieved, and the efficiency and accuracy of callback business management can be improved, so as to provide users with more reliable unified callback task processing and business support.
[0023] The embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings.
[0024] Figure 1 FIG. 4 is a flowchart of a callback processing method according to an exemplary embodiment of the present disclosure. Figure 1 As shown, the callback processing method includes: step S101, receiving a callback task request issued by the first business system through a callback processing platform, the callback task request carrying information related to the callback interface and callback policy of the callback task, wherein the callback processing platform is connected to multiple business systems including the first business system, and is used to provide unified management including callback policy for the multiple business systems; and step S102, processing the callback task according to the callback task request.
[0025] In the present disclosure, the callback processing platform as a unified callback center can support the processing of callback task requests of multiple business systems, wherein each business system in the multiple business systems supported by the callback processing platform can refer to any business party system that has the need to call back the corresponding target interface through the callback processing platform. For example, one or more of the business systems supported by the callback processing platform can be a (message generation / push) system that needs to call the target interface for sending SMS through the callback processing platform to push the message to the big data platform, etc. It can be understood that the target interface for sending SMS mentioned in the embodiment of the present disclosure is only a possible interface example among the multiple target interfaces supported by the callback processing platform. According to the actual application scenario requirements, the callback processing platform can also support the call of multiple other target interfaces to support the different target interface callback requirements of different business systems. In addition, the callback mentioned in the present disclosure is a common calling method between modules. Specifically, callback refers to a two-way calling mode between modules, that is, the called party will also call the other party's interface when the interface is called. In addition, it can be understood that the embodiment of the present disclosure takes one of the multiple business systems supported by the callback processing platform as an example to illustrate the interaction process between the callback processing platform and the business system. As for the other business systems in the multiple business systems supported by the callback processing platform, the interaction between them and the callback processing platform can be consistent with or similar to the example business system. In other words, the first business system in the embodiment of the present disclosure can be any one of the multiple business systems supported by the callback processing platform, that is, each business system in the multiple business systems supported by the callback processing platform can interact with the callback processing platform in a manner consistent with or similar to the manner described in the present disclosure.
[0026] According to some embodiments, before receiving the callback task request sent by the first business system through the callback processing platform in step S101, the method may further include: determining that the first business system has completed the registration operation at the callback processing platform (i.e., has created or completed the callback subscription at the callback processing platform). Thus, each business system can use the callback processing platform to send a callback task only if it successfully completes the registration at the callback processing platform, thereby improving the security of callback processing through the callback processing platform.
[0027] According to some embodiments, in response to determining that the first business system has not completed the registration operation at the callback processing platform, the first business system can be instructed or reminded to perform the registration operation at the callback processing platform so that the callback business function provided by the callback processing platform can be used. According to some embodiments, for each business system that completes the registration operation at the callback processing platform, the corresponding registration information (i.e., callback subscription information) can be stored in a corresponding database (e.g., a Redis database, etc.) to facilitate unified management of these business systems. The stored registration information of each business system includes, but is not limited to, identification information (e.g., a physical Internet IP address, etc.) for uniquely identifying the corresponding business system, registration time, etc.
[0028] As described above, the callback processing platform in the embodiment of the present disclosure can serve as a unified callback center to provide unified management including callback policies for multiple business systems. When each business system issues a callback task request through the callback processing platform, i.e., creates a callback task, the callback processing platform can specify information related to the callback interface of the corresponding callback task (i.e., the target interface that the business system needs the callback processing platform to call) and the callback policy.
[0029] According to some embodiments, the information related to the callback interface includes at least one of the address of the callback interface (such as a physical IP address or port number, etc.), the request method of the callback interface, and the callback request parameters of the callback interface (such as parameters to be transmitted to the callback interface by the business system).
[0030] For example, taking the callback interface as the target interface for sending SMS mentioned above, the request method of the callback interface may include a GET request method or a POST request method. Accordingly, the callback request parameter of the callback interface may be a parameter in the form of URL (Uniform Resource Locator) corresponding to the GET request method, that is, the transmission parameter is included in the URL; or a parameter in the form of BODY (package body) corresponding to the POST request method, that is, the transmission parameter is included in the BODY. It can be understood that the above description of the request method and / or the data format of the callback request parameter supported by the callback interface is only an example. According to the actual scenario requirements and / or according to the different functions or types of the callback interface, the request method and / or the data format of the callback request parameter supported by the callback interface may also include various other different methods and / or formats.
[0031] According to some embodiments, the information related to the callback strategy includes information related to the callback failure retry strategy, and the information related to the callback failure retry strategy includes a first maximum callback retry count set for the callback interface. The value of the first maximum callback retry count can be flexibly set according to actual application requirements (such as the requirements for the processing result and / or processing speed of the callback task, etc.), for example, it can be set to any value in the range of 5 to 10 or a larger or smaller value, etc.
[0032] According to some embodiments, the information related to the callback failure retry strategy also includes the time interval between two adjacent callback processing operations of the callback task, wherein the time interval between two different adjacent callback processing operations of the callback task may be the same or different.
[0033] In other words, the callback processing platform of the disclosed embodiment can provide two different callback failure retry strategies for each business system to choose when creating a callback task. One is to stipulate that the time interval between each two adjacent callback processing operations of the callback task is a fixed value, which can be set by the user according to actual needs (for example, based on or fully considering the estimated time required for processing the callback task once, etc.) (for example, set to any value in the range of 10s to 15s, etc.), or it can be a default value of the platform; the other is to allow the user to flexibly define the time interval between each pair of adjacent callback processing operations of the callback task, so that the time interval between different adjacent callback processing operations of the callback task can be different. According to some embodiments, for the second callback failure retry strategy, the time interval between different adjacent callback processing operations of the callback task can be increasing. An example can be: the time interval between the first callback processing operation and the second callback processing operation (i.e., the first retry operation) can be defined as 10s, the time interval between the second callback processing operation and the third callback processing operation can be defined as 15s, the time interval between the third callback processing operation and the fourth callback processing operation can be defined as 30s, and so on. It is understandable that the above descriptions of the values of the time intervals are only examples, and they can be set to other different values according to actual application requirements.
[0034] By allowing users to set the time interval between two different adjacent callback processing operations of a callback task to different values (for example, to values that are increasing in trend), the flexibility and applicability of callback task processing can be improved, making the processing of callback tasks more in line with actual user needs. In addition, as the number of retries increases, the time interval between two adjacent callback processing operations can gradually increase, thereby achieving the effect of avoiding the impact on the stability of the platform or system due to frequent retries, and giving sufficient time for the network or system to recover after the callback task processing fails (this is because the reason for the failure of callback task processing is likely to be due to network reasons or the callback interface system jitters due to performance reasons, and these problems are likely to be self-repairable).
[0035] According to some embodiments, after receiving a callback task request issued by the first business system through the callback processing platform, that is, after the first business system creates a callback task through the callback processing platform to specify information related to the callback interface and callback strategy of the callback task, the corresponding callback task (and various callback data / information related thereto) can be sent to the message queue to implement asynchronous warehousing through the message queue. Thus, by introducing the message queue, the database write operation can be decoupled and the pressure on the database can be reduced. For example, the message queue can be implemented through Pulsar, and the database connected to the message queue can be implemented through TIDB, but the embodiments of the present disclosure are not limited to this.
[0036] According to some embodiments, after step S101 is performed in the manner described above, the operation of processing the callback task according to the callback task request described in step S102 may be performed.
[0037] According to some embodiments, the processing of the callback task according to the callback task request described in step S102 includes: processing the callback task according to information related to the callback interface and callback strategy of the callback task carried in the callback task request (for example, by parsing parameters of the callback task request, determining information such as the callback interface address, callback request parameters, and the first maximum number of callback retries, and processing the callback task based on this information); and setting the callback status of the callback interface according to the processing results obtained each time the callback task is processed, wherein the callback status of the callback interface includes a callback interface success status, a callback interface intermediate status, or a callback interface failure status.
[0038] By subdividing the callback status of the callback interface into three different states, namely, a success state, an intermediate state and a failure state, it is possible to easily and accurately know the specific result of each callback processing operation and / or the current callback process node based on the different states of the callback interface. In addition, when the different states of the callback interface are displayed through the front-end page of the callback processing platform (actively displayed and / or passively displayed through user queries), the different states of the callback interface can be displayed in different colors (for example, green for a success state, yellow for an intermediate state, red for a failure state, etc.), so that users can more easily and accurately know the specific result of each callback processing operation and / or the current callback process node.
[0039] According to some embodiments, Figure 2 FIG. 2 shows a schematic diagram of the state transition of the callback interface in the callback processing process according to an exemplary embodiment of the present disclosure. Figure 2 As shown, according to the processing result obtained by processing the callback task each time, setting the callback state of the callback interface includes: in response to determining that the current processing of the callback task is successfully executed, setting the callback state of the callback interface to the callback interface success state; in response to determining that the current processing of the callback task fails and determining the current number of retries of the callback task ( Figure 2 RC in (i.e., RetryCount) is less than the first maximum callback retry count of the callback interface ( Figure 2 In response to determining that the current processing execution of the callback task has failed and determining that the current number of executed retries of the callback task has reached the first maximum number of callback retries of the callback interface, the callback state of the callback interface is set to the callback interface failure state.
[0040] According to some embodiments, Figure 2As shown, since the current number of executed retries corresponding to the callback interface in the intermediate state has not reached the corresponding maximum number of callback retries, the callback interface in the intermediate state can eventually be transformed into a success state or a failure state by continuing to execute the remaining number of retry operations. That is, after setting the callback state of the callback interface to the callback interface intermediate state, the method further includes: performing a retry process on the callback task (wherein, the start time of the retry process can be determined according to the time interval between two adjacent callback processing operations of the callback task; that is, in addition to immediately performing a retry process on the callback task in response to setting the callback state of the callback interface to the callback interface intermediate state, in the case where the time interval between two adjacent callback processing operations of the callback task is set, the retry process can also be performed after waiting until the corresponding time interval arrives); in response to the successful execution of the retry process on the callback task, modifying the callback state of the callback interface from the callback interface intermediate state to the callback interface success state; and in response to the failure of the retry process on the callback task and determining that the current number of executed retries of the callback task has reached the first maximum number of callback retries of the callback interface, modifying the callback state of the callback interface from the callback interface intermediate state to the callback interface failure state. As for other situations, for example, if the retry processing of the callback task fails and the current number of executed retries of the callback task is still less than the first maximum callback retry number of the callback interface, the callback state of the callback interface can be maintained as the intermediate state of the callback interface, and the retry processing of the callback task can continue to be executed, which is not elaborated here.
[0041] After determining the processing result of the callback task (i.e., the callback result of the callback interface) related to the successful or failed execution based on the first maximum callback retry number through the above processing flow, if the first business system does not require the callback processing platform to feedback or notify it of the corresponding processing result (for example, the processing result notification address is not set, etc.), it can be considered that the processing process of the callback task has ended. In this case, the first business system can obtain the processing result of the callback task (i.e., the processing result of successful or failed execution) by actively querying the front-end page of the callback processing platform based on the task identifier assigned when the callback task was created, i.e., the task ID.
[0042] According to some embodiments, when creating a callback task, the first business system may require the callback processing platform to feedback or notify it of the processing result determined based on the first maximum callback retry count (for example, specifying a processing result notification address, etc.). In this case, considering that the notification process of the processing result from the callback processing platform to the first business system may fail due to network jitter or errors in the processing result notification address, the first business system may also specify a second maximum callback retry count through the callback processing platform to improve the success rate of notifying the processing result to the first business system.
[0043] Correspondingly, the information related to the callback failure retry strategy may also include a second maximum callback retry number related to the notification of the processing result, and the method may also include: notifying the first business system of the first processing result of the callback task determined based on the first maximum callback retry number regarding the successful execution or failed execution; and setting the callback status of the first business system based on the callback status of the callback interface corresponding to the first processing result, the notification result status of the first processing result, and the second maximum callback retry number, wherein the callback status of the first business system includes a business system success status, a business system intermediate status, or a business system failure status.
[0044] By also subdividing the callback status of the business system into three different states: success state, intermediate state and failure state, it is possible to more accurately and precisely know the specific results of each callback processing operation (including the execution results of the callback task and the notification results of the execution results, etc.) and / or the current callback process node. In addition, when the different states of the business system are displayed through the front-end page of the callback processing platform (active display and / or passive display through user query), the different states of the business system can also be displayed in different colors (for example, green for success state, yellow for intermediate state, red for failure state, etc.), so that users can more easily and accurately know the specific results of each callback processing operation and / or the current callback process node.
[0045] It can be understood that the value of the second maximum callback retry number in the present disclosure may be the same as or different from the value of the first maximum callback retry number, and can also be flexibly set according to actual application requirements, for example, it can be set to any value in the range of 5 to 10 or a larger or smaller value, etc.
[0046] According to some embodiments, Figure 2 As shown ( Figure 2A state flow diagram of a business system, such as a first business system, in a callback processing process according to an exemplary embodiment of the present disclosure is also shown. The callback state of the callback interface corresponding to the first processing result, the notification result state of the first processing result, and the second maximum callback retry count are set to the callback state of the first business system, including:
[0047] In response to the callback state of the callback interface corresponding to the first processing result being a callback interface success state: according to determining that the first processing result is successfully notified to the first business system, setting the callback state of the first business system to a business system success state; and according to determining that the first processing result is not successfully notified to the first business system, and determining the current number of executions of the retry processing of the callback task triggered by the processing result notification failure ( Figure 2 RRC in, that is, ReRetryCount) is less than the second maximum callback retry count ( Figure 2 MRRC in, i.e. MaxReRetryCount), sets the callback state of the first business system to the intermediate state of the business system.
[0048] According to some embodiments, Figure 2 As shown, setting the callback status of the first business system based on the callback status of the callback interface corresponding to the first processing result, the notification result status of the first processing result, and the second maximum callback retry number may also include:
[0049] In response to the callback state of the callback interface corresponding to the first processing result being a callback interface failure state: determining that the first processing result has not been successfully notified to the first business system, and determining the current number of executions of the retry processing of the callback task triggered by the processing result notification failure ( Figure 2 RRC in) is less than the second maximum callback retry number ( Figure 2 MRRC in), setting the callback status of the first business system to the intermediate status of the business system; and based on determining that the first processing result (in this case, the processing result of the failed execution of the callback task) is successfully notified to the first business system, setting the callback status of the first business system to the successful status of the business system.
[0050] According to some embodiments, Figure 2As shown, since the number of retry attempts currently executed corresponding to the first business system in the intermediate state triggered by the failure of the processing result notification has not reached the corresponding maximum number of callback retries, the first business system in the intermediate state can be transformed into a success state or a failure state by continuing to execute the remaining number of retry operations. That is, after setting the callback state of the first business system to the intermediate state of the business system, the method may further include:
[0051] Retry the callback task; in response to the corresponding processing result (whether successful or failed) of the retry processing of the callback task being successfully notified to the first business system, modify the callback state of the first business system from the business system intermediate state to the business system successful state; and in response to the corresponding processing result (whether successful or failed) of the retry processing of the callback task not being successfully notified to the first business system and the current number of executions of the retry processing of the callback task triggered by the failure of the processing result notification has reached the second maximum number of callback retries, modify the callback state of the first business system from the business system intermediate state to the business system failed state. As for other situations, such as the corresponding processing result of the retry processing of the callback task not being successfully notified to the first business system, and the current number of executions of the retry processing of the callback task triggered by the failure of the processing result notification is still less than the second maximum number of callback retries, etc., the callback state of the first business system can be maintained as the business system intermediate state, and the retry processing of the callback task can continue to be performed.
[0052] It is understandable that, since there is a situation where the processing result still cannot successfully reach the first business system after the retry processing of the second maximum callback retry number, the first business system can obtain the execution result of the callback task (i.e., callback result) and / or the notification result of the execution result by actively querying the front-end page of the callback processing platform based on the task ID assigned when the callback task was created, when the set notification time (the value of which can be flexibly set according to actual needs, for example, any value within the range of 5 to 10 minutes, etc.) since the creation of the callback task has arrived and the corresponding processing result has not been received. For example, the execution result of the callback task and the notification result of the execution result can be obtained based on the callback status of the callback interface set or stored by the callback processing platform and the callback status of the business interface.
[0053] In addition, although the above description uses the case where the second maximum callback retry count (e.g., MRRC) is not zero to describe the notification process of the callback result, it is understandable that the second maximum callback retry count can also be set to 0 (e.g., Figure 2The "retry is 0" situation shown in the lower right corner; that is, although the first business system specifies the callback processing platform to notify it of the callback result, it does not specify the corresponding number of retries related to the result notification, so that the value defaults to 0, etc.). In this case, after the callback processing platform notifies the first business system of the first processing result of the callback interface related to the successful execution or failed execution, it can directly determine or set the callback status of the first business system based on the notification result status of the first processing result. For example, in response to determining that the first processing result (whether the execution is successful or failed) is successfully notified to the first business system, the callback status of the first business system is set to the business system success status; and in response to determining that the first processing result (whether the execution is successful or failed) is not successfully notified to the first business system, the callback status of the first business system is set to the business system failure status.
[0054] Similarly, the first maximum callback retry count (e.g., MRC) described above may also have a special case where the value is 0. In this case, the callback state of the callback interface can be directly determined / set according to the result of one execution of the callback task. For example, in response to determining that the callback task is executed successfully, the callback state of the callback interface is set to the callback interface success state; and in response to determining that the callback task fails to execute, the callback state of the callback interface is set to the callback interface failure state.
[0055] According to some embodiments, the callback processing method described in the embodiments of the present disclosure may also include: in response to determining that the callback task has not been successfully executed when the first maximum callback retry number (and / or the second maximum callback retry number) of the callback task has been exhausted, receiving a manual callback request initiated by the user through the callback processing platform (for example, through a manual callback compensation control set in the front-end page of the callback processing platform, etc.); and performing callback compensation processing on the callback task according to the manual callback request. In this way, since the manual callback compensation function after the callback failure retry number is exhausted is additionally provided, the applicability of callback business processing through the callback processing platform can be further improved, and the user's application experience of using the callback processing platform can be improved. It can be understood that if the callback task is successfully executed, the manual callback compensation control set in the front-end page of the callback processing platform may be in an unavailable state (that is, a manual callback request cannot be initiated at this time).
[0056] According to some embodiments, the callback task request may also carry the callback failure alarm address of the first business system, and the method further includes: in response to determining that the number of failures of the callback task within a set time period reaches a failure threshold, an alarm is sent to the first business system through the callback failure alarm address. Among them, the callback failure alarm address of the first business system may include an email address for receiving alarm information, or a text message address, etc. The set time period and failure threshold can be flexibly set according to actual application requirements. For example, the set time period can be set to 1 minute, and the failure threshold can be set to 8 to 10, etc., that is, if the number of failures within 1 minute reaches more than 8 times, an alarm message can be sent to the corresponding callback failure alarm address. The alarm message may include the cause of failure, the time when the failure occurred, the task ID where the failure occurred, etc.
[0057] According to some embodiments, the callback processing method described in the embodiments of the present disclosure may also include: determining a flow limit threshold of the callback interface of the callback task (e.g., an upper limit on the number of requests per minute); and controlling the flow of the callback interface according to the flow limit threshold. In this way, a unified flow limit support function can be implemented, further improving the applicability of callback business processing through the callback processing platform, and improving the user's application experience of using the callback processing platform.
[0058] According to some embodiments, the callback processing platform may determine the traffic limiting threshold of the callback interface based on the parameters of the traffic limiting threshold of the callback interface input when the first business system creates the callback task (the parameters may be carried in the callback task request); alternatively, the callback processing platform may obtain the traffic limiting threshold of the callback interface through communication interaction with the callback interface.
[0059] According to some embodiments, the callback processing method described in the embodiments of the present disclosure may also include: collecting callback data / information related to the callback task of the first business system (such as the processing result of the callback task's successful execution or failed execution, the failure reason of the execution failure, the number of failures, the corresponding callback interface address, etc.); and performing unified aggregation analysis on the collected callback data / information related to the callback task of the first business system, as well as the callback data / information of other callback tasks performed by various business systems including the first business system through the callback processing platform. The results of the unified aggregation analysis can be used to obtain the processing performance (such as the traffic limit threshold), health or stability, etc. of the corresponding callback interface.
[0060] With reference to the foregoing, in the embodiment of the present disclosure, the callback data / information related to the callback task can be sent to the message queue to realize asynchronous writing to the database through the message queue, thereby decoupling the database writing operation and reducing the pressure on the database. However, the database may still be unavailable due to unexpected downtime, etc. In order to solve this problem, the callback processing method described in the embodiment of the present disclosure may also include: in response to the failure of the callback data / information to write the database, the callback data / information is sent to the delay queue; and in response to the arrival of the set delay time (whose value can be flexibly set according to actual needs, for example, it can be any value in the range of 5 to 10 minutes, etc.), the callback data in the delay queue is attempted to be written to the database (if the storage fails, the storage is attempted again after the set delay time). Therefore, by introducing the delay queue, in the case of unexpected downtime of the database causing the database to be unavailable, the callback processing platform can still provide services to the outside, thereby improving the reliability of callback business processing through the callback processing platform and improving the user's application experience using the callback processing platform. It can be understood that the delay queue can be included in the message queue as a subqueue of the message queue.
[0061] Referring to the relevant description above, the callback processing platform in the disclosed embodiment can support the unified designation / management of callback strategies, the unified aggregation analysis / audit of callback results (i.e., the execution results of the callback tasks mentioned above, etc.), and support current limiting, manual callback compensation, and callback failure alarm notification, etc. At the same time, when the database is unavailable due to unexpected downtime, etc., it can still provide external services, decoupling the direct contact between the business system and the callback interface party, and providing users with more reliable callback task processing and business support. In addition, the callback processing platform can also support interface token authentication verification. For example, if the other party's interface (such as the callback interface) requires authentication, the callback processing platform can carry the corresponding token in the corresponding information or request and send it to the other party's interface, etc.
[0062] Combination of the above Figure 1 and Figure 2 The callback processing method of the exemplary embodiment of the present disclosure is described in detail. Figure 3 A possible overall process of the callback processing method of the exemplary embodiment of the present disclosure is briefly described. Figure 3 As shown, the callback processing method includes:
[0063] Step S301, determine whether the business system to use the callback processing platform has completed the registration operation at the callback processing platform (i.e., whether a callback subscription has been created). If so, execute step S302; if not, the business system can be instructed or reminded to perform the registration operation at the callback processing platform.
[0064] Referring to the above description, for each business system that completes the registration operation at the callback processing platform, the corresponding registration information (ie, callback subscription information) may be stored in a corresponding database (eg, a Redis database, etc.).
[0065] Step S302: receiving a callback task request sent by the business system through the callback processing platform (ie, the business system creates a callback task through the callback processing platform).
[0066] Referring to the relevant description above, when the business system issues a callback task request through the callback processing platform, i.e., creates a callback task, the callback processing platform can specify information related to the callback interface and callback strategy of the callback task. In addition, the corresponding callback task created can be sent to a message queue to implement asynchronous warehousing through the message queue. For example, the message queue can be implemented through Pulsar, and the database connected to the message queue can be implemented through TIDB.
[0067] Step S303, process the callback task and determine whether the current processing of the callback task is successfully executed, if not, execute step S3041, if yes, execute step S3042.
[0068] Referring to the above description, the callback processing platform can parse the parameters of the callback task request to determine the callback interface address, callback request parameters, and the first maximum callback retry count, and process the callback task based on this information. In addition, it can be understood that due to the existence of the message queue, the callback processing platform can obtain the callback task to be processed through asynchronous consumption.
[0069] Step S3041, determine whether the current number of executed retries (RC) of the callback task has reached the first maximum number of callback retries (MRC) set for the callback interface. If so, execute step S3042; if not, continue to return to step S303 to retry the callback task through step S303.
[0070] According to some embodiments, Figure 3 As shown, if it is determined that the current number of executed retries of the callback task has not reached the first maximum number of callback retries set for the callback interface, the corresponding retry processing task (for example, in the form of Delay msg) can be sent to the message queue, so that the retry processing task can be obtained through asynchronous consumption to retry the callback task. In addition, referring to the relevant description above, in the process of executing steps S303 and S3042, the callback state of the callback interface can be set or changed based on the execution result of the corresponding callback task.
[0071] Step S3042: Notify the business system of a first processing result of the callback task, determined based on the first maximum callback retry number, regarding execution success or execution failure.
[0072] Referring to the relevant description above, if the business system does not require the callback processing platform to feedback or notify it of the corresponding first processing result, there is no need to execute step S3042 and its subsequent related result notification operations. At this time, it can be directly considered that the processing of the callback task has been completed.
[0073] Step S3051, determine whether the first processing result is successfully notified to the business system, if so, execute step S306, if not, execute step S3052.
[0074] Step S3052, determine whether the current number of executions (RRC) of the retry processing of the callback task triggered by the failure of the processing result notification has reached the second maximum callback retry number (MRRC); if not, continue to return to step S303 to retry the callback task through step S303; if so, the processing operation on the callback task can be terminated.
[0075] According to some embodiments, Figure 3 As shown, if it is determined that the current number of executions of the retry processing of the callback task triggered by the failure of the processing result notification has not reached the second maximum number of callback retries, the corresponding retry processing task (for example, in the form of Delay msg) can be sent to the message queue so that the retry processing task can be subsequently obtained through asynchronous consumption to retry the callback task.
[0076] Step S306: modify the data status according to the first processing result successfully notified to the business system.
[0077] In step S306, the callback interface and / or the callback state of the business system may be set or modified according to the first processing result (which may be the result of successful or failed execution of the callback task) that is successfully notified to the business system. After step S306 is executed, it can be considered that the processing operation for the callback task has ended.
[0078] According to another aspect of the present disclosure, a callback processing platform is also provided. Figure 4 A structural block diagram of a callback processing platform according to an exemplary embodiment of the present disclosure is shown. Figure 4As shown, the callback processing platform 400 includes: a task receiving unit 401, configured to receive a callback task request issued by the first business system through the callback processing platform, the callback task request carries information related to the callback interface and callback policy of the callback task, wherein the callback processing platform is connected to multiple business systems including the first business system, and is used to provide unified management including callback policy for the multiple business systems; and a task processing unit 402, configured to process the callback task according to the callback task request.
[0079] It is understandable that the specific execution mode of each operation in the task receiving unit 401 and the task processing unit 402 and / or the specific meaning of each parameter are consistent with the above description, which will not be repeated here. In addition, it is also understandable that the callback processing platform may also include corresponding units or modules configured to perform the other functions described above, which will not be repeated here.
[0080] According to another aspect of the present disclosure, an electronic device is also provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the above-mentioned callback processing method.
[0081] According to another aspect of the present disclosure, a non-transitory computer-readable storage medium storing computer instructions is further provided, wherein the computer instructions are used to enable the computer to execute the above callback processing method.
[0082] According to another aspect of the present disclosure, a computer program product is further provided, including a computer program, wherein the computer program implements the above callback processing method when executed by a processor.
[0083] See also Figure 5 , a block diagram of an electronic device 500 that can be used as the present disclosure will now be described, which is an example of a hardware device that can be applied to various aspects of the present disclosure. The electronic device can be a computer device of different types, such as a laptop computer, a desktop computer, a workbench, a personal digital assistant, a server, a blade server, a mainframe computer, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present disclosure described and / or required herein.
[0084] Figure 5 1 shows a block diagram of an electronic device according to an embodiment of the present disclosure. Figure 5 As shown, the electronic device 500 may include at least one processor 501 , a working memory 502 , an I / O device 504 , a display device 505 , a storage device 506 , and a communication interface 507 that can communicate with each other via a system bus 503 .
[0085] The processor 501 may be a single processing unit or multiple processing units, all of which may include a single or multiple computing units or multiple cores. The processor 501 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuits, and / or any device that manipulates signals based on operating instructions. The processor 501 may be configured to obtain and execute computer-readable instructions stored in a working memory 502, a storage device 506, or other computer-readable media, such as program codes of an operating system 502a, program codes of an application 502b, and the like.
[0086] Working memory 502 and storage device 506 are examples of computer-readable storage media for storing instructions, which are executed by processor 501 to implement the various functions described above. Working memory 502 may include both volatile memory and non-volatile memory (e.g., RAM, ROM, etc.). In addition, storage device 506 may include a hard disk drive, a solid-state drive, a removable medium, including external and removable drives, memory cards, flash memory, a floppy disk, an optical disk (e.g., CD, DVD), a storage array, a network attached storage, a storage area network, etc. Working memory 502 and storage device 506 may all be collectively referred to herein as memory or computer-readable storage media, and may be a non-transitory medium capable of storing computer-readable, processor-executable program instructions as computer program code, which may be executed by processor 501 as a specific machine configured to implement the operations and functions described in the examples herein.
[0087] The I / O device 504 may include an input device and / or an output device. The input device may be any type of device capable of inputting information to the electronic device 500, and may include but is not limited to a mouse, a keyboard, a touch screen, a track pad, a track ball, a joystick, a microphone, and / or a remote controller. The output device may be any type of device capable of presenting information, and may include but is not limited to a video / audio output terminal, a vibrator, and / or a printer.
[0088] The communication interface 507 allows the electronic device 500 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks, and may include but is not limited to a modem, a network card, an infrared communication device, a wireless communication transceiver and / or a chipset, such as a Bluetooth™ device, an 802.11 device, a WiFi device, a WiMax device, a cellular communication device and / or the like.
[0089] The application 502b in the working register 502 can be loaded to execute the various methods and processes described above, such as Figure 1 In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 500 via the storage device 506 and / or the communication interface 507. When the computer program is loaded and executed by the processor 501, one or more steps of the callback processing method described above may be executed.
[0090] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include: being implemented in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.
[0091] The program code for implementing the method of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device, so that the program code, when executed by the processor or controller, enables the functions / operations specified in the flow chart and / or block diagram to be implemented. The program code may be executed entirely on the machine, partially on the machine, partially on the machine and partially on a remote machine as a stand-alone software package, or entirely on a remote machine or server.
[0092] In the context of the present disclosure, a machine-readable medium may be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, device, or equipment. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or equipment, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, 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 disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
[0093] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, voice input, or tactile input).
[0094] The systems and techniques described herein may be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer with a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), and the Internet.
[0095] A computing system may include clients and servers. Clients and servers are generally remote from each other and usually interact through a communication network. The relationship of client and server is generated by computer programs running on respective computers and having a client-server relationship to each other.
[0096] It should be understood that the various forms of processes shown above can be used to reorder, add or delete steps. For example, the steps recorded in this disclosure can be performed in parallel, sequentially or in a different order, as long as the desired results of the technical solutions disclosed in this disclosure can be achieved, and this document is not limited here.
[0097] Although the embodiments or examples of the present disclosure have been described with reference to the accompanying drawings, it should be understood that the above-mentioned methods, systems and devices are merely exemplary embodiments or examples, and the scope of the present invention is not limited by these embodiments or examples, but only by the claims after authorization and their equivalent scope. Various elements in the embodiments or examples can be omitted or replaced by their equivalent elements. In addition, each step can be performed in an order different from that described in the present disclosure. Further, the various elements in the embodiments or examples can be combined in various ways. It is important that with the evolution of technology, many elements described herein can be replaced by equivalent elements that appear after the present disclosure.
Claims
1. A callback processing method, comprising: The callback processing platform receives a callback task request sent by the first business system through the callback processing platform, wherein the callback task request carries information related to a callback interface and a callback policy of the callback task, wherein the callback interface is a target interface that the first business system needs the callback processing platform to call, and the callback interface does not directly contact the first business system, and wherein the callback processing platform is connected to multiple business systems including the first business system, and is used to provide unified management including callback policies for the multiple business systems; and Processing the callback task according to the callback task request; The information related to the callback strategy includes information related to the callback failure retry strategy, and the information related to the callback failure retry strategy includes a first maximum callback retry count set for the callback interface; Wherein, processing the callback task according to the callback task request includes: Processing the callback task according to the information related to the callback interface and callback strategy of the callback task carried in the callback task request; and setting the callback state of the callback interface according to the processing result obtained by processing the callback task each time, wherein the callback state of the callback interface includes a callback interface success state, a callback interface intermediate state or a callback interface failure state; The information related to the callback failure retry strategy also includes a second maximum callback retry count related to notification of the processing result, and the method further includes: Notify the first business system of the first processing result of the successful execution or failed execution of the callback task determined based on the first maximum callback retry number; and set the callback status of the first business system based on the callback status of the callback interface corresponding to the first processing result, the notification result status of the first processing result and the second maximum callback retry number, wherein the callback status of the first business system includes a business system success status, a business system intermediate status or a business system failure status.
2. The method according to claim 1, wherein: The information related to the callback interface includes at least one of an address of the callback interface, a request method of the callback interface, and a callback request parameter of the callback interface.
3. The method according to claim 1, wherein: The information related to the callback failure retry strategy also includes the time interval between two adjacent callback processing operations of the callback task, wherein the time intervals between two different adjacent callback processing operations of the callback task are the same or different.
4. The method according to claim 1, wherein: According to the processing result obtained by processing the callback task each time, setting the callback state of the callback interface includes: In response to determining that the current processing of the callback task is successfully executed, setting the callback state of the callback interface to a callback interface success state; In response to determining that the current processing execution of the callback task fails and determining that the current executed retry count of the callback task is less than the first maximum callback retry count of the callback interface, setting the callback state of the callback interface to a callback interface intermediate state; and In response to determining that the current processing execution of the callback task fails and determining that the current number of executed retries of the callback task has reached the first maximum number of callback retries of the callback interface, setting the callback state of the callback interface to a callback interface failure state.
5. The method according to claim 4, wherein: After setting the callback state of the callback interface to the callback interface intermediate state, the method further includes: Retrying the callback task; In response to a successful execution of the retry process for the callback task, modifying the callback state of the callback interface from a callback interface intermediate state to a callback interface success state; and In response to the failure of the retry processing of the callback task and determining that the current number of executed retries of the callback task has reached the first maximum callback retry number of the callback interface, the callback state of the callback interface is modified from the callback interface intermediate state to the callback interface failure state.
6. The method according to claim 1, wherein: The step of setting the callback status of the first business system based on the callback status of the callback interface corresponding to the first processing result, the notification result status of the first processing result, and the second maximum callback retry count includes: In response to the callback status of the callback interface corresponding to the first processing result being a callback interface success status: According to determining that the first processing result is successfully notified to the first business system, setting the callback state of the first business system to a business system success state; and Based on determining that the first processing result has not been successfully notified to the first business system, and determining that the current number of executions of the retry processing of the callback task triggered by the failure of the processing result notification is less than the second maximum callback retry number, the callback state of the first business system is set to an intermediate state of the business system.
7. The method according to claim 1, wherein: The step of setting the callback status of the first business system based on the callback status of the callback interface corresponding to the first processing result, the notification result status of the first processing result, and the second maximum callback retry count includes: In response to the callback status of the callback interface corresponding to the first processing result being a callback interface failure status: According to determining that the first processing result has not been successfully notified to the first business system, and determining that the current number of executions of the retry processing of the callback task triggered by the failure of the processing result notification is less than the second maximum callback retry number, setting the callback state of the first business system to a business system intermediate state; and According to determining that the first processing result is successfully notified to the first business system, the callback state of the first business system is set to a business system success state.
8. The method according to claim 6 or 7, wherein: After setting the callback state of the first business system to the business system intermediate state, the method further includes: Retrying the callback task; In response to the corresponding processing result of the retry processing of the callback task being successfully notified to the first business system, modifying the callback state of the first business system from the business system intermediate state to the business system success state; and In response to the corresponding processing result of the retry processing of the callback task not being successfully notified to the first business system and determining that the current number of executions of the retry processing of the callback task triggered by the failure of the processing result notification has reached the second maximum callback retry number, the callback state of the first business system is changed from a business system intermediate state to a business system failure state.
9. The method according to claim 1, further comprising: In response to determining that the callback task has not been successfully executed when the first maximum callback retry count of the callback task is exhausted, receiving a manual callback request initiated by a user through the callback processing platform; and According to the manual callback request, callback compensation processing is performed on the callback task.
10. The method according to claim 1, wherein: The callback task request also carries a callback failure alarm address of the first business system, and the method further includes: In response to determining that the number of failures of the callback task within a set time period reaches a failure threshold, an alarm is sent to the first business system via the callback failure alarm address.
11. The method according to claim 1, further comprising: Determine a flow limit threshold of the callback interface of the callback task; as well as The callback interface is subjected to flow control according to the flow limit threshold.
12. The method according to claim 1, further comprising: Collecting callback data related to the callback task of the first business system; as well as The collected callback data related to the callback task of the first business system and the callback data of other callback tasks performed by various business systems including the first business system through the callback processing platform are uniformly aggregated and analyzed.
13. The method according to claim 1, further comprising: The callback data related to the callback task is sent to a message queue, so as to realize asynchronous writing into a database through the message queue.
14. The method according to claim 13, further comprising: In response to a failure in writing the callback data into the database, sending the callback data to a delay queue; And in response to the set delay time being reached, the callback data in the delay queue is written into the database.
15. A callback processing platform, comprising: a task receiving unit, configured to receive a callback task request issued by a first business system through the callback processing platform, wherein the callback task request carries information related to a callback interface and a callback policy of the callback task, wherein the callback interface is a target interface that the first business system needs the callback processing platform to call, and the callback interface does not directly contact the first business system, and wherein the callback processing platform is connected to a plurality of business systems including the first business system, and is used to provide unified management including callback policies for the plurality of business systems; and A task processing unit, configured to process the callback task according to the callback task request; The information related to the callback strategy includes information related to the callback failure retry strategy, and the information related to the callback failure retry strategy includes a first maximum callback retry count set for the callback interface; Wherein, processing the callback task according to the callback task request includes: Processing the callback task according to the information related to the callback interface and callback strategy of the callback task carried in the callback task request; and setting the callback state of the callback interface according to the processing result obtained by processing the callback task each time, wherein the callback state of the callback interface includes a callback interface success state, a callback interface intermediate state or a callback interface failure state; The information related to the callback failure retry strategy also includes a second maximum callback retry count related to the notification of the processing result, and the task processing unit is further configured to: Notify the first business system of the first processing result of the successful execution or failed execution of the callback task determined based on the first maximum callback retry number; and set the callback status of the first business system based on the callback status of the callback interface corresponding to the first processing result, the notification result status of the first processing result and the second maximum callback retry number, wherein the callback status of the first business system includes a business system success status, a business system intermediate status or a business system failure status.
16. An electronic device, comprising: at least one processor; as well as a memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, and when the instructions are executed by the at least one processor, the at least one processor is caused to perform the method of any one of claims 1-14.
17. A non-transitory computer-readable storage medium storing computer instructions, wherein: The computer instructions, when executed by a computer, cause the computer to perform a method according to any one of claims 1-14.
18. A computer program product comprising a computer program, wherein: The computer program implements the method of any one of claims 1 to 14 when executed by a processor.
Citation Information
Patent Citations
Approval method and device, apparatus and computer readable storage medium
CN110310091A
Method for realizing workflow callback message and message gateway system
CN113590355A