A service processing method and device, a server and a medium

Abstract

Embodiments of the application disclose a service processing method and device, a server and a medium, wherein the method comprises: starting a target interface calling thread according to a service requirement, calling the target interface through the target interface calling thread, and generating a retry interface calling message when the calling of the target interface fails, and putting the retry interface calling message into a preset message queue; monitoring the preset message queue through a message monitoring thread, and repeatedly calling the target interface according to the retry interface calling message when the message monitoring thread monitors that the retry interface calling message enters the preset message queue, until a condition for stopping the calling of the target interface is met, and the service requirement is completed. The technical scheme of the embodiment solves the problem of blocking of a single thread serial repeated interface calling thread, which affects the overall performance of the system, and realizes decoupling of a service main process and a step of calling a target interface by using an asynchronous mechanism, so that the interface calling and the main process are independent, and the system performance and stability are ensured.

Description

Technical Field

[0001] Embodiments of the present invention relate to the field of communication technologies, and in particular to a service processing method, device, server, and medium. Background Art

[0002] Large-scale internet project applications are often complex, with frequent interactions between various business parties. Interfaces between different business modules are crucial vehicles and vehicles for these interactions. In real-world operations, calls between these interfaces often have a certain failure rate. When an interface call fails, it must be retried to retrieve data.

[0003] Currently, after an interface call fails, it is usually immediately retried in a loop until the interface call succeeds or is repeated a preset number of times; or, in some business scenarios, a scheduled task is used to complete the corresponding business.

[0004] However, in the process of implementing the present invention, it was found that there are at least the following technical problems in the existing technology: the loop call method is a real-time serial operation method, and the use of thread sleep will cause thread blocking and resource occupation, affecting the overall performance of the system; and the form of scheduled tasks will be limited in application scenarios. Summary of the Invention

[0005] The embodiments of the present invention provide a business processing method, device, server and medium to decouple the main business process from the steps of calling the target interface, release and protect system resources, improve the system's ability to process business, and expand a wider range of application scenarios.

[0006] In a first aspect, an embodiment of the present invention provides a service processing method, the method comprising:

[0007] Open a target interface call thread according to business needs, call the target interface through the target interface call thread, and generate a retry interface call message when the call of the target interface fails, and put the retry interface call message into a preset message queue;

[0008] The preset message queue is monitored by a message monitoring thread. When a retry interface call message is detected entering the preset message queue, the target interface is repeatedly called according to the retry interface call message until the condition for stopping the target interface call is met to complete the business requirement.

[0009] Optionally, while repeatedly calling the target interface according to the retry interface call message, the method further includes:

[0010] Record the number of times the target interface is repeatedly called;

[0011] When the number of calls reaches a preset number, a warning message is issued.

[0012] Optionally, the condition for stopping the target interface call includes:

[0013] Successfully call the target interface and obtain the target business information; or,

[0014] The target interface is repeatedly called a preset number of times and still fails to be called.

[0015] Optionally, repeatedly calling the target interface according to the retry interface call message until a condition for stopping the target interface call is met, thereby completing the service requirement, includes:

[0016] After successfully calling the target interface and obtaining the target business information, the target business information is updated to the business information corresponding to the business requirement, and the business operation associated with the business requirement is executed to complete the business requirement; or

[0017] After repeatedly calling the target interface for a preset number of times and still failing, the result of the interface call failure is fed back to the business information corresponding to the business demand, and the business process is ended.

[0018] Optionally, repeatedly calling the target interface according to the retry interface call message includes:

[0019] The target interface is repeatedly called according to the message consumption time interval in the message consumption strategy of the message queue management platform.

[0020] Optionally, when a retry interface call message is detected entering the preset message queue, the method further includes:

[0021] Setting the key value of the retry interface call message queue message to the identifier of the business requirement;

[0022] Accordingly, before repeatedly calling the target interface according to the retry interface call message, the method further includes:

[0023] Identify the key value of the retry interface call message and determine whether the retry interface call message has been executed.

[0024] Optionally, the business requirements include order management business requirements.

[0025] In a second aspect, an embodiment of the present invention further provides a service processing device, the device comprising:

[0026] A retry message generation module is used to start a target interface call thread according to business needs, call the target interface through the target interface call thread, and generate a retry interface call message when the call of the target interface fails, and put the retry interface call message into a preset message queue;

