Multi-channel transport capacity real-time matching method and system based on API gateway

Abstract

The invention relates to a multi-channel transport capacity real-time matching method and system based on an API gateway, and the method comprises the following steps: carrying out the protocol format processing of a multi-channel request order received by the API gateway through employing a preset protocol conversion rule, and obtaining a standardized request order; carrying out identity authentication on the standardized request order to obtain an authentication request order, obtaining available transport capacity data of each express delivery and express transportation enterprise, and carrying out matching degree calculation on the authentication request order and the available transport capacity data to obtain a transport capacity matching degree list; and the transport capacity matching degree list is pushed to a corresponding order initiating end, so that intelligent scheduling and real-time optimal distribution of multi-channel request orders are realized, and the technical problems that the initial period of order processing is prolonged and order information is easily lost or disordered due to format analysis errors in the traditional technology are solved.

Description

Technical Field

[0001] This invention relates to the field of data matching technology, and in particular to a method and system for real-time matching of multi-channel capacity based on an API gateway. Background Technology

[0002] With the booming development of the e-commerce industry and the diversified expansion of offline retail formats, logistics orders have become increasingly diversified. These include bulk orders from mainstream e-commerce platforms, immediate delivery needs from offline stores, and customized freight requests from corporate clients, forming a typical multi-channel order scenario. However, orders from different channels differ significantly in their protocol formats. Some use JSON for transmission, others use the traditional XML protocol, and even some smaller partners still use custom proprietary data formats. These differences require logistics platforms to invest significant manpower and time in format conversion and adaptation when receiving orders. This not only prolongs the initial order processing cycle but also easily leads to order information loss or corruption due to format parsing errors, seriously affecting the accuracy of subsequent capacity scheduling and becoming the primary bottleneck restricting the efficient processing of multi-channel orders. Summary of the Invention

[0003] This invention aims to at least solve one of the technical problems existing in the prior art. To this end, this invention proposes a real-time multi-channel capacity matching method based on an API gateway, comprising the following steps: The multi-channel request orders received from the API gateway are processed according to the preset protocol conversion rules to obtain standardized request orders; The standardized request order is authenticated to obtain an authenticated request order. The available transportation capacity data of each express delivery and freight company is obtained. The matching degree of the authenticated request order and the available transportation capacity data is calculated to obtain a transportation capacity matching degree list. The capacity matching list is pushed to the corresponding order initiator to achieve intelligent scheduling and real-time optimized allocation of orders requested from multiple channels.

[0004] Furthermore, the multi-channel request orders received from the API gateway are processed according to preset protocol conversion rules to obtain standardized request orders, including: The protocol headers of the multi-channel request orders received from the API gateway are parsed to obtain the protocol type identifiers of each channel request order. The protocol type identifiers are then categorized and organized to obtain classified protocol types. Based on the aforementioned classification protocol type, the corresponding protocol conversion rules are used to convert the format of request orders from various channels, transforming request orders from different channels with different protocol formats into standardized request orders with a unified internal protocol format.

[0005] Furthermore, after obtaining the standardized request order, the process includes: The total number of standardized request orders within a unit of time is statistically analyzed, and the trend of change in the total number of requests is monitored in real time. Based on the request volume change trend, the standardized request orders are initially screened by setting a traffic threshold in the traffic control module. When the request volume change trend exceeds the traffic threshold, the excess standardized requests are marked as pending requests, resulting in a mixed request that includes normal requests and pending requests. The pending requests in the mixed requests are delayed or discarded, while the normal requests are marked to obtain controlled order requests.

[0006] Furthermore, the standardized request order is authenticated to obtain an authenticated request order, including: The standardized request order is split into request data to separate the request body data. The request body data is then used to locate key fields and extract key fields containing user identity features. These key fields include the user's unique identifier and encrypted identity token. The user's unique identifier is hashed to generate a fixed-length identity hash value. At the same time, the encrypted identity token is decrypted to obtain the decrypted identity plaintext information. The identity hash value is compared with a preset legal identity hash database to obtain a hash matching status. At the same time, the identity plaintext information is matched with a preset legal identity plaintext database to obtain a plaintext matching status. When both the hash matching status and the plaintext matching status are successful, the standardized request order is determined to have passed identity authentication. When either the hash matching status or the plaintext matching status fails, a secondary verification process is initiated. The secondary verification process involves sending a dynamic verification code to the user's pre-registered contact information and requiring the user to return the dynamic verification code to the system within a specified time. The system compares the returned dynamic verification code with the generated dynamic verification code. If the comparison is successful, the identity authentication is deemed successful; if the comparison fails, the identity authentication is deemed unsuccessful. The standardized request order that has successfully authenticated the identity is then used as the authentication request order.

[0007] Furthermore, the matching degree of the authentication request order and the available capacity data is calculated to obtain a capacity matching degree list, including: The authentication request order is processed to extract order attributes, including order weight, order volume and order delivery time requirements. The available transportation capacity data is processed to extract transportation capacity attributes, including vehicle load capacity, vehicle volume and vehicle transportation time range. The load matching degree is obtained by comparing the order weight with the vehicle load capacity, the volume matching degree is obtained by comparing the order volume with the vehicle volume, and the time matching degree is obtained by calculating the overlap between the order delivery time requirement and the vehicle's transportable time range. The load matching degree, volume matching degree, and time matching degree are weighted and summed to obtain the comprehensive matching degree. The combination of authentication request orders and available capacity data is then sorted from high to low according to the comprehensive matching degree to obtain the capacity matching degree list.

[0008] Furthermore, the capacity matching list will be pushed to the corresponding order initiation end to achieve intelligent scheduling and real-time optimized allocation of multi-channel request orders, including: Based on the protocol type identifier, add a corresponding exclusive identifier field to the capacity matching list, and convert the capacity matching list data with the added identifier field into a JSON format push data packet; The push data packet is sent to the order initiator through the ACK confirmation mechanism, and the receiver is waited for the confirmation signal. If no confirmation signal is received within the preset timeout period, the re-push mechanism is triggered and the push result record is obtained. Based on the legitimate order requests in the push result record, the transportation resources corresponding to the successfully pushed orders are marked as occupied, and the corresponding transportation resources are deducted from the available transportation resources data to obtain the remaining allocable amount. Orders that failed to push or whose order initiators reported abandoning the selected capacity are added back to the preset pool of orders to be matched. A second matching is triggered by combining the real-time updated remaining allocable capacity to achieve intelligent scheduling and real-time optimized allocation of orders requested from multiple channels.

[0009] Furthermore, based on the protocol type identifier, a corresponding exclusive identifier field is added to the capacity matching list, including: The protocol type identifier is converted into a dedicated identifier field through a preset identifier mapping rule. The identifier mapping rule is the correspondence between different protocol type identifiers and dedicated identifier fields. Add a unique identifier field to the standardized request orders in the capacity matching list.

[0010] This invention also provides a multi-channel real-time capacity matching system based on an API gateway, comprising: The receiving module is used to process the multi-channel request orders received from the API gateway according to the preset protocol conversion rules to obtain standardized request orders; The authentication module is used to authenticate the standardized request order, obtain the authentication request order, acquire the available transportation capacity data of each express delivery and freight company, calculate the matching degree between the authentication request order and the available transportation capacity data, and obtain a transportation capacity matching degree list. The push module is used to push the capacity matching list to the corresponding order initiator to realize intelligent scheduling and real-time optimized allocation of multi-channel request orders.

[0011] The present invention also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of any of the above methods.

[0012] The present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of any of the above methods.

[0013] This invention provides a real-time multi-channel capacity matching method based on an API gateway, comprising the following steps: processing multi-channel request orders received from the API gateway according to preset protocol conversion rules to obtain standardized request orders; authenticating the standardized request orders to obtain authenticated request orders; acquiring available capacity data of various express delivery and freight companies; calculating the matching degree between the authenticated request orders and the available capacity data to obtain a capacity matching degree list; and pushing the capacity matching degree list to the corresponding order initiator to achieve intelligent scheduling and real-time optimized allocation of multi-channel request orders, solving the problem of... Traditional technologies often extend the initial order processing cycle and are prone to errors in format parsing, leading to lost or corrupted order information. This new technology generates a capacity matching list through multi-dimensional matching degree calculations, breaking the limitations of relying on historical data or manual experience to estimate capacity. It enables real-time and accurate matching of orders and capacity. Furthermore, the matching process fully considers key indicators such as transportation costs, delivery timeliness, and route rationality, selecting the optimal capacity combination. This not only improves the utilization rate of logistics resources but also meets diverse customer needs, enhances customer satisfaction, and aligns with the development direction of intelligent and refined operations in the logistics industry. Attached Figure Description

[0014] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which: Figure 1 This is a flowchart illustrating the steps of the multi-channel real-time capacity matching method based on an API gateway in this embodiment of the invention. Figure 2 This is a structural block diagram of the multi-channel real-time capacity matching system based on an API gateway in this embodiment of the invention; Figure 3This is a schematic block diagram of the structure of a computer device according to an embodiment of the present invention.

[0015] The objectives, features, and advantages of this invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0016] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0017] In the description of this invention, it should be understood that the orientation descriptions, such as up, down, front, back, left, right, etc., are based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limiting this invention.

[0018] In the description of this invention, "several" means one or more, "more than" means two or more, "greater than," "less than," and "exceeding" are understood to exclude the stated number, while "above," "below," and "within" are understood to include the stated number. The use of "first" and "second" in the description is merely for distinguishing technical features and should not be construed as indicating or implying relative importance, or implicitly indicating the number of indicated technical features, or implicitly indicating the order of the indicated technical features.

[0019] In the description of this invention, unless otherwise explicitly defined, terms such as "set up," "install," and "connect" should be interpreted broadly, and those skilled in the art can reasonably determine the specific meaning of the above terms in this invention in conjunction with the specific content of the technical solution.

[0020] The embodiments of this application will be further described below with reference to the accompanying drawings.

[0021] Reference Figure 1 This invention provides a method for real-time matching of multi-channel capacity based on an API gateway, comprising the following steps: Step S1: The multi-channel request orders received from the API gateway are processed according to the protocol format using preset protocol conversion rules to obtain standardized request orders.

[0022] Specifically, when processing multi-channel request orders received from the API gateway to obtain standardized request orders using preset protocol conversion rules, the system first retrieves request orders from different channels from the API gateway, such as JSON format orders from e-commerce platforms and XML format orders from offline stores. Then, it calls the system's preset protocol conversion rules, which clearly define the correspondence between order fields in different formats and standardized order fields. For example, "order_code" in a JSON order corresponds to the "order number" in a standardized order, and "order_code" in an XML order corresponds to the "order number" in a standardized order.<goods_weight> "Corresponding to "cargo weight", each field is converted one by one according to this rule, and finally the multi-channel request orders with different protocol formats are uniformly processed into standardized request orders with consistent structure.

[0023] Step S2: Authenticate the standardized request order to obtain an authentication request order, obtain available transportation capacity data of various express delivery and freight companies, calculate the matching degree between the authentication request order and the available transportation capacity data, and obtain a transportation capacity matching degree list.

[0024] Specifically, when authenticating standardized request orders, the system extracts the user's unique identifier and encrypted identity token from the order. The identifier is hashed and compared with a valid hash database, while the token is decrypted and matched with a valid plaintext database. If both are successful, the authenticated request order is obtained. Then, through a dedicated interface, the system retrieves available capacity data such as idle vehicles and delivery personnel locations from various express delivery and freight companies. This data is then combined with attributes such as the weight and delivery time of the authenticated request order and compared with the load capacity and transportation time range of the capacity data to calculate the matching degree. For example, a 3-ton order is compared with a 5-ton load capacity to calculate the load capacity matching degree. Finally, all matching results are summarized to form a capacity matching degree list.

[0025] Step S3: The capacity matching list is pushed to the corresponding order initiator to realize intelligent scheduling and real-time optimized allocation of multi-channel request orders.

[0026] Specifically, when pushing a list based on capacity matching, the system first identifies the order initiator type for each authenticated order request. If it's a batch order from an e-commerce platform, the list is pushed to its logistics management backend via the platform's dedicated API. If it's an immediate order from an offline store, it's sent directly to the store manager's management app. For customized orders from enterprise clients, the system also simultaneously copies the contact person via email. For example, if an e-commerce platform has 100 orders from Beijing to Shanghai, the pushed list displays capacity information from companies like Express A and Courier B, sorted by matching degree. After the platform selects the appropriate capacity, the system updates the available capacity data for each company in real time. If new orders are subsequently initiated, the matching degree can be recalculated based on the updated capacity, thereby achieving intelligent scheduling and real-time optimized allocation of orders from multiple channels.

[0027] In a specific embodiment, a preset protocol conversion rule is used to process the protocol format of multi-channel request orders received from the API gateway to obtain standardized request orders, including: The protocol headers of the multi-channel request orders received from the API gateway are parsed to obtain the protocol type identifiers of each channel request order. The protocol type identifiers are then categorized and organized to obtain classified protocol types. Based on the aforementioned classification protocol type, the corresponding protocol conversion rules are used to convert the format of request orders from various channels, transforming request orders from different channels with different protocol formats into standardized request orders with a unified internal protocol format.

[0028] Specifically, when processing multi-channel request orders received from the API gateway to obtain standardized request orders, the protocol headers of these multi-channel request orders are first parsed. Specifically, the protocol identifier field of each order data header is extracted. For example, the protocol header of an order sent by e-commerce platform A contains the identifier "Content-Type:application / json", the protocol header of an offline store B is marked "Protocol-Type:XMLv1.0", and the protocol header of a small partner C has a custom "Order-Protocol:Private-V2" field. By identifying these different identifiers, the protocol type identifier of each channel request order can be obtained. Then, they are classified and organized according to the identifier content. Those with the identifier "application / json" are classified as JSON, those with the identifier "XMLv1.0" are classified as XML, and those with the identifier "Private-V2" are classified as private protocol types, thus obtaining the classified protocol types. After classification, the order formats requested from each channel are converted using the corresponding protocol conversion rules based on these classification protocol types. For JSON orders, the "order_id" field is converted to the "order number" field of the internal protocol, and the "recipient_addr" field is converted to the "recipient address" field, according to the preset JSON field mapping table. For XML orders, the XML tag parsing rules are followed. <ordernumber>Extract content from the tag and fill it into the "Order Number" field. <receiveraddress>The content in the label is extracted and filled into the "recipient address" field; for private protocol orders, the "ORD-NO" corresponding information is converted into "order number" and the "REC-ADDR" corresponding information is converted into "recipient address" according to the field correspondence agreed with cooperation party C in advance. Through such conversion operation, the channel request orders of different protocol formats can be uniformly converted into standardized request orders in the unified internal protocol format with the preset structure of the platform. In the whole process, the conversion rules of each type of protocol are designed according to its format characteristics to ensure that the converted data fields are complete and consistent with the internal protocol requirements. For example, when processing the JSON format order of a certain e-commerce platform, even if there is a difference between the field name and the internal protocol, it can be accurately converted through the fixed mapping rule, and there will be no field omission or mismatch. For private protocol orders, the field correspondence is explicitly defined in advance, and the conversion can be efficiently completed. Finally, all orders from different channels have a unified format, providing a standardized data basis for subsequent traffic limitation, identity authentication and other links.

[0029] In specific embodiments, after the step of obtaining standardized request orders, the following steps are included: The total amount of requests of the standardized request orders in a unit of time is counted, and the request amount change trend of the total amount of requests is monitored in real time; Based on the request amount change trend, the standardized request orders are preliminarily screened through the traffic threshold set in the traffic control module. When the request amount change trend exceeds the traffic threshold, the part exceeding the traffic threshold is marked as a to-be-processed request, and a mixed request containing normal requests and to-be-processed requests is obtained; The to-be-processed requests in the mixed request are processed by delaying or discarding, and the normal requests are marked to obtain controlled order requests.

[0030] Specifically, after obtaining the standardized request order, the total number of requests of the standardized request order in a unit time is first counted, such as setting the unit time as 1 minute, and a counter in the system background is used to accumulate the number of all standardized request orders received in each minute in real time, and a line chart tool is used to dynamically display the fluctuation of the total number of requests in each minute, so as to monitor the request trend of the total number of requests in real time. For example, at the 5th minute after the start of the e-commerce promotion, the total number of requests suddenly increases from 300 orders per minute to 800 orders per minute, and the number of requests per minute increases by 100 orders per minute in the following minutes. This continuous rising trend constitutes the request trend at that time. Then, based on the request trend, the standardized request order is preliminarily screened by setting a traffic threshold in the traffic control module. Assuming that the traffic threshold is set to 600 orders per minute according to the server carrying capacity, when it is monitored that the request trend shows that the number of requests per minute will exceed 600 orders in the future, the part of the standardized request that exceeds 600 orders is marked as a request to be processed. For example, 800 orders are actually received in a certain minute, of which 600 orders are normal requests, and the other 200 orders are marked as requests to be processed. Thus, a mixed request containing normal requests and requests to be processed is obtained. Then, the requests to be processed in the mixed request are processed with delay or discarded. If these requests to be processed are ordinary e-commerce orders, and the system expects that the server resources will be idle after 30 minutes, they are temporarily stored in a to-be-processed queue and set to be processed after 30 minutes. If the request to be processed is an invalid order submitted repeatedly, it is discarded after simple verification. At the same time, the normal requests in the mixed request are uniformly marked as "passed traffic screening". Through such operations, the controlled order request containing the marked normal request and the remaining request to be processed after delay or discard processing is finally obtained. During the whole process, the traffic threshold can be flexibly adjusted according to the real-time resource usage of the server. For example, when the CPU usage of the server is less than 50%, the threshold can be appropriately increased to 800 orders per minute, and when the CPU usage is more than 80%, the threshold can be reduced to 400 orders per minute, so as to ensure that the traffic limitation can avoid system overload and maximize the use of server resources.

[0031] In specific embodiments, the standardized request order is subjected to identity authentication to obtain an authenticated request order, comprising: The standardized request order is subjected to request data splitting to separate out request body data, and the request body data is subjected to key field positioning to extract key fields containing user identity features, wherein the key fields include a user unique identification code and an encrypted identity token. The user unique identification code is subjected to a hash operation to generate an identity hash value of a fixed length, and the encrypted identity token is subjected to a decryption operation to obtain decrypted identity plaintext information. The identity hash value is compared with a preset legal identity hash library to obtain a hash matching state, and the identity plaintext information is compared with a preset legal identity plaintext library to obtain a plaintext matching state; When the hash matching state and the plaintext matching state are both successful, it is determined that the standardized request order is identity authentication passed, and when one of the hash matching state and the plaintext matching state fails, a secondary verification process is started; The secondary verification process sends a dynamic verification code to the user's reserved contact information and requires the user to feed back the dynamic verification code to the system within a specified time. The system compares the feedback dynamic verification code with the generated dynamic verification code. If the comparison is successful, it is determined that the identity authentication is passed, and if the comparison fails, it is determined that the identity authentication fails. The standardized request order passed by the identity authentication is taken as the authentication request order.

[0032] Specifically, when the standardized request order is subjected to identity authentication to obtain the authentication request order, the request data of the standardized request order is first split to separate the protocol header, the additional parameter and the request body data in the order, and only the request body data containing the core information is left. Then, the field recognition tool is used to locate the key field of the request body data. For example, in the standardized request order of a certain e-commerce platform, "user_code: U20250601089" is found as the user unique identification code from the "user_auth" module, and "token: 8a7f3...d2c91" is extracted as the encrypted identity token from the "security_info" module to obtain the key field containing the user identity feature. Then, the user unique identification code "U20250601089" is subjected to SHA-256 hash operation to generate a 64-bit fixed-length identity hash value "3e4b8...9c7a2". At the same time, the pre-agreed RSA decryption algorithm is used to decrypt the encrypted identity token "8a7f3...d2c91" with the private key stored by the system to obtain the identity plaintext information "user: U20250601089; valid_time: 20250601-20250607".

[0033] After the operation and decryption are completed, the generated identity hash value is compared with a preset legal identity hash library, the SHA-256 hash value corresponding to the unique identification code of all registered users is stored in the legal identity hash library, if an entry completely consistent with "3e4b8...9c7a2" can be found, the hash matching state is successful, otherwise it is failed; at the same time, the decrypted identity plaintext information is compared with the preset legal identity plaintext library for string matching, whether the user identification in "user:U20250601089;valid_time:20250601-20250607" exists and the validity period is within the current time range, if both items meet the requirements, the plaintext matching state is successful, otherwise it is failed.

[0034] When the hash matching state and the plaintext matching state are both successful, it is directly determined that the standardized request order is identity authentication passed; if any one of the matching states is failed, such as the identity hash value is matched successfully but the validity period of the identity plaintext information has expired, a secondary verification process is started. The secondary verification process will first call the contact information reserved by the user from the system database, if it is a mobile phone number "139XXXX5678", a randomly generated 6-digit dynamic verification code "628941" is sent through the short message service platform, and a specified feedback time of 10 minutes is set, requiring the user to feed back the dynamic verification code to the system through the verification window of the order initiation end within 10 minutes; after the user submits the verification code, the system will compare the feedback verification code with the generated "628941" bit by bit, if they are exactly the same, it is determined that the identity authentication is passed, if the feedback verification code is wrong or not feedback within the specified time, it is determined that the identity authentication is failed, finally only the standardized request order with identity authentication passed is regarded as an authentication request order, which enters the subsequent available transport capacity data matching link.

[0035] In specific embodiments, the authentication request order and the available transport capacity data are matched to obtain a transport capacity matching degree list, including: The order attributes of the authentication request order are extracted to obtain order key attributes including order weight, order volume and order delivery time requirement, and the transport capacity attributes of the available transport capacity data are extracted to obtain transport capacity key attributes including vehicle load, vehicle volume and vehicle transportable time range; The order weight and the vehicle load are compared to obtain a load matching degree, the order volume and the vehicle volume are compared to obtain a volume matching degree, and the order delivery time requirement and the vehicle transportable time range are compared to obtain a time matching degree; The load matching degree, volume matching degree, and time matching degree are weighted and summed to obtain the comprehensive matching degree. The combination of authentication request orders and available capacity data is then sorted from high to low according to the comprehensive matching degree to obtain the capacity matching degree list.

[0036] Specifically, the matching degree of the authentication request order and the available transportation capacity data is calculated to obtain a transportation capacity matching degree list. First, the order attributes of the authentication request order are extracted, and the core information that directly affects the transportation capacity matching is filtered out from the order details. For example, in an authentication request order initiated by an e-commerce platform, the weight of the goods is clearly marked as 3 tons, the total volume after packaging is 8 cubic meters, and the delivery from Guangzhou to Changsha is required within 3 days. This information constitutes the key attributes of the order. At the same time, the transportation capacity attributes of the available transportation capacity data are extracted. From the real-time data fed back by various express delivery and freight companies, the transportation capacity information corresponding to the order attributes is extracted. For example, a truck of a certain freight company A is marked with a rated load of 5 tons, a cargo volume of 12 cubic meters, and can undertake transportation tasks from Guangzhou to Changsha within the next 5 days. These data form the key attributes of the vehicle's transportation capacity.

[0037] Next, matching scores are calculated based on the extracted attributes. For order weight and vehicle load capacity, a numerical comparison is used to determine the load capacity matching score. If an order weight of 3 tons is compared to a vehicle load capacity of 5 tons, and 3 tons accounts for 60% of 5 tons, the load capacity matching score is set to 60 points (out of 100). If another vehicle has a load capacity of only 2 tons, which cannot meet the 3-ton order weight requirement, the load capacity matching score is 0 points. For order volume and vehicle capacity, the volume matching score is also obtained through numerical comparison. If the order volume is 8 cubic meters, and the vehicle capacity is 12 cubic meters, then the matching score is 60 points. The volume matching score is 66.7. If a vehicle's volume is only 6 cubic meters, the volume matching score is 0. For the order delivery time requirement and the vehicle's transportable time range, the time matching score is calculated by the overlap of the time ranges. If the order requires delivery within 3 days and the vehicle's transportable time is within the next 5 days, the overlap of the two time ranges is 3 days, accounting for 60% of the total transportable time of the vehicle, so the time matching score is 60. If the vehicle is fully booked for transport tasks in the next 3 days and only has free time on the 4th and 5th days, there is no overlap with the order requirement of delivery within 3 days, so the time matching score is 0.

[0038] Then, based on the actual needs of logistics operations, different weights are assigned to load matching, volume matching, and time matching. For example, considering that whether the weight of the goods is compliant directly affects transportation safety, the weight matching weight is set to 40%, the volume matching weight to 30%, and the time matching weight to 30%. The weighted sum of each matching score is then used to obtain the overall matching score. Using the example data above, the overall matching score is calculated as follows: 60 × 40% + 66.7 × 30% + 60 × 30% = 24 + 20.01 + 18 = 62.01 points. Following the same method, after calculating the overall matching degree between the authentication request order and all available capacity data combinations, these combinations are sorted from high to low according to their overall matching degree. For example, a combination with an overall matching degree of 85 points is ranked first, a combination with 62.01 points is ranked fifth, and a combination with 30 points is ranked twelfth. Finally, a capacity matching degree list is formed according to priority. The list not only includes the overall matching degree score of each combination, but also marks the corresponding key order attributes and key capacity attributes, which is convenient for subsequent push to the order initiator for scheduling selection.

[0039] In a specific embodiment, the capacity matching list is pushed to the corresponding order initiator to achieve intelligent scheduling and real-time optimized allocation of multi-channel request orders, including: Based on the protocol type identifier, add a corresponding exclusive identifier field to the capacity matching list, and convert the capacity matching list data with the added identifier field into a JSON format push data packet; The push data packet is sent to the order initiator through the ACK confirmation mechanism, and the receiver is waited for the confirmation signal. If no confirmation signal is received within the preset timeout period, the re-push mechanism is triggered and the push result record is obtained. Based on the legitimate order requests in the push result record, the transportation resources corresponding to the successfully pushed orders are marked as occupied, and the corresponding transportation resources are deducted from the available transportation resources data to obtain the remaining allocable amount. Orders that failed to push or whose order initiators reported abandoning the selected capacity are added back to the preset pool of orders to be matched. A second matching is triggered by combining the real-time updated remaining allocable capacity to achieve intelligent scheduling and real-time optimized allocation of orders requested from multiple channels.

[0040] Specifically, when pushing the capacity matching list to the corresponding order initiator to achieve intelligent scheduling and real-time optimized allocation of multi-channel request orders, the system first adds a corresponding exclusive identifier field to the capacity matching list based on the previously obtained protocol type identifier. For example, if the protocol type identifier of an order initiator is "JSON-e-commerce A", then the exclusive identifier field "Platform:E-commerceA" is added to the capacity matching list of that order. If the protocol type identifier is "XML-store B", then the identifier field "Platform:StoreB" is added. After the identifier is added, the capacity matching list data with exclusive identifier fields is converted into a JSON format push data package using a data format conversion tool to ensure that the data can be correctly parsed by the systems of different order initiators.

[0041] Next, a push data packet is sent to the order initiator via the ACK confirmation mechanism. Taking e-commerce platform A as an example, the system will send a JSON-formatted push data packet to its preset receiving interface and start a timer to wait for the receiving end to send a confirmation signal. A timeout of 30 seconds is preset. If an "ACK:Received" signal is received from e-commerce platform A within 30 seconds, the push result is recorded as successful. If no confirmation signal is received after 30 seconds, the system will automatically trigger a re-push mechanism to send the same push data packet again. The push can be repeated up to 2 times. If no confirmation signal is received after 2 re-pushes, the push result is recorded as failed. All push success or failure information will be summarized to form a push result record.

[0042] Then, based on the legitimate order requests in the push results record, the transportation resources corresponding to the successfully pushed orders are marked as occupied. For example, if e-commerce platform A successfully pushes 50 orders, and each order is matched with one 4.2-meter truck from company A, the "occupied - e-commerce A" mark is added to the available transportation resources data of company A. At the same time, the corresponding transportation resources are deducted from the statistics module of available transportation resources data. Assuming that company A originally had 20 4.2-meter trucks in an idle state, after deducting the 50 trucks corresponding to the 50 orders (if a single truck can handle multiple orders, the deduction is based on the actual number of orders handled; here, it is assumed that each truck handles 1 order), if the actual number of idle vehicles is insufficient, the deduction is based on the actual number of vehicles, and finally the remaining allocable capacity is obtained, for example, 8 trucks remain after deduction. This remaining allocable capacity will be updated to the available transportation capacity database in real time.

[0043] Finally, for orders that fail to be pushed, such as the 10 store B orders that failed to receive a confirmation signal due to timeout, and the 5 enterprise C orders that the order initiator reported abandoning the selected capacity, these orders will be added to a preset pool of orders to be matched. The system will periodically check the number of orders in the pool of orders to be matched. When the number of orders reaches 20 or the interval is 10 minutes, a second matching will be triggered based on the real-time updated remaining allocable capacity (such as the remaining 8 trucks of A Express and the idle capacity added by other enterprises). A new capacity matching list will be generated according to the previous matching degree calculation method, and the push process will be executed again. Through such a cyclical operation, intelligent scheduling and real-time optimized allocation of orders requested from multiple channels can be achieved, ensuring that each legitimate order can be matched with suitable capacity as much as possible, while avoiding the waste of capacity resources.

[0044] In a specific embodiment, a corresponding exclusive identifier field is added to the capacity matching list based on the protocol type identifier, including: The protocol type identifier is converted into a dedicated identifier field through a preset identifier mapping rule. The identifier mapping rule is the correspondence between different protocol type identifiers and dedicated identifier fields. Add a unique identifier field to the standardized request orders in the capacity matching list.

[0045] Specifically, when adding a corresponding exclusive identifier field to the capacity matching list based on the protocol type identifier, the system first calls the preset identifier mapping rules. These rules clearly record the correspondence between different protocol type identifiers and exclusive identifier fields. For example, when the protocol type identifier is "JSON-e-commerce platform A", the corresponding exclusive identifier field is "Source:E-commerceA_Json"; when the protocol type identifier is "XML-offline store B", the exclusive identifier field is "Source:StoreB_Xml"; and if the protocol type identifier is "Private-enterprise customer C", the exclusive identifier field is set to "Source:EnterpriseC_Private". Once the correspondence is established, the protocol type identifier corresponding to each standardized request order is found in the capacity matching list. It is then converted into a unique identifier field according to the identifier mapping rules. Next, a new field is added to the data entry of each standardized request order, and the converted unique identifier field is filled in. For example, the original information of a standardized request order includes the order number, overall matching degree, and capacity information. After adding the unique identifier field, a unique identifier field such as "Source:E-commerceA_Json" will be added after these information. This ensures that each standardized request order can clearly identify the source corresponding to its original protocol type through the unique identifier field, which facilitates accurate identification of the order initiator in the subsequent push process.

[0046] The above describes the multi-channel real-time capacity matching method based on an API gateway in the embodiments of the present invention. The following describes the multi-channel real-time capacity matching system based on an API gateway in the embodiments of the present invention. Please refer to [link / reference]. Figure 2 One embodiment of the multi-channel real-time capacity matching system based on an API gateway in this invention includes: The receiving module 21 is used to process the multi-channel request orders received from the API gateway according to the preset protocol conversion rules to obtain standardized request orders; Authentication module 22 is used to authenticate the standardized request order, obtain the authentication request order, acquire the available transportation capacity data of each express delivery and freight company, calculate the matching degree between the authentication request order and the available transportation capacity data, and obtain a transportation capacity matching degree list. The push module 23 is used to push the capacity matching list to the corresponding order initiator to realize intelligent scheduling and real-time optimized allocation of multi-channel request orders.

[0047] In this embodiment, the specific implementation of each unit in the above system embodiment is the same as that in the above method embodiment, and will not be repeated here.

[0048] like Figure 3 As shown in the diagram, this embodiment of the invention provides a structural schematic block diagram of a computer device, including: At least one processor; At least one memory for storing at least one program; When at least one program is executed by at least one processor, the at least one processor implements the above-described multi-channel capacity real-time matching method based on API gateway.

[0049] It is evident that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented in this device embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0050] Furthermore, this application also discloses a computer program product or computer program stored in a computer-readable storage medium. A processor of a computer device can read the computer program from the computer-readable storage medium and execute the computer program, causing the computer device to perform the aforementioned multi-channel capacity real-time matching method based on an API gateway. Similarly, the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0051] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.< / receiveraddress> < / ordernumber>

Claims

1. An API gateway-based multi-channel capacity real-time matching method, characterized in that, The method comprises the following steps: The multi-channel request order received from the API gateway is processed in protocol format by using preset protocol conversion rules to obtain a standardized request order; The standardized request order is subjected to identity authentication to obtain an authenticated request order, and available capacity data of each express and express delivery enterprise is obtained, and the authenticated request order and the available capacity data are subjected to matching degree calculation to obtain a capacity matching degree list; The capacity matching degree list is pushed to the corresponding order initiator to realize intelligent scheduling and real-time optimized distribution of the multi-channel request order.

2. The API gateway based multi-channel capacity real-time matching method according to claim 1, characterized in that, The multi-channel request order received from the API gateway is processed in protocol format by using preset protocol conversion rules to obtain a standardized request order, comprising: The multi-channel request order received from the API gateway is subjected to protocol header analysis to obtain protocol type identifiers of each channel request order, and the protocol type identifiers are classified and arranged to obtain classified protocol types; Based on the classified protocol types, each channel request order is subjected to format conversion by using corresponding protocol conversion rules to convert each channel request order in different protocol formats into a standardized request order in a unified internal protocol format.

3. The API gateway based multi-channel capacity real-time matching method according to claim 1, characterized in that, After the step of obtaining the standardized request order, comprising: The total amount of requests of the standardized request order in a unit time is counted, and the request amount change trend of the total amount of requests is monitored in real time; Based on the request amount change trend, the standardized request order is preliminarily screened by setting a flow threshold value in a flow control module, and when the request amount change trend exceeds the flow threshold value, the part exceeding the flow threshold value is marked as a to-be-processed request to obtain a mixed request containing normal requests and to-be-processed requests; The to-be-processed request in the mixed request is subjected to delay processing or discard processing, and the normal request is marked to obtain a controlled order request.

4. The API gateway based multi-channel capacity real-time matching method according to claim 1, characterized in that, The standardized request order is subjected to identity authentication to obtain an authenticated request order, comprising: The standardized request order is subjected to request data splitting to separate out request body data, and the request body data is subjected to key field positioning to extract key fields containing user identity features, wherein the key fields include a user unique identification code and an encrypted identity token; The user unique identification code is subjected to hash operation to generate an identity hash value of fixed length, and the encrypted identity token is subjected to decryption operation to obtain decrypted identity plaintext information; The identity hash value is compared with a preset legal identity hash library to obtain a hash matching state, and the identity plaintext information is subjected to string matching with a preset legal identity plaintext library to obtain a plaintext matching state; When both the hash matching state and the plaintext matching state are successful, it is determined that the standardized request order passes the identity authentication, and when one of the hash matching state and the plaintext matching state fails, a secondary verification process is started. The secondary verification process sends a dynamic verification code to the user's reserved contact information and requires the user to feed back the dynamic verification code to the system within a specified time. The system compares the feedback dynamic verification code with the generated dynamic verification code. If the comparison is successful, it is determined that the identity authentication is passed. If the comparison fails, it is determined that the identity authentication fails. The standardized request order with a passed identity authentication is taken as an authentication request order.

5. The API gateway based multi-channel capacity real-time matching method according to claim 2, characterized in that, The authentication request order and the available transport capacity data are matched to obtain a transport capacity matching degree list, including: The order attributes of the authentication request order are extracted to obtain order key attributes including order weight, order volume, and order delivery time requirements. The transport capacity attributes of the available transport capacity data are extracted to obtain transport capacity key attributes including vehicle load, vehicle volume, and vehicle transportable time range; The order weight and the vehicle load are compared numerically to obtain a load matching degree. The order volume and the vehicle volume are compared numerically to obtain a volume matching degree. The order delivery time requirements and the vehicle transportable time range are calculated to obtain a time matching degree. The load matching degree, the volume matching degree, and the time matching degree are summed to obtain a comprehensive matching degree. The combinations of the authentication request order and the available transport capacity data are sorted in descending order of the comprehensive matching degree to obtain the transport capacity matching degree list.

6. The API gateway based multi-channel capacity real-time matching method according to claim 5, characterized in that, The transport capacity matching degree list is pushed to the corresponding order initiation end to realize intelligent scheduling and real-time optimization allocation of multi-channel request orders, including: Based on the protocol type identifier, a corresponding exclusive identifier field is added to the transport capacity matching degree list, and the transport capacity matching degree list data with the added identifier field is converted into a JSON format push data packet; The push data packet is sent to the order initiation end through the ACK confirmation mechanism, and the received confirmation signal is waited for feedback from the receiving end. If no confirmation signal is received within a preset timeout time, a push mechanism is triggered to obtain a push result record; Based on the legal order request in the push result record, the transport capacity resources corresponding to the successfully pushed orders are marked as occupied, and the corresponding transport capacity resources are deducted from the available transport capacity data to obtain the remaining allocatable amount; Orders that fail to be pushed or that are fed back by the order initiation end to give up selecting transport capacity are added to a preset matching order pool. Combined with the real-time updated remaining allocatable amount, secondary matching is triggered to realize intelligent scheduling and real-time optimization allocation of multi-channel request orders.

7. The API gateway based multi-channel capacity real-time matching method according to claim 6, characterized in that, Based on the protocol type identifier, a corresponding exclusive identifier field is added to the transport capacity matching degree list, including: The protocol type identifier is converted into an exclusive identifier field through a preset identifier mapping rule, where the identifier mapping rule is the correspondence between different protocol type identifiers and exclusive identifier fields; The exclusive identifier field is added to the standardized request order in the transport capacity matching degree list.

8. An API gateway-based multi-channel capacity real-time matching system, characterized in that, including: The receiving module is configured to process multi-channel request orders received from the API gateway in a protocol format using a preset protocol conversion rule to obtain standardized request orders; An authentication module is configured to authenticate the standardized request order, obtain an authentication request order, acquire available capacity data of each express and express enterprise, perform matching degree calculation on the authentication request order and the available capacity data, and obtain a capacity matching degree list. A pushing module is configured to push the capacity matching degree list to a corresponding order initiating end, so as to realize intelligent scheduling and real-time optimized distribution of multi-channel request orders. 9.A computer device, comprising a memory and a processor, wherein the memory stores a computer program, and the computer device is configured to perform the method according to any one of claims 1-8. The processor implements the steps of the method of any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program, when executed by the processor, implements the steps of the method of any one of claims 1 to 7.

Images