Business processing method and device, electronic equipment and computer readable medium

Abstract

The invention discloses a business processing method and device, electronic equipment and a computer readable medium, and relates to the technical field of computers, one specific implementation mode comprises the steps that a section is called to carry out real-time service abnormal information monitoring, and under the condition that the service abnormal information is monitored, a service party identifier and abnormal order data corresponding to the service abnormal information are acquired; deleting corresponding identification data in the abnormal order data according to the service party identifier to obtain preprocessed data, and determining a packaging type according to the preprocessed data; performing classified packaging on the abnormal order data based on the packaging type to obtain packaging data; executing an exception retry program according to the encapsulated data, and determining an exception type in response to an exception retry failure; and calling and executing corresponding exception handling logic according to the exception type, responding to exception handling success, acquiring processing result data, and pushing the processing result data to a service party corresponding to the service party identifier. The order receiving verification capability of a service party can be improved, and the service processing failure rate is reduced.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a business processing method, device, electronic device and computer-readable medium. Background Art

[0002] At present, in the international logistics business scenario, companies similar to international logistics businesses do not have the basis for judging their delivery and fulfillment capabilities. In order to ensure the validity of merchants' orders, the system service process provided to merchants will synchronously call the last-mile service provider's system, relying on the last-mile service provider's order verification capabilities to ensure the validity of the documents issued by merchants. The different last-mile system service capability stability and the poor order verification capabilities of the last-mile service provider lead to a high business processing failure rate. Summary of the invention

[0003] In view of this, the embodiments of the present application provide a business processing method, device, electronic device and computer-readable medium, which can solve the existing problem of high failure rate when judging the merchant's performance ability.

[0004] To achieve the above objective, according to one aspect of an embodiment of the present application, a service processing method is provided, including:

[0005] Call the aspect to monitor service exception information in real time. When service exception information is detected, obtain the service provider ID and abnormal order data corresponding to the service exception information.

[0006] Deleting corresponding identification data in the abnormal order data according to the service provider identifier to obtain pre-processed data, and determining the packaging type according to the pre-processed data;

[0007] Classify and package abnormal order data based on packaging type to obtain packaging data;

[0008] executing an exception retry procedure according to the encapsulated data, and determining an exception type in response to an exception retry failure;

[0009] The corresponding exception handling logic is called and executed according to the exception type, and in response to successful exception handling, the processing result data is obtained and pushed to the service provider corresponding to the service provider identifier.

[0010] Optionally, determine the encapsulation type, including:

[0011] Input the preprocessed data into the classification model to output the corresponding classification type, calculate the similarity between the classification type and the preset abnormality type, and determine the preset abnormality type corresponding to the similarity greater than the preset threshold as the matching abnormality type, wherein the classification model is used to characterize the corresponding relationship between the preprocessed data and the classification type;

[0012] Identify the matching exception type as the encapsulation type.

[0013] Optionally, perform an exception retry procedure, including:

[0014] Calling and executing the data adjustment logic corresponding to the encapsulated data to obtain the adjustment data corresponding to the encapsulated data;

[0015] Based on the adjustment data, the abnormal retry procedure is executed a preset number of times.

[0016] Optionally, calling and executing corresponding exception handling logic according to the exception type, obtaining processing result data in response to successful exception handling, and pushing the processing result data to the service provider corresponding to the service provider identifier, including:

[0017] In response to the abnormality type being that the service abnormality time exceeds a threshold, obtaining accumulated contract performance verification information corresponding to the service provider identifier;

[0018] The abnormal order data is matched with the accumulated fulfillment verification information. In response to the match being successful, a successful order acceptance message is returned. In response to restoring the service of the service party corresponding to the service party identifier, the abnormal order data is asynchronously pushed to the service party corresponding to the service party identifier.

[0019] Optionally, calling and executing corresponding exception handling logic according to the exception type, obtaining processing result data in response to successful exception handling, and pushing the processing result data to the service provider corresponding to the service provider identifier, including:

[0020] In response to the exception type being exceeding the upper limit of the fulfillment contract, calling the splitting logic to split the abnormal order data according to the upper limit of the fulfillment contract to obtain split order data;

[0021] Push the split order data to the service provider corresponding to the service provider ID.

[0022] Optionally, call and execute corresponding exception handling logic according to the exception type, including:

[0023] In response to the exception type being exceeding the traffic limit, the waybill interface is asynchronously called to process the service exception information.

[0024] Optionally, call and execute corresponding exception handling logic according to the exception type, including:

[0025] In response to the exception type being that the service exception time exceeds a threshold, a fuse policy mechanism is executed, and then switching to a candidate service provider to provide business processing services.

[0026] In addition, the present application also provides a service processing device, including:

[0027] An acquisition unit is configured to call a slice to perform real-time service exception information monitoring, and when service exception information is detected, acquire a service provider identifier and abnormal order data corresponding to the service exception information;

[0028] The package type determination unit is configured to delete the corresponding identification data in the abnormal order data according to the service provider identifier to obtain pre-processed data, and determine the package type according to the pre-processed data;

[0029] The packaging unit is configured to classify and package the abnormal order data based on the packaging type to obtain packaging data;

[0030] an exception retry unit configured to execute an exception retry procedure according to the encapsulated data and determine an exception type in response to an exception retry failure;

[0031] The execution unit is configured to call and execute corresponding exception handling logic according to the exception type, obtain processing result data in response to successful exception handling, and push the processing result data to the service provider corresponding to the service provider identifier.

[0032] Optionally, the encapsulation type determination unit is further configured to:

[0033] Deleting identification data corresponding to the service provider identifier from the abnormal order data to obtain pre-processed data;

[0034] Input the preprocessed data into the classification model to output the corresponding classification type, calculate the similarity between the classification type and the preset abnormality type, and determine the corresponding preset abnormality type as the matching abnormality type when the similarity is greater than a preset threshold, wherein the classification model is used to characterize the corresponding relationship between the preprocessed data and the classification type;

[0035] Identify the matching exception type as the encapsulation type.

[0036] Optionally, the exception retry unit is further configured to:

[0037] Calling and executing the data adjustment logic corresponding to the encapsulated data to obtain the adjustment data corresponding to the encapsulated data;

[0038] Based on the adjustment data, the abnormal retry procedure is executed a preset number of times.

[0039] Optionally, the execution unit is further configured to:

[0040] In response to the abnormality type being that the service abnormality time exceeds a threshold, obtaining accumulated contract performance verification information corresponding to the service provider identifier;

[0041] The abnormal order data is matched with the accumulated fulfillment verification information. In response to the match being successful, a successful order acceptance message is returned. In response to restoring the service of the service party corresponding to the service party identifier, the abnormal order data is asynchronously pushed to the service party corresponding to the service party identifier.

[0042] Optionally, the execution unit is further configured to:

[0043] In response to the exception type being exceeding the upper limit of the fulfillment contract, calling the splitting logic to split the abnormal order data according to the upper limit of the fulfillment contract to obtain split order data;

[0044] Push the split order data to the service provider corresponding to the service provider ID.

[0045] Optionally, the execution unit is further configured to:

[0046] In response to the exception type being exceeding the traffic limit, the waybill interface is asynchronously called to process the service exception information.

[0047] Optionally, the execution unit is further configured to:

[0048] In response to the exception type being that the service exception time exceeds a threshold, a fuse policy mechanism is executed, and then switching to a candidate service provider to provide business processing services.

[0049] In addition, the present application also provides a business processing electronic device, including: one or more processors; a storage device for storing one or more programs, when the one or more programs are executed by one or more processors, the one or more processors implement the business processing method as described above.

[0050] In addition, the present application also provides a computer-readable medium on which a computer program is stored, and when the program is executed by a processor, the business processing method as described above is implemented.

[0051] One embodiment of the above invention has the following advantages or beneficial effects: the present application calls the aspect to monitor the service exception information in real time, and when the service exception information is monitored, obtains the service party identification and abnormal order data corresponding to the service exception information; deletes the corresponding identification data in the abnormal order data according to the service party identification to obtain preprocessing data, and classifies and encapsulates the abnormal order data based on the encapsulation type to obtain encapsulated data; executes the abnormal retry program according to the encapsulation data, and determines the abnormal type in response to the failure of the abnormal retry; calls and executes the corresponding exception handling logic according to the exception type, obtains the processing result data in response to the success of the exception handling, and pushes the processing result data to the service party corresponding to the service party identification. Thereby, the service party's order acceptance and verification capabilities can be improved and the failure rate of business processing can be reduced.

[0052] The further effects of the above-mentioned non-conventional optional manner will be described below in conjunction with the specific implementation manner. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] The accompanying drawings are used to better understand the present application and do not constitute an improper limitation on the present application.

[0054] Figure 1 It is a schematic diagram of the main process of a business processing method provided according to an embodiment of the present application;

[0055] Figure 2 It is a schematic diagram of the main process of a business processing method provided according to an embodiment of the present application;

[0056] Figure 3 This is a schematic diagram of an application scenario of a business processing method provided according to an embodiment of the present application;

[0057] Figure 4 is a schematic diagram of main units of a service processing device according to an embodiment of the present application;

[0058] Figure 5 is an exemplary system architecture diagram to which the embodiments of the present application can be applied;

[0059] Figure 6 It is a structural diagram of a computer system of a terminal device or server suitable for implementing an embodiment of the present application. DETAILED DESCRIPTION

[0060] The following is an explanation of the exemplary embodiments of the present application in conjunction with the accompanying drawings, including various details of the embodiments of the present application to facilitate understanding, which should be considered as merely exemplary. Therefore, those of ordinary skill in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present application. Similarly, for the sake of clarity and conciseness, the description of well-known functions and structures is omitted in the following description. It should be noted that in the technical solution of the present disclosure, the collection, collection, update, analysis, processing, use, transmission, storage and other aspects of user personal information involved are in compliance with the provisions of relevant laws and regulations, are used for legitimate purposes, and do not violate public order and good morals. Take necessary measures for user personal information to prevent illegal access to user personal information data and maintain user personal information security, network security and national security.

[0061] Figure 1 is a schematic diagram of the main process of a business processing method provided according to an embodiment of the present application, such as Figure 1 As shown, the business processing method includes:

[0062] Step S101, calling the aspect to perform real-time service exception information monitoring, and in the case of monitoring service exception information, obtaining the service provider identifier and abnormal order data corresponding to the service exception information.

[0063] In this embodiment, the execution subject of the business processing method (for example, a server) can detect whether the service exception information is received through a wired connection or a wireless connection. The execution subject can call the public component class to continuously collect the service information generated by the business processing through the aspect method, such as continuously collecting the records of each request failure, the time-consuming records of success, and the accurate core performance data, that is, the postal code of the province, city, and county. Monitor the service exception information from the service information.

[0064] For example, when the aspect monitors that an order fails, it can trigger the sending of service exception information. After receiving the service exception information, the execution subject can obtain the service provider identification and abnormal order data in the information. Among them, the service provider identification can be the account number or number of the last-mile service provider used for delivery fulfillment, etc. The embodiment of the present application does not specifically limit the service provider identification. Abnormal order data may, for example, include the user identification corresponding to the user who generated the abnormal order (for example, each order that failed to request), order type, place of shipment, destination, weight of items in the order, and other data. The embodiment of the present application does not specifically limit the abnormal order data.

[0065] Step S102, deleting the corresponding identification data in the abnormal order data according to the service provider identifier to obtain pre-processed data, and determining the packaging type according to the pre-processed data.

[0066] The identification data corresponding to the service provider's identifier is deleted from the abnormal order data to obtain preprocessed data, wherein the identification data may include, for example, the service provider's registered address information, radiation range information, name information, etc.

[0067] In an embodiment of the present application, the execution subject may perform secondary packaging on the error information, specifically, it may be to classify and package some error information of the service provider, shield the identification mark of the last-mile service provider, so as to obtain the pre-processed data corresponding to the error information. Determine the encapsulation type according to the classification type corresponding to the pre-processed data. The classification type corresponding to the pre-processed data may be, for example, error data, quality of service data, interface performance data, retry data, business push data, etc. For example, the corresponding encapsulation type may include error encapsulation type, quality of service encapsulation type, interface performance encapsulation type, retry encapsulation type, business encapsulation type, etc. The embodiment of the present application does not specifically limit the encapsulation type.

[0068] Specifically, determining the encapsulation type includes: inputting preprocessed data into a classification model to output a corresponding classification type, calculating the similarity between the classification type and a preset exception type, and determining the preset exception type corresponding to a similarity greater than a preset threshold as a matching exception type, wherein the classification model is used to characterize the correspondence between the preprocessed data and the classification type.

[0069] Delete the identification data corresponding to the service provider's identification from the abnormal order data to obtain preprocessed data, wherein the identification data may include, for example, the service provider's registered address information, radiation range information, name information, etc.; input the preprocessed data into the classification model to determine the corresponding classification type based on the probability score output by the decision tree in the classification model, calculate the similarity between the classification type and the preset abnormal type, and determine the preset abnormal type corresponding to the similarity greater than the preset threshold as the matching abnormal type, wherein the classification model is used to characterize the correspondence between the preprocessed data and the classification type; determine the matching abnormal type as the encapsulation type. In this way, the public component class encapsulated based on the determined encapsulation type can collect more accurate data when collecting abnormal data through the section method.

[0070] Step S103, classify and package the abnormal order data based on the packaging type to obtain packaging data.

[0071] The packaging type may be, for example, delivery weight overweight, delivery time overtime, delivery fee exceeding a preset threshold, etc. The present application embodiment does not specifically limit the packaging type. The execution subject may classify and package the corresponding abnormal order data according to the determined packaging type to obtain corresponding packaging data.

[0072] Step S104, executing an exception retry procedure according to the encapsulated data, and determining the exception type in response to an exception retry failure.

[0073] A three-level retry procedure is performed on the packaged data, where the three-level retry procedure includes three stages: level one: from the waybill center to the last-mile service provider; level two: from the international supply chain service platform (iFOP) to the waybill center; level three: from the merchant system to the international supply chain service platform (iFOP).

[0074] The three-level retry solution can effectively solve the problems of network anomalies and last-mile service system anomalies.

[0075] When the third-level retry procedure fails, determine the type of exception. For example, the exception type may include service exception time exceeding the threshold, overseas warehouse and distribution order acceptance time exceeding the upper limit of the contract, the last-mile service provider's traffic limit causing the merchant's instantaneous document failure, and individual last-mile service providers failing.

[0076] Step S105 , calling and executing corresponding exception handling logic according to the exception type, obtaining processing result data in response to successful exception handling, and pushing the processing result data to the service provider corresponding to the service provider identifier.

[0077] The processing result data may include, for example, the matching information between the abnormal order data and the accumulated fulfillment verification information and the corresponding abnormal order data. When the matching is successful, the execution subject may push the abnormal order data to the service provider corresponding to the service provider identifier for processing by the service provider. The data push method may be asynchronous push to reduce the service provider's business processing pressure.

[0078] Specifically, the corresponding exception handling logic is called and executed according to the exception type, and in response to successful exception handling, the processing result data is obtained, and the processing result data is pushed to the service party corresponding to the service party identifier, including: in response to the exception type being that the service exception time exceeds the threshold, the cumulative fulfillment verification information corresponding to the service party identifier is obtained; the abnormal order data is matched with the cumulative fulfillment verification information, and in response to the match being successful, an order success message is returned; in response to restoring the service of the service party corresponding to the service party identifier, the abnormal order data is asynchronously pushed to the service party corresponding to the service party identifier.

[0079] For example, a service provider overseas has a long-term service anomaly, which leads to the failure of the international logistics system to accept orders, seriously affecting the customer experience. The embodiment of the present application is based on the performance verification information accumulated by the current service provider in history, and matches the currently accumulated data. If the data validity is matched, the merchant system can be fed back that the order has been accepted successfully. After the service of the last-mile service provider is restored, the data is pushed to the last-mile service provider in an asynchronous manner.

[0080] This embodiment calls the aspect to monitor the service exception information in real time. When the service exception information is monitored, the service provider identification and abnormal order data corresponding to the service exception information are obtained; the corresponding identification data in the abnormal order data is deleted according to the service provider identification to obtain pre-processed data, and the abnormal order data is classified and packaged based on the encapsulation type to obtain encapsulated data; according to the encapsulated data, the abnormal retry program is executed, and in response to the failure of the abnormal retry, the abnormal type is determined; according to the abnormal type, the corresponding exception handling logic is called and executed, and in response to the success of the exception handling, the processing result data is obtained, and the processing result data is pushed to the service provider corresponding to the service provider identification. This can improve the service provider's order verification capability and reduce the failure rate of business processing.

[0081] Figure 2 is a main flow chart of a business processing method provided according to an embodiment of the present application, such as Figure 2 As shown, the business processing method includes:

[0082] Step S201, calling the aspect to perform real-time service exception information monitoring, and in the case of monitoring service exception information, obtaining the service provider identifier and abnormal order data corresponding to the service exception information.

[0083] When the aspect monitors that the service abnormality time exceeds the threshold or the order acceptance time of a section of overseas warehouse distribution exceeds the upper limit of the contract fulfillment or the traffic limit of the last-mile service provider causes the merchant's instantaneous document failure or the failure of individual last-mile service providers, the execution entity can monitor the service abnormality information. In the case of receiving service abnormality information, the execution entity can obtain the corresponding service provider identification and abnormal order information. The service provider identification can be the name or merchant identification of the merchant providing the service. The embodiment of the present application does not specifically limit the service provider identification. Abnormal order data may include, for example, the user identification corresponding to the user who generated the abnormal order (for example, each request failed), the order type, the place of shipment, the destination, the weight of the items in the order, and the identification data corresponding to the service provider identification. The embodiment of the present application does not specifically limit the abnormal order data.

[0084] Step S202, deleting the corresponding identification data in the abnormal order data according to the service provider identifier to obtain pre-processed data, and determining the packaging type according to the pre-processed data.

[0085] Data is cleaned according to the service provider's identification, and the corresponding identification data in the abnormal order data is deleted to obtain preprocessed data.

[0086] The identification data corresponding to the service provider identifier is deleted from the abnormal order data to obtain the pre-processed data M, wherein the identification data may include, for example, the service provider's registered address information, radiation range information, name information, etc.; the execution subject may obtain the historical order data S corresponding to the preset abnormal type, calculate the cosine similarity between the pre-processed data M and the historical order data S (which may include sub-historical order data such as S1, S2, S3, ..., Sn), and determine the preset abnormal type corresponding to the sub-historical order data (for example, Sn) corresponding to the largest cosine similarity as the matching abnormal type, that is, the encapsulation type.

[0087] Step S203, classify and package the abnormal order data based on the packaging type to obtain packaging data.

[0088] The encapsulated data may be different types of service abnormality information, such as error abnormality data, service quality abnormality data, interface performance abnormality data, retry abnormality data, business abnormality data, etc. The embodiment of the present application does not specifically limit the encapsulated data.

[0089] Step S204, calling and executing the data adjustment logic corresponding to the encapsulated data to obtain the adjustment data corresponding to the encapsulated data.

[0090] The adjustment data may be data that is repaired and adjusted accordingly based on the abnormal type of the packaged data that is initially checked.

[0091] Step S205 , executing a preset number of abnormal retry procedures based on the adjustment data.

[0092] The preset number of times is, for example, three times. The embodiments of the present application do not specifically limit the preset number of times. Based on the processing status data, execute the preset number of abnormal retry procedures. When the processing status data is a request failure, execute the three-level retry procedure. Among them, the three-level retry procedure includes three stages, the first level: the waybill center to the last-mile service provider stage; the second level: the international supply chain service platform (iFOP) to the waybill center stage; the third level: the merchant system to the international supply chain service platform (iFOP) stage.

[0093] Specifically, in the first level, from the waybill center to the last-leg service provider stage, based on the process of each production business requesting the last-leg service provider, a public component class is encapsulated through dynamic proxy technology, which continuously collects records of each failed request, successful time-consuming records, and accurate core fulfillment data, i.e., province, city, county, and postal codes, through aspects.

[0094] Based on the collected data, it provides: secondary packaging of error reports, TP99 retry basis, abnormal retry basis, service quality analysis, abnormal manual re-push and other data.

[0095] Among them, the secondary packaging of error reports: classify and package some error information of the service provider, shield the identification information of the service provider, and improve the coverage of abnormal data identification.

[0096] TP99 retry basis: Based on the T99 data of the past two weeks, the retry timeout is dynamically identified and set, mainly to avoid the risk of order failure due to instantaneous cross-border network jitter through multiple requests. Among them, TP99: within a period of time (for example, 5 minutes), the time consumed by each call of a method is counted, and these times are sorted from small to large, and the 99th value is taken as the TP99 value, which is the minimum consumption required to meet 99% of network requests.

[0097] Abnormal retry basis: The system automatically retries based on the service provider's error information. The error information may be, for example: Weare unable to process this request. Please try again later or contact FedEx Customer Service.

[0098] Service quality analysis: There are many regional service providers in the world whose systems are not very stable, are relatively small in scale, and have weak Internet technology capabilities. When international logistics evaluates their service quality, order failure records will be used as an evaluation basis.

[0099] Manual re-push due to exceptions: In some scenarios, business data is abnormal and R&D needs to manually adjust the data and re-push it.

[0100] Level 2: International Supply Chain Service Platform (iFOP) to Waybill Center Stage: After the first-level retry fails, some important merchant customers (i.e. KA merchant customers) do not rely on the order results and need to be pushed through the second-level retry mechanism.

[0101] Level 3: From merchant system to international logistics system: After the first-level retry fails, it contains other failure scenario data, provides customers with error status codes, and executes retry logic.

[0102] The three-level retry solution can effectively solve problems such as network anomalies and service system anomalies.

[0103] Step S206, in response to the abnormal retry failure, determining the abnormal type.

[0104] For example, exception types may include service exception time exceeding the threshold, overseas warehouse and distribution order acceptance time exceeding the fulfillment limit, last-mile service provider traffic restrictions resulting in merchant instantaneous document failure, and individual last-mile service provider failure.

[0105] Step S207, calling and executing the corresponding exception handling logic according to the exception type, and in response to the exception handling being successful, obtaining the processing result data, and pushing the processing result data to the service provider corresponding to the service provider identifier.

[0106] Specifically, the corresponding exception handling logic is called and executed according to the exception type, and in response to successful exception handling, the processing result data is obtained, and the processing result data is pushed to the service party corresponding to the service party identifier, including: in response to the exception type being exceeding the fulfillment limit, calling the splitting logic to split the abnormal order data according to the fulfillment limit to obtain split order data; pushing the split order data to the service party corresponding to the service party identifier.

[0107] For example, when accepting orders in overseas warehouse and distribution scenarios, the fulfillment limit is exceeded, resulting in the service provider accepting orders that exceed the fulfillment capacity. The execution entity can split multiple products into multiple packages for fulfillment. According to the fulfillment capacity limit, the order data is automatically adjusted to compliant data, so that the split order data meets the service provider's fulfillment capacity and improves the order success rate.

[0108] Specifically, the corresponding exception handling logic is called and executed according to the exception type, including: in response to the exception type being exceeding the traffic limit, asynchronously calling the waybill interface to perform service exception information processing.

[0109] For example, international last-mile service providers have traffic restrictions in some regions, such as a daily request limit of 10,000 and only 10 requests can be processed per minute. If the limit is exceeded, an error will be reported. Specifically, methods to reduce the pressure on the service provider interface may include: asynchronous processes to reduce the pressure on the service provider, and synchronous customer asynchronous processing. To improve the service provider interface capabilities, you can increase the load balancing during calls by horizontally expanding the service provider accounts (e.g., service provider account 1, service provider account 2, ..., service provider account n), thereby increasing the instantaneous request volume.

[0110] Specifically, the corresponding exception handling logic is called and executed according to the exception type, including: in response to the exception type being that the service exception time exceeds the threshold, executing the fuse policy mechanism, and then switching to the candidate service provider to provide business processing services.

[0111] For example, in the overseas market environment, there are many small and medium-sized service providers, and system service anomalies and regular maintenance often occur for consecutive days. Users have a very poor experience with these small and medium-sized service providers. The execution entity can be configured with an alternative service provider configuration module to automatically select multiple alternative service providers. When the service provider system is abnormal, configure the circuit breaker strategy mechanism, switch to another service provider and re-order, and improve the customer's order success rate.

[0112] Figure 3 This is a logical diagram of a three-level retry procedure of a business processing method provided in an embodiment of the present application. The business processing method of the embodiment of the present application can be applied to the last-mile service scenario. In the embodiment of the present application, the last-mile service is when the overseas warehouse receives the buyer's order and uses the overseas local logistics team to transport the goods to the consumer. Figure 3 As shown in the figure, the three-level retry procedure includes three stages: Level 1: from the waybill center to the final service provider; Level 2: from the international supply chain service platform (iFOP) to the waybill center; Level 3: from the merchant system to the international supply chain service platform (iFOP). International supply chain service platform (iFOP): a platform for connecting merchant systems. Waybill center: a waybill management system for international logistics. Final service provider: a local final service provider.

[0113] Specifically, in the first level, from the waybill center to the last-leg service provider (i.e., the service provider in this application), the waybill center synchronizes the service provider's order interface to the last-leg service provider system, and the last-leg service provider system returns the order result to the waybill center. Specifically, the order result may include request success data or request failure data. Based on the process of each production business request to the last-leg service provider, the embodiment of the present application encapsulates a common component class through dynamic proxy technology, and continuously collects the records of each request failure, the successful time-consuming records, and the accurate core performance data, i.e., the province, city, county, zip code, etc., through the aspect method.

[0114] Based on the collected data, it provides: secondary packaging of error reports, TP99 retry basis, abnormal retry basis, service quality analysis, abnormal manual re-push and other data.

[0115] Among them, the secondary packaging of error reports: classify and package some error information of the service provider, shield the identification information of the last-mile service provider, and improve the last-mile coverage.

[0116] TP99 retry basis: Based on the T99 data of the past two weeks, the retry timeout is dynamically identified and set, mainly to avoid the risk of order failure due to instantaneous cross-border network jitter through multiple requests. Among them, TP99: within a period of time (for example, 5 minutes), the time consumed by each call of a method is counted, and these times are sorted from small to large, and the 99th value is taken as the TP99 value, which is the minimum consumption required to meet 99% of network requests.

[0117] Abnormal retry basis: The system automatically retries based on the error information of the last-mile service provider. The error message may be, for example: We are unable to process this request. Please try again later or contact FedEx Customer Service.

[0118] Service quality analysis: There are many regional service providers in the world whose systems are not very stable, are relatively small in scale, and have weak IT capabilities. When international logistics evaluates their service quality, order failure records will be used as an evaluation basis.

[0119] Manual re-push due to exceptions: In some scenarios, business data is abnormal and R&D needs to manually adjust the data and re-push it.

[0120] Level 2: International Supply Chain Service Platform (iFOP) in the system service (intranet) to the waybill center stage: iFOP synchronously calls the waybill interface to the waybill center, and the waybill center returns the order result to iFOP, that is, the first-level retry result, which can be a first-level retry success or a first-level retry failure. After the first-level retry fails, some important merchant customers (i.e., KA merchant customers) do not rely on the order result and need to be pushed through the second-level retry mechanism.

[0121] Level 3: From the merchant system (i.e., the merchant system) to the international logistics system (i.e., the system where the iFOP International Supply Chain Service Platform (iFOP) is located): When a shopping customer creates a warehouse and distribution order with the merchant system, the merchant system calls the order interface to iFOP, and iFOP returns the order result to the merchant system (for example, it may include the first-level retry result and / or the second-level retry result). After the first-level retry fails, it includes other failure scenario data, provides the customer with an error status code, and executes the retry logic.

[0122] The three-level retry solution can effectively solve problems such as network anomalies and last-mile service system anomalies. In the embodiment of the present application, through the business traffic of the production environment, the execution entity automatically precipitates and accumulates accurate performance data, including: four-level addresses, postal code rules, carrier performance capacity range and other core data. Based on this data, the learning ability of the system is continuously improved, the accuracy of recognition is improved, and the international logistics performance recognition capability is established at low cost. In the golden process of placing orders, multiple methods such as three-level retries, asynchronous degradation, traffic load, and horizontal account expansion are added to improve the success rate of international logistics orders and improve user experience.

[0123] Figure 4 Schematic diagram of the main units of the service processing device according to an embodiment of the present application. Figure 4 As shown, the service processing device 400 includes an acquisition unit 401 , an encapsulation type determination unit 402 , an encapsulation unit 403 , an abnormal retry unit 404 and an execution unit 405 .

[0124] The acquisition unit 401 is configured to call the aspect to perform real-time service abnormality information monitoring, and when the service abnormality information is monitored, obtain the service provider identifier and abnormal order data corresponding to the service abnormality information;

[0125] The encapsulation type determination unit 402 is configured to delete the corresponding identification data in the abnormal order data according to the service provider identifier to obtain pre-processed data, and determine the encapsulation type according to the pre-processed data;

[0126] The encapsulation unit 403 is configured to classify and encapsulate the abnormal order data based on the encapsulation type to obtain encapsulated data;

[0127] The exception retry unit 404 is configured to execute an exception retry procedure according to the encapsulated data and determine the exception type in response to the exception retry failure;

[0128] The execution unit 405 is configured to call and execute the corresponding exception handling logic according to the exception type, obtain the processing result data in response to the exception handling being successful, and push the processing result data to the service provider corresponding to the service provider identifier.

[0129] In some embodiments, the encapsulation type determination unit 402 is further configured to input the preprocessed data into the classification model to output the corresponding classification type, calculate the similarity between the classification type and the preset exception type, and determine the preset exception type corresponding to the similarity greater than a preset threshold as a matching exception type, wherein the classification model is used to characterize the correspondence between the preprocessed data and the classification type; and determine the matching exception type as the encapsulation type.

[0130] In some embodiments, the abnormal retry unit 404 is further configured to: call and execute data adjustment logic corresponding to the encapsulated data to obtain adjustment data corresponding to the encapsulated data; and execute an abnormal retry procedure for a preset number of times based on the adjustment data.

[0131] In some embodiments, the execution unit 405 is further configured to: in response to the exception type being that the service exception time exceeds a threshold, obtain the cumulative fulfillment verification information corresponding to the service party identifier; match the abnormal order data with the cumulative fulfillment verification information, and in response to a successful match, return order success information; in response to restoring the service of the service party corresponding to the service party identifier, asynchronously push the abnormal order data to the service party corresponding to the service party identifier.

[0132] In some embodiments, the execution unit 405 is further configured to: in response to the exception type being exceeding the fulfillment limit, call the splitting logic to split the abnormal order data according to the fulfillment limit to obtain split order data; and push the split order data to the service party corresponding to the service party identifier.

[0133] In some embodiments, the execution unit 405 is further configured to: in response to the exception type being exceeding the traffic limit, asynchronously call the waybill interface to perform service exception information processing.

[0134] In some embodiments, the execution unit 405 is further configured to: in response to the exception type being that the service exception time exceeds a threshold, execute a fuse policy mechanism, and then switch to a candidate service provider to provide business processing services.

[0135] It should be noted that the business processing method and the business processing device of the present application have a corresponding relationship in terms of specific implementation content, so the repeated content will not be described again.

[0136] Figure 5 An exemplary system architecture 500 is shown to which the service processing method or service processing device according to the embodiment of the present application can be applied.

[0137] like Figure 5 As shown, system architecture 500 may include terminal devices 501, 502, 503, a network 504 and a server 505. Network 504 is used to provide a medium for communication links between terminal devices 501, 502, 503 and server 505. Network 504 may include various connection types, such as wired, wireless communication links or optical fiber cables, etc.

[0138] Users can use terminal devices 501, 502, 503 to interact with server 505 through network 504 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 501, 502, 503, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, etc. (only as examples).

[0139] The terminal devices 501, 502, 503 may be various electronic devices having a service processing screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop computers, desktop computers, and the like.

[0140] Server 505 can be a server that provides various services, such as a background management server that provides support for service exception information received by users using terminal devices 501, 502, and 503 (only as an example). The background management server calls the aspect to monitor real-time service exception information. When service exception information is detected, the service provider identifier and abnormal order data corresponding to the service exception information are obtained; the corresponding identification data in the abnormal order data is deleted according to the service provider identifier to obtain pre-processing data, and the encapsulation type is determined according to the pre-processing data; the abnormal order data is classified and encapsulated based on the encapsulation type to obtain encapsulation data; according to the encapsulation data, the abnormal retry program is executed, and the abnormal type is determined in response to the failure of the abnormal retry; according to the abnormal type, the corresponding exception handling logic is called and executed, and in response to the success of the abnormal handling, the processing result data is obtained, and the processing result data is pushed to the service provider corresponding to the service provider identifier. Thereby, the service provider's order verification capability can be improved and the failure rate of business processing can be reduced.

[0141] It should be noted that the business processing method provided in the embodiment of the present application is generally executed by the server 505 , and accordingly, the business processing device is generally set in the server 505 .

[0142] It should be understood that Figure 5 The number of terminal devices, networks and servers in the embodiment is only for illustration. Any number of terminal devices, networks and servers may be provided according to implementation requirements.

[0143] Reference below Figure 6 , which shows a schematic diagram of the structure of a computer system 600 of a terminal device suitable for implementing an embodiment of the present application. Figure 6 The terminal device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0144] like Figure 6As shown, the computer system 600 includes a central processing unit (CPU) 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage part 608 into a random access memory (RAM) 603. In the RAM 603, various programs and data required for the operation of the computer system 600 are also stored. The CPU 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0145] The following components are connected to the I / O interface 605: an input section 606 including a keyboard, a mouse, etc.; an output section 607 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, a modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the I / O interface 605 as needed. A removable medium 611, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 610 as needed, so that a computer program read therefrom is installed into the storage section 608 as needed.

[0146] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 609, and / or installed from the removable medium 611. When the computer program is executed by the central processing unit (CPU) 601, the above-mentioned functions defined in the system of the present application are executed.

[0147] It should be noted that the computer-readable medium shown in the present application may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. Computer-readable storage media may include, for example, but are not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device. In the present application, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, in which a computer-readable program code is carried. This propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, optical cable, RF, etc., or any suitable combination of the above.

[0148] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the above-mentioned module, program segment or a part of a code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flow chart, and the combination of the boxes in the block diagram or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0149] The units involved in the embodiments described in the present application may be implemented by software or hardware. The units described may also be set in a processor, for example, it may be described as: a processor includes an acquisition unit, a package type determination unit, a package unit, an abnormal retry unit, and an execution unit. The names of these units do not constitute limitations on the units themselves in some cases.

[0150] As another aspect, the present application also provides a computer-readable medium, which may be included in the device described in the above embodiment; or it may exist independently and not be assembled into the device. The above computer-readable medium carries one or more programs. When the above one or more programs are executed by a device, the device calls the aspect to perform real-time service exception information monitoring. When the service exception information is monitored, the service provider identification and abnormal order data corresponding to the service exception information are obtained; the corresponding identification data in the abnormal order data is deleted according to the service provider identification to obtain preprocessing data, and the encapsulation type is determined according to the preprocessing data; the abnormal order data is classified and encapsulated based on the encapsulation type to obtain encapsulation data; according to the encapsulation data, the abnormal retry program is executed, and the abnormal type is determined in response to the failure of the abnormal retry; according to the abnormal type, the corresponding exception handling logic is called and executed, and in response to the success of the abnormal handling, the processing result data is obtained, and the processing result data is pushed to the service provider corresponding to the service provider identification.

[0151] According to the technical solution of the embodiment of the present application, the order verification capability of the service provider can be improved and the business processing failure rate can be reduced.

[0152] The above specific implementations do not constitute a limitation on the protection scope of this application. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may occur depending on design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of this application should be included in the protection scope of this application.

Claims

1. A business processing method, characterized in that: include: Call the aspect to monitor service exception information in real time, and when service exception information is detected, obtain the service provider identifier and abnormal order data corresponding to the service exception information; Deleting corresponding identification data in the abnormal order data according to the service provider identifier to obtain pre-processed data, and determining a packaging type according to the pre-processed data; Classify and package the abnormal order data based on the packaging type to obtain packaging data; executing an exception retry procedure according to the encapsulated data, and determining an exception type in response to an exception retry failure; The corresponding exception handling logic is called and executed according to the exception type, and in response to successful exception handling, processing result data is obtained, and the processing result data is pushed to the service party corresponding to the service party identifier.

2. The method according to claim 1, characterized in that The determining of the encapsulation type includes: Input the preprocessed data into a classification model to output a corresponding classification type, calculate the similarity between the classification type and a preset abnormality type, and determine the preset abnormality type corresponding to a similarity greater than a preset threshold as a matching abnormality type, wherein the classification model is used to characterize the corresponding relationship between the preprocessed data and the classification type; The matching exception type is determined as an encapsulation type.

3. The method according to claim 1, characterized in that The execution of the abnormal retry procedure includes: Calling and executing the data adjustment logic corresponding to the encapsulated data to obtain the adjustment data corresponding to the encapsulated data; Based on the adjustment data, a preset number of abnormal retry procedures are performed.

4. The method according to claim 1, characterized in that The calling and executing corresponding exception handling logic according to the exception type, obtaining processing result data in response to successful exception handling, and pushing the processing result data to the service party corresponding to the service party identifier includes: In response to the abnormality type being that the service abnormality time exceeds a threshold, acquiring accumulated contract performance verification information corresponding to the service provider identifier; The abnormal order data is matched with the accumulated fulfillment verification information, and in response to the match being successful, order success information is returned. In response to restoring the service of the service party corresponding to the service party identifier, the abnormal order data is asynchronously pushed to the service party corresponding to the service party identifier.

5. The method according to claim 1, characterized in that The calling and executing corresponding exception handling logic according to the exception type, obtaining processing result data in response to successful exception handling, and pushing the processing result data to the service party corresponding to the service party identifier includes: In response to the exception type being exceeding the upper limit of the fulfillment contract, calling a splitting logic to split the abnormal order data according to the upper limit of the fulfillment contract to obtain split order data; Push the split order data to the service provider corresponding to the service provider identifier.

6. The method according to claim 1, characterized in that The calling and executing corresponding exception handling logic according to the exception type includes: In response to the exception type being exceeding the traffic limit, an asynchronous call to the waybill interface is performed to process service exception information.

7. The method according to claim 1, characterized in that The calling and executing corresponding exception handling logic according to the exception type includes: In response to the abnormality type being that the service abnormality time exceeds a threshold, a fuse policy mechanism is executed, and then switching to a candidate service provider to provide business processing services.

8. A service processing device, characterized in that: include: An acquisition unit is configured to call a slice to perform real-time service exception information monitoring, and when service exception information is monitored, acquire a service provider identifier and abnormal order data corresponding to the service exception information; A package type determination unit is configured to delete corresponding identification data in the abnormal order data according to the service provider identifier to obtain pre-processed data, and determine the package type according to the pre-processed data; a packaging unit configured to classify and package the abnormal order data based on the packaging type to obtain packaging data; an exception retry unit configured to execute an exception retry procedure according to the encapsulated data and determine an exception type in response to an exception retry failure; The execution unit is configured to call and execute corresponding exception handling logic according to the exception type, obtain processing result data in response to successful exception handling, and push the processing result data to the service party corresponding to the service party identifier.

9. The device according to claim 8, characterized in that The encapsulation type determination unit is further configured to: Input the preprocessed data into a classification model to output a corresponding classification type, calculate the similarity between the classification type and a preset abnormality type, and determine the preset abnormality type corresponding to a similarity greater than a preset threshold as a matching abnormality type, wherein the classification model is used to characterize the corresponding relationship between the preprocessed data and the classification type; The matching exception type is determined as an encapsulation type.

10. The device according to claim 8, characterized in that The abnormal retry unit is further configured to: Calling and executing the data adjustment logic corresponding to the encapsulated data to obtain the adjustment data corresponding to the encapsulated data; Based on the adjustment data, a preset number of abnormal retry procedures are performed.

11. A business processing electronic device, characterized in that: include: one or more processors; a storage device for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 7.

12. A computer readable medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

Images