CN113112316A

CN113112316A - Exception handling method and device

Info

Publication number: CN113112316A
Application number: CN201911348550.1A
Authority: CN
Inventors: 李高峰
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Group Holding Ltd
Priority date: 2019-12-24
Filing date: 2019-12-24
Publication date: 2021-07-13

Abstract

The application discloses an exception handling method and device. The method comprises the following steps: obtaining abnormal configuration information corresponding to a current application from a service configuration center, wherein the current application comprises at least one service called during order completion, and the abnormal configuration information is used for indicating at least one abnormal processing rule set when the at least one service is abnormal during the order completion; configuring the current application by using the abnormal configuration information; and when the order is abnormal, calling the at least one abnormal processing rule to perform abnormal processing on the order. By adopting the method and the system, the service configuration center can be used for directly configuring the exception handling information of the service, the pressure of technical personnel on code maintenance is relieved, and customized exception handling service can be provided for different customers.

Description

Exception handling method and device

Technical Field

The present application relates to the field of computer technologies, and in particular, to an exception handling method and an exception handling apparatus.

Background

With the popularization of computers and the rapid development of internet technology, especially the proposal of micro-service architecture prompts the system architecture to develop from a single system architecture to a distributed system architecture, and with the rapid iteration of the system architecture, the call between services is changed from the call of the service inside the system to the call between the services of cross-host, cross-application cluster and the like, and the problem of excessive network overhead, unstable service and the like causes abnormal service call.

In the related art, in order to avoid the exception that may occur during the invocation of many services, code segments to the respective services may be located and different exception handling codes may be added at corresponding locations, but in this way, locating and adding exception handling codes to each service when the number of services is large, the number of codes to be developed and maintained is enormous for developers, and the cost of labor is enormous.

Disclosure of Invention

The embodiment of the application provides an exception handling method, an exception handling device and an electronic device, which at least solve the above-mentioned technical problems.

An embodiment of the present application further provides an exception handling method, where the method includes: obtaining abnormal configuration information corresponding to a current application from a service configuration center, wherein the current application comprises at least one service called during order completion, and the abnormal configuration information is used for indicating at least one abnormal processing rule set when the at least one service is abnormal during the order completion; configuring the current application by using the abnormal configuration information; and when the order is abnormal, calling the at least one abnormal processing rule to perform abnormal processing on the order.

An embodiment of the present application further provides an exception handling method, where the method includes: receiving abnormal configuration information sent by at least one node for a specific service when a slave service is called; determining specific abnormal configuration information of the specific service in the application in response to the application being started; sending the specific exception configuration information to the application.

An embodiment of the present application further provides an exception handling method, where the method includes: determining whether the slave service is abnormal according to the return information after the slave service is called; and if the processing is abnormal processing, determining abnormal configuration information matched with the main service from at least one abnormal configuration information corresponding to the main service calling the slave service.

An embodiment of the present application further provides an exception handling apparatus, where the apparatus includes: one or more processors; a memory; and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs including instructions for performing the above methods.

Embodiments of the present application also provide a computer readable storage medium storing one or more programs, the one or more programs comprising instructions, which when executed by a computing device, cause the computing device to perform the above method.

The embodiment of the application adopts at least one technical scheme which can achieve the following beneficial effects:

by adopting the method and the system, the service configuration center can be used for directly configuring the exception handling information of the service, the pressure of technical personnel on code maintenance is relieved, and customized exception handling service can be provided for different customers.

Drawings

The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the application and together with the description serve to explain the application and not to limit the application. In the drawings:

FIG. 1 is a scenario diagram illustrating a distributed service invocation according to an exemplary embodiment of the present application;

FIG. 2 is a flow chart illustrating an exception handling method according to an exemplary embodiment of the present application;

FIG. 3 is a flowchart illustrating a process when an exception occurs to a service call in accordance with an illustrative embodiment of the present application;

FIG. 4 is a scenario diagram illustrating exception handling according to an exemplary embodiment of the present application;

FIG. 5 is a scenario diagram illustrating exception handling according to an exemplary embodiment of the present application;

FIG. 6 is a display interface showing a setup service according to an exemplary embodiment of the present application;

FIG. 7 is a display interface showing setting exception configuration information for a service according to an exemplary embodiment of the present application;

FIG. 8 is a flowchart illustrating an exception handling method according to an exemplary embodiment of the present application;

FIG. 9 is a flowchart illustrating an exception handling method according to an exemplary embodiment of the present application;

fig. 10 is a block diagram showing an exception handling apparatus according to an exemplary embodiment of the present application;

FIG. 11 is a schematic diagram of an architecture of a computer system provided by an embodiment of the present application;

fig. 12 is a schematic diagram of an architecture of an electronic device provided in an embodiment of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the technical solutions of the present application will be described in detail and completely with reference to the following specific embodiments of the present application and the accompanying drawings. It should be apparent that the described embodiments are only some of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

In order to relieve the pressure of technicians on code maintenance and provide customized exception handling services for different clients, the exception handling method according to the exemplary embodiment of the application can directly perform exception handling information configuration on the services by using the service configuration center.