[0027] The retry message execution module is used to monitor the preset message queue through a message monitoring thread. When a retry interface call message is detected entering the preset message queue, the target interface is repeatedly called according to the retry interface call message until the condition for stopping the target interface call is met, thereby completing the business requirements.

[0028] Optionally, the service processing device further includes an interface call alarm module, configured to record the number of repeated calls to the target interface while repeatedly calling the target interface according to the retry interface call message;

[0029] When the number of calls reaches a preset number, a warning message is issued.

[0030] Optionally, the retry message execution module satisfies the condition for stopping the target interface call when the target interface is successfully called and the target business information is obtained; or, the retry message execution module satisfies the condition for stopping the target interface call when the target interface is repeatedly called a preset number of times and still fails.

[0031] Optionally, the retry message execution module is specifically used to:

[0032] After successfully calling the target interface and obtaining the target business information, the target business information is updated to the business information corresponding to the business requirement, and the business operation associated with the business requirement is executed to complete the business requirement; or

[0033] After repeatedly calling the target interface for a preset number of times and still failing, the result of the interface call failure is fed back to the business information corresponding to the business demand, and the business process is ended.

[0034] Optionally, the retry message execution module is further configured to:

[0035] The target interface is repeatedly called according to the message consumption time interval in the message consumption strategy of the message queue management platform.

[0036] Optionally, the business processing device further includes a message identifier adding module, which is used to set the key value of the retry interface call message queue message as the identifier of the business demand when a retry interface call message enters the preset message queue;

[0037] Correspondingly, the retry message execution module is further used to:

[0038] Before repeatedly calling the target interface according to the retry interface call message, a key value of the retry interface call message is identified to determine whether the retry interface call message has been executed.

[0039] Optionally, the business requirements include order management business requirements.

[0040] In a third aspect, an embodiment of the present invention further provides a server, comprising:

[0041] one or more processors;

[0042] a memory for storing one or more programs;

[0043] When the one or more programs are executed by the one or more processors, the one or more processors implement the business processing method provided by any embodiment of the present invention.

[0044] In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the business processing method provided by any embodiment of the present invention.

[0045] The embodiments of the above invention have the following advantages or beneficial effects:

[0046] The embodiment of the present invention starts a target interface calling thread according to business needs, calls the target interface through the target interface calling thread, and generates a retry interface calling message when the call of the target interface fails. Then, when the message listening thread monitors that there is a retry interface calling message entering the preset message queue, a new target interface calling thread is started according to the retry interface calling message to repeatedly call the target interface until the conditions for stopping the target interface call are met, thereby completing the business needs. This solves the problem in the prior art that repeated serial calls to the interface using a single thread lead to thread blocking, affecting the overall performance of the system, and that the use of a timed task method for retrying the call interface will have usage scenario limitations. It implements an asynchronous mechanism to decouple the main business process from the step of calling the target interface, making the interface call independent of the main process, thereby ensuring system performance and stability, while expanding the use scenarios of the application and making it more versatile. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] Figure 1 This is a flowchart of a service processing method provided by the first embodiment of the present invention;

[0048] Figure 2 This is a retry interface call message signaling diagram provided by the first embodiment of the present invention;

[0049] Figure 3 This is a flow chart of a business processing method provided by Embodiment 2 of the present invention;

[0050] Figure 4 This is an interface call retry flow chart provided by the second embodiment of the present invention;

[0051] Figure 5 This is a schematic diagram of the structure of a service processing device provided by Embodiment 3 of the present invention;

[0052] Figure 6 This is a structural diagram of a server provided in Example 4 of the present invention. DETAILED DESCRIPTION

[0053] The present invention will be further described in detail below with reference to the accompanying drawings and examples. It will be understood that the specific embodiments described herein are intended only to illustrate the present invention and are not intended to limit the present invention. It should also be noted that, for ease of description, the accompanying drawings only illustrate portions relevant to the present invention, not all structures.

[0054] Example 1

[0055] Figure 1 This is a flowchart of a service processing method provided in Example 1 of the present invention. This embodiment is applicable to situations where an interface call fails and a retry is performed. The method can be executed by a service processing device, which can be implemented in software and / or hardware and integrated into an electronic device with application development capabilities.

[0056] like Figure 1 As shown, the business processing method includes the following steps:

[0057] S110. Start a target interface calling thread according to business needs, call the target interface through the target interface calling thread, and generate a retry interface calling message when the call of the target interface fails, and put the retry interface calling message into a preset message queue.

[0058] Business requirements include the need for business interaction between different business systems. For example, if one step in the business process of System A requires obtaining messages generated by System B related to the business of System A, then System A needs to establish a connection with System B to obtain the corresponding information or complete the corresponding operation. Accordingly, the channel through which System A can establish a connection with System B is the target interface.

[0059] Specifically, when the system detects a business need, it will start a target interface call thread and call the target interface through the thread to obtain the corresponding business information or complete the corresponding business instructions and obtain feedback. However, due to fluctuations in network signals or system failures, the call of the target interface may fail, and the business need of calling the target interface cannot be completed. In this embodiment, when the target interface call fails, a retry interface call message is generated, and the retry interface call message is placed in a preset message queue, so that the business system starts a new thread to retry calling the target interface. Instead, in a thread that calls the target interface, the target interface is repeatedly retried and feedback is waited for the message of successful interface call.

[0060] S120. Monitor the preset message queue through a message monitoring thread. When a retry interface call message is detected in the preset message queue, repeatedly call the target interface according to the retry interface call message until the condition for stopping the target interface call is met, thereby completing the business requirement.

[0061] Among them, the role of the message listening thread is to listen for the retry interface call message in the preset queue message, that is, a new thread is opened to implement the retry interface call operation. When the retry interface call information is listened, the message is parsed and the corresponding target interface is called according to the parsed result.

[0062] Furthermore, when the target interface is successfully retried, the target business information related to the business requirement will be obtained. For example, in the hospital registration system, the payment system interface is called to complete the registration and payment task. After calling the payment system interface, feedback information such as payment entry or payment success will be obtained, and the current target interface call task can be completed to achieve the business requirement. When the target interface call fails to be retried, a retry interface call message is generated again based on the feedback result of the call failure, and the retry interface call message is placed in the preset message queue. The message listening thread then listens to and executes the retry interface call message until the number of retry calls to the target interface reaches the preset number, and the call failure information is fed back to end the interface call business requirement. The preset number of times can be determined according to the parameters set by the queue message consumption policy of the message queue management platform. For example, the upper limit of the number of retry calls to the target interface is 5 times. Then, when the retry interface call message is listened to for the 6th time, the message listening thread is ended and the target interface call is no longer retried.

[0063] In a preferred real-time mode, the production and consumption process of retry interface call messages can be referred to Figure 2 The retry interface shown calls the message signaling diagram.

[0064] Specifically, in Figure 2In the example, the producer and listener of the retry (interface call) message are both business systems that generate business needs for calling the target interface. After the business system fails to call the target interface, it will generate a retry interface call message and put the retry interface call message into the preset message queue. When the retry message listener hears the retry interface call message, it sets the key value of the retry interface call message queue message to the identifier of the business need. When the retry target interface call is subsequently executed, it verifies whether the retry message has been consumed based on the identifier, thereby ensuring that each retry message is consumed only once, ensuring the idempotence of message consumption.

[0065] In addition, when the retry message listener repeatedly calls the target interface according to the retry interface call message it listens to, it also records the number of times the target interface is repeatedly called; when the number of calls reaches the preset number, a warning message is issued so that the system maintenance personnel can also grasp the target interface call failure information and handle it in the shortest time. Among them, the preset number of times the upper limit of the number of calls to repeatedly call the target interface can be a parameter of the message consumption strategy configured by the message queue management console. Furthermore, the target interface call retry mechanism can also be based on the message queue management console, and the retry interval can be achieved by configuring the message consumption strategy, that is, according to the message consumption time interval in the message consumption strategy of the message queue management platform, the retry interface call message is consumed and the target interface is repeatedly called. During the consumption process of each retry interface call message, if the call still fails, it is matched with the consumption strategy configured by the queue message management platform to determine whether to retry again. If retry is required, the call result is fed back to the retry message producer.

[0066] The technical solution of this embodiment is to start a target interface calling thread according to business needs, call the target interface through the target interface calling thread, and generate a retry interface calling message when the call of the target interface fails. Then, when the message listening thread monitors that there is a retry interface calling message entering the preset message queue, a new target interface calling thread is started according to the retry interface calling message to repeatedly call the target interface until the conditions for stopping the target interface call are met, thereby completing the business needs. It solves the problem in the prior art that repeated serial calls to the interface using a single thread lead to thread blocking, affecting the overall performance of the system, and that the use of a scheduled task method for retrying the call interface will have usage scenario limitations. It implements an asynchronous mechanism to decouple the main business process from the step of calling the target interface, making the interface call independent of the main process, thereby ensuring system performance and stability, while expanding the use scenarios of the application to make it more versatile.

[0067] Example 2

[0068] Figure 3This is a flowchart of a business processing method provided in Example 2 of the present invention. This embodiment is applicable to order management scenarios where an asynchronous mechanism is used to retry interface calls. It shares the same inventive concept as the business processing method in the previous embodiment. This method can be executed by a business processing device, which can be implemented in software and / or hardware and integrated into a server device with application development capabilities.

[0069] like Figure 3 As shown, the business processing method includes the following steps:

[0070] S210: Monitor order delivery information of the order generation system, and parse the order delivery information to obtain order information.

[0071] Among them, the order generation system can be any shopping platform system. When a user purchases physical items or virtual items, an order will be generated. The warehouse management subsystem in the order generation system will send order outbound information to the preset message queue based on the order information of each order when the item is shipped out. The order outbound information includes information such as order number, order item name, outbound time and logistics information.

[0072] S220. When the order information includes an order management identifier, the order information is stored in a database of the business management system, and a target interface calling thread is started according to order management business requirements, and a target interface is called through the target interface calling thread.

[0073] Due to the different categories of items in the orders, some orders require further unified management. For example, registration and supervision of orders for purchasing special items, or providing associated virtual services to users who purchase a certain item, etc. These all require unified management of orders with management needs, and further matching management serial numbers for orders with management needs.

[0074] When parsing the order outbound information and identifying that the order information contains an order management identifier, the order information is stored in the database of the business management system, and the order management information is backed up. Then, according to the order management business requirements, the target interface call thread is started, and the target interface is called through the target interface call thread. It should be noted that the business management system is a system that monitors order outbound information. The target interface can be a serialization center system, which calls the serialization center interface to obtain a serial number for the order that needs to be managed, so as to facilitate unified management; the target interface can also be a customer service center, which calls the customer service center interface to match the corresponding additional service information for the items purchased by the user, etc., or the target interface can be any system interface related to the order management business, so as to obtain the corresponding target business information and complete the business requirements in order to execute subsequent related business logic operations.

[0075] S230. When the call of the target interface fails, a retry interface call message is generated, and the retry interface call message is placed in a preset message queue.

[0076] Due to network signal fluctuations or system failures, the target interface call may fail, and the business needs of calling the target interface may not be met, such as not being able to obtain the order serial number fed back by the target interface. In this embodiment, when the target interface call fails, a retry interface call message is generated and placed in a preset message queue so that the business management system can start another new thread to retry calling the target interface.

[0077] S240. The preset message queue is monitored through a message monitoring thread. When a retry interface call message is detected entering the preset message queue, the target interface is repeatedly called according to the retry interface call message until the condition for stopping the target interface call is met, and the target interface call result is updated to the database to complete the order management business needs.

[0078] When the retry interface call information is monitored, the message is parsed, the corresponding order information can be obtained, and the corresponding target interface is called according to the parsing result. When the target interface is successfully retried, the target business information related to the order management business needs will be obtained, and the current target interface call task can be completed to achieve the business needs. When the retry target interface call fails, the retry interface call message is generated again according to the feedback result of the call failure, and the retry interface call message is placed in the preset message queue. The message listening thread then listens to and executes the retry interface call message until the number of times the target interface is retried reaches the preset number, and the call failure information is fed back to end the interface call business need. Among them, the preset number can be determined by the parameters set according to the queue message consumption policy of the message queue management platform. For example, the upper limit of the number of times the target interface is retried is 5 times. Then, when the retry interface call message is monitored for the 6th time, the message listening thread is ended and the target interface call is no longer retried.

[0079] Specifically, the technical solution of this embodiment can also refer to Figure 4 The interface call retry flow chart shown in the figure. In this flow chart, after successfully calling the target interface and obtaining the target business information, the information will be fed back to the user to inform the user of the corresponding operation.

[0080] In particular, the retry interface calling solution of this embodiment is not only applicable to the order management business of some large e-commerce systems, but also applicable to other business scenarios such as communications, medical care, insurance, and banking.

[0081] The technical solution of this embodiment monitors the order delivery information of the order generation system, identifies the orders that need to be managed based on the order delivery information, and starts the target interface calling thread according to the business needs of order management, calls the target interface through the target interface calling thread, and generates a retry interface calling message when the call of the target interface fails, and then when the message listening thread monitors that there is a retry interface calling message entering the preset message queue, starts a new target interface calling thread according to the retry interface calling message to repeatedly call the target interface until the conditions for stopping the target interface call are met, so as to realize order management related operations; it solves the problem in the prior art that when performing order management operations, a single thread is used to repeatedly call the interface serially, causing thread blocking and affecting the overall performance of the system, and the problem that the use of a scheduled task method to retry calling the interface will have usage scenario limitations, and realizes the use of an asynchronous mechanism to decouple the main business process from the step of calling the target interface, so that the interface call is independent of the main process, thereby ensuring system performance and stability, and expanding the use scenarios of the application to make it more versatile.

[0082] The following is an embodiment of a service processing device provided by an embodiment of the present invention. This device and the service processing methods of the aforementioned embodiments are based on the same inventive concept and can implement the service processing methods of the aforementioned embodiments. For details not fully described in the embodiments of the service processing device, reference can be made to the embodiments of the aforementioned service processing methods.

[0083] Example 3

[0084] Figure 5 This is a structural diagram of a service processing device provided by Embodiment 3 of the present invention. This embodiment is applicable to situations where an interface call fails and is retried.

[0085] like Figure 5 As shown, the service processing device includes a retry message generating module 310 and a retry message executing module 320.

[0086] Among them, the retry message generation module 310 is used to start the target interface calling thread according to business needs, call the target interface through the target interface calling thread, and generate a retry interface calling message when the call of the target interface fails, and put the retry interface calling message into the preset message queue; the retry message execution module 320 is used to monitor the preset message queue through the message monitoring thread, and when a retry interface calling message is detected entering the preset message queue, the target interface is repeatedly called according to the retry interface calling message until the conditions for stopping the target interface call are met, thereby completing the business needs.

[0087] The technical solution of this embodiment is to start a target interface calling thread according to business needs, call the target interface through the target interface calling thread, and generate a retry interface calling message when the call of the target interface fails. Then, when the message listening thread monitors that there is a retry interface calling message entering the preset message queue, a new target interface calling thread is started according to the retry interface calling message to repeatedly call the target interface until the conditions for stopping the target interface call are met, thereby completing the business needs. It solves the problem in the prior art that repeated serial calls to the interface using a single thread lead to thread blocking, affecting the overall performance of the system, and that the use of a scheduled task method for retrying the call interface will have usage scenario limitations. It implements an asynchronous mechanism to decouple the main business process from the step of calling the target interface, making the interface call independent of the main process, thereby ensuring system performance and stability, while expanding the use scenarios of the application to make it more versatile.

[0088] Optionally, the service processing device further includes an interface call alarm module, configured to record the number of repeated calls to the target interface while repeatedly calling the target interface according to the retry interface call message;

[0089] When the number of calls reaches a preset number, a warning message is issued.

[0090] Optionally, the retry message execution module 320 satisfies the condition for stopping the target interface call when the target interface is successfully called and the target business information is obtained; or, satisfies the condition for stopping the target interface call when the target interface is repeatedly called a preset number of times and still fails.

[0091] Optionally, the retry message execution module 320 is specifically configured to:

[0092] After successfully calling the target interface and obtaining the target business information, the target business information is updated to the business information corresponding to the business requirement, and the business operation associated with the business requirement is executed to complete the business requirement; or

[0093] After repeatedly calling the target interface for a preset number of times and still failing, the result of the interface call failure is fed back to the business information corresponding to the business demand, and the business process is ended.

[0094] Optionally, the retry message execution module 320 is further configured to:

[0095] The target interface is repeatedly called according to the message consumption time interval in the message consumption strategy of the message queue management platform.

[0096] Optionally, the business processing device further includes a message identifier adding module, which is used to set the key value of the retry interface call message queue message as the identifier of the business demand when a retry interface call message enters the preset message queue;

[0097] Accordingly, the retry message execution module 320 is further configured to:

[0098] Before repeatedly calling the target interface according to the retry interface call message, a key value of the retry interface call message is identified to determine whether the retry interface call message has been executed.

[0099] Optionally, the business requirements include order management business requirements.

[0100] The service processing device provided by the embodiment of the present invention can execute the service processing method provided by any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0101] Example 4

[0102] Figure 6 A schematic diagram of the structure of a server provided in embodiment 4 of the present invention. Figure 6 A block diagram of an exemplary server 12 suitable for use in implementing embodiments of the present invention is shown. Figure 6 The server 12 shown is only an example and should not limit the functionality and scope of use of the embodiments of the present invention. The server 12 can be any terminal device with computing capabilities, such as an intelligent controller and server, a mobile phone, and other terminal devices.

[0103] like Figure 6 As shown, server 12 is implemented as a general-purpose computing device. Components of server 12 may include, but are not limited to, one or more processors or processing units 16, system memory 28, and a bus 18 that connects various system components (including system memory 28 and processing units 16).

[0104] Bus 18 represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processor, or a local bus using any of a variety of bus architectures. Examples of these architectures include, but are not limited to, an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MAC) bus, an Enhanced ISA bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus.

[0105] The server 12 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by the server 12, including volatile and non-volatile media, removable and non-removable media.

[0106] System memory 28 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and / or cache memory 32. Server 12 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 34 may be configured to read and write non-removable, non-volatile magnetic media ( Figure 6 Not shown, often called a "hard drive"). Although Figure 6 Not shown, a magnetic disk drive for reading and writing to a removable non-volatile magnetic disk (e.g., a "floppy disk"), and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 18 via one or more data media interfaces. System memory 28 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of various embodiments of the present invention.

[0107] A program / utility 40 having a set (at least one) of program modules 42 may be stored, for example, in system memory 28. Such program modules 42 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data, each of which, or some combination thereof, may include an implementation of a network environment. Program modules 42 generally perform the functions and / or methods of the embodiments described herein.

[0108] The server 12 may also communicate with one or more external devices 14 (e.g., keyboards, pointing devices, displays 24, etc.), one or more devices that enable a user to interact with the server 12, and / or any device that enables the server 12 to communicate with one or more other computing devices (e.g., a network card, a modem, etc.). Such communication may occur via an input / output (I / O) interface 22. Furthermore, the server 12 may also communicate with one or more networks (e.g., a local area network (LAN), a wide area network (WAN), and / or a public network, such as the Internet) via a network adapter 20. As shown, the network adapter 20 communicates with the other modules of the server 12 via the bus 18. It should be understood that although Figure 6Not shown, other hardware and / or software modules may be used in conjunction with server 12, including but not limited to microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0109] The processing unit 16 executes various functional applications and data processing by running programs stored in the system memory 28, for example, implementing a business processing method provided by an embodiment of the present invention, which includes:

[0110] Open a target interface call thread according to business needs, call the target interface through the target interface call thread, and generate a retry interface call message when the call of the target interface fails, and put the retry interface call message into a preset message queue;

[0111] The preset message queue is monitored by a message monitoring thread. When a retry interface call message is detected entering the preset message queue, the target interface is repeatedly called according to the retry interface call message until the condition for stopping the target interface call is met to complete the business requirement.

[0112] Example 5

[0113] This fifth embodiment provides a computer-readable storage medium having a computer program stored thereon. When the program is executed by a processor, the service processing method provided in any embodiment of the present invention is implemented, including:

[0114] Open a target interface call thread according to business needs, call the target interface through the target interface call thread, and generate a retry interface call message when the call of the target interface fails, and put the retry interface call message into a preset message queue;

[0115] The preset message queue is monitored by a message monitoring thread. When a retry interface call message is detected entering the preset message queue, the target interface is repeatedly called according to the retry interface call message until the condition for stopping the target interface call is met to complete the business requirement.

[0116] The computer storage medium of the embodiment of the present invention can adopt any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium can be, for example, but not limited to: an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or component, or any combination of the above. More specific examples (non-exhaustive list) of computer-readable storage media include: an electrical connection with one or more wires, 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 above. In this document, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device.

[0117] A computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0118] Program code embodied on a computer-readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0119] The computer program code for performing the operations of the present invention can be written in one or more programming languages, or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0120] Those skilled in the art will appreciate that the modules or steps of the present invention described above can be implemented using a general-purpose computing device. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Alternatively, they can be implemented using program code executable by a computer device, which can then be stored in a storage device and executed by the computing device. Alternatively, they can be fabricated into separate integrated circuit modules, or multiple modules or steps can be fabricated into a single integrated circuit module. Thus, the present invention is not limited to any specific combination of hardware and software.

[0121] Note that the above are only preferred embodiments of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and that various obvious changes, readjustments, and substitutions can be made by those skilled in the art without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments and may include many other equivalent embodiments without departing from the concept of the present invention. The scope of the present invention is determined by the scope of the appended claims.

Claims

1. A business processing method, characterized in that: include: Monitor the order outbound information of the order generation system, parse the order outbound information, and obtain order information; When the order information contains an order management identifier, the order information is stored in a database of the business management system; Open a target interface call thread according to order management business requirements, call the target interface through the target interface call thread, and generate a retry interface call message when the call of the target interface fails, and put the retry interface call message into a preset message queue; The preset message queue is monitored by a message monitoring thread. When a retry interface call message is detected in the preset message queue, the target interface is repeatedly called according to the retry interface call message until the condition for stopping the target interface call is met, and the target interface call result is updated in the database to complete the order management business requirement; When a retry interface call message is detected entering the preset message queue, the method further includes: Setting the key value of the retry interface call message queue message to the identifier of the business requirement; Accordingly, before repeatedly calling the target interface according to the retry interface call message, the method further includes: Identify the key value of the retry interface call message and determine whether the retry interface call message has been executed.

2. The method according to claim 1, characterized in that While repeatedly calling the target interface according to the retry interface call message, the method further includes: Record the number of times the target interface is repeatedly called; When the number of calls reaches a preset number, a warning message is issued.

3. The method according to claim 1, characterized in that The conditions for stopping the target interface call are as follows: Successfully call the target interface and obtain the target business information; or, The target interface is repeatedly called a preset number of times and still fails to be called.

4. The method according to claim 3, wherein Repeatedly calling the target interface according to the retry interface call message until a condition for stopping the target interface call is met, thereby completing the business requirement, including: After successfully calling the target interface and obtaining the target business information, the target business information is updated to the business information corresponding to the business requirement, and the business operation associated with the business requirement is executed to complete the business requirement; or After repeatedly calling the target interface for a preset number of times and still failing, the result of the interface call failure is fed back to the business information corresponding to the business demand, and the business process is ended.

5. The method according to claim 1, wherein Repeatingly calling the target interface according to the retry interface call message includes: The target interface is repeatedly called according to the message consumption time interval in the message consumption strategy of the message queue management platform.

6. A business processing device, characterized in that: include: Monitor the order outbound information of the order generation system, parse the order outbound information, and obtain order information; When the order information contains an order management identifier, the order information is stored in a database of the business management system; A retry message generation module is used to start a target interface call thread according to order management business requirements, call the target interface through the target interface call thread, and generate a retry interface call message when the call of the target interface fails, and put the retry interface call message into a preset message queue; A retry message execution module is configured to monitor the preset message queue through a message monitoring thread, and when a retry interface call message is detected in the preset message queue, repeatedly call the target interface according to the retry interface call message until a condition for stopping the target interface call is met, and update the target interface call result to the database to complete the order management business requirement; A message identifier adding module is used to set the key value of the retry interface call message queue message as the identifier of the business demand when monitoring the entry of a retry interface call message into the preset message queue; The retry message execution module is further used for: Before repeatedly calling the target interface according to the retry interface call message, a key value of the retry interface call message is identified to determine whether the retry interface call message has been executed.

7. A server, characterized in that: The server includes: one or more processors; a memory for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the business processing method according to any one of claims 1 to 5.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the service processing method according to any one of claims 1 to 5 is implemented.

Images