An order management system, an order dispatching method, a device and a storage medium

Abstract

Embodiments of the present application provide an order management system, an order dispatching method, equipment and a storage medium. In the embodiments of the present application, the processes of "order receiving" and "order dispatching" of to-be-processed orders are decoupled, and the order management system is divided into a business system responsible for order receiving and a fulfillment system responsible for order dispatching. The to-be-processed orders are dispatched by the fulfillment system, and the fulfillment system and the business system are asynchronously interacted through the dispatching result. The business system no longer needs to query order information through a system call mode, that is, the business system no longer needs to wait online for the fulfillment system to feed back the dispatching result. This can effectively avoid dispatching failure caused by system call timeout, and improve the stability of dispatching. Moreover, the fulfillment system stores the received order information into an order queue first, and then dispatches the to-be-processed orders in the order queue according to dispatching scheduling logic. Asynchronous dispatching can be implemented, and the stability of dispatching is further improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an order management system, order dispatching method, device and storage medium. Background Technology

[0002] Order dispatch refers to the process by which a service platform automatically assigns orders to specific service providers (such as merchants or domestic service personnel), and the service providers provide corresponding services to the users who place orders based on the dispatched tasks.

[0003] Currently, the service platform processes orders according to a pre-defined dispatch logic after the user completes payment. This dispatch process includes: querying order information, recalling, sorting, and selecting service providers, and finally assigning the order to the selected service provider. This dispatch method can be called synchronous dispatch. However, querying order information involves system calls. If these system calls time out, dispatch will fail, causing instability in the dispatch process. Summary of the Invention

[0004] This application provides an order management system, order dispatching method, device, and storage medium to improve the stability of order dispatching.

[0005] This application provides an order management system that decouples order collection and order dispatch. The order management system includes a business system responsible for order collection and a fulfillment system responsible for order dispatch.

[0006] The business system is used to receive pending orders submitted by users and send dispatch requests to the fulfillment system in an asynchronous manner. The dispatch request includes the order information of the pending orders.

[0007] The fulfillment system is configured to receive order dispatch requests sent asynchronously by the business system; add the order information of the pending orders to the order queue of the fulfillment system, and dispatch the pending orders in the order queue according to the order dispatching logic; take the currently dispatched pending order as the target order, determine the order type of the target order according to the order information of the target order, and dispatch the target order according to the order dispatching logic corresponding to the order type; and return the dispatching result of the target order to the business system asynchronously.

[0008] The business system is also used to notify the order-placing user of the order dispatch result by modifying the order status of the target order based on the dispatch result returned by the fulfillment system.

[0009] This application provides an order dispatching method applicable to the fulfillment system responsible for order dispatching in an order management system. The order management system decouples order receiving and order dispatching, and also includes a business system responsible for order receiving. The order dispatching method includes:

[0010] Receive an order dispatch request sent by the business system in an asynchronous request manner, wherein the order dispatch request includes order information of the order to be processed;

[0011] The order information of the pending orders is added to the order queue of the fulfillment system, and the pending orders in the order queue are dispatched and scheduled according to the dispatching logic.

[0012] The currently scheduled pending order is taken as the target order. The order type of the target order is determined according to the order information of the target order. The target order is then dispatched according to the dispatch logic corresponding to the order type.

[0013] The system returns the order assignment result of the target order to the business system in an asynchronous response manner, so that the business system can notify the ordering user of the order assignment result by modifying the order status of the target order.

[0014] This application also provides a computing device, including: a memory, a processor, and a communication component;

[0015] The memory is used to store one or more computer instructions;

[0016] The processor is coupled to the memory and the communication component to execute one or more computer instructions for performing the aforementioned dispatching method.

[0017] This application also provides a computer-readable storage medium for storing computer instructions, which, when executed by one or more processors, cause the one or more processors to perform the aforementioned dispatching method.

[0018] This application also provides a computer program product, including a computer program; when the computer program is executed by a processor, it causes the processor to execute the aforementioned dispatching method.

[0019] In this embodiment, the order management system is divided into a business system responsible for receiving orders and a fulfillment system responsible for dispatching orders. The fulfillment system receives dispatch requests sent asynchronously by the business system, adds the order information of the pending orders carried in the dispatch request to the order queue, and dispatches the pending orders in the order queue according to the dispatch scheduling logic; it takes the currently dispatched pending order as the target order, processes the target order according to the dispatch logic corresponding to the order type of the target order, and returns the dispatch result of the target order to the business system in an asynchronous response manner, so that the business system can notify the user of the dispatch result by modifying the order status of the target order. In this way, for any pending order, the "receiving" and "dispatching" of the pending order are decoupled. The fulfillment system dispatches the pending order and interacts asynchronously with the business system through the dispatch result. The business system no longer needs to query order information through system calls, which can effectively avoid dispatch failures caused by system call timeouts and improve the stability of dispatching. Furthermore, the fulfillment system first stores the received order information into the order queue, and then dispatches the pending orders in the order queue according to the dispatching logic, which can realize asynchronous dispatching and thus further improve the stability of dispatching. Attached Figure Description

[0020] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0021] Figure 1 A schematic diagram of the structure of an order management system provided for an exemplary embodiment of this application;

[0022] Figure 2 A schematic diagram of a dispatching logic provided for an exemplary embodiment of this application;

[0023] Figure 3 A schematic diagram of a dispatching application scenario provided as an exemplary embodiment of this application;

[0024] Figure 4 A flowchart illustrating a dispatching method provided for another exemplary embodiment of this application;

[0025] Figure 5 This is a schematic diagram of the structure of a computing device provided as another exemplary embodiment of this application. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0027] As mentioned earlier, order dispatch usually refers to the process by which a service platform or system automatically assigns orders or tasks to suitable service providers (such as merchants or domestic service personnel) based on task requirements. The service providers then provide corresponding services to the users who place orders based on the dispatched tasks they receive.

[0028] Currently, service platforms that execute order dispatch typically, upon receiving an order dispatch request for an pending order, recall available service providers according to a pre-defined dispatch logic, and then select the final service provider from the recalled providers to assign to the pending order. The process of recalling available service providers and selecting the final service provider involves a significant amount of calculation, which may prolong the time required to determine the final service provider. If the order dispatch request does not receive a dispatch result within the specified time, it will cause platform call timeouts, leading to order dispatch failures and instability.

[0029] To improve this situation, this embodiment proposes an order management scheme that divides the service platform used for order dispatching in the traditional solution into a business system responsible for receiving orders and a fulfillment system responsible for dispatching orders. This decouples the "order receiving" and "order dispatching" processes, eliminating the need to wait online for dispatching results after order receiving. By asynchronously executing the interaction between order receiving and dispatching, and by asynchronously dispatching orders, order dispatching failures due to call timeouts or calculation timeouts can be avoided, thus improving the stability of order dispatching.

[0030] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0031] Figure 1 This is a schematic diagram of the structure of an order management system provided for an exemplary embodiment of this application. For example... Figure 1 As shown, the system includes a business system and a fulfillment system. The business system is responsible for receiving orders, and the fulfillment system is responsible for dispatching orders. A communication connection is established between the business system and the fulfillment system, which can be a wired or wireless network. Generally, the business system and the fulfillment system can be located within the same local area network or on different networks, connected via the Internet.

[0032] The order management system provided in this embodiment can be applied to various order dispatch scenarios that require assigning service providers to orders, such as assigning domestic service personnel to users who place orders or assigning delivery personnel to food delivery orders. This embodiment does not limit the application scenarios.

[0033] refer to Figure 1 For the business system, it can receive pending orders submitted by users and send dispatch requests to the fulfillment system asynchronously. The dispatch request includes the order information of the pending order. Pending orders refer to orders without assigned service providers, and the order information may include, but is not limited to, order time, order location, and service category. Asynchronous requests allow the business system to send requests to and receive responses from the fulfillment system without blocking the main thread, and can continue executing other tasks or operations without waiting for the fulfillment system's response. Before sending a dispatch request to the fulfillment system, the pending order can be validated to determine if it is an order eligible for dispatch. If the validation passes, a dispatch request is sent to the fulfillment system; if the validation fails, the order is reported as unavailable to the user, and a refund is issued.

[0034] For the fulfillment system, it can receive order dispatch requests sent asynchronously by the business system. Upon receiving each request, it immediately sends a signal to the business system indicating successful receipt. Then, it can parse the order information of the pending orders from the dispatch request, add this information to the fulfillment system's order queue, and dispatch the pending orders according to the dispatch scheduling logic. However, the fulfillment system does not immediately execute the dispatch scheduling logic after adding the order information to the order queue; instead, it needs to consider the current system processing capacity and reasonably control the number of concurrently executed tasks to avoid system overload.

[0035] In this embodiment, the order dispatching logic can be based on the request order of pending orders and the order priority corresponding to each pending order. For example, the fulfillment system can dispatch pending orders in the message queue sequentially according to the order order in the order queue; or, the business system can mark the order priority of pending orders according to actual business needs and carry the order priority in the order information so that the fulfillment system can dispatch pending orders according to the order priority in the order information. The business needs affecting order priority may include, but are not limited to, the user ordering platform, the order scenario, and the service provider type.

[0036] Based on this, the currently scheduled pending orders can be used as target orders; that is, the pending orders being dispatched can be used as target orders. As mentioned earlier, the fulfillment system can execute multiple tasks concurrently. This means the fulfillment system can dispatch multiple target orders simultaneously. The dispatching logic for these target orders is the same. The following explanation uses a single target order as an example to illustrate the dispatching process.

[0037] Continue to refer to Figure 1The system can extract the order information of the target order from the order queue, determine the order type of the target order based on the order information, and process the target order according to the dispatch logic corresponding to the order type to generate the dispatch result of the target order. The fulfillment system integrates dispatch logic corresponding to various order types, which may include, but are not limited to, distribution dispatch, stored value priority dispatch, designated merchant dispatch, black-box dispatch to merchants, and direct dispatch of service personnel.

[0038] After retrieving the target order's information from the order queue according to the dispatching logic, the fulfillment system can identify the order type based on the order information and dispatch the target order according to the pre-defined dispatching logic for that order type, generating a dispatching result. Subsequently, the dispatching result can be asynchronously returned to the business system, allowing the business system to notify the ordering user of the dispatching result by modifying the target order's order status. The order status may include dispatching progress, service provider information, and dispatching time.

[0039] For the business system, after receiving the successful receipt request signal from the fulfillment system, the dispatch progress of the target order can be changed from "order placed" to "dispatching". After receiving the dispatch result from the fulfillment system, the target order can be assigned to the corresponding target service provider according to the dispatch result, and the dispatch progress of the target order can be changed from "dispatching" to "dispatched". The target service provider information can be added to the order status of the target order. The target service provider information includes, but is not limited to, name, order number, contact number, service time, etc.

[0040] Optionally, the order management system may also include an order system for maintaining orders. This order system can directly interact with users. After a user submits an order on the order system, the order system generates pending orders and order information, and provides these to the business system. The business system then requests the fulfillment system to dispatch the pending order based on the order information. After the fulfillment system sends the dispatch result for the pending order to the business system, the business system can assign the target order to the corresponding target service provider according to the dispatch result and send order modification information for the target order to the order system. Upon receiving the order modification information, the order system can modify the order status of the target order accordingly.

[0041] In practical applications, through the interaction between the order system and the business system, orders can be dispatched promptly after a user places an order, and order information can be updated in a timely manner after dispatching, so that users can know the latest status of their orders in a timely manner, which can improve the user experience.

[0042] In this embodiment, the system can monitor whether there are any pending orders in the order queue. If so, the pending orders are processed for re-dispatch. Pending orders refer to orders that have timed out but have not yet been successfully dispatched. Timeout here refers to exceeding a preset order processing time, which can be set by the fulfillment system or by the business system. The monitoring of the order queue can be real-time or periodic, for example, once per hour. Furthermore, the process of re-dispatching pending orders is the same as the process of dispatching pending orders; specific technical details can be found in the previous description of dispatching pending orders, and will not be repeated here.

[0043] By establishing a re-dispatch mechanism in the fulfillment system, orders that have been stuck in the order queue for a long time can be identified in a timely manner and re-dispatched promptly, avoiding missed dispatches, ensuring the stability of dispatch, and improving user experience.

[0044] Accordingly, in this embodiment, the order management system is divided into a business system responsible for receiving orders and a fulfillment system responsible for dispatching orders. The fulfillment system receives dispatch requests sent asynchronously by the business system, adds the order information of the pending orders carried in the dispatch request to the order queue, and dispatches the pending orders in the order queue according to the dispatch scheduling logic; it takes the currently dispatched pending order as the target order, processes the target order according to the dispatch logic corresponding to the order type of the target order, and returns the dispatch result of the target order to the business system in an asynchronous response manner, so that the business system can notify the user of the dispatch result by modifying the order status of the target order. In this way, by decoupling the "receiving" and "dispatching" of pending orders, the fulfillment system uniformly dispatches pending orders and interacts asynchronously with the business system through the dispatch result. The business system no longer needs to wait online for the dispatch result from the fulfillment system, nor does it need to query order information through system calls. This effectively avoids dispatch failures caused by system call timeouts and improves the stability of dispatching. Furthermore, the fulfillment system first stores the received order information into the order queue, and then dispatches the pending orders in the order queue according to the dispatching logic, which can realize asynchronous dispatching and thus further improve the stability of dispatching.

[0045] In the above or below embodiments, the fulfillment system may use various implementation methods to dispatch target orders according to the dispatch logic corresponding to the order type.

[0046] In one optional implementation, multiple dispatch sub-logics can be parsed from the dispatch logic corresponding to the order type. These dispatch sub-logics include service provider recall, service provider selection, and service provider allocation. The service provider recall sub-logic can be executed to retrieve available service providers that are idle and capable of accepting the target order from the service provider management system. The service provider selection sub-logic can be executed to retrieve the service characteristics of available service providers from the service provider profiling system. Based on the service characteristics of available service providers, candidate service providers are selected. The service provider allocation sub-logic can be executed to select the target service provider from the candidate service providers and allocate the target order to the target service provider.

[0047] In this optional implementation, the purpose of the order dispatch logic is to determine the corresponding target service provider for the target order. The service provider can be understood as a merchant or service personnel who provides corresponding services to the user who submitted the target order. Different order types have different order dispatch requirements. For example, when the order type is "direct dispatch to service personnel," only the service personnel dimension needs to be considered. When the order type is "stored value priority dispatch," in addition to considering the service provider dimension, the user's stored value dimension also needs to be considered. Therefore, different order dispatch logic is configured for different order types.

[0048] Each dispatching logic consists of multiple steps; therefore, each dispatching logic contains multiple dispatching sub-logics. Different dispatching sub-logics describe different steps in the dispatching process. These sub-logics include, but are not limited to, service provider recall sub-logics, service provider selection sub-logics, and service provider allocation sub-logics. The service provider recall sub-logic is used to filter out a subset of available service providers from a massive pool that can provide services for the target order. The selection sub-logic is used to further select candidate service providers suitable for the target order from the selected available service providers. The allocation sub-logic is used to determine the final target service provider to be assigned to the target order from the previously selected candidate service providers. In this way, through layer-by-layer filtering, the most suitable service provider can be selected for the target order.

[0049] Figure 2 This is a schematic diagram illustrating the structure of a dispatching logic provided for an exemplary embodiment of this application. For example... Figure 2 As shown, the fulfillment system also establishes communication connections with the service provider management system and the service provider profiling system. The service provider management system provides the fulfillment system with available service providers that are idle and capable of accepting the target order, and modifies the status information of the target service provider to a non-idle state according to the status modification information sent by the business system. The service provider profiling system provides the fulfillment system with the service characteristics of available service providers.

[0050] refer to Figure 2The fulfillment system can execute a service provider recall sub-logic to retrieve available service providers that are idle and capable of accepting the target order from the service provider management system. The service provider management system can contain service provider information for all service providers, including merchants and service personnel. Service provider information can include merchant name, service personnel name, service status, service location, service type, and service items. When the fulfillment system executes the service provider recall sub-logic, it can send a recall request to the service provider management system. Upon receiving the recall request, the service provider management system can query the service status of each service provider in its stored service provider information. Service status can be "working," "idle," "vacation," or "muted," etc. It first filters out service providers whose service status is idle, and then, based on the order information of the target order carried in the recall request, combined with the service location, service type, and service items of each service provider, it filters out service providers from the idle service providers who match the target order as available service providers capable of accepting the target order. It should be noted that in this embodiment, different service provider management systems can be built for different service providers, or the service provider information of multiple service providers can be stored in the same service provider management system. This embodiment does not impose any limitations on this.

[0051] Based on this, the fulfillment system can execute the service provider selection sub-logic to obtain the service characteristics of available service providers from the service provider profiling system, and select candidate service providers based on these characteristics. The service provider profiling system contains service characteristics corresponding to different service providers. These characteristics describe the service performance of service providers from different dimensions, including but not limited to service level, service rate, dispatch rate, ratings, and complaint rate. Furthermore, the service provider profiling system stores different types of service providers in partitioned storage, such as partitioning the service characteristics of merchants and service personnel, to facilitate service characteristic retrieval. The fulfillment system can send the service information of available service providers obtained through the recall sub-logic to the service provider profiling system, allowing the system to query the service characteristics of available service providers based on the service information and return the corresponding service characteristics of each available service provider to the fulfillment system. The fulfillment system can then further filter candidate service providers from among the numerous available service providers based on the mapping relationship between available service providers and service characteristics.

[0052] In this optional implementation, multiple implementation schemes can be used to select candidate service providers from available service providers.

[0053] Preferably, the dispatch structure corresponding to the order type can be obtained according to the order type of the target order. The dispatch structure includes multiple filtering layers, each with feature filtering conditions associated with service characteristics. The multiple filtering layers are sorted according to their respective priorities, and based on the sorted multiple filtering layers, the available service providers are filtered layer by layer according to the feature filtering conditions corresponding to each filtering layer, so as to select candidate service providers for the target order.

[0054] It's understandable that the order dispatch structure corresponding to each order type is actually a hierarchical structure. Each filtering layer has corresponding feature filtering conditions, which are based on service characteristics. This can be understood as each filtering layer having service characteristics used to filter service providers. Furthermore, there is a priority order between the layers; the higher the priority of a filtering layer, the more important the service characteristics corresponding to that layer are. Service providers are filtered out sequentially from low to high priority through different filtering layers. The remaining service providers after the last filtering layer are then considered as candidate service providers.

[0055] For example, if the order dispatch structure has three filtering layers, the first filtering layer filters out available service providers with a complaint rate of 50% or higher, the second filtering layer filters out available service providers with a service level lower than level two, and the third filtering layer filters out available service providers with more than 10 negative reviews. After filtering the available service providers layer by layer, the remaining available service providers with a complaint rate of less than 50%, a service level of not less than level two, and no more than 10 negative reviews are selected as candidate service providers for the target order.

[0056] In addition, in this preferred implementation, offline layer-by-layer screening can be carried out. Offline computing can usually make full use of computing resources during off-peak hours, such as at night or on weekends, when the system load is low and large amounts of data can be processed more efficiently, thereby improving the efficiency of screening candidate service providers. It can also statistically analyze abnormal service providers, including but not limited to those who fail to provide services to users within the specified time, falsify user reviews, or have been complained about by users for a long time. Abnormal service providers can be punished to encourage them to reflect on and improve their behavior, thereby improving user satisfaction and loyalty.

[0057] In this way, by configuring different dispatch structures for different order types, the available service providers selected based on the dispatch structure are more closely matched to the order type, which can improve the accuracy of dispatch. Furthermore, the service features involved in the dispatch structure are pluggable, which allows for flexible configuration of the filtering layers and feature filtering conditions in the dispatch structure according to actual business needs, ensuring the flexibility and accuracy of dispatch.

[0058] Of course, other implementation schemes can also be used to select candidate service providers from available service providers, and no restrictions are imposed here.

[0059] Continue to refer to Figure 2 The fulfillment system can then proceed with the service provider allocation sub-logic to select a target service provider from the candidate service providers and assign the target order to that service provider. The number of target service providers can be one or more, and this number is the same as the number of service providers required for the target order contained in the order information. For example, a takeout order typically allocates one service provider, while an on-site installation order typically allocates multiple installation technicians.

[0060] In this embodiment, after the fulfillment system identifies the target service provider, it can send the order dispatch result containing the target service provider to the business system. The business system may assign the target order to the target service provider based on the order dispatch result, and after completing the assignment, send status modification information to the service provider management system. This allows the service provider management system to modify the status information of the target service provider to a non-idle state according to the status modification information sent by the business system. This ensures the accuracy of obtaining available service providers for new target orders, thereby improving the accuracy of order dispatch.

[0061] In this implementation, there are multiple ways to execute the service provider allocation logic to select the target service provider from the candidate service providers.

[0062] In one exemplary implementation, a score can be calculated for each candidate service provider based on their service characteristics and according to a preset scoring rule. The required number of service providers for the target order is parsed from the order information, and candidate service providers are selected in descending order of their scores as the target service providers for the target order. The scores calculated for the candidate service providers can be used to characterize their service quality. The scoring rule used to calculate the scores can be the same rule shared by different order dispatch structures, or different scoring rules can be configured for different order dispatch structures.

[0063] The approach to calculating scores for each candidate service provider is the same. Taking any candidate service provider as an example, the process of calculating scores will be explained.

[0064] Optionally, for any candidate service provider, the score mapping rules for service features and the mapping relationship between service features and weights can be parsed from the scoring rules. The score mapping rule refers to the mapping relationship between the feature value and feature score of a service feature. For example, the feature value corresponding to the service feature "complaint rate" can be from 0 to 100%. The score mapping rule for the complaint rate can be: if the complaint rate is 0-10%, the feature score corresponding to this service feature is 5; if the complaint rate is 11%-20%, the feature score corresponding to this service feature is 4; if the complaint rate is 21%-30%, the feature score corresponding to this service feature is 3; if the complaint rate is 31%-50%, the feature score corresponding to this service feature is 2; and if the complaint rate is 41%-100%, the feature score corresponding to this service feature is 1. The mapping relationship between service features and weights is used to describe the proportion of each service feature in the multiple service features involved in the calculation. For example, a candidate service provider may correspond to four service features: service level, order dispatch rate, evaluation, and complaint rate. The weight of service level is 30%, the weight of evaluation is 30%, the weight of order dispatch rate is 20%, and the weight of complaint rate is 20%.

[0065] Based on this, the feature scores corresponding to each service feature of the candidate service provider can be calculated according to the score mapping rules of service features. The feature scores corresponding to each service feature are then weighted and summed according to the mapping relationship between service features and weights to obtain the score for the candidate service provider. For example, if a candidate service provider can correspond to four service features: service level, dispatch rate, evaluation, and complaint rate, with feature scores of 4, 5, 3, and 4 respectively, and weights of 30%, 30%, 20%, and 20% respectively, then the weighted summation of the feature scores (4*30% + 5*30% + 3*20% + 4*20%) yields a score of 4.1 for the candidate service provider.

[0066] In this embodiment, service features are assigned weights based on their importance, and service provider scores are calculated using the service features and their weights. This allows the scores to more accurately represent the service quality of the service providers, helping to more objectively and accurately select suitable target service providers for target orders. As a result, orders can be assigned to higher-quality service providers, and users can receive better services, thus improving the user experience.

[0067] Of course, other calculation methods can also be used to calculate the score. For example, the feature score corresponding to each service feature of the candidate service provider can be calculated, and the average of all feature scores of the candidate service provider can be calculated as the final score. This embodiment does not limit this.

[0068] In addition to the above, other implementation schemes can be used to select target service providers from candidate service providers. For example, the order information can specify the number of service providers and the service characteristics most valued by the ordering user. The characteristic values ​​corresponding to each candidate service provider under the specified service characteristics can be determined, and the number of candidate service providers selected according to the characteristic values ​​from high to low can be selected as the target service providers for the target order. Alternatively, one or more candidate service providers can be randomly selected from the filtered candidate service providers as target service providers, with the number of target service providers being the same as the number of service providers specified in the order information. This embodiment does not limit the method of selecting target service providers.

[0069] It should be noted that other implementation methods can also be used in this embodiment to dispatch target orders according to the dispatch logic corresponding to the order type. As long as the dispatch of target orders can be achieved, no further examples will be given here.

[0070] In summary, in this embodiment, the order dispatch logic is composed of multiple sub-logic pieces, each representing a stage in the dispatch process. These sub-logic pieces are pluggable to the overall dispatch logic, allowing modification of the dispatch logic by replacing the sub-logic pieces. This enables real-time and flexible adjustment of the dispatch logic corresponding to order types based on business needs, ensuring both flexibility and accuracy in order dispatch. Furthermore, the dispatch process involves layer-by-layer screening of service providers, which improves the compatibility between target service providers and target orders, thereby enhancing dispatch accuracy.

[0071] In the above or below embodiments, a dispatcher can be configured in the fulfillment system. The dispatcher integrates dispatch logic corresponding to various order types and can be used to determine the order type of the target order based on the order information of the target order.

[0072] If an order type is identified based on the order information of the target order, that order type can be directly determined as the order type to which the target order belongs.

[0073] If multiple order types are identified based on the order information of the target order, the priority of each order type can be obtained, and the order types can be sorted based on their respective priorities. The first order type in the sorted order types is then determined as the order type to which the target order belongs.

[0074] From a development perspective, different order types can be annotated with corresponding order type descriptions, making it easier for developers to understand the order dispatch logic. This allows developers to quickly and accurately understand the correspondence between order types and order dispatch logic even if they change developers, which helps them maintain the order dispatch logic.

[0075] In practical applications, the order dispatcher manages the order dispatch logic for multiple order types in a unified manner, which can realize the unification of the order dispatch process and facilitate the maintenance of the order dispatch logic in the later stage. The order dispatcher also configures the priority for each order type, which can avoid order dispatch anomalies under mixed order types and ensure the stability of order dispatch.

[0076] In addition, the fulfillment system maintains multiple dispatch components. Each dispatch component implements dispatch sub-logic, and different dispatch components implement different dispatch sub-logic. The dispatch logic in the dispatch distributor is composed of multiple dispatch sub-logic. The dispatch logic corresponding to the dispatch type can be added, removed, or modified in the dispatch distributor.

[0077] When a new order type needs to be added, in response to the new order type operation, at least two order dispatch components required for the new order type can be selected from multiple order dispatch components. The order dispatch sub-logic implemented by multiple order dispatch components is concatenated to form the new order dispatch logic corresponding to the new order type, and the correspondence between the new order type and the new order dispatch logic is maintained.

[0078] Therefore, this embodiment abandons the approach of developing a separate complete dispatch logic for each order type. Instead, it integrates the core components of the dispatch logic into different dispatch components. By configuring various pluggable dispatch logics in the dispatcher through the dispatch components, the addition, removal, and maintenance of dispatch logic can be flexibly and quickly realized. This reduces the efficiency of developers in developing and maintaining dispatch logic, helps maintain the long-term and stable operation of the order management system, and thus contributes to the stability of dispatch.

[0079] Figure 3 This is a structural diagram illustrating a dispatching application scenario provided as an exemplary embodiment of this application. For example... Figure 3 As shown, the dispatching scenario involves assigning domestic service workers to domestic service orders. This application scenario includes an order system, a business system, a fulfillment system, a service provider profiling system, a merchant management system, and a service provider management system. The order system can be a terminal for interacting with users to place orders; the business system can be a server responsible for receiving orders; the fulfillment system can be a server responsible for dispatching orders; the service provider profiling system can be a database storing storage service characteristics; and the merchant management system and service provider management system can be databases storing merchant information and service provider information, respectively. The dispatching steps in this application scenario are as follows:

[0080] 1. The order system can respond to the user's order placement operation, generate pending orders, and send the generated pending orders to the business system. The order information of the pending orders includes the user's address, housekeeping service items, and arrival time.

[0081] 2. After receiving the pending order submitted by the order system, the business system sends a dispatch request to the fulfillment system;

[0082] 3. After receiving the order dispatch request, the fulfillment system immediately sends a signal to the business system that the request has been successfully received, and adds the order information of the pending orders parsed from the order dispatch request to the order queue of the fulfillment system.

[0083] 4. The fulfillment system can determine the order type of the target order based on the order information of the pending orders using the order dispatcher. The order type may include, but is not limited to, distribution order dispatch, stored value priority order dispatch, designated merchant order dispatch, black box order dispatch to merchants, and direct dispatch of service personnel.

[0084] 5. Determine the order dispatch logic corresponding to the order type. Different order types have different order dispatch logic. For example, when dispatching orders to merchants through black box, merchants need to be screened first, and then domestic service personnel need to be selected from the screened merchants. When dispatching service personnel directly, the selection of domestic service personnel can be carried out directly. Taking the recall logic corresponding to dispatching orders to merchants through black box as an example, the recall sub-logic, selection sub-logic, and allocation sub-logic can be extracted from the order dispatch logic.

[0085] 6. Execute the recall sub-logic to obtain available merchants that are idle and can accept the target order from the merchant management system, and obtain available domestic service personnel that are idle and can accept the target order from the service personnel management system.

[0086] 7. Based on the obtained available merchants and available domestic service personnel, execute the selection sub-logic to obtain the service characteristics of available merchants and available domestic service personnel from the service provider profiling system;

[0087] 8. Obtain the dispatch structure corresponding to the order type of the target order, and filter the available merchants and available domestic service personnel layer by layer according to the feature filtering conditions of each filtering layer in the dispatch structure, so as to filter out candidate merchants and candidate service personnel for the target order.

[0088] 9. Execute the allocation sub-logic to calculate the scores corresponding to each candidate merchant and each candidate domestic service worker based on the service characteristics of the candidate merchants and the service characteristics of the candidate domestic service workers. Then, select the target merchant and target domestic service worker from the candidate merchants and candidate domestic service workers in descending order of scores to generate the order dispatch result.

[0089] 10. Send the order dispatch results to the business system so that the business system can assign the target order to the target merchant and the target domestic service personnel, and send the order modification information for the target order to the order system so that the order system can modify the order status of the target order according to the order modification information;

[0090] 11. After sending order modification information to the order system, the business system can also send status modification information to the merchant management system and the service personnel management system to change the status information of the target merchant in the merchant management system to non-idle status and the status information of the target domestic service personnel in the service personnel management system to non-idle status.

[0091] 12. The fulfillment system can also monitor the order queue in real time, and process the order to be re-delivered when it detects that there are orders to be re-delivered in the order queue.

[0092] Figure 4 This is a flowchart illustrating an order dispatching method as provided in another exemplary embodiment of this application. The method can be executed by a fulfillment system responsible for order dispatching within an order management system. Physically, this fulfillment system can be a conventional server, cloud server, virtual data center, or other server equipment. The fulfillment system can be integrated into a data processing device, which can be implemented as a combination of software and / or hardware, and can be integrated into a computing device. The order management system decouples order receiving and order dispatching, and also includes a business system responsible for order receiving. (Reference) Figure 4 The method includes:

[0093] Step 400: Receive an order dispatch request sent by the business system in an asynchronous request manner. The order dispatch request includes the order information of the order to be processed.

[0094] Step 401: Add the order information of the pending orders to the order queue of the fulfillment system, and dispatch the pending orders in the order queue according to the dispatching logic.

[0095] Step 402: Take the currently scheduled pending order as the target order, determine the order type of the target order based on the order information of the target order, and dispatch the target order according to the dispatch logic corresponding to the order type.

[0096] Step 403: Return the order dispatch result of the target order to the business system in an asynchronous response manner, so that the business system can notify the ordering user of the dispatch result by modifying the order status of the target order.

[0097] In an optional embodiment, during the process of dispatching target orders according to the dispatching logic corresponding to the order type, the method includes:

[0098] From the dispatch logic corresponding to the order type, multiple dispatch sub-logic are extracted. The dispatch sub-logic includes service provider recall sub-logic, service provider selection sub-logic and service provider allocation sub-logic.

[0099] Execute the service provider recall sub-logic to retrieve available service providers that are idle and capable of accepting the target order from the service provider management system;

[0100] The service provider selection sub-logic is executed to obtain the service characteristics of available service providers from the service provider profiling system; and candidate service providers are selected based on the service characteristics of available service providers.

[0101] Execute the service provider allocation sub-logic to select the target service provider from the candidate service providers and assign the target order to the target service provider.

[0102] In an optional embodiment, the method for selecting candidate service providers based on the service characteristics of available service providers includes:

[0103] Obtain the dispatch structure corresponding to the order type. The dispatch structure includes multiple filtering layers, and each filtering layer has feature filtering conditions associated with service characteristics.

[0104] Sort the multiple filter layers according to their respective priorities;

[0105] Based on the sorted multiple filtering layers, the available service providers are filtered layer by layer according to the feature filtering conditions corresponding to each filtering layer, so as to select candidate service providers for the target order.

[0106] In an alternative embodiment, during the execution of the service provider allocation sub-logic to select a target service provider from candidate service providers, the method includes:

[0107] Based on the service characteristics of the candidate service providers, and according to the preset scoring rules, calculate the corresponding score for each candidate service provider.

[0108] From the order information of the target order, parse the number of service providers required for the target order;

[0109] Based on the scores from highest to lowest, select the candidate service providers by the number of service providers to be used as the target service providers for the target orders.

[0110] In an optional embodiment, the method includes the following steps in calculating the score for each candidate service provider based on its service characteristics and according to a preset scoring rule:

[0111] From the scoring rules, the score mapping rules of service features and the mapping relationship between service features and weights are extracted;

[0112] For any candidate service provider, based on the score mapping rule of service features, calculate the feature score corresponding to each service feature of the candidate service provider;

[0113] Based on the mapping relationship between service features and weights, the feature scores corresponding to each service feature are weighted and summed to obtain the score corresponding to the candidate service provider.

[0114] In an optional embodiment, the method for determining the order type of a target order based on its order information includes:

[0115] If an order type is identified based on the order information, the order type is determined to be the order type to which the target order belongs;

[0116] If multiple order types are identified based on order information, obtain the priority of each order type;

[0117] The order types are sorted based on their respective priorities.

[0118] The first order type in the sorted order types is determined as the order type to which the target order belongs.

[0119] In an optional embodiment, the fulfillment system maintains multiple dispatching components, each implementing dispatching sub-logic, and the method further includes the following steps during the process where different dispatching components implement different dispatching logic:

[0120] In response to a new operation for an order type, select at least two dispatch components from multiple dispatch components required to add the new order type;

[0121] The dispatch sub-logic implemented by multiple dispatch components is combined to form the new dispatch logic corresponding to the new order type;

[0122] Maintain the correspondence between new order types and new order dispatch logic.

[0123] In one optional embodiment, it is possible to monitor whether there are any pending orders in the order queue. Pending orders refer to orders that have timed out but have not yet been successfully dispatched. If such orders exist, they are then dispatched.

[0124] For the technical details of the above-mentioned order dispatching methods in various embodiments, please refer to the relevant descriptions of the actions of the fulfillment system in the aforementioned order management system embodiments. To save space, these details will not be repeated here, but this should not cause any loss to the scope of protection of this application.

[0125] It should be noted that the execution subject of each step of the method provided in the above embodiments can be the same device, or the method can be executed by different devices. For example, the execution subject of steps 401 to 403 can be device A; or the execution subject of steps 401 and 402 can be device A, and the execution subject of step 403 can be device B; and so on.

[0126] Furthermore, some processes described in the above embodiments and accompanying drawings include multiple operations that appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 401, 402, etc., are merely used to distinguish different operations and do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel.

[0127] Figure 5 This is a schematic diagram of the structure of a computing device provided as another exemplary embodiment of this application. For example... Figure 5 As shown, the computing device includes: a memory 50, a processor 51, and a communication component 52.

[0128] Processor 51, coupled to memory 50, is used to execute computer programs in memory 50 for:

[0129] Receives order dispatch requests sent asynchronously by the business system. The order dispatch request includes the order information of the orders to be processed.

[0130] Add the order information of the pending orders to the order queue of the fulfillment system, and dispatch the pending orders in the order queue according to the dispatching logic.

[0131] The currently scheduled pending order is taken as the target order. The order type of the target order is determined based on the order information of the target order. The target order is then dispatched according to the dispatch logic corresponding to the order type.

[0132] The system returns the order assignment result of the target order to the business system in an asynchronous response manner, so that the business system can notify the ordering user of the order result by modifying the order status of the target order.

[0133] In an optional embodiment, during the process of dispatching target orders according to the dispatching logic corresponding to the order type, the processor 51 is further configured to:

[0134] From the dispatch logic corresponding to the order type, multiple dispatch sub-logic are extracted. The dispatch sub-logic includes service provider recall sub-logic, service provider selection sub-logic and service provider allocation sub-logic.

[0135] Execute the service provider recall sub-logic to retrieve available service providers that are idle and capable of accepting the target order from the service provider management system;

[0136] Execute the service provider selection sub-logic to obtain the service characteristics of available service providers from the service provider profiling system;

[0137] Candidate service providers are selected based on the service characteristics of available service providers;

[0138] Execute the service provider allocation sub-logic to select the target service provider from the candidate service providers and assign the target order to the target service provider.

[0139] In an optional embodiment, during the process of selecting candidate service providers based on the service characteristics of available service providers, processor 51 is further configured to:

[0140] Obtain the dispatch structure corresponding to the order type. The dispatch structure includes multiple filtering layers, and each filtering layer has feature filtering conditions associated with service characteristics.

[0141] Sort the multiple filter layers according to their respective priorities;

[0142] Based on the sorted multiple filtering layers, the available service providers are filtered layer by layer according to the feature filtering conditions corresponding to each filtering layer, so as to select candidate service providers for the target order.

[0143] In an optional embodiment, during the execution of the service provider allocation sub-logic to select a target service provider from candidate service providers, processor 51 is further configured to:

[0144] Based on the service characteristics of the candidate service providers, and according to the preset scoring rules, calculate the corresponding score for each candidate service provider.

[0145] From the order information of the target order, parse the number of service providers required for the target order;

[0146] Based on the scores from highest to lowest, select the candidate service providers by the number of service providers to be used as the target service providers for the target orders.

[0147] In an optional embodiment, during the process of calculating the score corresponding to each candidate service provider based on the service characteristics of the candidate service providers and according to a preset scoring rule, the processor 51 is further configured to:

[0148] From the scoring rules, the score mapping rules of service features and the mapping relationship between service features and weights are extracted;

[0149] For any candidate service provider, based on the score mapping rule of service features, calculate the feature score corresponding to each service feature of the candidate service provider;

[0150] Based on the mapping relationship between service features and weights, the feature scores corresponding to each service feature are weighted and summed to obtain the score corresponding to the candidate service provider.

[0151] In an optional embodiment, during the process of determining the order type of the target order based on the order information of the target order, the processor 51 is further configured to:

[0152] If an order type is identified based on the order information, the order type is determined to be the order type to which the target order belongs;

[0153] If multiple order types are identified based on order information, obtain the priority of each order type;

[0154] The order types are sorted based on their respective priorities.

[0155] The first order type in the sorted order types is determined as the order type to which the target order belongs.

[0156] In an optional embodiment, the fulfillment system maintains multiple dispatching components, each dispatching component implements dispatching sub-logic, and different dispatching components implement different dispatching sub-logic. The processor 51 is further configured to:

[0157] In response to a new operation for an order type, select at least two dispatch components from multiple dispatch components required to add the new order type;

[0158] The dispatch sub-logic implemented by multiple dispatch components is combined to form the new dispatch logic corresponding to the new order type;

[0159] Maintain the correspondence between new order types and new order dispatch logic.

[0160] In an optional embodiment, the processor 51 is further configured to monitor whether there are any pending orders in the order queue, where pending orders refer to orders that have timed out but have not yet been successfully dispatched;

[0161] If such an order exists, it will be processed for re-delivery.

[0162] Furthermore, such as Figure 5 As shown, the computing device also includes other components such as a display 53 and a power supply 54. Figure 5 The diagram only shows some components and does not mean that the computing device includes only these components. Figure 5 The components shown.

[0163] It is worth noting that the technical details of the above-mentioned embodiments of the computing device can be referred to the relevant descriptions of the operation of the computing device in the aforementioned embodiments of the dispatching method. To save space, they will not be repeated here, but this should not cause any loss to the scope of protection of this application.

[0164] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed, can perform the steps that can be executed by a computing device in the above method embodiments.

[0165] This application also provides a computer program product, including a computer program. When the computer program is executed by a processor, it can implement the steps in the above-described order dispatching method. It should be noted that the technical solution of this computer program and the technical solution of the above-described order dispatching method belong to the same concept. Details not described in detail in the technical solution of the computer program can be found in the description of the technical solution of the above-described order dispatching method.

[0166] The above Figure 5 The memory in a computer is used to store computer programs and can be configured to store various other data to support operation on a computing platform. Examples of this data include instructions for any application or method operating on the computing platform, contact data, phone book data, messages, pictures, videos, etc. The memory can be implemented from any type of volatile or non-volatile storage device or a combination thereof, 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 storage, flash memory, magnetic disks, or optical disks.

[0167] The above Figure 5 The communication component is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device containing the communication component can access wireless networks based on communication standards, such as WiFi, 2G, 3G, 4G / LTE, 5G, or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component 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), Infrared Data Association (IrDA) technology, Ultra-Wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0168] The above Figure 5 The display includes a screen, which may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen can be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors can sense not only the boundaries of the touch or swipe action, but also the duration and pressure associated with the touch or swipe operation.

[0169] The above Figure 5 The power supply component provides power to the various components of the device in which it resides. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which it resides.

[0170] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0171] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0172] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0173] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0174] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0175] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0176] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0177] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0178] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0179] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. An order distribution method characterized by comprising: The application is suitable for an order management system responsible for order distribution, the order management system decouples order receiving and order distribution, and further comprises a business system responsible for order receiving, the order distribution method comprises: receiving an order distribution request sent by the business system in an asynchronous request mode, the order distribution request comprising order information of a to-be-processed order; adding the order information of the to-be-processed order to an order queue of the order management system, and scheduling the to-be-processed order in the order queue according to order distribution scheduling logic; taking a to-be-processed order currently scheduled as a target order, determining an order type to which the target order belongs according to the order information of the target order, and performing order distribution processing on the target order according to order distribution logic corresponding to the order type; returning an order distribution result of the target order to the business system in an asynchronous response mode, so that the business system notifies the order distribution result to an order placing user by modifying an order state of the target order.

2. The method of claim 1, wherein, The order distribution processing on the target order according to the order distribution logic corresponding to the order type comprises: parsing a plurality of order distribution sub-logics from the order distribution logic corresponding to the order type, the order distribution sub-logics comprising a service provider recall sub-logic, a service provider selection sub-logic and a service provider allocation sub-logic; executing the service provider recall sub-logic to obtain an available service provider in an idle state and capable of undertaking the target order from a service provider management system; executing the service provider selection sub-logic to obtain service characteristics of the available service provider from a service provider portrait system; selecting a candidate service provider according to the service characteristics of the available service provider; executing the service provider allocation sub-logic to select a target service provider from the candidate service provider and allocate the target order to the target service provider.

3. The method of claim 2, wherein, The selection of the candidate service provider according to the service characteristics of the available service provider comprises: obtaining an order distribution structure corresponding to the order type, the order distribution structure comprising a plurality of screening layers, each screening layer corresponding to a characteristic screening condition associated with service characteristics; sorting the plurality of screening layers according to respective priorities of the plurality of screening layers; based on the sorted plurality of screening layers, performing layer-by-layer screening on the available service provider according to respective characteristic screening conditions of the plurality of screening layers to screen a candidate service provider for the target order.

4. The method of claim 2, wherein, The execution of the service provider allocation sub-logic to select a target service provider from the candidate service provider comprises: based on the service characteristics of the candidate service provider, calculating respective scores of the candidate service providers according to a preset scoring rule; parsing a required number of service providers of the target order from the order information of the target order; selecting the candidate service providers of the required number of service providers in a descending order of the scores as the target service provider of the target order.

5. The method of claim 4, wherein, The calculation of the respective scores of the candidate service providers based on the service characteristics of the candidate service providers according to the preset scoring rule comprises: parsing a score mapping rule of service characteristics and a mapping relationship between service characteristics and weights from the scoring rule; For any candidate service provider, based on the score mapping rule of the service features, the feature score corresponding to each service feature of the candidate service provider is calculated; According to the mapping relationship between the service features and the weights, the feature scores corresponding to each service feature are weighted and summed to obtain the score corresponding to the candidate service provider.

6. The method of claim 1, wherein, According to the order information of the target order, determine the order type to which the target order belongs, including: If one order type is identified according to the order information, the order type is determined as the order type to which the target order belongs; If multiple order types are identified according to the order information, the priority corresponding to each of the multiple order types is obtained; Based on the priority corresponding to each of the multiple order types, the multiple order types are sorted; The first order type in the sorted order types is determined as the order type to which the target order belongs.

7. The method of claim 1, wherein, The fulfillment system maintains multiple order dispatch components, each of which implements order dispatch sub-logic, and different order dispatch components implement different order dispatch sub-logic, and the method further comprises: In response to an add operation for an order type, select at least two order dispatch components required for adding the order type from the multiple order dispatch components; Splice the order dispatch sub-logic implemented by the multiple order dispatch components to form the new order dispatch logic corresponding to the new order type; Maintain the correspondence between the new order type and the new order dispatch logic.

8. The method of claim 1, wherein, The method further comprises: Monitoring whether there is a to-be-reassigned order in the order queue, the to-be-reassigned order being an order that has timed out but has not been successfully dispatched; If so, perform reassignment processing on the to-be-reassigned order.

9. An order management system, characterized by, The order management system decouples order receiving and order dispatching, and the order management system includes a business system responsible for order receiving and a fulfillment system responsible for order dispatching; The business system is configured to receive a to-be-processed order submitted by a user, and send a dispatch request to the fulfillment system in an asynchronous request manner, the dispatch request including order information of the to-be-processed order; The fulfillment system is configured to receive the dispatch request sent by the business system in an asynchronous request manner; Add the order information of the to-be-processed order to an order queue of the fulfillment system, and dispatch the to-be-processed orders in the order queue according to a dispatch scheduling logic; Take the currently dispatched to-be-processed order as a target order, determine the order type to which the target order belongs according to the order information of the target order, and dispatch the target order according to the dispatch logic corresponding to the order type; In an asynchronous response manner, return the dispatch result of the target order to the business system; The business system is further configured to notify the user of the dispatch result by modifying the order state of the target order according to the dispatch result returned by the fulfillment system.

10. The system of claim 9, wherein, The order management system further comprises an order system for maintaining orders; The business system is further configured to send order modification information for the target order to the order system; The order system is configured to provide a to-be-processed order submitted by an order placing user to the business system, and modify an order state of the target order according to the order modification information sent by the business system.

11. The system of claim 9, wherein, The order management system further comprises a service provider management system and a service provider portrait system. The service provider management system is configured to provide, to the order fulfillment system, an available service provider in an idle state and capable of undertaking the target order. According to the state modification information sent by the business system, the state information of the target service provider is modified to a non-idle state. The service provider portrait system is configured to provide, to the order fulfillment system, service characteristics of the available service provider.

12. A computing device, comprising: comprises a memory, a processor, and a communication component; The memory is configured to store one or more computer instructions; The processor is coupled with the memory and the communication component, and is configured to execute the one or more computer instructions to execute the order dispatching method in any one of claims 1-8.

13. A computer readable storage medium storing computer instructions, wherein, When the computer instructions are executed by one or more processors, the one or more processors are caused to execute the order dispatching method in any one of claims 1-8.

Images