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

Abstract

The application relates to an API gateway-based multi-channel transport capacity real-time matching method and system, which comprises the following steps: adopting preset protocol conversion rules to perform protocol format processing on multi-channel request orders received from an API gateway to obtain standardized request orders; performing identity authentication on the standardized request orders to obtain authentication request orders, acquiring available transport capacity data of each express and express delivery enterprise, performing matching degree calculation on the authentication request orders and the available transport capacity data to obtain a transport capacity matching degree list; and pushing the transport capacity matching degree list to a corresponding order initiator to realize intelligent scheduling and real-time optimized distribution of the multi-channel request orders, thereby solving the technical problems that the initial cycle of order processing is prolonged in the traditional technology, and order information is easily lost or disordered due to format analysis errors.

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:

[0004] The multi-channel request orders received from the API gateway are processed according to the preset protocol conversion rules to obtain standardized request orders;

[0005] 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.

[0006] 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.

[0007] 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:

[0008] 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.

[0009] 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.

[0010] Furthermore, after obtaining the standardized request order, the process includes:

[0011] 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.

[0012] 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.

[0013] The pending requests in the mixed requests are delayed or discarded, while the normal requests are marked to obtain controlled order requests.

[0014] Furthermore, the standardized request order is authenticated to obtain an authenticated request order, including:

[0015] 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.

[0016] 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.

[0017] 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.

[0018] 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.

[0019] 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.

[0020] Furthermore, the matching degree of the authentication request order and the available capacity data is calculated to obtain a capacity matching degree list, including:

[0021] 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.

[0022] 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.

[0023] 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.

[0024] 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:

[0025] 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;

[0026] 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.

[0027] 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.

[0028] 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.

[0029] Furthermore, based on the protocol type identifier, a corresponding exclusive identifier field is added to the capacity matching list, including:

[0030] 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.

[0031] Add a unique identifier field to the standardized request orders in the capacity matching list.

[0032] This invention also provides a multi-channel real-time capacity matching system based on an API gateway, comprising:

[0033] 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;

[0034] 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.

[0035] 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.

[0036] 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.

[0037] 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.

[0038] 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

[0039] 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:

[0040] 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.

[0041] 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;

[0042] Figure 3 This is a schematic block diagram of the structure of a computer device according to an embodiment of the present invention.

[0043] 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

[0044] 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.

[0045] 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.

[0046] 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.

[0047] 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.

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

[0049] 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:

[0050] 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.

[0051] 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.

[0052] 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.

[0053] 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.

[0054] 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.

[0055] 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.

[0056] 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:

[0057] 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.

[0058] 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.

[0059] 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 extracted from the tag is filled into the "Recipient Address" field. For orders with private protocols, the information corresponding to "ORD-NO" is converted into "Order Number" and the information corresponding to "REC-ADDR" is converted into "Recipient Address" according to the pre-agreed field correspondence with partner C. Through this conversion operation, orders from various channels with different protocol formats can be uniformly converted into standardized order requests using a unified internal protocol format with a pre-set structure on the platform. Throughout the process, the conversion rules for 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 JSON format orders from an e-commerce platform, even if some field names differ from the internal protocol, they can be accurately converted through fixed mapping rules without any omissions or mismatches. For private protocol orders, the conversion can be completed efficiently because the field correspondence is clear in advance. Ultimately, all orders from different channels have a unified format, providing a standardized data foundation for subsequent traffic restrictions, identity authentication, and other processes.

[0060] In a specific embodiment, after the step of obtaining the standardized request order, the following steps are included:

[0061] 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.

[0062] 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.

[0063] The pending requests in the mixed requests are delayed or discarded, while the normal requests are marked to obtain controlled order requests.

[0064] Specifically, after receiving standardized order requests, the system first counts the total number of standardized order requests per unit of time. For example, if the unit of time is set to 1 minute, the system backend counter accumulates the number of all standardized order requests received per minute in real time. At the same time, a line graph tool is used to dynamically display the fluctuation of the total number of requests per minute, thereby monitoring the trend of the total number of requests in real time. For example, in the 5th minute after the start of an e-commerce promotion, the total number of requests suddenly increased from 300 orders per minute to 800 orders, and continued to increase by 100 orders per minute in the following minutes. This continuous upward trend constitutes the trend of the request volume at that time. Next, based on this request volume trend, standardized request orders are initially 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's carrying capacity, when the monitoring of the request volume trend shows that the subsequent request volume per minute will exceed 600 orders, the standardized requests exceeding 600 orders will be marked as pending requests. For example, if 800 orders are actually received in a certain minute, then 600 of them are normal requests, and the other 200 are marked as pending requests, thus obtaining a mixed request that includes normal requests and pending requests. The system then delays or discards pending requests within the mixed requests. If these pending requests are ordinary e-commerce orders and the system anticipates server resources will be available in 30 minutes, they are temporarily stored in the pending queue and processed after 30 minutes. If the pending requests are duplicate or invalid orders, they are discarded after simple verification. Simultaneously, normal requests within the mixed requests are marked as "passed traffic filtering." Through this process, a controlled set of order requests is obtained, including marked normal requests and the remaining pending requests after delays or discards. Throughout this process, the traffic threshold is flexibly adjusted based on real-time server resource usage. For example, when server CPU utilization is below 50%, the threshold can be increased to 800 orders per minute, while when CPU utilization exceeds 80%, the threshold is decreased to 400 orders per minute, ensuring that traffic limiting avoids system overload while maximizing server resource utilization.

[0065] In a specific embodiment, the standardized request order is authenticated to obtain an authenticated request order, including:

[0066] 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.

[0067] 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.

[0068] 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.

[0069] 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.

[0070] 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.

[0071] Specifically, when authenticating a standardized request order to obtain an authenticated request order, the request data is first split, separating the protocol header, additional parameters, and request body data, leaving only the request body data containing core information. Then, a field recognition tool is used to locate key fields in the request body data. For example, in a standardized request order on an e-commerce platform, "user_code:U20250601089" is found from the "user_auth" module as the user's unique identifier, and "token:8a7f3...d2c91" is extracted from the "security_info" module as the encrypted identity token, thereby obtaining key fields containing user identity characteristics. The extracted user unique identifier "U20250601089" is then subjected to a SHA-256 hash operation to generate a 64-bit fixed-length identity hash value, "3e4b8...9c7a2". Simultaneously, the encrypted identity token "8a7f3...d2c91" is decrypted using the pre-agreed RSA decryption algorithm and the private key stored in the system, yielding the plaintext identity information "user:U20250601089;valid_time:20250601-20250607".

[0072] After completing the calculation and decryption, the generated identity hash value is compared with a preset legitimate identity hash database. The legitimate identity hash database stores the SHA-256 hash values ​​corresponding to the unique identifiers of all registered users. If an entry that completely matches "3e4b8...9c7a2" is found, the hash match status is successful; otherwise, it is a failure. At the same time, the decrypted identity plaintext information is matched with a preset legitimate identity plaintext database to check whether the user identifier in "user:U20250601089;valid_time:20250601-20250607" exists and whether the validity period is within the current time range. If both requirements are met, the plaintext match status is successful; otherwise, it is a failure.

[0073] When both hash matching and plaintext matching are successful, the standardized request order is directly deemed to have passed identity authentication. If either matching status fails, such as a successful hash match but the plaintext identity information has expired, a secondary verification process is initiated. This process first retrieves the user's pre-registered contact information from the system database. If it's a mobile number like "139XXXX5678", a randomly generated 6-digit dynamic verification code "628941" is sent via SMS. A 10-minute feedback period is set, requiring the user to submit the dynamic verification code to the system through the order initiator's verification window within 10 minutes. After the user submits the verification code, the system compares the returned verification code with the generated "628941" digit by digit. If they match exactly, identity authentication is considered successful. If the returned verification code is incorrect or not submitted within the specified time, identity authentication fails. Finally, only standardized request orders that have passed identity authentication are considered authentication request orders and proceed to the subsequent available capacity data matching stage.

[0074] In a specific embodiment, the matching degree of the authentication request order and the available capacity data is calculated to obtain a capacity matching degree list, including:

[0075] 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.

[0076] 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.

[0077] 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.

[0078] 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.

[0079] 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.

[0080] 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.

[0081] 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:

[0082] 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;

[0083] 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.

[0084] 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.

[0085] 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.

[0086] 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.

[0087] 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.

[0088] 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.

[0089] 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.

[0090] In a specific embodiment, a corresponding exclusive identifier field is added to the capacity matching list based on the protocol type identifier, including:

[0091] 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.

[0092] Add a unique identifier field to the standardized request orders in the capacity matching list.

[0093] 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.

[0094] 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:

[0095] 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;

[0096] 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.

[0097] 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.

[0098] 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.

[0099] like Figure 3 As shown in the diagram, this embodiment of the invention provides a structural schematic block diagram of a computer device, including:

[0100] At least one processor;

[0101] At least one memory for storing at least one program;

[0102] 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.

[0103] 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.

[0104] 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.

[0105] 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; Identity authentication is performed on the standardized request order to obtain an authentication request order, available transport capacity data of each express and express delivery enterprise is acquired, matching degree calculation is performed on the authentication request order and the available transport capacity data to obtain a transport capacity matching degree list; The transport capacity matching degree list is pushed to the corresponding order initiation end to realize intelligent scheduling and real-time optimized allocation of the multi-channel request order; Identity authentication is performed on the standardized request order to obtain an authentication request order, including: Request data splitting is performed on the standardized request order to separate out request body data, and key field positioning is performed on the request body data to extract key fields containing user identity features, wherein the key fields include a user unique identification code and an encrypted identity token; Hash operation is performed on the user unique identification code to generate an identity hash value of a fixed length, and decryption operation is performed on the encrypted identity token 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 string matching is performed on the identity plaintext information and 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 a 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 fed-back dynamic verification code with the generated dynamic verification code, and if the comparison is successful, it is determined that the identity authentication passes, and if the comparison fails, it is determined that the identity authentication fails, and the standardized request order that passes the identity authentication is taken as the authentication request order; Matching degree calculation is performed on the authentication request order and the available transport capacity data to obtain a transport capacity matching degree list, including: Order attribute extraction is performed on the authentication request order to obtain order key attributes including order weight, order volume and order delivery time requirement, and transport capacity attribute extraction is performed on the available transport capacity data to obtain transport capacity key attributes including vehicle load, vehicle volume and vehicle transportable time range; Numerical comparison is performed on the order weight and the vehicle load to obtain a load matching degree, numerical comparison is performed on the order volume and the vehicle volume to obtain a volume matching degree, and time range overlap calculation is performed on the order delivery time requirement and the vehicle transportable time range to obtain a time matching degree; Weighted summation is performed on the load matching degree, the volume matching degree and the time matching degree to obtain a comprehensive matching degree, and the combination of the authentication request order and the available transport capacity data is sorted in descending order of the comprehensive matching degree to obtain the transport capacity matching degree list; The transport capacity matching degree list is pushed to the corresponding order initiation end to realize intelligent scheduling and real-time optimized allocation of the multi-channel request order, including: Add a corresponding exclusive identification field to the transport capacity matching degree list based on the protocol type identification, and convert the transport capacity matching degree list data with the added identification field into a push data packet in JSON format; Send the push data packet to the order initiator through an ACK confirmation mechanism, and wait for the received confirmation signal from the feedback end. If no confirmation signal is received within the preset timeout period, trigger the push mechanism to obtain a push result record; Based on the legal order request in the push result record, mark the transport capacity resources corresponding to the successfully pushed orders as occupied, and deduct the corresponding transport capacity resources from the available transport capacity data to obtain the remaining allocable amount; Re-add the orders that failed to push or that the order initiator feeds back as giving up selecting transport capacity to the preset matching order pool, and trigger a secondary matching in combination with the real-time updated remaining allocable amount to realize intelligent scheduling and real-time optimized allocation of multi-channel request orders.

2. The API gateway based multi-channel capacity real-time matching method of claim 1, wherein, Adopt a preset protocol conversion rule to process the multi-channel request orders received from the API gateway in a protocol format to obtain standardized request orders, including: Perform protocol header analysis on the multi-channel request orders received from the API gateway to obtain protocol type identifications of the request orders of each channel, and classify and organize the protocol type identifications to obtain classified protocol types; Based on the classified protocol types, adopt corresponding protocol conversion rules to convert the request orders of each channel in different protocol formats into standardized request orders in a unified internal protocol format.

3. The API gateway based multi-channel capacity real-time matching method of claim 1, wherein, After obtaining the standardized request orders, including: Statistical the total amount of requests of the standardized request orders within a unit of time, and monitor the request amount trend of the total amount of requests in real time; Based on the request amount trend, preliminarily screen the standardized request orders by setting a traffic threshold in the traffic control module. When the request amount trend exceeds the traffic threshold, mark the exceeding part of the standardized request orders as pending requests to obtain mixed requests containing normal requests and pending requests; Delay or discard the pending requests in the mixed requests, and mark the normal requests to obtain controlled order requests.

4. The API gateway based multi-channel capacity real-time matching method of claim 1, wherein, Add a corresponding exclusive identification field to the transport capacity matching degree list based on the protocol type identification, including: Convert the protocol type identification into an exclusive identification field through a preset identification mapping rule, wherein the identification mapping rule is the correspondence between different protocol type identifications and exclusive identification fields; Add the exclusive identification field to the standardized request orders in the transport capacity matching degree list.

5. An API gateway-based multi-channel capacity real-time matching system, characterized in that, Including: A receiving module configured to adopt a preset protocol conversion rule to process multi-channel request orders received from an API gateway in a protocol format to obtain standardized request orders; An authentication module configured to perform identity authentication on the standardized request orders to obtain authenticated request orders, acquire available transport capacity data of each express and express delivery enterprise, and perform matching degree calculation on the authenticated request orders and the available transport capacity data to obtain a transport capacity matching degree list; The push module is configured to push the transport capacity matching degree list to the corresponding order initiating end to realize intelligent scheduling and real-time optimized allocation of multi-channel request orders. Identity authentication is performed on the standardized request order to obtain an authenticated request order, including: Request data splitting is performed on the standardized request order to separate out request body data, and key field positioning is performed on the request body data to extract key fields containing user identity features, wherein the key fields include a user unique identification code and an encrypted identity token. Hash operation is performed on the user unique identification code to generate an identity hash value of a fixed length, and decryption is performed on the encrypted identity token 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 string matching is performed on the identity plaintext information and 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 a 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 fed-back dynamic verification code with the generated dynamic verification code. If the comparison is successful, it is determined that the identity authentication passes, and if the comparison fails, it is determined that the identity authentication fails. The standardized request order that passes the identity authentication is taken as the authenticated request order. Matching degree calculation is performed on the authenticated request order and the available transport capacity data to obtain a transport capacity matching degree list, including: Order attribute extraction is performed on the authenticated request order to obtain order key attributes including order weight, order volume and order delivery time requirement, and transport capacity attribute extraction is performed on the available transport capacity data to obtain transport capacity key attributes including vehicle load, vehicle volume and vehicle transportable time range. Numerical comparison is performed on the order weight and the vehicle load to obtain a load matching degree, numerical comparison is performed on the order volume and the vehicle volume to obtain a volume matching degree, and time range overlap calculation is performed on the order delivery time requirement and the vehicle transportable time range to obtain a time matching degree. Weighted summation is performed on the load matching degree, the volume matching degree and the time matching degree to obtain a comprehensive matching degree, and the combination of the authenticated request order and the available transport capacity data is sorted in descending order of the comprehensive matching degree to obtain the transport capacity matching degree list. The transport capacity matching degree list is pushed to the corresponding order initiating end to realize intelligent scheduling and real-time optimized allocation of multi-channel request orders, including: A corresponding exclusive identification field is added to the transport capacity matching degree list based on a protocol type identifier, and the transport capacity matching degree list data with the added identification field is converted into a JSON format push data packet. The push data packet is sent to the order initiating end through an ACK confirmation mechanism, and the system waits for the feedback of a received confirmation signal from the receiving end. If no confirmation signal is received within a preset timeout period, a re-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 in the available transport capacity data to obtain a remaining allocable amount; Orders that fail to be pushed or that are abandoned by the order initiator are re-added to a preset order pool to be matched, and a secondary matching is triggered in combination with the real-time updated remaining allocable amount, so as to realize intelligent scheduling and real-time optimized allocation of orders requested through multiple channels. 6.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-5 when the computer program is executed by the processor. The processor, when executing the computer program, implements the steps of the method of any one of claims 1 to 4.

7. 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 4.

Images