As shown in fig. 1, in an implementation, a client may need multiple service calls to each other in order to run a particular application, e.g., a shopping-type application. As shown in fig. 1, assume that an application includes three services, service a, service B, and service C, and when the application is executed, the call order among the three services is that service a calls service B and service B calls service C. Although not shown in the drawings, in actual implementation, each service may be provided by one service cluster. For example, taking service B as an example, the device providing the service B may be a plurality of nodes.

For example, assuming that the application used by the user is a shopping application, the functions of order generation, payment, in-warehouse picking and logistics distribution after the user selects goods may be services under the application. Referring to fig. 1, the order creation service corresponds to service a, the payment service corresponds to service B, the in-warehouse pickup service corresponds to service C, and the logistics distribution service corresponds to service D.

Assuming that a user purchases fresh goods on shopping application, the user sends a message of order generation after generating the order, the payment service receives payment from the user and sends a message of successful payment to the goods picking service in the warehouse, the goods picking service sends a message of goods taking out to the logistics distribution service after realizing goods taking in the warehouse, and then the logistics distribution service sends goods after receiving the message and sends a message of successful delivery of the goods. Therefore, shopping applications need to call different services to each other to realize the function.

In this process, as shown in fig. 1, when a client needs a certain service, the client may query and subscribe to the service configuration center, and still taking the service B as an example, the node where the service a is located may obtain a service information list from the service configuration center, select a service node from the service nodes by using a load balancing algorithm, and then send a request to the service node by using address information of the service node and obtain a processing result of the service node.

The service configuration center is capable of receiving service registration information sent by each service node, including information such as address information list and service routing rule of the service node which can execute subscription, and uniformly managing the information and providing a standard interface. When each service needs to acquire the configuration information, the configuration information can be directly pulled to the corresponding interface in the service configuration center. In addition, when various parameters in the service configuration center are updated, each service can be notified, so that each service can pull the update information in real time to update the update information dynamically.

As shown in fig. 1, when service a calls service B, the required service node needs to be called through the service configuration center. Still taking the shopping class application as an example, when a payment class service invokes an "pick in bin" service by sending a "pay successful" message to the "pick in bin" the "pay" service needs to determine the node of the "pick in bin" service and the path routed to that node through the service configuration center.

During the invocation, there may be a service exception, for example, a service timeout may occur, that is, a return result of the service B is not received within a predetermined time (for example, 1s), and at this time, this may be handled by executing the exception handling method according to the exemplary embodiment of the present application.

The exception handling method of the exemplary embodiment of the present application will be described in detail below with reference to fig. 2.

Fig. 2 is a flowchart illustrating an exception handling method according to an exemplary embodiment of the present application. The method is described from the perspective of the client. In an implementation, a user may launch an application on their client, e.g., a shopping class application, and as the application is launched, the following steps may be performed.

In step S210, obtaining, from a service configuration center, abnormal configuration information corresponding to a current application, where the current application includes at least one service invoked during the order completion period, and the abnormal configuration information is used to indicate at least one abnormal processing rule set when an abnormality occurs in the at least one service during the order completion period.

As described above, the current application is composed of a plurality of services, and for convenience of description, a service side (e.g., a specific service) calling a service is referred to as a master service, and a service side called a slave service. For example, service a calls service B, service a is the master service and service B is the slave service. It should be noted that the foregoing is illustrative only and is not intended to be in any limiting sense.

In particular, a user may launch applications in a client for various needs. In order to meet the requirements of users, the application needs a plurality of services to call each other to realize in the execution process, and in order to realize the call among the services, the client needs to query and subscribe the services from the service configuration center first, and obtain a service information list, wherein the service information is provided for the service configuration center in advance by each service, and includes but is not limited to the address of a node where the service is located and the configuration information required by service execution.

Therefore, when it is necessary to set abnormal configuration information for a service, it is possible to set and store abnormal configuration information for various services by in the service configuration center. Specifically, the user places an order to purchase the item as needed, and the current application may face various abnormal situations when completing the order.

Based on this, the current application may set exception configuration information according to requirements for at least one service within the application in units of applications in the service configuration center, where the exception configuration information may be stored as identification information of a corresponding service and an exception handling rule matching the service. The exception handling rule mentioned here includes an exception handling service set for a preset exception type of the service.

The exception configuration information for service a may include various identification information for identifying service a (e.g., service name of service a) and various exception handling rules corresponding to service a, which include interface information of the slave service called by service a and exception handling services of different exception types for this slave service, since service a may call different slave services, such as service B, service C, service D.

Taking the shopping-like application as an example, when the service a serves to generate the order, the abnormal configuration information of the service a may include identification information of the order-generating service and various abnormal handling rules corresponding to the generated order, for example, abnormal handling rules corresponding to that the goods cannot be added into the shopping cart, and for example, when the purchased goods are pre-sold goods, the corresponding slave services may be the above-mentioned payment service, in-warehouse picking service, and logistics distribution service.

In a specific implementation, the at least one exception handling rule includes preset merchant information and an exception handling service invoked by the preset merchant information in the face of an exception. That is, different merchant information may correspond to different exception handling services. For better description, this part will be described in detail below with reference to fig. 4 and 5.

As shown in FIG. 4, a shopping application may have multiple offline brick and mortar stores along with an online store, such as: a plurality of offline entity centers are arranged in different cities and different positions of the same city in the country, and merchants residing in different entity centers may also be different.

The off-line physical store and the on-line online store can be uniformly managed through the shopping application, but different processing modes can be adopted by different merchants when the same service in the application running process is abnormal, and in addition, the same abnormality can also adopt different processing modes due to the difference of the merchants.

For convenience of description, as shown in fig. 4, the online mall is further configured to have three offline physical stores, and the merchant residence conditions of the three offline physical stores are as follows: entity hub 10 hosts merchant 1, merchant 2, and merchant 3, entity hub 20 hosts merchant 1, merchant 2, merchant 3, and entity hub 30 hosts merchant 1, merchant 2, merchant 3, and merchant 4. For convenience of description, merchants of the same commodity are uniformly described as the same merchant, and for convenience of understanding, the merchant 1 is specifically a fresh merchant, the merchant 2 is specifically a catering merchant and the merchant 3 is a clothing merchant, and the locations of the entity centers are beijing, shanghai and guangzhou, respectively.

In the case of the entity center located in beijing, when the distribution service is abnormal, the following manner can be adopted as shown in table 1 below:

commercial tenant	Type of exception handling	Exception handling method
			Fresh commercial tenant	Lack of goods	Telephone notification
Catering commercial tenant	Lack of goods	Fast refund
			Clothing merchant	Lack of goods	Short message notification

TABLE 1

As shown in table 1, the fresh merchant, the catering merchant, and the clothing merchant are all located in the entity center of beijing, but when the "logistics distribution" service is subject to the exception handling of "out of stock", the exception handling manners adopted are completely different. The fresh product merchant adopts a processing mode of telephone notification to inform the user that the fresh product is out of stock in time due to the fact that the timeliness of the fresh product is stronger. Catering merchants, due to delivery time constraints (e.g., must arrive within an hour), face out of stock, choose an extremely fast refund so that the user can select other catering merchants as soon as possible. The timeliness is not strong, and the user can be informed through the short message when the customer is in short supply.

In the case where the entity center is located in the state of Guangzhou, when the delivery service is abnormal, the following table 2 may be used:

commercial tenant	Type of exception handling	Exception handling method
			Fresh commercial tenant	Lack of goods	Fast refund
Catering commercial tenant	Lack of goods	Fast refund
			Clothing merchant	Lack of goods	Short message notification

TABLE 2

As shown in table 2, the merchants are different from those in table 1 only in regional differences, but when the "logistics distribution" service is confronted with exception handling of "out of stock", the exception handling manner may be different. Because the temperature of Guangzhou is higher, when fresh merchants face the abnormal handling of shortage of goods, the mode of 'fast refund' is adopted. When catering merchants face abnormal processing of out-of-stock, the same abnormal processing mode as that of Beijing merchants can be adopted, and the processing mode of extremely fast refund is selected, so that users can select other catering merchants as soon as possible. The clothing merchant can also adopt the same exception handling mode as the Beijing merchant, and the user can be informed by short messages.

In the case of the entity center located in shanghai, when the distribution service is abnormal, the following table 3 may be used:

commercial tenant	Type of exception handling	Exception handling method
			Fresh commercial tenant	Lack of goods	Issuing coupons
Catering commercial tenant	Lack of goods	Telephone notification
			Clothing merchant	Lack of goods	Short message notification

TABLE 3

The entity center located in Shanghai is located in a suburban area, and the past experience is that users usually do not accept direct refunds, and are more willing to accept economic compensation or have an alternative scheme, so that fresh merchants choose to send coupons delaying delivery to the accounts of the users in the face of shortage of goods, catering merchants choose to inform the users by telephone and provide alternative catering for the users in the telephone notification in the face of shortage of goods, and clothing merchants have low time limit requirements and can inform the users by short messages.

It can be seen from the above three tables that different merchants located in the same entity center adopt different exception handling manners when facing the same exception type due to different characteristic information of the product, and in addition, even the same merchant also adopts different exception handling manners due to being located in different entity centers (different area information). The exception handling modes can be provided for the service configuration center by the merchant according to the needs of the merchant.

In addition, in the implementation, there is a case that the abnormal processing service is different due to different channels for the merchant to sell the goods, that is, the processing manner of the same kind of goods for the abnormal situation may be different on line and under line, as shown in table 4 below, when the same clothing is purchased, due to different purchasing routes, different processing manners may be adopted when the type of abnormal processing of goods shortage is faced. Specifically, when a garment is purchased in an online mall and the goods are out of stock, the customer service is directly accessed, and the customer service explains the reason for the customer and provides an alternative. When the commodity is purchased in the entity center and the type of exception handling of the out-of-stock is faced, the manager of the warehouse can be directly notified, and the manager of the warehouse can apply for calling the commodity to other warehouses.

Purchasing routes	Type of exception handling	Exception handling method
			Online shopping mall	Lack of goods	Customer service access
Entity center	Lack of goods	Notification storehouse

TABLE 4

In summary, in order to be able to target different execution subjects in the same application, resulting in the invoked service being exception-faced with different invoked exception handling services, it is necessary to standardize the exception configuration for the same service and to expose the existing exception configuration for the service to various merchants.

In addition, different exception handling methods can be adopted for the same exception handling type according to different membership grades of users, and for better clarity, the following description will refer to table 5 for example.

User level	Type of exception handling	Exception handling method
			Platinum member	Refund required by quality problem	Fast refund
Silver member	Refund required by quality problem	Refund after customer service access
			General members	Refund required by quality problem	Refund after receiving commodity

TABLE 5

Taking the after-sales service in the shopping application as an example, in the case of the exception handling type requiring return of goods in the face of quality problems, the exception handling mode is determined according to the stored user information corresponding to the user. As shown in table 5, different exception handling manners may be performed according to the user level, when the user level is a platinum member, when a refund is required for a quality problem, an extremely fast refund manner may be employed, and when the user level is a silver member, when a refund is required for a quality problem, the customer service may be accessed to know the situation and then determine whether to directly refund. When the user is a common member, the refund can be performed after receiving the returned goods according to the normal flow.

In step S220, the current application is configured using the exception handling information. Specifically, after receiving and loading the abnormal configuration information, the application may determine the service corresponding to the application according to the identification information in the abnormal configuration information, and then configure the service using the abnormal processing information corresponding to the service.

In step S230, when the order is abnormal, the at least one exception handling rule is invoked to perform exception handling on the order.

In implementation, after the master service is configured by using the abnormal configuration information, the master service may listen to the slave service when calling the slave service, and for better describing this part, the following will be described in detail with reference to fig. 3, where fig. 3 shows a processing flow chart when an abnormality occurs in service calling according to an exemplary embodiment of the present application.

For convenience of description, the following description will be given in the case that the service a calls the service B, when the service a calls the service B, the service a may monitor whether the processing of the service B is exception processing all the time, for example, monitor whether the response speed of the service B becomes slow, and if it is determined that the service B is exception processing, determine whether the exception occurred in the service a matches the exception type in the exception processing rule according to the exception processing rule of the service a. If not, an exception alert operation may be triggered, and an error message for service B may be returned to service A, as an example.

When it is determined that the exception occurring in the service a is the specified exception in the exception handling rule, the exception may be handled according to an exception handling manner corresponding to the specified exception, for example, the service C may be called, and after the execution of the service C is completed, corresponding call response data may be returned to the service calling the service a.

For example, when there is still an exception to the exception execution processing according to the exception processing rule, an exception alarm operation may be triggered and an error message to invoke the service may be returned to the service a as described above.

In the present application, a configuration interface to a service may be set up and presented on a service configuration center with reference to fig. 6 and 7.

FIG. 6 illustrates a display interface of a setup service according to an exemplary embodiment of the present application; fig. 7 illustrates a display interface for setting abnormal configuration information for a service according to an exemplary embodiment of the present application.

In order to enable the service configuration center to accurately identify the service requiring the abnormal configuration processing, a description (identification information) of the service may be added to the interface as shown in fig. 4, including the service name of the service, the interface of the slave service called by the service, the service version information, and the service grouping.

Subsequently, the user may input the exception configuration information set for the service, including the exception type set for the service and the exception call service for various exception types, in the input box as shown in fig. 5.

As shown in fig. 6, after inputting identification information (e.g., a service name) of the service on the display interface and selecting information such as a current state (whether the service is running) of the service, a slave service to which the abnormal configuration information is directed, that is, an invoked service, may be determined, or an intercepted service indicated in the drawing.

In addition, the user may input data for determining the type of the exception in an input box corresponding to the specified exception, which may include, for example, a condition key, an operator, and a numerical value (as shown in fig. 6, the input box of the condition key, the input box of the operator, and the input box of the numerical value may be included in the display interface), so as to complete the exception configuration information corresponding to the specified exception for the invoked service.

Further, the user may enter abnormal configuration information for other services on the display interface in the manner described above. That is, different users can use the display interface to input different abnormal configuration information, and the users include offline merchants and online merchants, and the users may also be users of different commodity sources, for example, restaurant merchants or fresh merchants.

After determining the abnormal configuration information for each service in the current application, the terminal device of the current application may send the abnormal configuration information to the service configuration center, and after receiving the abnormal configuration information, the service configuration center may store the abnormal configuration information as the configuration information for the current application.

In a possible implementation manner, a user may also query details of an exception handling rule for a certain service in the current application through a query interface of the terminal device, or may modify or delete the exception handling rule, so that, since the exception handling rule for any service of the current application is configured and checked through the terminal device, exception handling invoked between services may be customized and visualized, thereby facilitating corresponding management and maintenance for the user.

