WO2018113601A1 - 一种业务处理方法及装置 - Google Patents

一种业务处理方法及装置 Download PDF

Info

Publication number
WO2018113601A1
WO2018113601A1 PCT/CN2017/116509 CN2017116509W WO2018113601A1 WO 2018113601 A1 WO2018113601 A1 WO 2018113601A1 CN 2017116509 W CN2017116509 W CN 2017116509W WO 2018113601 A1 WO2018113601 A1 WO 2018113601A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
server
client
category
service result
Prior art date
Application number
PCT/CN2017/116509
Other languages
English (en)
French (fr)
Inventor
倪飞
胡宗旺
Original Assignee
阿里巴巴集团控股有限公司
倪飞
胡宗旺
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 阿里巴巴集团控股有限公司, 倪飞, 胡宗旺 filed Critical 阿里巴巴集团控股有限公司
Priority to JP2019534167A priority Critical patent/JP7036826B2/ja
Priority to KR1020197017251A priority patent/KR102246394B1/ko
Priority to EP17882785.3A priority patent/EP3534585A4/en
Priority to MYPI2019002979A priority patent/MY186646A/en
Publication of WO2018113601A1 publication Critical patent/WO2018113601A1/zh
Priority to US16/421,188 priority patent/US11132666B2/en
Priority to PH12019501204A priority patent/PH12019501204A1/en

Links

Images

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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
    • 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405—Establishing or using transaction specific rules
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network

Definitions

  • the present application relates to the field of computer technologies, and in particular, to a service processing method and apparatus.
  • Online systems can provide users with rich business services with the support of their back-end business systems. Some of these services may require different business systems to work together.
  • the service request initiated by the user through a client such as a browser or an application (Application, APP)
  • the process of processing the foregoing service request may be specifically: according to the order of the business process,
  • the business system that processes the business request will generate the corresponding processing result (which can be called the intermediate result), and return it to the client.
  • the client redirects to the next business system in the business process according to the intermediate result, and initiates the request.
  • the next business system is post-processed, and so on, until the entire business process is completed.
  • the service request is first processed by the service system A to generate an intermediate result a.
  • the service system A returns the intermediate result a to the client, and the client is redirected to the service system B based on the intermediate result a.
  • the business system B will process the request, generate the business result b, and return to the client.
  • each service system interacts with the client through the Internet, and the stability of the network environment of the Internet is poor.
  • the network delay may occur due to the influence of the network environment, causing the client to The process of sending an intermediate request to the next service system takes a long time; in addition, in the above manner, the service system only performs the corresponding processing after receiving the request from the client, and the online system usually Faced with a large number of user accesses, the workload of each business system is high, resulting in a request waiting delay in the processing queue of the business system.
  • there may be a certain delay in the transmission phase and processing phase of the request which will inevitably result in a longer waiting time for the client, which makes the timeliness of the business process less.
  • the embodiment of the present application provides a service processing method and device, which are used to solve the problem of poor timeliness of the existing service processing process.
  • the second server receives the first service result sent by the first server, where the first service result is generated after the first server processes the first service request sent by the client;
  • the second server After receiving the second service request sent by the client, the second server feeds back the generated second service result to the client.
  • the first server receives the first service request sent by the client
  • Transmitting the first service result to the second server so that the second server determines a category corresponding to the first service result, and generates a second that matches the category according to the first service result and the category.
  • the service result and after the second server receives the second service request generated by the client according to the first service result, sends the generated second service result to the client.
  • the feedback module when the second server receives the second service request sent by the client, feeds back the generated second service result to the client.
  • the sending module the first service result is sent to the client, and the second server, so that the second server determines a category corresponding to the first service result, according to the first service result and category,
  • the second service result is generated, and after the second server receives the second service request generated by the client according to the first service result, the generated second service result is sent to the client.
  • the embodiment of the present application provides a service processing method and device.
  • the first server receives the first service request sent by the client, the first server processes the first service request and generates a corresponding first service.
  • the first server sends the first service result to the second server according to the service process, and the second server determines the first service result.
  • the category in which the second server can process the first service result, and generate a second service result that matches the category in advance.
  • the second server can generate the second service result before receiving the second service request sent by the client, and after the second server receives the second request actually sent by the client,
  • the second service result that has been generated can be directly returned to the client, and the generated second service result is consistent with the service type of the first service result.
  • the second server can pre-generate the second service result according to the first service result before receiving the second service request of the client, thereby effectively saving the waiting time of the client. It also improves the timeliness of processing business requests.
  • FIG. 1b is a process of processing a service based on a second server side according to an embodiment of the present application
  • FIG. 2 is a service processing procedure based on a first server side according to an embodiment of the present application
  • FIG. 3 is a schematic diagram of a service processing procedure in an application example provided by an embodiment of the present application.
  • FIG. 4 is a schematic structural diagram of a service processing apparatus based on a second server side according to an embodiment of the present application
  • FIG. 5 is a schematic structural diagram of a service processing apparatus based on a first server side according to an embodiment of the present disclosure.
  • the client when a user obtains a service service that needs to be completed by multiple service systems from a network system through a client, the client usually needs to receive intermediate service results returned by different service systems, and performs redirection based on the intermediate service result. , the next business system issues a request until the completion of the complete business process, but in the process, the client is vulnerable to the network environment when sending a request to the business system, resulting in transmission delay, and the business system can only After receiving the service request sent by the client, the processing will be processed.
  • the service service of the online system since the user accesses the service service from the online system through the client, the service service of the online system often needs to be completed by multiple service systems, so the client will follow the business process and target different business systems. Different service requests are initiated, but it can be considered that different service requests initiated by the client are to complete the same service.
  • the service processing method in the embodiment of the present application is based on the architecture shown in FIG. 1a, and can be seen in FIG. 1.
  • the architecture includes a service client (hereinafter referred to as a client) used by a user, and a first server.
  • the second server wherein the client may be a browser running in the terminal, an APP application, etc., the first server and the second server have different service functions, and the first server and the second server may specifically be
  • the two adjacent service servers in the business process the second server may be a service server that is processed in the business process after the first server, for example, assume that three existing service servers A, B, and C are The service server needs to be completed in the order of the service servers A to B and then to C.
  • the first server may be the service server A, and the second server may be the service server B;
  • the first server may be the service server B, and the second server may be the service server C.
  • the first server and the second server in the present application are not limited to the scenario of two servers.
  • the service processing method in the present application is described below in conjunction with the architecture shown in FIG. 1a.
  • the service processing procedure shown in FIG. 1b includes the following steps:
  • Step S101 The second server receives the first service result sent by the first server.
  • the first service result is generated after the first server processes the first service request sent by the client.
  • a user when a user obtains a service service by using a client, it usually needs to send a service request to the corresponding service server. For example, after the user places an order for an item, the client sends the message to the next server.
  • the order server is the first server, and the order request is the first service request.
  • the first service request may be a service request received by the first server, and the first service request may be a service request sent by the client according to the operation instruction of the user, or the client may receive the business process.
  • the first business result can be regarded as an intermediate result generated by the first server after corresponding processing of the first service request.
  • the process of the client sending the second service request to the second server may be delayed by the network environment, and the second server may also generate the second service request and process the second service request.
  • the first server sends the first service result to the client.
  • the first server sends the first service result to the client.
  • the first service result is directly sent to the second server, and then the second server can process in advance according to the first service result.
  • the category corresponding to the first service result may be considered as the category corresponding to the first server, and it should be understood that, in actual applications, for the first server of different service providers, the category (such as There are usually differences in the types of services provided and the categories of the service providers themselves. Accordingly, there are different requirements for the categories of the second business results.
  • the telecom operator at this time, the first server is the telecom carrier server
  • the bank at this time, the first server is the bank server
  • the business result is usually related to the telecommunication service
  • the first service result generated by the bank server is usually related to the financial service. It can be understood that the categories of the second service result generated by the above two service providers should also be different.
  • S103 Generate, according to the category and the first service result, a second service result that matches the category.
  • the second server After the second server receives the first service result, it can process in advance to generate a second service result that matches the category.
  • the second server After receiving the second service request, the second server can directly feed back the second result generated in advance to the client, thereby reducing or avoiding the waiting time of the client.
  • the first server After the first server receives the first service request sent by the client, the first server processes the first service request and generates a corresponding first service result. At this time, the first server except the first service The result is returned to the client, and the first service result is sent to the second server according to the business process, and the second server determines the category corresponding to the first service result, so that the second server can A business result is processed to generate a second business result that matches the category in advance. It is the manner in which the second server can generate the second service result before receiving the second service request sent by the client, and after the second server receives the second request actually sent by the client, The second service result that has been generated can be directly returned to the client, and the generated second service result is consistent with the service type of the first service result. Obviously, the second server can pre-generate the second service result according to the first service result before receiving the second service request of the client, thereby effectively saving the waiting time of the client. It also improves the timeliness of processing business requests.
  • a user uses a client of a product website to purchase an item on the product website. It can be considered that the user's purchase operation for a certain product through the client involves placing an order and paying two services, and the payment service provider (eg, a payment platform) can provide a payment service in the process (ie, the order service is performed by the The order server in the background of the product website is completed, and the payment service is completed by the payment server in the background of the payment platform).
  • the first service request is an order request
  • the first server includes an order server
  • the first service result includes order information
  • the second server includes a payment server
  • the second service result includes a payment interface or an abnormal page.
  • determining the category corresponding to the first service result includes: determining a category identifier of the order server included in the order data.
  • the category identifier actually reflects the category identifier of the first server.
  • the category identifier may include: a name of the service provider to which the first server belongs, industry category information, and The name of a server itself, the device number, and the like, are not intended to limit the application.
  • the generated payment pages are usually different, so the payment server Different payment page templates are usually stored to correspond to different order servers, and the order data sent by the order server also includes the category identifier of the order server, so that the corresponding payment page template can be determined.
  • the order data to be rendered may also be different.
  • the payment page For example, for the payment page of a product website, the payment page needs to display the user's order number, payment amount, mailing address and the like, and
  • the payment page of the mobile phone card recharge the payment page needs to display the data of the single number, the mobile phone number to be recharged, the amount and the like.
  • the order data to be rendered is not the same.
  • the process of the payment server determining the payment status according to the order data may be implemented based on an account pre-registered by the user, and the method is divided into two cases:
  • the account registered by the user at the service provider is generally used for the order server and the payment server.
  • the payment server has the right to query the user's account balance, thereby Determine if this payment can be successful.
  • the order server and the payment server belong to different service providers respectively. Then, it can be understood that the accounts registered by the user at the two service providers should be related to each other, so that the payment server still has the right to query the user to place the server. The balance of the account registered in the account, and based on this, judge whether the payment can be successful.
  • the method further comprises: deleting the mark of the order data, rendering and constructing an abnormal page.
  • the data that is successfully rendered may also be marked for subsequent optimization of the system, where It is not described in detail.
  • the order data in the embodiment of the present application further includes a client identifier
  • the method further includes: establishing a correspondence between the client identifier and the payment page or the abnormal page.
  • the feedback of the generated second service result to the client includes: determining a client identifier in the second service request, and generating a payment page corresponding to the client identifier or The exception page is fed back to the client.
  • the payment server After the payment server receives the payment request sent by the client, the payment page or the abnormal page that is rendered and constructed in advance can be fed back to the client.
  • Step S201 The first server receives the first service request sent by the client.
  • Step S202 Generate, according to the first service request, a first service result corresponding to the first server self category.
  • the first server After receiving the first service request, the first server processes the first service request to generate a corresponding service result, that is, the first service result, where the first service result is usually an intermediate service result.
  • the first service request may carry the identifier information of the client
  • the first service result generated by the first server may also include the identifier information of the client.
  • Step S301 The user issues an order operation instruction to the client.
  • Step S302 The client sends an order request to the single server according to the order operation instruction.
  • Step S303 The ordering server processes the received order request to generate order information.
  • Step S305 The ordering server sends the order information to the client. So that the client performs step S307.
  • Step S306 The payment server determines a corresponding payment page template according to the order information, and further generates a payment page.
  • Step S307 The client redirects to the payment server according to the order information, and issues a payment page request to the payment server.
  • Step S308 The payment server returns a payment page to the client.
  • the order server in the actual payment scenario, once the order server generates the order information, it will immediately send it to the payment server for processing to generate a corresponding payment page, then when the client sends a payment page to the payment server. After the request, the payment server can immediately return the generated payment page to the client. Obviously, such an approach will effectively reduce the time the client waits to generate a payment page, and further allows the user to browse to the payment page more quickly to complete the payment service in the payment page.
  • the present application further provides an embodiment of the service processing apparatus, as shown in FIG. 4 .
  • the service processing device of FIG. 4, the device may be disposed in a second server, the device comprising:
  • the receiving module 401 is configured to receive a first service result sent by the first server, where the first service result is generated by the first server processing the first service request sent by the client;
  • the category determining module 402 is configured to determine a category corresponding to the first service result
  • the generating module 4033 is configured to generate, according to the category and the first service result, a second service result that matches the category;
  • the feedback module 404 when the second server receives the second service request sent by the client, feeds back the generated second service result to the client.
  • the first service request is an order request; the first server includes an order server; the first service result includes order data; and the second server includes a payment.
  • the order data includes a category identifier of the order server; the category determining module 402 determines a category identifier of the order server included in the order data; and the generating module 403 is configured according to the pre-established category identifier.
  • the page template determining a page template corresponding to the order data, marking, according to the determined interface template, order data matching the page template in the order data, and rendering according to the marked order data Build a payment page.
  • the generating module 403 determines a payment status according to the order data, and when it is determined that the payment status is payable, renders and constructs a payment page according to the marked order data. .
  • the generating module 403 determines that the payment status is not payable, the mark of the order data is deleted, and an abnormal page is rendered and constructed. .
  • the order data carries a client identifier
  • the device further includes: a relationship establishing module 405, configured to establish a correspondence between the client identifier and the payment page or the abnormal page.
  • the feedback module 404 determines the client identifier in the second service request, and feeds the generated payment page or the abnormal page corresponding to the client identifier to the client.
  • the application further provides a service processing device.
  • the device may be disposed in the first server, including:
  • the receiving module 501 receives a first service request sent by the client.
  • the generating module 502 is configured to generate, according to the first service request, a first service result corresponding to the first server self category;
  • the sending module 503 is configured to send the first service result to the client and the second server, so that the second server determines a category corresponding to the first service result, according to the first service result and category
  • the second service result is generated, and after the second server receives the second service request generated by the client according to the first service result, the generated second service result is sent to the client.
  • HDL Hardware Description Language
  • the controller can be implemented in any suitable manner, for example, the controller can take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code (eg, software or firmware) executable by the (micro)processor.
  • computer readable program code eg, software or firmware
  • examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, The Microchip PIC18F26K20 and the Silicone Labs C8051F320, the memory controller can also be implemented as part of the memory's control logic.
  • the controller can be logically programmed by means of logic gates, switches, ASICs, programmable logic controllers, and embedding.
  • Such a controller can therefore be considered a hardware component, and the means for implementing various functions included therein can also be considered as a structure within the hardware component.
  • a device for implementing various functions can be considered as a software module that can be both a method of implementation and a structure within a hardware component.
  • the system, device, module or unit illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product having a certain function.
  • a typical implementation device is a computer.
  • the computer can be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or A combination of any of these devices.
  • embodiments of the present invention can be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or a combination of software and hardware. Moreover, the invention can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) including computer usable program code.
  • computer-usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.
  • the computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture comprising the instruction device.
  • the apparatus implements the functions specified in one or more blocks of a flow or a flow and/or block diagram of the flowchart.
  • These computer program instructions can also be loaded onto a computer or other programmable data processing device such that a series of operational steps are performed on a computer or other programmable device to produce computer-implemented processing for execution on a computer or other programmable device.
  • the instructions provide steps for implementing the functions specified in one or more of the flow or in a block or blocks of a flow diagram.
  • a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
  • processors CPUs
  • input/output interfaces network interfaces
  • memory volatile and non-volatile memory
  • the memory may include non-persistent memory, random access memory (RAM), and/or non-volatile memory in a computer readable medium, such as read only memory (ROM) or flash memory.
  • RAM random access memory
  • ROM read only memory
  • Memory is an example of a computer readable medium.
  • Computer readable media includes both permanent and non-persistent, removable and non-removable media.
  • Information storage can be implemented by any method or technology.
  • the information can be computer readable instructions, data structures, modules of programs, or other data.
  • Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory. (ROM), electrically erasable programmable read only memory (EEPROM), flash memory or other memory technology, compact disk read only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, Magnetic tape cartridges, magnetic tape storage or other magnetic storage devices or any other non-transportable media can be used to store information that can be accessed by a computing device.
  • computer readable media does not include temporary storage of computer readable media, such as modulated data signals and carrier waves.
  • embodiments of the present application can be provided as a method, system, or computer program product.
  • the present application can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment in combination of software and hardware.
  • the application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) including computer usable program code.
  • the application can be described in the general context of computer-executable instructions executed by a computer, such as a program module.
  • program modules include routines, programs, objects, components, data structures, and the like that perform particular transactions or implement particular abstract data types.
  • the present application can also be practiced in distributed computing environments where transactions are performed by remote processing devices that are connected through a communication network.
  • program modules can be located in both local and remote computer storage media including storage devices.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Signal Processing (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Telephonic Communication Services (AREA)

Abstract

本申请实施例公开了一种业务处理方法及装置，该方法包括：第二服务器接收第一服务器发送的第一业务结果，其中，所述第一业务结果是所述第一服务器针对客户端发送的第一业务请求进行处理后生成的，确定所述第一业务结果对应的类别，根据所述类别以及所述第一业务结果，生成与该类别相匹配的第二业务结果，当所述第二服务器接收到所述客户端发送的第二业务请求后，将已生成的第二业务结果反馈给所述客户端。通过本方法，第二服务器在接收到客户端的第二业务请求之前，就可以根据第一业务结果，生成相应的第二业务结果，一旦接收到第二业务请求，便立即返回第二业务结果，从而有效节省了客户端的等待时长，也提升了处理业务请求的时效性。

Description

一种业务处理方法及装置 技术领域
本申请涉及计算机技术领域，尤其涉及一种业务处理方法及装置。
背景技术
在线系统(如：网站)在其后台的业务系统的支持下，可向用户提供丰富的业务服务。其中的某些业务可能需要不同的业务系统共同完成。
现有技术中，由用户通过诸如浏览器、应用(Application，APP)等客户端所发起的业务请求，那么，对上述的业务请求的处理过程具体可为：按照业务流程的顺序，先对该业务请求进行处理的业务系统会生成相应的处理结果(可称为中间结果)，返回给客户端，客户端根据中间结果，重定向至业务流程中的下一业务系统，并发起请求(可称为中间请求)，使得下一业务系统进行后续处理，以此类推，直到完成整个业务流程为止。
例如：假设客户端所发出的某业务请求需要业务系统A和B共同完成。按照业务流程，该业务请求首先由业务系统A进行处理，生成中间结果a，此时，业务系统A会将中间结果a返回给客户端，该客户端基于中间结果a重定向至业务系统B，并进一步向业务系统B发出请求，从而，业务系统B会对该请求处理，生成业务结果b，并返回给客户端。
但是，在现有技术的方式中，各业务系统与客户端之间通过互联网进行交互，而互联网的网络环境的稳定性较差，可能由于网络环境的影响，产生网络延时，导致客户端根据中间业务结果向下一业务系统发送中间请求的过程需要耗费较长的时间；此外，上述的方式中，业务系统只会在接收到了客户端的请求后，才进行相应的处理，而在线系统通常会面对大量的用户访问，造成各业务系统的工作负荷较高，导致请求在业务系统的处理队列中产生等待延时。显然，在请求的传输阶段和处理阶段都可能存在一定的延时，这必然会造成客户 端的等待时间较长，使得业务处理过程的时效性较差。
发明内容
本申请实施例提供一种业务处理方法及装置，用以解决现有的业务处理过程的时效性较差的问题。
本申请实施例提供的一种业务处理方法，包括：
第二服务器接收第一服务器发送的第一业务结果，其中，所述第一业务结果是所述第一服务器针对客户端发送的第一业务请求进行处理后生成的；
确定所述第一业务结果对应的类别；
根据所述类别以及所述第一业务结果，生成与该类别相匹配的第二业务结果；
当所述第二服务器接收到所述客户端发送的第二业务请求后，将已生成的第二业务结果反馈给所述客户端。
本申请实施例还提供的一种业务处理方法，包括：
第一服务器接收客户端发送的第一业务请求；
根据所述第一业务请求，生成对应于该第一服务器自身类别的第一业务结果；
将所述第一业务结果发送给所述第二服务器，以使得所述第二服务器确定所述第一业务结果对应的类别，根据第一业务结果及类别，生成与该类别相匹配的第二业务结果，并当该第二服务器接收到客户端根据所述第一业务结果生成的第二业务请求后，将已生成的所述第二业务结果发送给客户端。
本申请实施例提供的一种业务处理装置，包括：
接收模块，接收第一服务器发送的第一业务结果，其中，所述第一业务结果是所述第一服务器针对客户端发送的第一业务请求进行处理后生成的；
类别确定模块，确定所述第一业务结果对应的类别；
生成模块，根据所述类别以及所述第一业务结果，生成与该类别相匹配的 第二业务结果；
反馈模块，当所述第二服务器接收到所述客户端发送的第二业务请求后，将已生成的第二业务结果反馈给所述客户端。
本申请实施例另提供的一种业务处理装置，包括：
接收模块，接收客户端发送的第一业务请求；
生成模块，根据所述第一业务请求，生成对应于该第一服务器自身类别的第一业务结果；
发送模块，将所述第一业务结果发送给所述客户端、以及第二服务器，以使得所述第二服务器确定所述第一业务结果对应的类别，根据所述第一业务结果及类别，生成第二业务结果，并当该第二服务器接收到客户端根据所述第一业务结果生成的第二业务请求后，将已生成的所述第二业务结果发送给客户端。
本申请实施例提供一种业务处理方法及装置，通过该方法，第一服务器接收到了客户端所发出的第一业务请求后，将对该第一业务请求进行处理，并生成相应的第一业务结果，此时，第一服务器除了将第一业务结果返回给客户端之外，还会按照业务流程，将该第一业务结果发送给第二服务器，第二服务器会确定第一业务结果对应的类别，这样一来，第二服务器便可以该第一业务结果进行处理，提前生成与该类别相匹配的第二业务结果。正是采用了这样的方式，使得第二服务器在接收到来自客户端所发送的第二业务请求之前，便可以生成第二业务结果，当第二服务器接收到了客户端实际发送的第二请求后，便可以将已经生成的第二业务结果直接返回给客户端，而且，所生成的第二业务结果符合第一业务结果的业务类型。显然，相较于现有技术中的方式而言，第二服务器在接收到客户端的第二业务请求之前，就可以根据第一业务结果预先生成第二业务结果，从而有效节省了客户端的等待时长，也提升了处理业务请求的时效性。
附图说明
此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1a为本申请实施例提供的业务处理过程所基于的架构示意图；
图1b为本申请实施例提供的基于第二服务器侧的业务处理过程；
图2为本申请实施例提供的基于第一服务器侧的业务处理过程；
图3为本申请实施例提供的应用实例中的业务处理过程的示意图；
图4为本申请实施例提供的基于第二服务器侧的业务处理装置结构示意图；
图5为本申请实施例提供的基于第一服务器侧的业务处理装置结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
正如前述，用户通过客户端从在线系统中获取需要由多个业务系统共同完成的业务服务时，客户端端通常需要接收不同业务系统所返回的中间业务结果，并基于中间业务结果进行重定向后，向下一业务系统发出请求，直到完成完整的业务流程为止，但在该过程中，客户端在向业务系统发送请求时，容易受到网络环境的影响，产生传输延时，且业务系统只能够在接收到客户端所发出的业务请求后，才会进行处理，在业务系统工作负荷较高的情况下，业务系统处理该业务请求时也会产生一定的处理延时，这样一来，对于客户端而言，将受到传输延时和处理延时的双重影响，使得客户端的等待耗时较长，显然，这会对业务请求的时效性造成严重影响。
基于此，就需要一种能够减少客户端等待时间的业务处理方式，也即，在 本申请实施例中，供一种业务处理方法。
需要说明的是，在本申请实施例中，由于用户通过客户端，从在线系统内所获取的业务服务往往需要多个业务系统共同完成，故客户端会按照业务流程，针对不同的业务系统会发起不同的业务请求，但可以认为，客户端所发起的不同的业务请求，是为了完成同一业务。
本申请实施例中所述的业务处理方法，基于如图1a所示的架构，在图1中可见，该架构中包含用户所使用的业务客户端(以下简称为：客户端)、第一服务器以及第二服务器，其中，所述的客户端，可以是运行在终端中的浏览器、APP应用等，第一服务器和第二服务器具有不同的业务功能，第一服务器和第二服务器具体可以是在业务流程中相邻的两个业务服务器，所述的第二服务器，可以是在业务流程中处理顺序位于第一服务器之后的业务服务器，例如：假设现有3个业务服务器A、B、C，某种业务服务需要按照业务服务器A至B再至C的顺序完成，那么，针对业务服务器A、B而言，第一服务器就可以是业务服务器A，第二服务器就可以是业务服务器B；针对业务服务器B、C而言，第一服务器就可以是业务服务器B，第二服务器就可以是业务服务器C。换言之，本申请中的第一服务器和第二服务器并非只限于2个服务器的场景。
下面将结合如图1a所示的架构，对本申请中的业务处理方法进行说明，具体而言，如图1b所示的业务处理过程包括如下步骤：
步骤S101：第二服务器接收第一服务器发送的第一业务结果。
其中，所述第一业务结果是所述第一服务器针对客户端发送的第一业务请求进行处理后生成的。
在实际应用场景下，当用户使用客户端获取业务服务时，通常需要向相应的业务服务器发出业务请求，例如：用户针对某商品下单后，此时，客户端就会向下单服务器发送下单请求，在该示例中，下单服务器就是第一服务器，下单请求就是第一业务请求。
其中，第一业务请求，可以是由第一服务器所接收到的业务请求，该第一 业务请求既可以由客户端根据用户的操作指令所发出的业务请求，也可以是客户端接收到了业务流程中的前一业务服务器所反馈的中间业务结果后所发出的业务请求。当然，这里并不构成对本申请的限定。
第一业务结果，可认为是第一服务器对第一业务请求进行了相应处理后所生成的中间结果。
考虑到实际应用中，客户端向第二服务器发送第二业务请求的过程可能会受到网络环境的影响而产生延时，第二服务器在接收到第二业务请求并进行处理时，也可能会产生处理延时，显然，这两种情况均会造成客户端的等待时间较长，因此，为了减少客户端的等待时长，在本申请实施例中，第一服务器除了将第一业务结果发送给客户端之外，还会直接向第二服务器发送该第一业务结果，那么，第二服务器便可根据第一业务结果提前进行处理。
S102：确定所述第一业务结果对应的类别。
本申请实施例中，第一业务结果所对应的类别，可认为是第一服务器所对应的类别，应理解，在实际应用中，对于不同业务提供方的第一服务器而言，其类别(如：所提供的业务类别、业务提供方自身的类别)通常存在差异，相应地，对第二业务结果的类别也会存在不同的要求。
例如：电信运营商(此时，第一服务器就是电信运营商服务器)和银行(此时，第一服务器就是银行服务器)分别是不同的业务提供方，显然，电信运营商服务器所生成的第一业务结果通常与电信业务相关，而银行服务器所生成的第一业务结果通常与金融业务相关，可以理解，以上两个业务提供方对后续生成的第二业务结果的类别应该也存在差异。
因此，在本申请实施例中，将确定出第一业务结果所对应的类别，以便于执行后续操作。
S103：根据所述类别以及所述第一业务结果，生成与该类别相匹配的第二业务结果。
当第二服务器接收到了第一业务结果后，便可以提前进行处理，生成与该 类别相匹配的第二业务结果。
S104：当所述第二服务器接收到所述客户端发送的第二业务请求后，将已生成的第二业务结果反馈给所述客户端。
第二服务器接收到了第二业务请求后，便可以将提前生成的第二结果直接反馈给客户端，从而减少或避免了客户端的等待耗时。
通过上述步骤，第一服务器接收到了客户端所发出的第一业务请求后，将对该第一业务请求进行处理，并生成相应的第一业务结果，此时，第一服务器除了将第一业务结果返回给客户端之外，还会按照业务流程，将该第一业务结果发送给第二服务器，第二服务器会确定第一业务结果对应的类别，这样一来，第二服务器便可以该第一业务结果进行处理，提前生成与该类别相匹配的第二业务结果。正是采用了这样的方式，使得第二服务器在接收到来自客户端所发送的第二业务请求之前，便可以生成第二业务结果，当第二服务器接收到了客户端实际发送的第二请求后，便可以将已经生成的第二业务结果直接返回给客户端，而且，所生成的第二业务结果符合第一业务结果的业务类型。显然，相较于现有技术中的方式而言，第二服务器在接收到客户端的第二业务请求之前，就可以根据第一业务结果预先生成第二业务结果，从而有效节省了客户端的等待时长，也提升了处理业务请求的时效性。
为了清楚的阐述本申请的上述业务处理方法，现以实际的支付业务场景进行详细说明：
假设某用户使用某商品网站的客户端，在该商品网站中购买某商品。可以认为，用户通过客户端针对某商品的购买操作涉及下单和支付两种业务，而支付业务提供方(如：支付平台)可在该过程中，提供支付服务(即，下单业务由该商品网站后台的下单服务器完成，而支付业务由支付平台后台的支付服务器完成)。那么，在该场景中，第一业务请求为下单请求，第一服务器包括下单服务器，第一业务结果包括订单信息，第二服务器包括支付服务器，第二业务结果包括支付界面或异常页面。
在此场景下，上述步骤S101中，第二服务器接收第一服务器发送的第一业务结果，具体包括：支付服务器接收下单服务器发送的订单数据。其中，所述的订单数据中可包含诸如订单流水号、第一服务器的类别标识、支付状态数据、账户信息、商品信息、金额信息等。这里并不作具体限定。
上述步骤S102中，确定所述第一业务结果对应的类别，具体包括：确定所述订单数据中包含的下单服务器的类别标识。
这里，所述的类别标识，实际上反映了第一服务器的类别标识，在本申请实施例中，所述的类别标识可以包括：第一服务器所属的业务提供方的名称、行业类别信息、第一服务器自身的名称、设备号等等，这里并不构成对本申请的限定。
根据所述类别以及所述第一业务结果，生成与该类别相匹配的第二业务结果，具体包括：根据预先建立的类别标识与页面模板的对应关系，确定所述订单数据所对应的页面模板，根据确定出的所述页面模板，在所述订单数据中标记匹配于该页面模板的订单数据，根据标记的订单数据渲染并构建支付页面。
需要说明的是，在实际的支付场景下，针对不同的第一服务器，即下单服务器(如：商品网站服务器、电信运营商服务器等)，所生成的支付页面通常也是不同的，故支付服务器中通常会存储有不同的支付页面模板，以对应于不同的下单服务器，而下单服务器发送的订单数据中，也会包含有下单服务器的类别标识，从而可确定相应的支付页面模板。
针对不同的支付页面模板，其所需渲染的订单数据也可能不同，例如：针对某商品网站的支付页面来说，该支付页面上需要展示用户的订单号、支付金额、邮寄地址等数据，而针对手机卡充值的支付页面来说，该支付页面上需要展示单号、待充值手机号、金额等数据。显然，对于这两类支付页面，所需渲染的订单数据并不相同。
此外，在实际支付场景下，支付页面可能存在两种情况：一种情况是成功渲染支付页面，另一种情况是支付过程出现问题而显示异常页面。所以，支付 服务器在进行渲染页面的操作之前，还会判断是否能够成功的支付，也即，根据标记的订单数据渲染并构建支付页面，具体包括：根据所述订单数据判断支付状态，当判断出所述支付状态为可进行支付时，则根据标记的订单数据渲染并构建支付页面。
这里需要说明的是，作为本申请实施例中的一种方式，支付服务器根据订单数据判断支付状态的过程，可以基于用户预先注册的账户实现，该方式下分为两种情况：
一、如果下单服务器和支付服务器均属于同一业务提供方，那么，用户在该业务提供方处所注册的账户通用于下单服务器和支付服务器，换言之，支付服务器有权限查询用户的账户余额，从而判断本次支付是否能够成功。
二、下单服务器和支付服务器分别属于不同的业务提供方，那么，可以理解，用户在两个业务提供方处所注册的账户应是相互关联的，这样，支付服务器仍然有权限查询用户在下单服务器中注册的账户的余额，并基于此判断支付是否能成功。
当然，上述的两种情况并不构成对本申请的限定。
而如果当确定所述通知消息所表征的支付状态为不可进行支付时，则所述方法还包括：删除对所述订单数据的标记，渲染并构建异常页面。
作为本申请实施例中的一种可能方式，在生成了相应的页面(包括前述的支付页面或异常页面)后，还可针对成功进行渲染的数据进行标记，用以后续对系统进行优化，这里并不进行详细赘述。
当然，本申请实施例中的所述订单数据中，还携带有客户端标识，基于此，所述方法还包括：建立所述客户端标识与所述支付页面或异常页面之间的对应关系。这样一来，将已生成的第二业务结果反馈给所述客户端，具体包括：确定所述第二业务请求中的客户端标识，将已生成的且与该客户端标识对应的支付页面或异常页面反馈给所述客户端。
通过上述内容，当支付服务器接收到客户端发送的支付请求后，便可以将 提前渲染并构建的支付页面或异常页面反馈给所述客户端。
可见，采用上述的方式，可以节省客户端完成支付流程所消耗的时间。
以上是针对第二服务器侧的描述，在本申请实施例中，基于第一服务器侧，还提供一种业务处理方法，如图2所示，具体包括以下步骤：
步骤S201：第一服务器接收客户端发送的第一业务请求。
步骤S202，根据所述第一业务请求，生成对应于该第一服务器自身类别的第一业务结果。
当第一服务器接收到了第一业务请求后，便会针对该第一业务请求进行处理，从而生成相应的业务结果，即第一业务结果，这里的第一业务结果通常是一种中间业务结果。
当然，在本申请实施例中的一种方式下，第一业务请求中往往会携带客户端的标识信息，那么，第一服务器所生成的第一业务结果中也会包含客户端的标识信息。
步骤S203，将所述第一业务结果发送给所述第二服务器，以使得所述第二服务器确定所述第一业务结果对应的类别，根据第一业务结果及类别，生成与该类别相匹配的第二业务结果，并当该第二服务器接收到客户端根据所述第一业务结果生成的第二业务请求后，将已生成的所述第二业务结果发送给客户端。
实际应用中，如图3所示，示出了上述场景下的业务流程：
步骤S301：用户向客户端发出下单操作指令。
步骤S302：客户端根据下单操作指令，向下单服务器发送下单请求。
步骤S303：下单服务器针对接收到的下单请求进行处理，生成订单信息。
步骤S304：下单服务器将订单信息发送给支付服务器。以使得支付服务器执行步骤S306。
步骤S305：下单服务器将订单信息发送给客户端。以使得客户端执行步骤 S307。
步骤S306：支付服务器根据订单信息，确定相应的支付页面模板，并进一步生成支付页面。
步骤S307：客户端根据订单信息，重定向至支付服务器，并向支付服务器发出支付页面请求。
步骤S308：支付服务器向客户端返回支付页面。
从上述内容及示例中可见，在实际支付场景中，一旦订单服务器生成了订单信息后，将立即发送给支付服务器进行处理，以生成相应的支付页面，那么，当客户端向支付服务器发出支付页面请求后，支付服务器可以立即向客户端返回已经生成的支付页面。显然，这样的方式将有效减少客户端等待生成支付页面的时间，进一步也使得用户可更快捷地浏览到支付页面，以便在支付页面中完成支付业务。
以上为本申请提供的业务处理方法的几种实施例，基于同样的思路，本申请还提供了业务处理装置的实施例，如图4所示。图4中的业务处理装置，所述装置可以设置于第二服务器中，该装置包括：
接收模块401，接收第一服务器发送的第一业务结果，其中，所述第一业务结果是所述第一服务器针对客户端发送的第一业务请求进行处理后生成的；
类别确定模块402，确定所述第一业务结果对应的类别；
生成模块4033，根据所述类别以及所述第一业务结果，生成与该类别相匹配的第二业务结果；
反馈模块404，当所述第二服务器接收到所述客户端发送的第二业务请求后，将已生成的第二业务结果反馈给所述客户端。
在本申请实施例中的一种场景下，所述第一业务请求为下单请求；所述第一服务器包括下单服务器；所述第一业务结果包括订单数据；所述第二服务器包括支付服务器；所述第二业务结果包括支付界面或异常页面。
基于此，所述订单数据中包含下单服务器的类别标识；所述类别确定模块402，确定所述订单数据中包含的下单服务器的类别标识；所述生成模块403，根据预先建立的类别标识与页面模板的对应关系，确定所述订单数据所对应的页面模板，根据确定出的所述界面模板，在所述订单数据中标记匹配于该页面模板的订单数据，根据标记的订单数据渲染并构建支付页面。
所述生成模块403，根据所述订单数据判断支付状态，当判断出所述支付状态为可进行支付时，则根据标记的订单数据渲染并构建支付页面。。
当所述生成模块403判断出所述支付状态为不可进行支付时，删除对所述订单数据的标记，渲染并构建异常页面。。
所述订单数据中携带有客户端标识，所述装置还包括：关系建立模块405，建立所述客户端标识与所述支付页面或异常页面之间的对应关系。所述反馈模块404，确定所述第二业务请求中的客户端标识，将已生成的且与该客户端标识对应的支付页面或异常页面反馈给所述客户端。
在第一服务器侧，本申请还提供一种业务处理装置，如图5所示，该装置可以设置在第一服务器中，包括：
接收模块501，接收客户端发送的第一业务请求；
生成模块502，根据所述第一业务请求，生成对应于该第一服务器自身类别的第一业务结果；
发送模块503，将所述第一业务结果发送给所述客户端、以及第二服务器，以使得所述第二服务器确定所述第一业务结果对应的类别，根据所述第一业务结果及类别，生成第二业务结果，并当该第二服务器接收到客户端根据所述第一业务结果生成的第二业务请求后，将已生成的所述第二业务结果发送给客户端。
在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改 进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable Gate Array，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware Description Language)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(Ruby Hardware Description Language)等，目前最普遍使用的是VHDL(Very-High-Speed Integrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。
控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip  PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一 个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括 那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定事务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行事务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (14)

  1. 一种业务处理方法，其特征在于，包括：
    第二服务器接收第一服务器发送的第一业务结果，其中，所述第一业务结果是所述第一服务器针对客户端发送的第一业务请求进行处理后生成的；
    确定所述第一业务结果对应的类别；
    根据所述类别以及所述第一业务结果，生成与该类别相匹配的第二业务结果；
    当所述第二服务器接收到所述客户端发送的第二业务请求后，将已生成的第二业务结果反馈给所述客户端。
  2. 如权利要求1所述的方法，其特征在于，所述第一业务请求为下单请求；所述第一服务器包括下单服务器；所述第一业务结果包括订单数据；所述第二服务器包括支付服务器；所述第二业务结果包括支付页面或异常页面。
  3. 如权利要求2所述的方法，其特征在于，所述订单数据中包含下单服务器的类别标识；
    确定所述第一业务结果对应的类别，具体包括：
    确定所述订单数据中包含的下单服务器的类别标识；
    根据所述类别以及所述第一业务结果，生成与该类别相匹配的第二业务结果，具体包括：
    根据预先建立的类别标识与页面模板的对应关系，确定所述订单数据所对应的页面模板；
    根据确定出的所述页面模板，在所述订单数据中标记匹配于该页面模板的订单数据；
    根据标记的订单数据渲染并构建支付页面。
  4. 如权利要求3所述的方法，其特征在于，根据标记的订单数据渲染并构建支付页面，具体包括：
    根据所述订单数据判断支付状态；
    当判断出所述支付状态为可进行支付时，则根据标记的订单数据渲染并构建支付页面。
  5. 如权利要求4所述的方法，其特征在于，当判断出所述支付状态为不可进行支付时，则所述方法还包括：
    删除对所述订单数据的标记；
    渲染并构建异常页面。
  6. 如权利要求4或5所述的方法，其特征在于，所述订单数据中携带有客户端标识；
    所述方法还包括：
    建立所述客户端标识与所述支付页面或异常页面之间的对应关系；
    将已生成的第二业务结果反馈给所述客户端，具体包括：
    确定所述第二业务请求中的客户端标识；
    将已生成的且与该客户端标识对应的支付页面或异常页面反馈给所述客户端。
  7. 一种业务处理方法，其特征在于，包括：
    第一服务器接收客户端发送的第一业务请求；
    根据所述第一业务请求，生成对应于该第一服务器自身类别的第一业务结果；
    将所述第一业务结果发送给所述第二服务器，以使得所述第二服务器确定所述第一业务结果对应的类别，根据第一业务结果及类别，生成与该类别相匹配的第二业务结果，并当该第二服务器接收到客户端根据所述第一业务结果生成的第二业务请求后，将已生成的所述第二业务结果发送给客户端。
  8. 一种业务处理装置，其特征在于，包括：
    接收模块，接收第一服务器发送的第一业务结果，其中，所述第一业务结果是所述第一服务器针对客户端发送的第一业务请求进行处理后生成的；
    类别确定模块，确定所述第一业务结果对应的类别；
    生成模块，根据所述类别以及所述第一业务结果，生成与该类别相匹配的第二业务结果；
    反馈模块，当所述第二服务器接收到所述客户端发送的第二业务请求后，将已生成的第二业务结果反馈给所述客户端。
  9. 如权利要求8所述的装置，其特征在于，所述第一业务请求为下单请求；所述第一服务器包括下单服务器；所述第一业务结果包括订单数据；所述第二服务器包括支付服务器；所述第二业务结果包括支付界面或异常页面。
  10. 如权利要求9所述的装置，其特征在于，所述订单数据中包含下单服务器的类别标识；所述类别确定模块，确定所述订单数据中包含的下单服务器的类别标识；
    所述生成模块，根据预先建立的类别标识与页面模板的对应关系，确定所述订单数据所对应的页面模板，根据确定出的所述页面模板，在所述订单数据中标记匹配于该页面模板的订单数据，根据标记的订单数据渲染并构建支付页面。
  11. 如权利要求10所述的装置，其特征在于，所述生成模块，根据所述订单数据判断支付状态，当判断出所述支付状态为可进行支付时，则根据标记的订单数据渲染并构建支付页面。
  12. 如权利要求11所述的装置，其特征在于，当所述生成模块判断出所述支付状态为不可进行支付时，删除对所述订单数据的标记，渲染并构建异常页面。
  13. 如权利要求11或12所述的装置，其特征在于，所述订单数据中携带有客户端标识；
    所述装置还包括：关系建立模块，建立所述客户端标识与所述支付页面或异常页面之间的对应关系；
    所述反馈模块，确定所述第二业务请求中的客户端标识，将已生成的且与该客户端标识对应的支付页面或异常页面反馈给所述客户端。
  14. 一种业务处理装置，其特征在于，包括：
    接收模块，接收客户端发送的第一业务请求；
    生成模块，根据所述第一业务请求，生成对应于该第一服务器自身类别的第一业务结果；
    发送模块，将所述第一业务结果发送给所述客户端、以及第二服务器，以使得所述第二服务器确定所述第一业务结果对应的类别，根据所述第一业务结果及类别，生成第二业务结果，并当该第二服务器接收到客户端根据所述第一业务结果生成的第二业务请求后，将已生成的所述第二业务结果发送给客户端。
PCT/CN2017/116509 2016-12-21 2017-12-15 一种业务处理方法及装置 WO2018113601A1 (zh)

Priority Applications (6)

Application Number Priority Date Filing Date Title
JP2019534167A JP7036826B2 (ja) 2016-12-21 2017-12-15 サービス処理方法および装置
KR1020197017251A KR102246394B1 (ko) 2016-12-21 2017-12-15 서비스 처리 방법 및 장치
EP17882785.3A EP3534585A4 (en) 2016-12-21 2017-12-15 SERVICE PROCESSING METHOD AND APPARATUS
MYPI2019002979A MY186646A (en) 2016-12-21 2017-12-15 Service processing method and apparatus
US16/421,188 US11132666B2 (en) 2016-12-21 2019-05-23 Service processing method and apparatus
PH12019501204A PH12019501204A1 (en) 2016-12-21 2019-05-30 Service processing method and apparatus

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201611195605.6A CN107070858B (zh) 2016-12-21 2016-12-21 一种业务处理方法及装置
CN201611195605.6 2016-12-21

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/421,188 Continuation US11132666B2 (en) 2016-12-21 2019-05-23 Service processing method and apparatus

Publications (1)

Publication Number Publication Date
WO2018113601A1 true WO2018113601A1 (zh) 2018-06-28

Family

ID=59619421

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/116509 WO2018113601A1 (zh) 2016-12-21 2017-12-15 一种业务处理方法及装置

Country Status (9)

Country Link
US (1) US11132666B2 (zh)
EP (1) EP3534585A4 (zh)
JP (1) JP7036826B2 (zh)
KR (1) KR102246394B1 (zh)
CN (1) CN107070858B (zh)
MY (1) MY186646A (zh)
PH (1) PH12019501204A1 (zh)
TW (1) TWI737818B (zh)
WO (1) WO2018113601A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112561650A (zh) * 2020-12-17 2021-03-26 深圳希施玛数据科技有限公司 一种订单服务请求的处理系统

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107070858B (zh) * 2016-12-21 2021-09-21 创新先进技术有限公司 一种业务处理方法及装置
CN109450702B (zh) * 2018-12-10 2022-05-24 京信网络系统股份有限公司 一种数据处理方法及装置
CN111582902B (zh) * 2019-02-18 2023-07-21 阿里巴巴（北京）软件服务有限公司 数据处理方法、业务处理方法及装置
CN110263816B (zh) * 2019-05-28 2024-01-19 创新先进技术有限公司 一种企业的分类方法以及装置
CN110413421B (zh) * 2019-06-28 2024-01-30 创新先进技术有限公司 业务数据处理方法和装置、交易数据处理方法和装置
CN112311838B (zh) * 2019-08-02 2022-07-05 腾讯科技（深圳）有限公司 业务异步交互方法及装置
CN111192113A (zh) * 2019-12-30 2020-05-22 广州酷狗计算机科技有限公司 订单处理方法、装置、设备及存储介质
CN111240866B (zh) * 2020-01-14 2023-06-30 华瑞新智科技（北京）有限公司 一种业务数据处理方法及装置
CN111880931A (zh) * 2020-07-22 2020-11-03 北京三快在线科技有限公司 业务执行系统、应用于业务执行系统的业务执行方法
CN111930535B (zh) * 2020-07-31 2023-08-29 中国工商银行股份有限公司 一种应用功能调用方法、装置、计算机设备及存储介质
CN112181928B (zh) * 2020-09-03 2024-02-23 北京三快在线科技有限公司 一种业务执行的方法、装置及系统
CN114095574B (zh) * 2022-01-20 2022-04-29 恒生电子股份有限公司 数据处理方法、装置、电子设备及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102546165A (zh) * 2010-12-31 2012-07-04 中国银联股份有限公司 动态url生成器、生成方法、基于动态url的认证系统和方法
CN103164790A (zh) * 2011-12-09 2013-06-19 腾讯科技（深圳）有限公司 网络支付系统及其数据处理方法
US9390412B2 (en) * 2012-10-16 2016-07-12 Visa International Service Association Dynamic point of sale system integrated with reader device
CN107070858A (zh) * 2016-12-21 2017-08-18 阿里巴巴集团控股有限公司 一种业务处理方法及装置
CN107295052A (zh) * 2016-04-11 2017-10-24 阿里巴巴集团控股有限公司 一种业务处理方法及装置

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001344550A (ja) * 2000-06-02 2001-12-14 Nec Informatec Systems Ltd 電子決済方法及びシステム並びに電子決済用プログラムを記憶した記憶媒体
KR100376246B1 (ko) * 2000-06-23 2003-03-15 삼성물산 주식회사 물류 관리 시스템 및 그 관리방법
GB2400961B (en) 2001-05-02 2004-12-29 Virtual Access Ltd Secure payment method and system
ATE371240T1 (de) 2001-05-02 2007-09-15 Virtual Access Ltd Gesichertes zahlungsverfahren und -system
US20060271497A1 (en) * 2005-05-24 2006-11-30 Cullen Andrew J Payment authorisation process
CA2578466A1 (en) 2007-01-12 2008-07-12 Truecontext Corporation Method and system for customizing a mobile application using a web-based interface
US20080208762A1 (en) 2007-02-22 2008-08-28 First Data Corporation Payments using a mobile commerce device
US9053474B2 (en) 2008-08-04 2015-06-09 At&T Mobility Ii Llc Systems and methods for handling point-of-sale transactions using a mobile device
US20110209049A1 (en) 2010-02-23 2011-08-25 Microsoft Corporation Data binding for a web-based visual representation of a structured data solution
JP2011210171A (ja) * 2010-03-30 2011-10-20 Japan Research Institute Ltd 決済サーバ、決済システム、決済方法および決済プログラム
CN102761580B (zh) * 2011-04-29 2015-06-17 阿里巴巴集团控股有限公司 信息安全处理的方法、处理服务器及处理客户端
KR101086620B1 (ko) 2011-08-23 2011-11-23 정대영 스마트 오피스 시스템 및 운용을 위한 서버 및 운용 방법
EP2786328A4 (en) 2011-11-30 2015-06-03 Spectrum Message Services Pty Ltd SYSTEM, PAYMENT AGENT, AND COMPUTER READABLE STORAGE MEDIUM FACILITATING MOBILE CONTACTLESS PAYMENT TRANSACTIONS
CN103366303A (zh) * 2012-03-28 2013-10-23 黄金富 手机购物方法和相应的手机购物电子商务系统
CN103729768B (zh) * 2012-10-15 2018-10-19 北京京东尚科信息技术有限公司 一种电子交易信息处理方法和装置
WO2014062623A1 (en) 2012-10-15 2014-04-24 Powered Card Solutions, Llc System and method for secure remote access and remote payment using a mobile device and a powered display card
CN103226769A (zh) * 2013-04-12 2013-07-31 深圳市发掘科技有限公司 基于移动设备的餐饮管理系统及方法
WO2015003050A1 (en) 2013-07-02 2015-01-08 Boku, Inc. Merchant hosted checkout
CN104599125A (zh) 2013-10-30 2015-05-06 中华电信股份有限公司 手机应用软件付款服务系统及其方法
CN105607910A (zh) * 2015-12-22 2016-05-25 北京奇虎科技有限公司 一种实现通用支付前端服务的方法和装置
EP3659084A4 (en) 2017-07-27 2021-05-05 Ingenico Inc. SECURE CARD DATA ENTRY SYSTEM AND METHOD
US20190102778A1 (en) 2017-09-29 2019-04-04 Enmax Encompass Inc. Secure online transaction system and method therefor
US20200183553A1 (en) 2018-12-10 2020-06-11 Square, Inc. Customized Web Page Development based on Point-of-Sale Information

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102546165A (zh) * 2010-12-31 2012-07-04 中国银联股份有限公司 动态url生成器、生成方法、基于动态url的认证系统和方法
CN103164790A (zh) * 2011-12-09 2013-06-19 腾讯科技（深圳）有限公司 网络支付系统及其数据处理方法
US9390412B2 (en) * 2012-10-16 2016-07-12 Visa International Service Association Dynamic point of sale system integrated with reader device
CN107295052A (zh) * 2016-04-11 2017-10-24 阿里巴巴集团控股有限公司 一种业务处理方法及装置
CN107070858A (zh) * 2016-12-21 2017-08-18 阿里巴巴集团控股有限公司 一种业务处理方法及装置

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112561650A (zh) * 2020-12-17 2021-03-26 深圳希施玛数据科技有限公司 一种订单服务请求的处理系统
CN112561650B (zh) * 2020-12-17 2024-02-02 深圳希施玛数据科技有限公司 一种订单服务请求的处理系统

Also Published As

Publication number Publication date
KR102246394B1 (ko) 2021-04-30
CN107070858A (zh) 2017-08-18
EP3534585A1 (en) 2019-09-04
US20190279190A1 (en) 2019-09-12
CN107070858B (zh) 2021-09-21
TWI737818B (zh) 2021-09-01
US11132666B2 (en) 2021-09-28
JP2020502693A (ja) 2020-01-23
TW201824012A (zh) 2018-07-01
JP7036826B2 (ja) 2022-03-15
PH12019501204A1 (en) 2019-12-16
EP3534585A4 (en) 2020-04-29
MY186646A (en) 2021-08-03
KR20190082920A (ko) 2019-07-10

Similar Documents

Publication Publication Date Title
WO2018113601A1 (zh) 一种业务处理方法及装置
US20210150506A1 (en) Peer-to-peer payment systems and methods
TWI718232B (zh) 業務執行方法及裝置
KR102384124B1 (ko) 가상 카드 개설 방법 및 시스템, 결제 시스템, 및 카드 발급 시스템
TW201837896A (zh) 語音的功能控制方法和裝置
US20150163186A1 (en) Launching a client application based on a message
WO2019105138A1 (zh) 一种多业务系统下的业务标记方法、装置及设备
TWI742324B (zh) 基於掃描ｄｏｉ的資訊處理方法、裝置及設備
TWI678115B (zh) 資源傳輸方法及裝置
WO2022267766A1 (zh) 访问聚合码支付页面的方法、装置、设备及介质
WO2020134654A1 (zh) 一种电子支付方法、装置、系统和存储介质
US11438401B2 (en) Service processing method and device
WO2016101811A1 (zh) 一种信息排序方法及装置
CN110992040A (zh) 交易处理方法、装置及设备
US20200211010A1 (en) Resource transfer verification method and apparatus, and electronic payment verification method and apparatus
TW201732587A (zh) 應用ａｐｐ的資源載入方法、業務功能實現方法及裝置
CN110865797A (zh) 处理业务动态属性的方法和装置
CN114675982A (zh) 一种业务集成系统的数据获取通用方法及系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17882785

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2017882785

Country of ref document: EP

Effective date: 20190528

Ref document number: 20197017251

Country of ref document: KR

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2019534167

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE