CN113762677B - Service processing method and device - Google Patents

Service processing method and device Download PDF

Info

Publication number
CN113762677B
CN113762677B CN202011185671.1A CN202011185671A CN113762677B CN 113762677 B CN113762677 B CN 113762677B CN 202011185671 A CN202011185671 A CN 202011185671A CN 113762677 B CN113762677 B CN 113762677B
Authority
CN
China
Prior art keywords
task
butted
downstream
service system
return
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202011185671.1A
Other languages
Chinese (zh)
Other versions
CN113762677A (en
Inventor
周剑桥
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Jingdong Zhenshi Information Technology Co Ltd
Original Assignee
Beijing Jingdong Zhenshi Information Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Jingdong Zhenshi Information Technology Co Ltd filed Critical Beijing Jingdong Zhenshi Information Technology Co Ltd
Priority to CN202011185671.1A priority Critical patent/CN113762677B/en
Publication of CN113762677A publication Critical patent/CN113762677A/en
Application granted granted Critical
Publication of CN113762677B publication Critical patent/CN113762677B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G06Q10/06316—Sequencing of tasks or work
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/083—Shipping
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/103—Workflow collaboration or project management

Landscapes

  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • General Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Development Economics (AREA)
  • Game Theory and Decision Science (AREA)
  • Educational Administration (AREA)
  • Data Mining & Analysis (AREA)
  • Hardware Redundancy (AREA)

Abstract

The application discloses a business processing method and device, and relates to the technical field of computers. One embodiment of the method comprises the following steps: establishing a long connection with an upstream service system to receive a first service request of the upstream service system; determining a butted downstream service system according to the first service request, sending a corresponding second service request to the butted downstream service system, generating a task, wherein the task is used for receiving a return value of the butted downstream service system, and under the condition that long connection is not overtime, periodically inquiring state information of the task, and if the task is successfully executed, returning a set of the return values of the downstream service system received by the task to an upstream service system. The embodiment can return data information required by an upstream service system in real time, can automatically retry when abnormality occurs, adopts a pseudo real-time synchronous architecture to transmit downstream information to the upstream in real time, avoids the conditions of inconsistent state and information of the upstream and downstream systems, improves the overall response speed, and has good expansibility.

Description

Service processing method and device
Technical Field
The present application relates to the field of computer technologies, and in particular, to a service processing method and apparatus.
Background
In some business scenarios, the business processing system interfaces with an upstream business system, a downstream business system, respectively, taking as an example a mezzanine system (a cross-border packet transport management platform) in which upstream interfaces with merchants (e.g., system a), downstream interfaces with carriers (sometimes multi-level carriers, e.g., system C, D, etc.). In the prior art, the system A and the Ma-Zheng system synchronously interact, the Ma-Zheng system accesses the system C, D in one transaction, waits for the return value of the system C, D and synchronously returns to the system A, and the prior art cannot actually meet the synchronous return requirement of the system A.
In the process of implementing the present application, the inventor finds that at least the following problems exist in the prior art:
synchronous interaction with an upstream service system often times out, and complaints of upstream service parties are caused; because of more related systems, the conditions of inconsistent upstream and downstream system states and information are easy to occur; the whole response speed is not guaranteed, and a mature exception handling framework is lacked.
Disclosure of Invention
In view of this, the embodiment of the application provides a service processing method and device, which can return data information needed by an upstream service system in real time, has a mature and effective exception compensation mechanism, can automatically retry when an exception occurs, avoid the condition that the state and information of the upstream system and the downstream system are inconsistent, improve the overall response speed, and have good expansibility.
To achieve the above object, according to an aspect of an embodiment of the present application, there is provided a service processing method.
A business processing method, comprising: establishing a long connection with an upstream service system to receive a first service request of the upstream service system; determining a butted downstream service system according to the first service request, sending a corresponding second service request to the butted downstream service system, and generating a task, wherein the task is used for receiving a return value of the butted downstream service system, and the return value is generated by the butted downstream service system performing service processing according to the second service request; and under the condition that the long connection is not overtime, the state information of the task is queried regularly, and if the state information of the task indicates that the task is successfully executed, the set of the return values received by the task is returned to the upstream service system.
Optionally, the number of the docked downstream service systems is one or more, and each docked downstream service system has a respective return value; after the generating a task, the method comprises: recording the information of the task, wherein the information of the task comprises the state information of the task and the task return times, and the initial value of the task return times is determined according to the number of the butted downstream service systems; executing the task to receive the return value of the butted downstream service system, wherein the value of the task return number is reduced by 1 after each time the return value of one butted downstream service system is received; and when the value of the task return times indicates that the set of return values of the butted downstream service systems has been received, setting the state information of the task to a value indicating that the task execution is successful.
Optionally, when executing the task, the return values of the docked downstream service systems are respectively received through synchronous or asynchronous interfaces provided for the docked downstream service systems.
Optionally, the number of the docked downstream service systems may be dynamically expanded, and when a preset number of the docked downstream service systems is newly added, a synchronous or asynchronous interface corresponding to each newly added docked downstream service system is added, and the value of the task backhaul frequency is increased by the preset number.
Optionally, the sending the corresponding second service request to the docked downstream service system and generating a task include: sending a corresponding second service request to the butted downstream service system, and judging whether the second service request is successful or not; if the request is successful, generating the task; if the request fails, executing retry which does not exceed the preset times within the preset time range, and generating the task after the retry is successful.
Optionally, before the timing querying the state information of the task, the method further includes: checking the long connection state after the second service request is successful or the retry is successful to determine that the long connection is not overtime; the method further comprises the steps of: and after the state information of the task is queried at fixed time, if the state information of the task is queried to indicate that the task is initialized or the task is executed, returning to the step of checking the long connection state to determine that the long connection is not overtime after waiting for a preset time period.
According to another aspect of the embodiment of the present application, a service processing apparatus is provided.
A traffic processing apparatus comprising: the connection establishment module is used for establishing long connection with the upstream service system so as to receive a first service request of the upstream service system; the service processing module is used for determining a butted downstream service system according to the first service request, sending a corresponding second service request to the butted downstream service system, and generating a task, wherein the task is used for receiving a return value of the butted downstream service system, and the return value is generated by the butted downstream service system performing service processing according to the second service request; and the result return module is used for regularly inquiring the state information of the task under the condition that the long connection is not overtime, and returning the set of the return values received by the task to the upstream service system if the state information of the task indicates that the task is successfully executed.
Optionally, the number of the docked downstream service systems is one or more, and each docked downstream service system has a respective return value; the service processing module is further configured to: recording the information of the task, wherein the information of the task comprises the state information of the task and the task return times, and the initial value of the task return times is determined according to the number of the butted downstream service systems; executing the task to receive the return value of the butted downstream service system, wherein the value of the task return number is reduced by 1 after each time the return value of one butted downstream service system is received; and when the value of the task return times indicates that the set of return values of the butted downstream service systems has been received, setting the state information of the task to a value indicating that the task execution is successful.
Optionally, when the service processing module executes the task, the service processing module receives the return value of each docked downstream service system through a synchronous or asynchronous interface provided for each docked downstream service system.
Optionally, the number of the docked downstream service systems may be dynamically expanded; the service processing module is further configured to: when a preset number of the butted downstream service systems are newly added, synchronous or asynchronous interfaces corresponding to the newly added butted downstream service systems are added, and the value of the task return times is increased by the preset number.
Optionally, the service processing module is further configured to: sending a corresponding second service request to the butted downstream service system, and judging whether the second service request is successful or not; if the request is successful, generating the task; if the request fails, executing retry which does not exceed the preset times within the preset time range, and generating the task after the retry is successful.
Optionally, the service processing module is further configured to: checking the long connection state after the second service request is successful or the retry is successful to determine that the long connection is not overtime; the result return module is further configured to: and after the state information of the task is queried at fixed time, if the state information of the task is queried to indicate that the task is initialized or the task is executed, returning to the step of checking the long connection state to determine that the long connection is not overtime after waiting for a preset time period.
According to yet another aspect of an embodiment of the present application, an electronic device is provided.
An electronic device, comprising: one or more processors; and the memory is used for storing one or more programs, and when the one or more programs are executed by the one or more processors, the one or more processors are enabled to realize the service processing method provided by the embodiment of the application.
According to yet another aspect of an embodiment of the present application, a computer-readable medium is provided.
A computer readable medium having stored thereon a computer program which when executed by a processor implements a service processing method provided by an embodiment of the present application.
One embodiment of the above application has the following advantages or benefits: establishing a long connection with an upstream service system to receive a first service request of the upstream service system; determining a butted downstream service system according to the first service request, sending a corresponding second service request to the butted downstream service system, generating a task, wherein the task is used for receiving a return value of the butted downstream service system, and under the condition that long connection is not overtime, periodically inquiring state information of the task, and if the task is successfully executed, returning a set of the return values of the downstream service system received by the task to an upstream service system. The system can return data information needed by an upstream service system in real time, has a mature and effective abnormality compensation mechanism, can automatically retry when abnormality occurs, adopts a pseudo real-time synchronous architecture to transfer downstream information to the upstream in real time, avoids the condition that the state and the information of the upstream system and the downstream system are inconsistent, improves the overall response speed, has good expansibility, and can smoothly support an asynchronous (synchronous) interface between a newly added downstream service system in the future.
Further effects of the above-described non-conventional alternatives are described below in connection with the embodiments.
Drawings
The drawings are included to provide a better understanding of the application and are not to be construed as unduly limiting the application. Wherein:
FIG. 1 is a schematic diagram of the main steps of a business processing method according to one embodiment of the present application;
FIG. 2 is a diagram of a multi-system pseudo-synchronization ordering and backhaul architecture according to one embodiment of the present application;
fig. 3 is a schematic diagram of main modules of a service processing apparatus according to an embodiment of the present application;
FIG. 4 is an exemplary system architecture diagram in which embodiments of the present application may be applied;
FIG. 5 is a schematic diagram of a computer system suitable for use with a server implementing an embodiment of the application.
Detailed Description
Exemplary embodiments of the present application will now be described with reference to the accompanying drawings, in which various details of the embodiments of the present application are included to facilitate understanding, and are to be considered merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the application. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.
Fig. 1 is a schematic diagram of main steps of a service processing method according to an embodiment of the present application.
As shown in fig. 1, the service processing method according to an embodiment of the present application mainly includes the following steps S101 to S103.
Step S101: establishing a long connection with an upstream service system to receive a first service request of the upstream service system;
step S102: determining a butted downstream service system according to the first service request, sending a corresponding second service request to the butted downstream service system, and generating a task, wherein the task is used for receiving a return value of the butted downstream service system, and the return value is generated by the butted downstream service system performing service processing according to the second service request;
step S103: and under the condition that the long connection is not overtime, the state information of the task is queried regularly, and if the state information of the task indicates that the task is successfully executed, the set of return values received by the task is returned to the upstream service system.
The first service request carries service parameters, and according to the service parameters in the first service request, a docked downstream service system can be determined. For example, the service processing method according to an embodiment of the present application may be executed by a server (or a server cluster) of a mezzanine system (a cross-border packet transport management platform), where both the upstream service system and the upstream service system may be logistics merchant systems that interface with the mezzanine system, the first service request and the second service request may be order requests, and the service parameters carried in the first service request are parameters related to the order, where the parameters include information of the downstream logistics merchant that interfaces with the mezzanine system, and the mezzanine system may determine the downstream logistics merchant systems that interface with the mezzanine system according to the service parameters in the first service request.
In one embodiment, the number of the downstream service systems in the butt joint can be one or more, and each downstream service system in the butt joint has a respective return value, and the specific content of the return value is related to the service. Taking the following bill service as an example, for example, the above-mentioned hucho taimen system, the return value of the docked downstream service system may be the bill information of the bill, the last kilometer bill number information, etc.
In one embodiment, after generating the task, the information of the task may be recorded, where the information of the task includes state information of the task and a task backhaul number, and an initial value of the task backhaul number is determined according to the number of the docked downstream service systems, for example, the task backhaul number is equal to the number of the docked downstream service systems; executing tasks to receive the return values of the butted downstream service systems, wherein after receiving the return values of one butted downstream service system, the value of the task return times is reduced by 1; and when the value of the task return number indicates that the set of return values of each butted downstream service system has been received, setting the state information of the task to a value indicating that the task is successfully executed.
In one embodiment, the tasks are performed by receiving return values from the respective docked downstream business systems via synchronous or asynchronous interfaces provided to the respective docked downstream business systems.
In one embodiment, the number of the docked downstream service systems may be dynamically expanded, and when a preset number of docked downstream service systems is newly added, the synchronous or asynchronous interfaces corresponding to each newly added docked downstream service system are added, and the value of the task backhaul number is increased by the preset number.
In one embodiment, sending a corresponding second service request to the docked downstream service system and generating a task includes: sending a corresponding second service request to the butted downstream service system, and judging whether the second service request is successful or not; if the request is successful, generating a task; if the request fails, executing retry which does not exceed the preset times within the preset time range, and generating a task after the retry is successful.
If the retry exceeds the preset times and is unsuccessful, the fault is thrown to the upstream service system, and error prompt information is returned.
In one embodiment, before the timing inquiry task status information, the method further comprises: and after the second service request is successful or the retry is successful, checking the long connection state to determine that the long connection is not overtime. And under the condition of long connection timeout, returning error prompt information to an upstream service system.
In one embodiment, after the status information of the task is queried periodically, if the status information of the task is queried to indicate that the task is initialized or the task is executing, the method returns to the step of checking the long connection state after waiting for a preset period of time to determine that the long connection is not overtime; if the state information of the task is inquired to indicate that the task fails to execute, error prompt information is returned to the upstream service system.
The business processing flow of the embodiment of the application is described in detail below by taking a Mazemen system as an example.
For example, the mezheng system upstream docking merchant (e.g., system a), the downstream docking carrier (e.g., system C, D), system a orders the mezheng system, then the mezheng system orders the system C, D, then the system C, D returns the face order information, the last kilometer freight order number information, and the anomaly information of the freight order to the mezheng system in batches, and the mezheng system needs to return to system a once again after being aligned. In the prior art, the system a requires that the whole process is completed synchronously, but the interaction between the macleaya system and the system C, D is asynchronous communication, and as the service scenario expands, synchronous or asynchronous communication between the macleaya system and the system E and the like may also be required. The prior art has the following defects: synchronous interaction between the system A and the McPhellinus system often times out, and causes complaints of the system A merchants; because of more related systems, the conditions of inconsistent upstream and downstream system states and information are easy to occur; the overall response speed is not guaranteed, and no mature exception handling framework can be used.
Based on the defects in the prior art, the embodiment of the application packages the interaction between the Ma-Zhen system and the system A, C, D and the like into a pseudo real-time synchronous architecture, returns the data information required by the system A in real time, and can perform exception compensation mechanism processing when the Ma-Zhen system fails to order to the system C, D, and can perform real-time monitoring mechanism processing on the return value of an asynchronous interface between the Ma-Zhen system and the system C, D, and the architecture expansibility of the business processing flow based on the embodiment of the application is good, and the asynchronous (synchronous) interface between the future addition of the Ma-Zhen system and the system E (only an example) can also be smoothly supported.
The service processing flow of the embodiment of the application is specifically described based on the pseudo-synchronization ordering and backhaul architecture between multiple systems shown in fig. 2.
As shown in fig. 2, the macleaya system (abbreviated as macleaya system) of the embodiment of the present application provides a logistics gateway interface for external use, establishes a long connection with an upstream service system (such as the upstream system a in fig. 2, abbreviated as system a), interacts with the upstream service system through the logistics gateway interface, and the docked downstream service system (such as the downstream systems C, D and … … in fig. 2) returns a corresponding return value by calling an ISV (independent software developer) interface provided by the macleaya system for external use. The ISV interface in the embodiment of the present application generally refers to an interface provided by the hucho taimen system to an external system, and may be a synchronous or asynchronous interface.
In the embodiment of the application, the system A places orders to the McAb system, the McAb system receives the orders, requests the orders of the system A to drop the warehouse, places orders to the downstream systems C, D and … …, and can call the interfaces of the corresponding downstream systems when placing the orders. The order request of the upstream business system to the McPhemen system is a specific example of the first business request, and the order request of the McPhemen system to the docked downstream business system is a specific example of the second business request.
The embodiment of the application provides an anomaly compensation mechanism, specifically, if the Mazeren system fails to order to the butted downstream service systems (systems C, D and … …), automatic retry is carried out, the number of times of automatic retry order in a specified time (namely a preset time range) can be preset to be not more than 3, and if the retry fails for 3 times, order failure information (or other error prompt information) is returned to the logistics gateway.
If the Ma-Zhen system issues a bill to the docked downstream service system (systems C, D, … …) successfully, or retries no more than 3 times within a preset time range and the retries are successful, a task is generated, the task is used for the Ma-Zhen system to receive a return value of the docked downstream service system (systems C, D, … …), and the return value is generated by the respective docked downstream service system performing the bill issuing process according to the request of the Ma-Zhen for bill issuing.
The embodiment of the application is based on task driving, and two tables need to be established: a task polling list and a task result list. The main field of the task polling list is shown in table 1, and the task polling list records the task information, including a main key of the task, a service identifier (e.g., a bill number) corresponding to the task, a task number, a task name, a task return number, status information (i.e., a task status) of the task, etc., and after the task is generated, the task information may be recorded into the task polling list, where the default value (initial value) of the task return number is the number of the docked downstream service systems, and after each receiving a return value of a docked downstream service system, the mezeren system subtracts 1 from the value of the task return number, so that it may be determined whether the return values of the docked downstream service systems are aligned through the task return number.
In one embodiment, when any one of the downstream service systems such as the system C, D calls the interface, the macleaya system may first determine whether the value of the task backhaul number field of the task polling list is greater than 0, and if so, continue to receive the return value of the downstream service system.
Receiving the return value of the downstream service system includes: the received return VALUE is Inserted (INSERT) into the task result table by KEY/VALUE, the main fields of the task result table are shown in table 2. When the INSERT operation is performed, if the KEY is already present, then the UPDATE (UPDATE) is updated.
The value of the task return number field of the task polling list is subtracted by 1 while each execution of the INSERT operation is performed, and then whether the task return number is 0 is judged, if so, the task status field in the task polling list is updated to be successful (as shown in the following table 1, for example, set to be "2").
TABLE 1
TABLE 2
Name of the name Business meaning Type(s) Whether or not to fill Description of the application
id Main key bigint(50) Is that
taskResultId Task result numbering varchar Is that
taskId Task numbering varchar Is that
returnKey Returning keys varchar Is that
returnValue Return value varchar Is that
The embodiment of the application adopts long connection core logic, packages the interaction between the McPhemen system and the system A, C, D into a pseudo real-time synchronous architecture, and can return the data information needed by the system A in real time. The long connection core logic of the embodiment of the application can be realized based on a while loop, as shown in fig. 2, after the hucho system issues a successful order to the system C, D (specifically, the order request is successful or the order request is retried successfully), the long connection state of the hucho system and the system a is checked to determine whether the long connection is overtime. Specifically, a timeout time L may be configured in the macleaya system, when the macleaya system receives a bill from the upstream system a, the current time T1 is recorded, then the bill is issued to the docked downstream system C, D, a while cycle is entered, and whether the time difference between the current time T2 and the recorded T1 is smaller than L is judged at the beginning, if smaller, the timeout is not performed, and the cycle is continued; if greater than or equal to L, then time out.
Specifically, if the task is not timed out, the state field of the task polling list, i.e. the state information of the task is periodically queried within the while loop to determine whether the task is instructed to be successfully executed (e.g. in table 1, 2 indicates that the task is successfully executed), if not (the initialized or executing task state, i.e. the task state field value is 0 or 1), the process waits for a preset period of time (i.e. the set thread sleep (sleep) waiting time, for example, 100 ms), and then returns to the step of checking the long connection state, and continues the next loop.
And when the operation of the operation is successfully inquired by the McChinen system, inquiring corresponding information in the operation result table according to the operation number, assembling the message according to the recorded information such as the return value of each butted downstream service system, and jumping out of the while circulation, and returning the message to the merchant (namely the upstream system A).
If the long connection times out, the upstream system A is thrown by mistake and jumps out of the loop, and the task state is task execution failure (the state field value is 3).
The anomaly compensation mechanism of the embodiment of the application further comprises: and when the interaction between the McPhellinus system and the system A is overtime, automatically cleaning the related data (logic deletion) of the database of the McPhellinus system.
The architecture of this embodiment facilitates dynamic expansion of a downstream docking system, for example, when docking system X is newly added downstream of the macleaya system, then a default value +1 of a task return number field of the task polling list (a default system interacts with the macleaya system only once), when the macleaya system newly adds to system X to place an order, system X invokes an ISV interface return value of the macleaya system, the architecture of this embodiment ensures that the return value of system X can be returned to system a in real time, i.e., dynamically accessed to system X, so that an asynchronous (synchronous) interface between new addition of the macleaya system and another downstream system in the future can also be smoothly supported.
Fig. 3 is a schematic diagram of main modules of a service processing apparatus according to an embodiment of the present application.
As shown in fig. 3, a service processing apparatus 300 according to an embodiment of the present application mainly includes: a connection establishment module 301, a service processing module 302, and a result return module 303.
The connection establishment module 301 is configured to establish a long connection with an upstream service system to receive a first service request of the upstream service system.
The service processing module 302 is configured to determine a docked downstream service system according to the first service request, send a corresponding second service request to the docked downstream service system, and generate a task, where the task is configured to receive a return value of the docked downstream service system, where the return value is generated by performing service processing on the docked downstream service system according to the second service request.
The result returning module 303 is configured to query the status information of the task at regular time if the long connection is not timed out, and if the status information of the task indicates that the task is executed successfully, return the set of return values received by the task to the upstream service system.
The number of the docked downstream service systems can be one or more, and each docked downstream service system has a respective return value.
The service processing module may specifically be configured to: recording task information, wherein the task information comprises task state information and task return times, and the initial value of the task return times is determined according to the number of the butted downstream service systems; executing tasks to receive the return values of the butted downstream service systems, wherein after receiving the return values of one butted downstream service system, the value of the task return times is reduced by 1; and when the value of the task return number indicates that the set of return values of each butted downstream service system has been received, setting the state information of the task to a value indicating that the task is successfully executed.
When the service processing module executes the task, the service processing module can respectively receive the return values of the butted downstream service systems through synchronous or asynchronous interfaces provided for the butted downstream service systems.
The number of the butted downstream service systems can be dynamically expanded; the service processing module is specifically further configured to: when the preset number of the butted downstream service systems are newly added, synchronous or asynchronous interfaces corresponding to each newly added butted downstream service system are added, and the value of the task return times is increased by the preset number.
The service processing module is specifically further configured to: sending a corresponding second service request to the butted downstream service system, and judging whether the second service request is successful or not; if the request is successful, generating a task; if the request fails, executing retry which does not exceed the preset times within the preset time range, and generating a task after the retry is successful.
The service processing module is specifically further configured to: and after the second service request is successful or the retry is successful, checking the long connection state to determine that the long connection is not overtime.
The result return module may in particular also be used for: after the state information of the task is queried regularly, if the state information of the task is queried to indicate that the task is initialized or the task is executed, the method returns to the step of checking the long connection state after waiting for a preset time period to determine that the long connection is not overtime.
In addition, the specific implementation of the service processing device in the embodiment of the present application has been described in detail in the service processing method described above, so that the description is not repeated here.
Fig. 4 illustrates an exemplary system architecture 400 to which a business processing method or business processing apparatus of embodiments of the present application may be applied.
As shown in fig. 4, the system architecture 400 may include terminal devices 401, 402, 403, a network 404, and a server 405. The network 404 is used as a medium to provide communication links between the terminal devices 401, 402, 403 and the server 405. The network 404 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others.
A user may interact with the server 405 via the network 404 using the terminal devices 401, 402, 403 to receive or send messages or the like. Various communication client applications, such as shopping class applications, web browser applications, search class applications, instant messaging tools, mailbox clients, social platform software, etc. (by way of example only) may be installed on the terminal devices 401, 402, 403.
The terminal devices 401, 402, 403 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smartphones, tablets, laptop and desktop computers, and the like.
The server 405 may be a server providing various services, such as a background management server (by way of example only) providing support for shopping-type websites browsed by users using the terminal devices 401, 402, 403. The background management server may analyze and process the received data such as the product information query request, and feedback the processing result (e.g., the target push information, the product information—only an example) to the terminal device.
It should be noted that, the service processing method provided in the embodiment of the present application is generally executed by the server 405, and accordingly, the service processing apparatus is generally disposed in the server 405.
It should be understood that the number of terminal devices, networks and servers in fig. 4 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.
Referring now to FIG. 5, there is illustrated a schematic diagram of a computer system 500 suitable for use in implementing a server of an embodiment of the present application. The server illustrated in fig. 5 is merely an example, and should not be construed as limiting the functionality and scope of use of embodiments of the present application.
As shown in fig. 5, the computer system 500 includes a Central Processing Unit (CPU) 501, which can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) 502 or a program loaded from a storage section 508 into a Random Access Memory (RAM) 503. In the RAM 503, various programs and data required for the operation of the system 500 are also stored. The CPU 501, ROM 502, and RAM 503 are connected to each other through a bus 504. An input/output (I/O) interface 505 is also connected to bus 504.
The following components are connected to the I/O interface 505: an input section 506 including a keyboard, a mouse, and the like; an output portion 507 including a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker, and the like; a storage portion 508 including a hard disk and the like; and a communication section 509 including a network interface card such as a LAN card, a modem, or the like. The communication section 509 performs communication processing via a network such as the internet. The drive 510 is also connected to the I/O interface 505 as needed. A removable medium 511 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 510 as needed so that a computer program read therefrom is mounted into the storage section 508 as needed.
In particular, according to the disclosed embodiments of the application, the processes described above with reference to the main step schematic diagrams may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method shown in the main step schematic. In such an embodiment, the computer program may be downloaded and installed from a network via the communication portion 509, and/or installed from the removable media 511. The above-described functions defined in the system of the present application are performed when the computer program is executed by a Central Processing Unit (CPU) 501.
The computer readable medium shown in the present application may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present application, however, the computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with the computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.
The primary step diagrams and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the main step diagrams or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or main step diagrams, and combinations of blocks in the block diagrams or main step diagrams, can be implemented by special purpose hardware-based systems that perform the specified functions or operations, or combinations of special purpose hardware and computer instructions.
The modules involved in the embodiments of the present application may be implemented in software or in hardware. The described modules may also be provided in a processor, for example, as: a processor comprises a connection establishment module, a service processing module and a result return module. The names of these modules do not in any way constitute a limitation of the module itself, for example, the connection establishment module may also be described as "a module for establishing a long connection with an upstream service system to receive a first service request of the upstream service system".
As another aspect, the present application also provides a computer-readable medium that may be contained in the apparatus described in the above embodiments; or may be present alone without being fitted into the device. The computer readable medium carries one or more programs which, when executed by a device, cause the device to include: establishing a long connection with an upstream service system to receive a first service request of the upstream service system; determining a butted downstream service system according to the first service request, sending a corresponding second service request to the butted downstream service system, and generating a task, wherein the task is used for receiving a return value of the butted downstream service system, and the return value is generated by the butted downstream service system performing service processing according to the second service request; and under the condition that the long connection is not overtime, the state information of the task is queried regularly, and if the state information of the task indicates that the task is successfully executed, the set of the return values received by the task is returned to the upstream service system.
According to the technical scheme of the embodiment of the application, long connection is established with an upstream service system so as to receive a first service request of the upstream service system; determining a butted downstream service system according to the first service request, sending a corresponding second service request to the butted downstream service system, generating a task, wherein the task is used for receiving a return value of the butted downstream service system, and under the condition that long connection is not overtime, periodically inquiring state information of the task, and if the task is successfully executed, returning a set of the return values of the downstream service system received by the task to an upstream service system. The system can return data information needed by an upstream service system in real time, has a mature and effective abnormality compensation mechanism, can automatically retry when abnormality occurs, adopts a pseudo real-time synchronous architecture to transfer downstream information to the upstream in real time, avoids the condition that the state and the information of the upstream system and the downstream system are inconsistent, improves the overall response speed, has good expansibility, and can smoothly support an asynchronous (synchronous) interface between a newly added downstream service system in the future.
The above embodiments do not limit the scope of the present application. It will be apparent to those skilled in the art that various modifications, combinations, sub-combinations and alternatives can occur depending upon design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present application should be included in the scope of the present application.

Claims (8)

1. A method for processing a service, comprising:
establishing a long connection with an upstream service system to receive a first service request of the upstream service system;
determining a butted downstream service system according to the first service request, sending a corresponding second service request to the butted downstream service system, and generating a task, wherein the task is used for receiving a return value of the butted downstream service system, and the return value is generated by the butted downstream service system performing service processing according to the second service request;
if the long connection is not overtime, the state information of the task is queried regularly, and if the state information of the task indicates that the task is successfully executed, the set of the return values received by the task is returned to the upstream service system;
the number of the butted downstream service systems is one or more, and each butted downstream service system has the return value; after the generating a task, the method comprises: recording the information of the task, wherein the information of the task comprises the state information of the task and the task return times, the initial value of the task return times is determined according to the number of the butted downstream service systems, and when a preset number of the butted downstream service systems is newly added, the value of the task return times is increased by the preset number; executing the task to receive the return value of the butted downstream service system, wherein the value of the task return number is reduced by 1 after each time the return value of one butted downstream service system is received; and when the value of the task return times indicates that the set of return values of the butted downstream service systems has been received, setting the state information of the task to a value indicating that the task execution is successful.
2. The method of claim 1, wherein the tasks are performed by receiving return values of the respective docked downstream service systems via synchronous or asynchronous interfaces provided to the respective docked downstream service systems.
3. A method according to claim 1 or 2, wherein the number of said docked downstream service systems is dynamically expandable, and when a preset number of said docked downstream service systems is added, a synchronous or asynchronous interface corresponding to each newly added docked downstream service system is added.
4. The method of claim 1, wherein the sending the corresponding second service request to the docked downstream service system and generating the task comprises:
sending a corresponding second service request to the butted downstream service system, and judging whether the second service request is successful or not; if the request is successful, generating the task; if the request fails, executing retry which does not exceed the preset times within the preset time range, and generating the task after the retry is successful.
5. The method of claim 4, wherein prior to the timing the querying of the status information of the task, further comprising:
checking the long connection state after the second service request is successful or the retry is successful to determine that the long connection is not overtime;
the method further comprises the steps of:
and after the state information of the task is queried at fixed time, if the state information of the task is queried to indicate that the task is initialized or the task is executed, returning to the step of checking the long connection state to determine that the long connection is not overtime after waiting for a preset time period.
6. A service processing apparatus, comprising:
the connection establishment module is used for establishing long connection with the upstream service system so as to receive a first service request of the upstream service system;
the service processing module is used for determining a butted downstream service system according to the first service request, sending a corresponding second service request to the butted downstream service system, and generating a task, wherein the task is used for receiving a return value of the butted downstream service system, and the return value is generated by the butted downstream service system performing service processing according to the second service request;
the result returning module is used for regularly inquiring the state information of the task under the condition that the long connection is not overtime, and returning the set of the return values received by the task to the upstream service system if the state information of the task indicates that the task is successfully executed;
the number of the butted downstream service systems is one or more, and each butted downstream service system has the return value; the service processing module is further configured to: recording the information of the task, wherein the information of the task comprises the state information of the task and the task return times, the initial value of the task return times is determined according to the number of the butted downstream service systems, and when a preset number of the butted downstream service systems is newly added, the value of the task return times is increased by the preset number; executing the task to receive the return value of the butted downstream service system, wherein the value of the task return number is reduced by 1 after each time the return value of one butted downstream service system is received; and when the value of the task return times indicates that the set of return values of the butted downstream service systems has been received, setting the state information of the task to a value indicating that the task execution is successful.
7. An electronic device, comprising:
one or more processors;
a memory for storing one or more programs,
the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the method of any of claims 1-5.
8. A computer readable medium, on which a computer program is stored, characterized in that the program, when being executed by a processor, implements the method according to any of claims 1-5.
CN202011185671.1A 2020-10-29 2020-10-29 Service processing method and device Active CN113762677B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011185671.1A CN113762677B (en) 2020-10-29 2020-10-29 Service processing method and device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011185671.1A CN113762677B (en) 2020-10-29 2020-10-29 Service processing method and device

Publications (2)

Publication Number Publication Date
CN113762677A CN113762677A (en) 2021-12-07
CN113762677B true CN113762677B (en) 2023-11-03

Family

ID=78785910

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011185671.1A Active CN113762677B (en) 2020-10-29 2020-10-29 Service processing method and device

Country Status (1)

Country Link
CN (1) CN113762677B (en)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107181787A (en) * 2017-03-21 2017-09-19 阿里巴巴集团控股有限公司 A kind of request processing method and device
CN108520454A (en) * 2018-04-10 2018-09-11 平安科技（深圳）有限公司 Method and system for calling back orders in real time
CN109660584A (en) * 2017-10-12 2019-04-19 阿里巴巴集团控股有限公司 A kind of method and communication means and communication system of client and the long connection of server foundation
CN111835467A (en) * 2020-07-28 2020-10-27 中国平安财产保险股份有限公司 Message sending method, device, computer equipment and storage medium

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20140100163A (en) * 2013-02-05 2014-08-14 한국전자통신연구원 A method and apparatus for wavelength selection of onu/ont in passive optical network

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107181787A (en) * 2017-03-21 2017-09-19 阿里巴巴集团控股有限公司 A kind of request processing method and device
CN109660584A (en) * 2017-10-12 2019-04-19 阿里巴巴集团控股有限公司 A kind of method and communication means and communication system of client and the long connection of server foundation
CN108520454A (en) * 2018-04-10 2018-09-11 平安科技（深圳）有限公司 Method and system for calling back orders in real time
CN111835467A (en) * 2020-07-28 2020-10-27 中国平安财产保险股份有限公司 Message sending method, device, computer equipment and storage medium

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"QoS Provisioning Method for Downstream VoIP Service Flows in HFC Networks Publisher: IEEE";Jong-won Park et.al.;《 IEEE Transactions on Consumer Electronics》;第53卷(第2期);第448 - 453页 *
"基于AMQP的消息中间件的设计和实现";吴晗;《中国优秀硕士学位论文全文数据库 信息科技辑》;第2020年卷(第06期);第I138-359页 *
供电企业移动现场作业系统的设计和应用;郑芒英;;信息通信(第05期);第88-90页 *

Also Published As

Publication number Publication date
CN113762677A (en) 2021-12-07

Similar Documents

Publication Publication Date Title
WO2019196244A1 (en) Real-time order callback method and system
CN111277639B (en) Method and device for maintaining data consistency
CN112288577B (en) Transaction processing method, device, electronic equipment and medium for distributed service
US8738770B2 (en) Sending synchronous responses to requests from frontend applications
CN111127181B (en) Voucher accounting method and device
CN113839977A (en) Message pushing method and device, computer equipment and storage medium
CN111181765A (en) Task processing method and device
CN112445860B (en) Method and device for processing distributed transaction
CN113472687B (en) Data processing method and device
CN113157405B (en) Method and device for retrying break points of business process
CN113762677B (en) Service processing method and device
WO2023186154A1 (en) Data transmission system and method
CN115190125B (en) Monitoring method and device for cache cluster
CN111259032A (en) Service processing method and device
CN114756173A (en) Method, system, device and computer readable medium for file merging
CN112306791B (en) Performance monitoring method and device
CN113238919A (en) Statistical method, device and system for user access number
CN113760487A (en) Service processing method and device
CN112883103A (en) Method and device for data transfer between clusters
CN112732471A (en) Error correction method and error correction device for interface return data
CN113766437B (en) Short message sending method and device
CN111159585A (en) Method, device, equipment and medium for automatically submitting data
CN116431367B (en) Method, system and computer readable storage medium for modifying ticket information
CN113364615B (en) Method, device, equipment and computer readable medium for rolling upgrade
CN116010126B (en) Service aggregation method, device and system

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant