CN113112316B

CN113112316B - Exception handling method and device

Info

Publication number: CN113112316B
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: 2024-06-25
Anticipated expiration: 2039-12-24
Also published as: CN113112316A

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 order completion; configuring the current application by utilizing the abnormal configuration information; and when the order is abnormal, invoking the at least one abnormal processing rule to execute abnormal processing on the order. By adopting the application, the service configuration center can be utilized to directly configure the exception handling information of the service, thus relieving the pressure of technicians on code maintenance and providing customized exception handling service for different clients.

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 apparatus thereof.

Background

With the popularization of computers and the rapid development of internet technology, in particular, the proposal of a micro-service architecture promotes the development of a system architecture 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 in the system to the call between services such as a cross-host, a cross-application cluster and the like, and the call of the service is abnormal due to the problems of overlarge network overhead, unstable service and the like.

In the related art, in order to avoid an abnormality that may occur during a call of a plurality of services, code segments of respective services may be located and different exception handling codes may be added at corresponding positions, but thus, when the number of services is large, locating each service and adding an exception handling code in each service is huge, the number of codes for development and maintenance is huge for a developer, and the cost of labor is huge.

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 technical problems.

The embodiment of the application also provides an exception handling method, which 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 order completion; configuring the current application by utilizing the abnormal configuration information; and when the order is abnormal, invoking the at least one abnormal processing rule to execute abnormal processing on the order.

The embodiment of the application also provides an exception handling method, which comprises the following steps: receiving abnormal configuration information sent by at least one node for specific service when calling the slave service; determining, in response to an application being launched, particular abnormal configuration information for the particular service in the application; the specific abnormal configuration information is sent to the application.

The embodiment of the application also provides an exception handling method, which comprises the following steps: determining whether the slave service is abnormal processing according to the return information after the slave service is called; if the processing is abnormal processing, determining abnormal configuration information matched with the main service from at least one piece of abnormal configuration information corresponding to the main service calling the auxiliary service.

The embodiment of the application also provides an exception handling device, which comprises: 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 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 methods.

The above at least one technical scheme adopted by the embodiment of the application can achieve the following beneficial effects:

By adopting the application, the service configuration center can be utilized to directly configure the exception handling information of the service, thus relieving the pressure of technicians on code maintenance and providing customized exception handling service for different clients.

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 specification, illustrate embodiments of the application and together with the description serve to explain the application and do not constitute a limitation on the application. In the drawings:

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

FIG. 2 is a flowchart 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 according to an exemplary embodiment of the present application;

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

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

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

fig. 7 is a display interface showing setting of abnormal 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 illustrating 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 according to an embodiment of the present application;

fig. 12 is a schematic diagram of an architecture of an electronic device according to 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 clearly and completely described below with reference to specific embodiments of the present application and corresponding drawings. It will be apparent that the described embodiments are only some, but not all, embodiments of the application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.

In order to relieve the pressure of technicians on code maintenance and provide customized exception handling services to different customers, the exception handling method according to an exemplary embodiment of the present application may utilize a service configuration center to directly configure exception handling information for the services to which they belong.

In implementations, as shown in FIG. 1, a client may require multiple service interactions in order to run a particular application, e.g., a shopping class application. As shown in fig. 1, it is assumed that a certain application includes three services, service a, service B, and service C, and when the application is executed, the order of call between the three services is that service a calls service B, and service B calls service C. Although not shown in the figures, in actual implementation, each service may be provided by one service cluster. For example, taking service B as an example, the device that provides the service B may be a plurality of nodes.

For example, assuming that the user uses a shopping application, the user generates orders, pays, in-house pick-up, and logistics distribution functions after purchasing goods may be services under the application. In contrast to fig. 1, the generated order service corresponds to service a, the payment service corresponds to service B, the in-warehouse pick-up service corresponds to service C, and the logistics distribution service corresponds to service D.

Assuming that the user purchases fresh commodities on the shopping application, after generating the order, the user sends an order generation message, the payment service receives the order and sends a successful payment message to the in-warehouse picking service, and after realizing in-warehouse picking, the in-warehouse picking service sends a commodity taking message to the logistics distribution service, and then the logistics distribution service receives the order and sends a commodity successful distribution message. It follows that shopping class applications need to invoke different services to each other to implement this functionality.

In this process, as shown in fig. 1, when a client needs a certain service, a service configuration center may be queried and subscribed to, and still taking service B as an example, a node where service a is located may obtain a service information list from the service configuration center, and 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 used for receiving service registration information sent by each service node, and comprises information such as an address information list of the subscribed service node, a service routing rule and the like, and uniformly managing the information and providing a standard interface. When each service needs to acquire configuration information, the configuration information can be directly pulled to a corresponding interface in the service configuration center. In addition, when various parameters in the service configuration center are updated, the service configuration center can also be notified to each service, so that each service can pull the update information in real time to dynamically update the update information.

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

During the call, 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, 1 s), at which time this may be handled by running the exception handling method according to an exemplary embodiment of the present application.

An exception handling method according to an exemplary embodiment of the present application will be described in detail 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 implementations, a user may launch an application on his client, e.g., a shopping class application, with the following steps being performed as the application is launched.

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

As described above, the current application is constituted by a plurality of services, and for convenience of description, a service party (e.g., a specific service) that invokes a service is referred to as a master service, and a service party that invokes a service is referred to as a slave service. For example, if service a calls service B, then service a is the master service and service B is the slave service. It should be noted that the above is for illustration only and is not intended to be limiting in any way.

Specifically, a user may launch an application in a client for various needs. In order to meet the requirements of users, the application needs to mutually call and realize a plurality of services in the execution process, and in order to realize the call among the services, a client needs to firstly inquire and subscribe the services to a service configuration center to acquire a service information list, wherein the service information is provided by each service to the service configuration center in advance, and comprises and is not limited to the address of a node where the service is located and configuration information required by the service execution.

Accordingly, when it is necessary to set the abnormal configuration information for the service, the abnormal configuration information for various services can be set and stored by being set in the service configuration center. Specifically, the user places an order for a commodity as desired, and the current application may be faced with various anomalies when the order is completed.

Based on this, the current application may set, in the service configuration center, abnormal configuration information for at least one service within the application according to the need in an application unit, wherein the abnormal configuration information may be stored as identification information of a corresponding service and an abnormal processing rule matched with the service. The abnormality processing rule mentioned here includes an abnormality processing service set for a preset abnormality type of the service.

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

Taking the shopping class application as an example, when the service a is the generation order service, the abnormal configuration information of the service a may include identification information of the generation order service and various abnormal processing rules corresponding to the generation order, for example, abnormal processing rules corresponding to the inability of the commodity to join the shopping cart, and for example, abnormal processing rules corresponding to the case that the purchased commodity is a pre-sold commodity, and the corresponding sub-service may be the payment service, the in-warehouse picking service, and the logistics distribution service mentioned above.

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 when faced with an exception. That is, different merchant information may correspond to different exception handling services. For a 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 an online store with multiple offline physical stores, such as: multiple off-line entity centers are provided in different cities throughout the country and at different locations in the same city, and merchants where different entity centers reside may also be different.

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

For convenience of description, as shown in fig. 4, the online mall is further configured to have three offline physical stores, where the merchant residences of the three offline physical stores are: entity center 10 hosts merchant 1, merchant 2, and merchant 3, entity center 20 hosts merchant 1, merchant 2, and merchant 3, and entity center 30 hosts merchant 1, merchant 2, merchant 3, and merchant 4. For convenience of description, merchants of the same commodity are collectively described as the same merchant, and in addition, for convenience of understanding, merchant 1 is specifically a fresh merchant, merchant 2 is specifically a catering merchant and merchant 3 is a clothing merchant, and positions of entity centers are Beijing, shanghai and Guangzhou respectively.

In the case where the entity center is located in beijing, when the delivery service is abnormal, the following manner may be adopted as shown in table 1:

Commercial tenant	Exception handling type	Exception handling mode
			Fresh commercial tenant	Lack of stock	Telephone notification
Dining merchant	Lack of stock	Very fast refund
			Clothing merchant	Lack of stock	Short message notification

TABLE 1

As shown in table 1, fresh merchants, catering merchants and clothing merchants are all located in the entity center of beijing, but the exception handling modes adopted are completely different when the "logistics distribution" service faces the exception handling of "out of stock". The timeliness of the fresh products is strong, so that the fresh merchants adopt a telephone notification processing mode to inform users that the fresh products are out of stock in time. The restaurant merchant selects a quick refund when faced with the backorder due to the distribution time limitation (e.g., must be reached within an hour) so that the user can select other restaurant merchants as soon as possible. The clothing merchant is not good in timeliness, and the user can be notified through a short message when the clothing merchant faces the shortage of goods.

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