Further, fig. 5 is another scenario diagram illustrating exception handling according to an exemplary embodiment of the present application.

As shown in fig. 5, in the application scenario of logistics distribution, the "pick in bin" service may invoke the "pick complete" service, in order to perform anomaly monitoring on the "pick in bin" service, unusual configuration information about the "pick-in-bin" service may be provided to the service configuration center by different merchants, as shown, the take-away merchant, the brick-and-mortar store, the dining merchant and the on-line merchant may input different exception handling rules for the "pick-in-warehouse" service via the interface shown in fig. 6, and stores these exception handling rules as exception configuration information corresponding to the service in a service configuration center, as shown in fig. 6, the exception handling rules include exception handling rules for take-away merchants, exception handling rules for brick and mortar stores, exception handling rules for catering merchants, and exception handling rules for online merchants.

Subsequently, after each application merchant launches an application on a respective client, the exception handling rules may be sent to a different application and configure the "pick in bin" service in that application.

Subsequently, at the client where each merchant is located, the "pick in the warehouse" service may listen for the "pick complete" service, and three situations may occur for the "pick complete" service: full sorting, full out-of-stock delivery and partial out-of-stock delivery. And when the in-bin goods picking service monitors that all goods are out of stock, determining that the in-bin goods picking service is abnormal.

At this point, different exception configuration rules may be employed for different merchants. For example, for a case where the take-away merchant is "out of stock", the service of very fast refund, short message, phone, coupon, etc. may be invoked and the service of "customer service intervention" may be invoked in certain cases. For the case of "full out of stock" in a brick and mortar store, a "customer intervention" service may be invoked. And aiming at the condition that the pre-sale shortage of goods appears 'full shortage of goods is out', the 'customer intervention' service can be called. Aiming at the condition that the catering trade company has 'full out of stock' the service such as fast refund, short message, telephone, coupon and the like can be called.

In addition, the method can also be applied to a distribution scene, specifically, a merchant distributes the commodities according to the user order, and returns distribution information to the merchant when the commodity distribution is completed, wherein the distribution information comprises successful distribution, rejection of the user and overtime distribution.

The merchant may set the user rejection and the timeout delivery as exceptions, and thus, when the "delivery complete" service is invoked to check the delivery information, the returned result indicates that the delivery information is the user rejection and the timeout delivery. At this time, the abnormal bottom-holding processing can be performed according to an abnormal processing mode preset by the merchant, for example, for an abnormal order rejected by the user, a voucher with the amount of money such as an order can be issued to the user and the user is notified by a short message; and aiming at the abnormal orders distributed overtime, a gift card can be issued to the user and the user is informed by short messages.

The exception handling method according to the exemplary embodiment of the present application has been described above from the perspective of the client, and will be described below from the perspective of the service configuration center and the service node.

Fig. 8 is a flowchart illustrating an exception handling method according to an exemplary embodiment of the present application, wherein the method illustrated in fig. 8 is a method performed by a service configuration center.

In step S810, abnormal configuration information sent by at least one node for a specific service when a slave service is invoked is received.

In the present application, in order for users (e.g., technicians) on different nodes to set abnormal configuration information for a specific service in the same format, the service configuration center may send the format for setting the abnormal configuration information to the nodes, and thus, the abnormal configuration information is information generated in a standardized format for the at least one node, and as described above, the abnormal configuration information may be information input by the user on the display interface of the at least one node.

In addition, the at least one node includes a node corresponding to an online store and a node corresponding to an offline store. That is, any node that may call the specific service may set an exception handling rule according to its own requirement, and may also view exception configuration information corresponding to the specific service, which is stored in the service configuration center.

In step S820, in response to the application being started, specific abnormal configuration information of the specific service in the application is determined. After an application node managed by a service configuration center is started, the service configuration center may send configuration information to the node, and in the present application, the service configuration center may determine abnormal configuration information corresponding to each service of the application.

In step S830, the specific abnormal configuration information is sent to the application. In this application, when the abnormal configuration information of the application is updated, the service configuration center may broadcast the information that the configuration information is updated to the corresponding node through the registration information at the time of registration.

In practice, the exception handling modes facing the same exception handling type can be updated according to user settings, and the updating modes can be updated according to time, such as quarterly updating, commodity attributes, such as different fresh exception handling modes, or promotion interaction updating, such as delayed delivery double compensation at large promotion, and the like.

When the exception handling mode is changed, the corresponding exception handling information is also changed, and at the moment, the service node corresponding to the exception handling information can send update information to the service configuration center. The service configuration center can inform each relevant service node according to the node information during registration. Fig. 9 is a flowchart illustrating an exception handling method according to an exemplary embodiment of the present application. The above-mentioned

In step S910, it is determined whether the slave service is exception handling according to the return information after the slave service is called.

In step S920, if the processing is exception handling, determining exception configuration information matched with the master service from at least one exception configuration information corresponding to the master service invoking the slave service. Optionally, the at least one exception configuration information includes exception configuration information set when the slave service is called by a different interface.

In summary, according to the exception handling method of the exemplary embodiment of the present application, the service configuration center can be used to directly configure the exception handling information for the service, so that the pressure of technicians on code maintenance is relieved, and customized exception handling services can be provided for different customers. Furthermore, different users can set different abnormal configuration information according to requirements for a specific service, so that the service can adopt different abnormal processing modes according to different application scenes, and thousands of people can be realized. Further, the method can standardize the abnormal configuration information, thereby facilitating different users to customize different abnormal configuration rules. Furthermore, the method is not sensitive to the user, and the user experience is improved. Furthermore, different abnormal configuration information can be set for each service through a visual user interface, so that corresponding management and maintenance are facilitated for users. Furthermore, the method can realize online and offline linkage, and enhance user experience.

In order to more clearly understand the inventive concept of the exemplary embodiment of the present application, a block diagram of an exception handling apparatus of the exemplary embodiment of the present application will be described below with reference to fig. 10. Those of ordinary skill in the art will understand that: the apparatus in fig. 10 shows only components related to the present exemplary embodiment, and common components other than those shown in fig. 10 are also included in the apparatus.

Fig. 10 shows a block diagram of an exception handling apparatus of an exemplary embodiment of the present application. The exception handling apparatus refers to an apparatus that can perform an exception handling method according to an exemplary embodiment of the present application. Referring to fig. 10, the apparatus includes, at a hardware level, a processor, an internal bus, and a computer-readable storage medium, wherein the computer-readable storage medium includes a volatile memory and a non-volatile memory. The processor reads the corresponding computer program from the non-volatile memory and then runs it. Of course, besides the software implementation, the present application does not exclude other implementations, such as logic devices or a combination of software and hardware, and the like, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.

Specifically, the processor performs the following operations: obtaining abnormal configuration information corresponding to a current application from a service configuration center, wherein the current application comprises at least one service called during order completion, and the abnormal configuration information is used for indicating at least one abnormal processing rule set when the at least one service is abnormal during the order completion; configuring the current application by using the abnormal configuration information; and when the order is abnormal, calling the at least one abnormal processing rule to perform abnormal processing on the order.

Optionally, the at least one exception handling rule includes merchant information and an exception handling service invoked by the merchant information in the face of an exception.

The merchant information comprises the area information of the merchant, the channel information of the merchant for selling the commodity and the characteristic information of the merchant for selling the commodity.

The processor invoking the at least one exception handling rule when the order is abnormal in the implementing step to perform exception handling on the order comprises: acquiring current merchant information from the order information; determining an exception handling rule corresponding to the current merchant information; and calling an exception handling service in the exception handling rule to perform exception handling on the order.

The exception handling rule is further configured to correlate with user information for executing the current order.

The processor may further implement the steps of: receiving an abnormal configuration information updating notice broadcasted by a service configuration center and aiming at the current application; receiving at least one updated anomalous configuration information for the current application from the service configuration center in response to the anomalous configuration information update notification.

The processor may further implement the steps comprising, after receiving at least one updated exception configuration information for the application from the service configuration center: determining at least one service to be updated corresponding to the at least one abnormal processing information; and updating the abnormal configuration information of the at least one service to be updated into corresponding updated abnormal configuration information.

According to an exemplary embodiment of the present application, the server may further perform the steps of: receiving abnormal configuration information sent by at least one node for a specific service when a slave service is called; determining specific abnormal configuration information of the specific service in the application in response to the application being started; sending the specific exception configuration information to the application.

Optionally, the at least one node includes a node corresponding to an online store and a node corresponding to an offline store.

Optionally, the abnormal configuration information is information generated for the at least one node standardized format.

Optionally, the exception configuration information is exception handling information acquired on a display interface of the at least one node.

According to an exemplary embodiment of the present application, the server may further perform the steps of: determining whether the slave service is abnormal according to the return information after the slave service is called; and if the processing is abnormal processing, determining abnormal configuration information matched with the main service from at least one abnormal configuration information corresponding to the main service calling the slave service.

Optionally, the at least one exception configuration information includes exception configuration information set when the slave service is called by a different interface.

In summary, the exception handling apparatus according to the exemplary embodiment of the present application may directly perform exception handling information configuration on the service by using the service configuration center, which relieves the pressure of technicians on code maintenance and may provide customized exception handling services to different customers. Furthermore, different users can set different abnormal configuration information according to requirements for a specific service, so that the service can adopt different abnormal processing modes according to different application scenes, and thousands of people can be realized. Further, the method can standardize the abnormal configuration information, thereby facilitating different users to customize different abnormal configuration rules. Furthermore, the method is not sensitive to the user, and the user experience is improved. Furthermore, different abnormal configuration information can be set for each service through a visual user interface, so that corresponding management and maintenance are facilitated for users. Furthermore, the method can realize online and offline linkage, and enhance user experience.

Fig. 11 illustrates an architecture of a computer system, which may specifically include a processor 1010, a video display adapter 1011, a disk drive 1012, an input/output interface 1013, a network interface 1014, and a memory 1020. The processor 1010, the video display adapter 1011, the disk drive 1012, the input/output interface 1013, and the network interface 1014, and the memory 1020 may be communicatively connected by a communication bus 1030.

The processor 1010 may be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an Application Specific Integrated Circuit (ASIC), or one or more Integrated circuits, and is configured to execute related programs to implement the technical solution provided by the present Application.

The Memory 1020 may be implemented in the form of a ROM (Read Only Memory), a RAM (Random Access Memory), a static storage device, a dynamic storage device, or the like. The memory 1020 may store an operating system 1021 for controlling the operation of the computer system 1000, a Basic Input Output System (BIOS) for controlling low-level operations of the computer system 1000. In addition, a web browser 1023, a data storage management system 1024, a task issuing processing system 1025 and the like can be stored. The task issuing processing system 1025 can be a task issuing server that specifically implements the operations of the foregoing steps in this embodiment of the application. In summary, when the technical solution provided in the present application is implemented by software or firmware, the relevant program codes are stored in the memory 1020 and called for execution by the processor 1010.

The input/output interface 1013 is used for connecting an input/output module to realize information input and output. The i/o module may be configured as a component in a device (not shown) or may be external to the device to provide a corresponding function. The input devices may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output devices may include a display, a speaker, a vibrator, an indicator light, etc.

The network interface 1014 is used for connecting a communication module (not shown in the figure) to realize the communication interaction between the device and other devices. The communication module can realize communication in a wired mode (such as USB, network cable and the like) and also can realize communication in a wireless mode (such as mobile network, WIFI, Bluetooth and the like).

Bus 1030 includes a path that transfers information between various components of the device, such as processor 1010, video display adapter 1011, disk drive 1012, input/output interface 1013, network interface 1014, and memory 1020.

In addition, the computer system 1000 may also obtain information of specific obtaining conditions from the virtual resource object obtaining condition information database 1041, so as to perform condition judgment, and the like.

It should be noted that although the above devices only show the processor 1010, the video display adapter 1011, the disk drive 1012, the input/output interface 1013, the network interface 1014, the memory 1020, the bus 1030, etc., in a specific implementation, the device may also include other components necessary for normal operation. Furthermore, it will be understood by those skilled in the art that the apparatus described above may also include only the components necessary to implement the solution of the present application, and not necessarily all of the components shown in the figures.

Where fig. 12 illustrates an architecture of an electronic device, for example, device 1100 can be a mobile phone, a computer, a digital broadcast terminal, a messaging device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, an aircraft, and the like.

Referring to fig. 12, device 1100 may include one or more of the following components: processing component 1102, memory 1104, power component 1106, multimedia component 1108, audio component 1110, input/output (I/O) interface 1112, sensor component 1114, and communications component 1116.

The processing component 1102 generally controls the overall operation of the device 1100, such as operations associated with display, telephone calls, data communications, camera operations, and recording operations. The processing element 1102 may include one or more processors 1120 to execute instructions to perform all or a portion of the steps of the methods provided by the disclosed subject matter. Further, the processing component 1102 may include one or more modules that facilitate interaction between the processing component 1102 and other components. For example, the processing component 1102 may include a multimedia module to facilitate interaction between the multimedia component 1108 and the processing component 1102.

The memory 1104 is configured to store various types of data to support operation at the device 1100. Examples of such data include instructions for any application or method operating on device 1100, contact data, phonebook data, messages, pictures, videos, and so forth. The memory 1104 may be implemented by any type or combination of volatile or non-volatile memory devices such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disks.

A power component 1106 provides power to the various components of the device 1100. The power components 1106 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power for the device 1100.

The multimedia component 1108 includes a screen that provides an output interface between the device 1100 and a user. In some embodiments, the screen may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive an input signal from a user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundary of a touch or slide action, but also detect the duration and pressure associated with the touch or slide operation. In some embodiments, the multimedia component 1108 includes a front facing camera and/or a rear facing camera. The front-facing camera and/or the rear-facing camera may receive external multimedia data when the device 1100 is in an operating mode, such as a shooting mode or a video mode. Each front camera and rear camera may be a fixed optical lens system or have a focal length and optical zoom capability.

The audio component 1110 is configured to output and/or input audio signals. For example, the audio component 1110 includes a Microphone (MIC) configured to receive external audio signals when the device 1100 is in operating modes, such as a call mode, a recording mode, and a voice recognition mode. The received audio signals may further be stored in the memory 1104 or transmitted via the communication component 1116. In some embodiments, the audio assembly 1110 further includes a speaker for outputting audio signals.

The I/O interface 1112 provides an interface between the processing component 1102 and peripheral interface modules, which may be keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to: a home button, a volume button, a start button, and a lock button.

The sensor assembly 1114 includes one or more sensors for providing various aspects of state assessment for the device 1100. For example, the sensor assembly 1114 may detect the open/closed state of the device 1100, the relative positioning of components, such as a display and keypad of the device 1100, the sensor assembly 1114 may also detect a change in the position of the device 1100 or a component of the device 1100, the presence or absence of user contact with the device 1100, orientation or acceleration/deceleration of the device 1100, and a change in the temperature of the device 1100. The sensor assembly 1114 may include a proximity sensor configured to detect the presence of a nearby object without any physical contact. The sensor assembly 1114 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 1114 may also include an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

The communication component 1116 is configured to facilitate wired or wireless communication between the device 1100 and other devices. The device 1100 may access a wireless network based on a communication standard, such as WiFi, 2G or 3G, or a combination thereof. In an exemplary embodiment, the communication component 1116 receives a broadcast signal or broadcast associated information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communications component 1116 also includes a Near Field Communication (NFC) module to facilitate short-range communications. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID) technology, infrared data association (IrDA) technology, Ultra Wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

In an exemplary embodiment, the device 1100 may be implemented by one or more Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPDs), Programmable Logic Devices (PLDs), Field Programmable Gate Arrays (FPGAs), controllers, micro-controllers, microprocessors or other electronic components for performing the above-described methods.

In an exemplary embodiment, a non-transitory computer-readable storage medium comprising instructions, such as the memory 1104 comprising instructions, executable by the processor 1120 of the device 1100 to perform the methods provided by the disclosed aspects is also provided. For example, the non-transitory computer readable storage medium may be a ROM, a Random Access Memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, and the like.

From the above description of the embodiments, it is clear to those skilled in the art that the present application can be implemented by software plus necessary general hardware platform. Based on such understanding, the technical solutions of the present application may be essentially or partially implemented in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method according to the embodiments or some parts of the embodiments of the present application.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, the system or system embodiments are substantially similar to the method embodiments and therefore are described in a relatively simple manner, and reference may be made to some of the descriptions of the method embodiments for related points. The above-described system and system embodiments are only illustrative, wherein the units described as separate parts may or may not be physically separate, and the parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.

The task issuing processing method, the task issuing processing device and the electronic equipment provided by the application are introduced in detail, a specific example is applied in the text to explain the principle and the implementation mode of the application, and the description of the embodiment is only used for helping to understand the method and the core idea of the application; meanwhile, for a person skilled in the art, according to the idea of the present application, the specific embodiments and the application range may be changed. In view of the above, the description should not be taken as limiting the application.

Claims

1. An exception handling method, comprising:

obtaining abnormal configuration information corresponding to a current application from a service configuration center, wherein the current application comprises at least one service called during order completion, and the abnormal configuration information is used for indicating at least one abnormal processing rule set when the at least one service is abnormal during the order completion;

configuring the current application by using the abnormal configuration information;

and when the order is abnormal, calling the at least one abnormal processing rule to perform abnormal processing on the order.

2. The method of claim 1, wherein the at least one exception handling rule comprises merchant information and an exception handling service invoked by the merchant information in the face of an exception.

3. The method as recited in claim 2, wherein the merchant information includes area information where the merchant is located, channel information where the merchant sells goods, and feature information where the merchant sells goods.

4. The method of claim 2, wherein invoking the at least one exception handling rule to perform exception handling on the order when the order is anomalous comprises:

acquiring current merchant information from the order information;

determining an exception handling rule corresponding to the current merchant information;

and calling an exception handling service in the exception handling rule to perform exception handling on the order.

5. The method of claim 2, wherein the exception handling rule is further configured to correlate to user information for executing the current order.

6. The method of any of claims 1 to 5, further comprising:

receiving an abnormal configuration information updating notice broadcasted by a service configuration center and aiming at the current application;

receiving at least one updated anomalous configuration information for the current application from the service configuration center in response to the anomalous configuration information update notification.

7. The method of claim 6, wherein receiving at least one updated exception configuration information for the application from the service configuration center comprises:

determining at least one service to be updated corresponding to the at least one abnormal processing information;

and updating the abnormal configuration information of the at least one service to be updated into corresponding updated abnormal configuration information.

8. An exception handling method, comprising:

receiving abnormal configuration information sent by at least one node for a specific service when a slave service is called;

determining specific abnormal configuration information of the specific service in the application in response to the application being started;

sending the specific exception configuration information to the application.

9. The method of claim 8, wherein the at least one node comprises a node corresponding to an online store and a node corresponding to an offline store.

10. The method of claim 8, wherein the abnormal configuration information is information generated for the at least one node standardized format.

11. The method of claim 10, wherein the exception configuration information is exception handling information obtained on a display interface of the at least one node.

12. An exception handling method, comprising:

determining whether the slave service is abnormal according to the return information after the slave service is called;

and if the processing is abnormal processing, determining abnormal configuration information matched with the main service from at least one abnormal configuration information corresponding to the main service calling the slave service.

13. The method of claim 12, wherein the at least one exception configuration information comprises exception configuration information set when the slave service is invoked by a different interface.

14. An exception handling apparatus, comprising:

one or more processors;

a memory; and

one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs comprising instructions for performing any of the methods of claims 1-13.

15. A computer readable storage medium storing one or more programs, the one or more programs comprising instructions, which when executed by a computing device, cause the computing device to perform any of the methods of claims 1-13.