Commercial tenant	Exception handling type	Exception handling mode
			Fresh commercial tenant	Lack of stock	Very fast refund
Dining merchant	Lack of stock	Very fast refund
			Clothing merchant	Lack of stock	Short message notification

TABLE 2

As shown in table 2, these merchants differ from the merchants in table 1 only in geographical differences, but when the "logistics distribution" service faces "out of stock" exception handling, the exception handling may be different. Because the temperature of Guangzhou is high, when the fresh merchants face abnormal handling of backorders, a mode of 'quick refund' is adopted. When the catering merchants face abnormal handling of backorders, the same abnormal handling mode as that of Beijing merchants can be adopted, and the handling mode of quick refund is selected, so that users can select other catering merchants as soon as possible. The clothing merchant can also adopt the same abnormal processing mode as Beijing merchant, and the user can be notified through a short message.

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

Commercial tenant	Exception handling type	Exception handling mode
			Fresh commercial tenant	Lack of stock	Issuing coupons
Dining merchant	Lack of stock	Telephone notification
			Clothing merchant	Lack of stock	Short message notification

TABLE 3 Table 3

The entity center at Shanghai is in suburban areas, past experience is that users usually do not accept direct refunds and are willing to accept economic compensation or alternative schemes, so fresh merchants choose to send coupons for delayed delivery to the user's accounts in the face of backorders, catering merchants choose to notify the user by telephone and provide alternative catering to the user in telephone notification in the face of backorders, and clothing merchants can notify the user by short messages due to poor time-limited requirements.

From the above three tables, it can be seen that different merchants located in the same entity center can adopt different exception handling modes when feature information of the commodities is different and faces the same exception type, and in addition, even the same merchant can also adopt different exception handling modes due to being located in different entity centers (different area information). These exception handling modes can be provided to the service configuration center by the merchant according to the own requirements.

In addition, in practice, there is a case where the merchant sells goods in different channels, which results in different abnormality handling services, that is, the same goods may be handled differently on line and off line for abnormality, and different handling methods may be adopted when the same garment is purchased due to different purchase routes and when the type of abnormality handling is faced for backout, as shown in table 4 below. Specifically, when clothing is purchased in an online mall and goods are out of stock, customer service is directly accessed, and the customer service explains the reasons and provides alternatives. When the type of exception handling in the face of a backout is made when a commodity is purchased at an entity center, the manager of the warehouse may be notified directly, and the manager of the warehouse may apply to call the commodity to other warehouses.

Purchasing route	Exception handling type	Exception handling mode
			Online mall	Lack of stock	Customer service access
Entity center	Lack of stock	Notification warehouse

TABLE 4 Table 4

In summary, in order to be able to be different for execution subjects in the same application, the service that is invoked is different for the exception handling, so that the invoked exception handling service is different, it is necessary to standardize the exception configuration for the same service and can show various merchants the existing exception configuration for the service.

In addition, different exception handling modes may be adopted for different member classes of the user, and for the same exception handling type, the following will be exemplified with reference to table 5 for more clarity of description.

User level	Exception handling type	Exception handling mode
			Platinum member	Quality problems require refunds	Very fast refund
Silver member	Quality problems require refunds	Access customer service refund
			General member	Quality problems require refunds	Receipt of a goods refund

TABLE 5

Taking after-sales service in shopping applications as an example, in the type of exception handling requiring return in the face of quality problems, the manner of exception handling is determined based on stored user information corresponding to the user. As shown in table 5, different exception handling modes can be executed according to the user level, when the user level is a platinum member, a fast refund mode can be adopted when refund is required to face quality problems, when the user is a silver member, when refund is required to face quality problems, customer service can be accessed to know the situation, and then a customer can judge whether to refund directly. When the user is a common member, refunds can be carried out after goods returned are received according to the normal flow.

In step S220, the current application is configured using the exception handling information. Specifically, after the application receives and loads the abnormal configuration information, the corresponding service in the application can be determined according to the identification information in the abnormal configuration information, and then the service is configured by using the abnormal processing information corresponding to the service.

In step S230, when an abnormality occurs in the order, the at least one abnormality processing rule is invoked to perform abnormality processing on the order.

In implementation, after configuring the master service with the exception configuration information, the master service may snoop the slave service when invoking the slave service, which will be described in detail below in conjunction with fig. 3, which shows a flow chart of a process when an exception occurs in service invocation according to an exemplary embodiment of the present application.

For convenience of description, in the case where 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 an exception processing in the whole course, for example, monitor whether the response speed of the service B is slow, and if it is determined that the service B is an exception processing, determine whether an exception occurred in the service a matches an exception type in an exception processing rule according to an exception processing rule of the service a. If there is no match, an exception alert operation may be triggered and an error message for service B returned to service A, for example.

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

For example, when there is still an exception in the exception handling performed according to the exception handling rules, an exception alert operation may be triggered as shown above and an error message invoking the service may be returned to service a.

In the present application, a configuration interface for a service may be set 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 for the service configuration center to accurately identify a service requiring abnormal configuration processing, a description (identification information) of the service may be added on an interface as shown in fig. 4, including a service name of the service, an interface of a slave service called by the service, service version information, and a service packet.

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

As shown in fig. 6, after the identification information (for example, service name) of the service is input on the display interface and the information such as the current state (whether to run) of the service is selected, the slave service for which the abnormal configuration information is aimed, that is, the called service, may be determined, or may be the interception service indicated in the drawing.

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

Still further, the user may input abnormal configuration information for other services on the display interface as described above. That is, different users can input different abnormal configuration information by using the display interface, and the users include off-line merchants and on-line 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 can also query the details of the exception handling rules for a certain service in the current application through a query interface of the terminal device, or can modify and delete the exception handling rules, so that, as the exception handling rules for any service of the current application can be configured and checked through the terminal device, the exception handling invoked between the services can be customized and visualized, and the user can conveniently perform corresponding management and maintenance.

Further, fig. 5 is another scene 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 "in-bin picking" service may call the "picking completion" service, in order to perform anomaly monitoring on the "in-bin picking" service, anomaly configuration information about the "in-bin picking" service may be provided to the service configuration center by different merchants, as shown in the drawing, the takeout merchant, the entity store, the catering merchant and the online merchant may input different anomaly processing rules for the "in-bin picking" service via the interface shown in fig. 6, respectively, and store these anomaly processing rules as anomaly configuration information corresponding to the service in the service configuration center, as shown in fig. 6, where the anomaly processing rules include anomaly processing rules for the takeout merchant, anomaly processing rules for the entity store, anomaly processing rules for the catering merchant and anomaly processing rules for the online merchant.

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

Subsequently, at the customer site of each merchant, the "in-warehouse pick" service may monitor the "pick complete" service, and three situations may occur with the "pick complete" service: full pick, full out of stock, and partial out of stock. When the in-bin order picking service monitors all out-of-stock, the in-bin order picking service is determined to be abnormal.

At this time, different abnormal configuration rules may be adopted for different merchants. For example, for the case where the take-out merchant is "all out of stock," a quick refund, SMS, phone, coupon, etc. service may be invoked and in certain cases a "customer service intervention" service may be invoked. For the case that the entity store has "all out of stock", a "customer intervention" service may be invoked. For the case of "all out of stock" in the pre-sell out, a "customer intervention" service may be invoked. The service such as quick refund, short message, telephone, coupon and the like can be called aiming at the condition that the catering merchant has the shortage of all goods.

In addition, the method can be applied to a delivery scene, in particular to delivery of commodities according to a user order by a merchant, and delivery information is returned to the merchant when the commodity delivery is completed, including successful delivery, user rejection and overtime delivery.

Merchants may set user rejections and time-out delivery to exceptions so that the "delivery complete" service, when invoking the "completion of performance" service to view delivery information, finds that the returned results indicate delivery information as user rejections and time-out delivery. At this time, the abnormal spam processing can be performed according to an abnormal processing mode preset by a merchant, for example, for abnormal orders rejected by a user, a cash coupon with an amount of order and the like can be issued to the user and the user can be notified by a short message; for abnormal orders of overtime delivery, gift cards can be issued to users and the users can be notified by short messages.

The abnormality processing method according to the exemplary embodiment of the present application has been described above from the viewpoint of the client, and will be described below from the viewpoint 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 transmitted 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 transmit a format for setting the abnormal configuration information to the nodes, and thus the abnormal configuration information is information generated for the standardized format of the at least one node, and as described above, the abnormal configuration information may be information input by the user on a display interface of the at least one node.

Further, 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 demand, and may also view exception configuration information corresponding to the specific service stored on the service configuration center.

In step S820, in response to an application being launched, 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.

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

In implementation, the exception handling mode facing the same exception handling type may be updated according to user settings, and the update mode may be updated according to time, for example, update in quarters, or update according to commodity attributes, for example, different exception handling modes of fresh, or update according to promotion interaction, for example, delay delivery of large promotion time is doubled for compensation, etc.

When the exception handling mode is changed, the corresponding exception handling information is changed, and at this time, the service node corresponding to the exception handling information can send update information to the service configuration center. The service configuration center may notify each relevant service node according to the node information at the time of registration. Fig. 9 is a flowchart illustrating an exception handling method according to an exemplary embodiment of the present application. The said

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

In step S920, if the processing is an exception processing, exception configuration information matching the master service is determined from at least one exception configuration information corresponding to the master service calling the slave service. Optionally, the at least one abnormal configuration information includes abnormal configuration information set when the slave service is invoked by a different interface.

In summary, the exception handling method 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, thereby relieving the pressure of technicians on code maintenance and providing customized exception handling services to different customers. Furthermore, for a specific service, different users can set different abnormal configuration information according to requirements, so that the service can adopt different abnormal processing modes according to different application scenes, and thousands of people and thousands of faces can be achieved. Furthermore, the method can normalize the abnormal configuration information, thereby facilitating different users to customize different abnormal configuration rules. Still further, the method is imperceptible to the user, improving the user experience. Furthermore, different abnormal configuration information can be set for each service through the visual user interface, so that the user can conveniently manage and maintain correspondingly. 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 abnormality processing 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 appreciate that: the apparatus in fig. 10 shows only components related to the present exemplary embodiment, and general components other than those shown in fig. 10 are included in the apparatus.

Fig. 10 shows a block diagram of an abnormality processing apparatus of an exemplary embodiment of the present application. The abnormality processing apparatus refers to an apparatus that can perform an abnormality processing method according to an exemplary embodiment of the present application. Referring to fig. 10, at a hardware level, the apparatus includes a processor, an internal bus, and a computer-readable storage medium, wherein the computer-readable storage medium includes a volatile memory and a nonvolatile memory. The processor reads the corresponding computer program from the non-volatile memory and then runs. Of course, other implementations, such as logic devices or combinations of hardware and software, are not excluded from the present application, that is, the execution subject of the following processing flows is not limited to each logic unit, but may 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 order completion; configuring the current application by utilizing the abnormal configuration information; and when the order is abnormal, invoking the at least one abnormal processing rule to execute abnormal processing on the order.

Optionally, the at least one exception handling rule includes merchant information and an exception handling service that the merchant information invokes when faced with an exception.

The merchant information comprises the regional information of the merchant, the channel information of the commodity sold by the merchant and the characteristic information of the commodity sold by the merchant.

The processor invoking the at least one exception handling rule to perform exception handling on the order when the order is exception in the implementing step includes: 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 execute exception handling on the order.

The exception handling rules are also configured to relate to user information for executing the current order.

The processor may further implement the steps of: receiving an abnormal configuration information update notification for the current application, which is broadcasted by a service configuration center; at least one updated abnormal configuration information for the current application is received from the service configuration center in response to the abnormal configuration information update notification.

The processor may further implement the steps of, after receiving at least one updated exception configuration information for the application from the service configuration center, comprising: determining at least one service to be updated corresponding to the at least one piece of exception handling information; 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 specific service when calling the slave service; determining, in response to an application being launched, particular abnormal configuration information for the particular service in the application; the specific abnormal configuration information is sent 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 processing according to the return information after the slave service is called; if the processing is abnormal processing, determining abnormal configuration information matched with the main service from at least one piece of abnormal configuration information corresponding to the main service calling the auxiliary service.

Optionally, the at least one abnormal configuration information includes abnormal configuration information set when the slave service is invoked 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 a service to which the exception handling apparatus belongs using a service configuration center, relieves pressure of technicians on code maintenance, and may provide customized exception handling services to different customers. Furthermore, for a specific service, different users can set different abnormal configuration information according to requirements, so that the service can adopt different abnormal processing modes according to different application scenes, and thousands of people and thousands of faces can be achieved. Furthermore, the method can normalize the abnormal configuration information, thereby facilitating different users to customize different abnormal configuration rules. Still further, the method is imperceptible to the user, improving the user experience. Furthermore, different abnormal configuration information can be set for each service through the visual user interface, so that the user can conveniently manage and maintain correspondingly. Furthermore, the method can realize online and offline linkage and enhance user experience.

Fig. 11 illustrates an exemplary architecture for a computer system, which may 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, 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, etc. for executing related programs to implement the technical solution provided by the present application.

The Memory 1020 may be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory ), static storage, dynamic storage, etc. Memory 1020 may store an operating system 1021 for controlling the operation of computer system 1000, and a Basic Input Output System (BIOS) for controlling the low-level operation of computer system 1000. In addition, web browser 1023, data storage management system 1024, and task delivery processing system 1025, and the like, may also be stored. The task issuing processing system 1025 may be a task issuing server for implementing the operations of the foregoing steps in the embodiment of the present application. In general, when implemented in software or firmware, the relevant program code is stored in memory 1020 and executed by processor 1010.

The input/output interface 1013 is used to connect with an input/output module to realize information input and output. The input/output module may be configured as a component in a device (not shown) or may be external to the device to provide corresponding functionality. Wherein the input devices may include a keyboard, mouse, touch screen, microphone, various types of sensors, etc., and the output devices may include a display, speaker, vibrator, indicator lights, etc.

The network interface 1014 is used to connect communication modules (not shown) to enable communication interactions of the device with other devices. The communication module may implement communication through a wired manner (such as USB, network cable, etc.), or may implement communication through a wireless manner (such as mobile network, WIFI, bluetooth, etc.).

Bus 1030 includes a path to transfer information between components of the device (e.g., 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 acquisition conditions from the virtual resource object acquisition condition information database 1041 for making condition judgment, and so on.

It is noted that although the above-described devices illustrate only the processor 1010, video display adapter 1011, disk drive 1012, input/output interface 1013, network interface 1014, memory 1020, bus 1030, etc., the device may include other components necessary to achieve proper operation in an implementation. Furthermore, it will be appreciated by those skilled in the art that the apparatus may include only the components necessary to implement the present application, and not all of the components shown in the drawings.

Fig. 12, among other things, illustrates an architecture of an electronic device, for example, device 1100 may be a mobile phone, a computer, a digital broadcast terminal, a messaging device, a game console, a tablet device, a medical device, an exercise device, a personal digital assistant, an aircraft, and so forth.

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

The processing component 1102 generally controls 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 part of the steps of the methods provided by the present disclosure. Further, the processing component 1102 can include one or more modules that facilitate interactions 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.

Memory 1104 is configured to store various types of data to support operations at device 1100. Examples of such data include instructions for any application or method operating on device 1100, contact data, phonebook data, messages, pictures, video, and the like. The memory 1104 may be implemented by any type or combination of volatile or nonvolatile 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 disk.

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

Multimedia component 1108 includes a screen between device 1100 and the user that provides an output interface. 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 input signals from a user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensor may sense not only the boundary of a touch or sliding action, but also the duration and pressure associated with the touch or sliding operation. In some embodiments, multimedia component 1108 includes a front camera and/or a rear camera. The front-facing camera and/or the rear-facing camera may receive external multimedia data when the device 1100 is in an operational 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 focal length and optical zoom capabilities.

The audio component 1110 is configured to output and/or input an audio signal. For example, the audio component 1110 includes a Microphone (MIC) configured to receive external audio signals when the device 1100 is in an operational mode, such as a call mode, a recording mode, and a voice recognition mode. The received audio signals may be further stored in the memory 1104 or transmitted via the communication component 1116. In some embodiments, the audio component 1110 further comprises 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: homepage button, volume button, start button, and lock button.

The sensor assembly 1114 includes one or more sensors for providing status assessment of various aspects of the device 1100. For example, the sensor assembly 1114 may detect an on/off state of the device 1100, a relative positioning of the components, such as a display and keypad of the device 1100, a change in position of the device 1100 or a component of the device 1100, the presence or absence of user contact with the device 1100, an orientation or acceleration/deceleration of the device 1100, and a change in temperature of the device 1100. The sensor assembly 1114 may include a proximity sensor configured to detect the presence of nearby objects in the absence of 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 gyroscopic sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

The communications component 1116 is configured to facilitate communication between the device 1100 and other devices, either wired or wireless. The device 1100 may access a wireless network based on a communication standard, such as WiFi,2G, or 3G, or a combination thereof. In one exemplary embodiment, the communication part 1116 receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component 1116 further includes a Near Field Communication (NFC) module to facilitate short range communication. 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, microcontrollers, microprocessors, or other electronic elements for executing the methods described above.

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

From the above description of embodiments, it will be apparent to those skilled in the art that the present application may be implemented in software plus a necessary general hardware platform. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art 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., including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method described in the embodiments or some parts of the embodiments of the present application.

In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for a system or system embodiment, since it is substantially similar to a method embodiment, the description is relatively simple, with reference to the description of the method embodiment being made in part. The systems and system embodiments described above are merely illustrative, wherein the elements illustrated as separate elements may or may not be physically separate, and the elements shown as elements may or may not be physical elements, may be located in one place, or may be distributed over a plurality of network elements. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment. Those of ordinary skill in the art will understand and implement the present invention without undue burden.

The task issuing processing method, device and electronic equipment provided by the application are described in detail, and specific examples are applied to illustrate the principle and implementation of the application, and the description of the above examples is only used for helping to understand the method and core ideas of the application; also, it is within the scope of the present application to be modified by those of ordinary skill in the art in light of the present teachings. In view of the foregoing, this description should not be construed as limiting the application.

Claims

1. An exception handling method, comprising:

obtaining abnormal configuration information respectively corresponding to at least one service called by the current application during order call completion from a service configuration center, wherein the abnormal configuration information corresponding to the service comprises identification information of the service and an abnormal processing rule matched with the service, and the abnormal processing rule is used for indicating to call at least one abnormal processing service set from the abnormal type of the service for the service;

determining the service in the application according to the identification information in the abnormal configuration information, and configuring the service by utilizing an abnormal processing rule in the abnormal configuration information;

When a certain service calls an abnormality of a certain abnormality type occurring in a certain slave service during completion of the order, an abnormality processing service set for the certain slave service is called for the certain service to execute abnormality processing on the order.

2. The method of claim 1, wherein the exception handling rules are specifically for indicating that at least one exception handling service set from an exception type of service is invoked under different merchant information for the service.

3. The method of claim 2, wherein the merchant information includes area information in which the merchant is located, channel information of the merchant sales items, and feature information of the merchant sales items.

4. The method of claim 2, wherein invoking an exception handling service set for a certain slave service to invoke the certain exception type of the certain slave service to perform exception handling for the order when the certain service invokes the certain slave service to raise an exception of the certain exception type during completion of the order comprises:

When a certain service calls an abnormality of a certain abnormality type occurring in a certain slave service during completion of the order, an abnormality processing service set for the certain slave service is called under current merchant information for the certain service to perform abnormality processing on the order.

5. The method of claim 2, wherein the exception handling rules are specifically for indicating that at least one exception handling service set from an exception type of service is invoked for the service under different merchant information and different user information.

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

Receiving an abnormal configuration information update notification for the current application, which is broadcasted by a service configuration center;

At least one updated abnormal configuration information for the current application is received from the service configuration center in response to the abnormal 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 updating abnormal configuration information;

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:

The method comprises the steps of receiving exception configuration information sent by at least one node and aiming at specific service when calling slave service, wherein the specific service is a service party for calling service, the exception configuration information of the specific service comprises identification information of the specific service and exception processing rules matched with the specific service, and the exception processing rules are used for indicating the specific service to call the exception processing service set by the exception type of at least one slave service;

Responsive to an application being started, determining abnormal configuration information corresponding to at least one specific service called by the application respectively;

and sending the abnormal configuration information corresponding to the at least one specific service 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 processing according to the return information after the slave service is called;

if the processing is abnormal processing, determining abnormal configuration information matched with the main service from at least one piece of abnormal configuration information corresponding to the main service calling the auxiliary service, wherein the abnormal configuration information comprises identification information of the main service and an abnormal processing rule matched with the main service, and the abnormal processing rule is used for indicating the calling of the abnormal processing service set by the abnormal type of the at least one auxiliary service for the main 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 abnormality processing 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.