A three-party routing system and method for warehousing business

Abstract

The application provides a three-party routing system and method for warehouse business, and relates to the technical field of warehouse management.The system comprises a routing configuration module, a capability point definition module, a capability point registration module, a routing matching module and a routing execution module.The routing configuration module, the capability point definition module, the capability point registration module, the routing matching module and the routing execution module are sequentially connected.The routing configuration module is used for establishing a routing configuration relationship according to the warehouse number, the business type, the capability point and the dimension defined by the external three-party application.The routing matching module is used for matching in the routing configuration mapping according to the warehouse number, the business type and the capability point information in the business request, and determining the corresponding external three-party system configuration definition.The routing execution module is used for dynamically calling the specific capability point implementation of the corresponding three-party system based on the routing matching result, and completing the data interaction with the external system.

Description

Technical Field

[0001] This invention relates to the field of warehouse management technology, and in particular to a three-party routing system and method for warehouse operations. Background Technology

[0002] Warehousing operations refer to all processes occurring within a warehouse, typically requiring integration with a WMS (Warehouse Management System), e-commerce platforms, logistics platforms, or third-party warehousing service providers. "Third parties" usually refer to external systems, such as JD Logistics, external warehousing service provider systems, and third-party e-commerce ERP or OMS. A routing system is an automated system with "rules, mappings, capability points, and executors." A third-party routing system for warehousing operations, however, is a system specifically designed for warehousing business scenarios. Through a business routing mechanism, it automatically selects and invokes the specific capability interfaces of the corresponding external third-party systems (such as external warehousing systems, e-commerce platforms, and logistics platforms) to achieve data interaction and business processing.

[0003] Modern warehousing operations are becoming increasingly complex, diversified, and highly externalized. With the continued rapid growth of e-commerce and the continuous extension of supply chains, enterprises often no longer rely on a single warehousing system, but instead simultaneously connect to multiple external warehousing service providers (such as JD.com, Cainiao, and SF Express warehousing), different cargo owners' own systems, third-party logistics platforms, and special external applications such as cross-border and bonded warehousing. Therefore, designing a third-party routing system for warehousing operations can avoid the chaos and lack of scalability caused by hard-coded code, ensuring a stable, flexible, and sustainable evolution of the integration process.

[0004] However, existing third-party routing systems for warehousing operations generally suffer from limitations such as insufficient flexibility, weak scalability, and high maintenance costs. Most systems maintain routing logic using hard-coding, with the mapping between warehouses, business types, and third-party interfaces fixed in the code. Changes to external systems necessitate program modifications, making it difficult to adapt to dynamic business needs involving multiple warehouses, multiple cargo owners, and multiple systems. Furthermore, the lack of a unified capability abstraction results in strong coupling between internal business logic and external interfaces, requiring significant repetitive development when adding or replacing third-party systems. In addition, traditional systems typically only support single-dimensional routing, failing to accurately match based on business combination conditions. They are also weak in exception handling and retry mechanisms, unable to effectively manage issues such as third-party system call failures, timeouts, or format differences. Summary of the Invention

[0005] In view of the shortcomings of the prior art, the purpose of this invention is to provide a third-party routing method for warehousing operations, which can solve the technical problems of traditional systems that usually only support single-dimensional routing, cannot accurately match according to business combination conditions, are weak in exception handling and retry mechanisms, and cannot effectively manage third-party system call failures, timeouts or format differences.

[0006] In a first aspect, this invention proposes a third-party routing system for warehousing operations, comprising: a routing configuration module, a capability point definition module, a capability point registration module, a routing matching module, and a routing execution module;

[0007] The route configuration module, capability point definition module, capability point registration module, route matching module, and route execution module are connected in sequence;

[0008] The routing configuration module is used to establish routing configuration relationships based on warehouse number, business type, capability points, and dimensions defined by external third-party applications.

[0009] The route matching module is used to match the warehouse number, business type and capability point information in the business request in the route configuration mapping to determine the corresponding external third-party system configuration definition.

[0010] The routing execution module is used to dynamically call the specific capabilities of the corresponding third-party system based on the routing matching results, and complete the data interaction with the external system.

[0011] A second aspect of this invention provides a three-party routing method for warehousing operations, applied to the three-party routing system of the first aspect, comprising:

[0012] S1: Receives external routing call requests from business systems;

[0013] S2: Extract route matching parameters from external route call requests;

[0014] S3: Based on the routing matching parameters and the routing configuration table, determine the unique definition of the external application and the capability points corresponding to the unique definition of the external application.

[0015] S4: Based on the unique definition of the external application, locate the specific implementation method of the corresponding capability point in the capability point mapping relationship;

[0016] S5: Dynamically invoke specific implementation methods and assemble business data parameters based on third-party system interface specifications;

[0017] S6: Record the execution status and return results of dynamic calls;

[0018] S7: Based on the execution status and return results, exceptions generated during the call process are classified and handled through the business system.

[0019] The beneficial effects of the technical solutions provided in the embodiments of the present invention include at least the following:

[0020] In this embodiment of the invention, by sequentially combining the routing configuration module, capability point definition module, capability point registration module, routing matching module, and routing execution module into a unified routing system, the system achieves complete decoupling and automation of external integration processes for warehousing operations. By constructing configurable routing relationships based on warehouse number, business type, capability points, and external third-party applications, the system can flexibly adapt to the selection requirements of third-party systems in different warehouses and business scenarios. Through the dynamic matching mechanism of the routing matching module, it ensures that business requests accurately locate the corresponding external third-party system configuration in a multi-system coexistence environment. Furthermore, through the dynamic capability point invocation method of the routing execution module, the system can automatically trigger the interface capability points of the target third-party system based on the matching results, achieving standardization and automation of data interaction. In summary, this solution significantly improves the flexibility, scalability, and operational efficiency of third-party integration in warehousing operations through configuration-based management, multi-dimensional routing matching, and dynamic execution mechanisms. It avoids the high maintenance costs associated with hard coding and enables the system to maintain stable and efficient integration capabilities in a complex and ever-changing warehousing ecosystem. Attached Figure Description

[0021] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts. Obviously, the drawings described below are merely some embodiments of the present invention, and those skilled in the art can obtain other drawings based on these drawings without any creative effort.

[0022] Figure 1 This is a schematic diagram of the structure of a third-party routing system for warehousing operations provided in an embodiment of the present invention.

[0023] Figure 2 This is a flowchart illustrating a third-party routing method for warehousing operations provided in an embodiment of the present invention. Detailed Implementation

[0024] To enable those skilled in the art to better understand the technical solutions in the embodiments of the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. It should be understood that these descriptions are merely exemplary and are not intended to limit the scope of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0025] The following description, in conjunction with the accompanying drawings, details the third-party routing method for warehousing operations provided by the embodiments of the present invention through specific implementations and application scenarios.

[0026] Reference manual attached Figure 1 The diagram shows a schematic representation of a three-party routing system for warehousing operations provided by an embodiment of the present invention.

[0027] This invention provides a third-party routing system for warehousing operations, comprising: a routing configuration module, a capability point definition module, a capability point registration module, a routing matching module, and a routing execution module.

[0028] The routing configuration module, capability point definition module, capability point registration module, route matching module, and route execution module are connected in sequence.

[0029] The routing configuration module is used to establish routing configuration relationships based on warehouse number, business type, capability points, and dimensions defined by external third-party applications.

[0030] The route matching module is used to match the warehouse number, business type, and capability point information in the business request in the route configuration mapping to determine the corresponding external third-party system configuration definition.

[0031] The routing execution module is used to dynamically call the specific capabilities of the corresponding third-party system based on the routing matching results, and complete the data interaction with the external system.

[0032] The routing configuration module is used to establish the mapping relationship between "business conditions → external systems", such as configuring which third-party system should be called based on dimensions such as warehouse number, business type, and capability points.

[0033] The capability point definition module is used to abstract and define the interface capabilities of external systems, such as "shipping notification", "inventory synchronization" and "cancellation of documents", forming standardized business capability points.

[0034] The capability point registration module is used to scan, identify and register the capability point implementations of each third-party system, and establish a mapping relationship between the specific code implementation and the capability point definition.

[0035] The route matching module refers to searching for matching external third-party system configurations in the route configuration based on the warehouse number, business type, and capability point identifier in the business request.

[0036] The routing execution module is used to dynamically call the corresponding third-party system's capabilities based on the matching results, and to complete data conversion, call execution, and result return.

[0037] It should be noted that by modularly dividing the routing configuration, capability point definition, matching and execution process, this solution achieves complete decoupling between business logic and external interfaces, enabling the system to dynamically select third-party systems based on different repositories and business needs. This improves integration efficiency, scalability and maintainability, and avoids the complexity and change risks caused by hard coding.

[0038] In this embodiment of the invention, by sequentially combining the routing configuration module, capability point definition module, capability point registration module, routing matching module, and routing execution module into a unified routing system, the system achieves complete decoupling and automation of external integration processes for warehousing operations. By constructing configurable routing relationships based on warehouse number, business type, capability points, and external third-party applications, the system can flexibly adapt to the selection requirements of third-party systems in different warehouses and business scenarios. Through the dynamic matching mechanism of the routing matching module, it ensures that business requests accurately locate the corresponding external third-party system configuration in a multi-system coexistence environment. Furthermore, through the dynamic capability point invocation method of the routing execution module, the system can automatically trigger the interface capability points of the target third-party system based on the matching results, achieving standardization and automation of data interaction. In summary, this solution significantly improves the flexibility, scalability, and operational efficiency of third-party integration in warehousing operations through configuration-based management, multi-dimensional routing matching, and dynamic execution mechanisms. It avoids the high maintenance costs associated with hard coding and enables the system to maintain stable and efficient integration capabilities in a complex and ever-changing warehousing ecosystem.

[0039] Reference manual attached Figure 2 The diagram illustrates a flowchart of a three-party routing method for warehousing operations provided by an embodiment of the present invention.

[0040] This invention provides a flowchart illustrating a third-party routing method for warehousing operations, including:

[0041] S1: Receives external routing call requests from business systems.

[0042] Among them, the business system refers to the internal system of an enterprise responsible for handling core processes such as warehousing, orders, and inventory, such as WMS, ERP, and OMS. It is the initiator of routing calls.

[0043] Among them, the external routing call request refers to the standardized request message sent by the business system when it needs to interact with a certain external third-party system. It includes the warehouse number, business type, capability point identifier and data object to be processed, and is used to trigger the routing system to determine which external system and corresponding capability point should be called.

[0044] It's worth noting that by uniformly receiving external routing call requests initiated by business systems, a standardized entry point is established for the entire routing process. This avoids individual business modules handling third-party system integration logic independently, ensuring consistency, standardization, and controllability of the call chain from the source. Simultaneously, this step provides complete input for subsequent parameter parsing, route matching, and dynamic invocation, enabling the system to perform unified routing scheduling for multi-warehouse and multi-business scenarios, improving the scalability and maintenance efficiency of the overall integration process.

[0045] S2: Extract route matching parameters from external route call requests.

[0046] In one possible implementation, the routing matching parameters include: warehouse number, business type, and capability point identifier.

[0047] Among them, the warehouse number is used to identify the inventory warehouse to which the current business belongs, the document / business type is used to distinguish different business scenarios such as sales outbound, purchase inbound, inventory count, and damage reporting, and the capability point identifier is used to identify specific business capability points, such as outbound creation notification and result feedback.

[0048] In one possible implementation, S2 specifically includes:

[0049] S201: Receives a call request from an HTTP interface, performs protocol parsing on the message in the call request, and determines the internal business request object.

[0050] Among them, the HTTP interface call request refers to the request message sent by the business system to the routing system through the HTTP protocol, which usually contains business data, routing conditions, call identifiers and other content.

[0051] Protocol parsing refers to the processing of HTTP messages, such as deserialization, format parsing, and parameter extraction, to transform the original request into a data object that the system can recognize.

[0052] Among them, the internal business request object refers to the structured object formed inside the system after parsing, which contains fields related to business interaction, such as warehouse information, business type, data content, etc.

[0053] S202: Extract basic routing factors from the internal business request object based on the business type in the external routing call request.

[0054] S203: Construct a unified route request object based on the basic routing factors.

[0055] The unified routing request object includes: a warehouse number, document / business type, capability point identifier, and a business data object used to transmit to third-party systems.

[0056] S204: Validate the unified routing request object.

[0057] The verification includes integrity verification and consistency verification.

[0058] S205: Determine if the validation result passes. If yes, use the unified route request object as the route matching parameter. Otherwise, log the exception and terminate the current routing process.

[0059] It's important to note that by employing standardized request reception, parsing, parameter extraction, and validation mechanisms, the system ensures that the data structure entering the routing system is uniform, the parameters are accurate, and the business logic is consistent. This prevents routing errors caused by non-standard data formats or missing fields from the outset. By constructing a unified routing request object and performing rigorous validation, this solution significantly improves the accuracy and stability of subsequent route matching. This ensures that third-party system integration in multi-business, multi-warehouse scenarios has a reliable data foundation before execution, thereby enhancing the overall system's reliability and maintainability.

[0060] S3: Based on the routing matching parameters and the routing configuration table, determine the unique definition of the external application and the corresponding capability points.

[0061] The routing configuration table refers to all configured routing rules in the storage system for "business conditions → external systems", including multi-dimensional mapping relationships between warehouses, business types, capability points and external third-party systems.

[0062] Among them, the unique definition of external application is used to uniquely identify the definition information of a certain external third-party system, such as external system code, system identifier, system alias, to ensure that the system can accurately locate the target third-party system.

[0063] Among them, capability points are abstract descriptions of the capabilities of external system interfaces, such as "order placement", "inventory synchronization", and "order cancellation", which are the smallest business granularity for the system to call external services.

[0064] In one possible implementation, S3 specifically includes:

[0065] S301: Based on business needs, provide a routing configuration interface on the management side to set routing rules.

[0066] The routing rules include multi-dimensional factors such as warehouse number, external warehouse number, external owner number, external application unique definition, warehouse type, business type, capability point identifier, and routing status. Each routing rule corresponds to a record in the routing configuration table. When configuring, it is necessary to ensure that the record dimensions of warehouse number + business type / document type + capability point identifier + external application unique definition are globally unique.

[0067] S302: Store routing rules in the routing configuration table to form a multi-dimensional routing configuration mapping.

[0068] Specifically, a multi-dimensional routing configuration mapping is formed, with warehouse number, business type, capability point identifier, and unique definition of external application as the main dimensions, and external warehouse number, external cargo owner number, and warehouse type as the secondary dimensions.

[0069] S303: Load the enabled route configuration record from the route configuration table when the system starts up or the routing rules change.

[0070] Specifically, when the system starts up or the routing rules change, the routing configuration records that are enabled are loaded from the routing configuration table, and optionally grouped and cached in memory by warehouse number, business type, capability point identifier, and unique definition of external application to improve the query efficiency of runtime route matching.

[0071] S304: Based on the loading results, the capability point registration module constructs a secondary capability point mapping relationship by scanning third-party system processor classes with predefined identifiers.

[0072] Specifically, the mapping relationship for secondary capability points is as follows: unique definition by external application → capability point identifier → method implementation. The routing configuration mapping and capability point mapping together constitute a complete link from business requests to the specific third-party interface implementation.

[0073] S305: Based on the secondary capability point mapping relationship, filter the loaded route records in the multi-dimensional route configuration mapping to determine the globally unique route record that meets the main dimension conditions, that is, the capability point that is uniquely defined by the external application.

[0074] Specifically, the routing configuration mapping first uses "warehouse number + business type / document type + capability point identifier + activation status" for precise matching, and filters out globally unique routing records that meet the main dimension conditions, which significantly improves the scalability, flexibility and system autonomy of the three-party connection.

[0075] It should be noted that by maintaining routing rules through configuration on the management end and dynamically loading effective configurations when the system starts up or rules change, the routing system has high flexibility and real-time performance. By automatically constructing capability point mapping relationships by scanning third-party processor classes with predefined identifiers, zero-intrusion expansion can be achieved when adding external systems or capability points. Finally, by combining the secondary mapping to filter multi-dimensional routing rules, the unique external system capability point can be accurately located, thereby ensuring the accuracy and maintainability of routing decisions.

[0076] S4: Based on the unique definition of the external application, locate the specific implementation method of the corresponding capability point in the capability point mapping relationship.

[0077] Among them, the capability point mapping relationship refers to the mapping table recorded in the system that shows "capability point identifier → specific method implementation", including the associated processor class, method name, parameter type, protocol characteristics, etc., which is used to manage the actual code implementation of capability points of each third-party system.

[0078] Specifically, the specific implementation method of locating the corresponding capability point refers to finding the specific execution logic such as the processing class, processing method, parameter structure, etc. in the code of the external system through the unique definition of the external application and the capability point identifier, which is used for subsequent call execution.

[0079] It's important to note that by using a unique definition from an external application to precisely locate the specific implementation in the capability point mapping relationship, the routing system can quickly find the correct business processing logic in complex environments where multiple third-party systems coexist and multiple versions of capability point implementations exist, avoiding interface misuse or call errors. This mechanism completely decouples external system capability points from code implementation, enabling flexible expansion and dynamic management of capability points. It allows the system to add or replace third-party interfaces without modifying core logic, significantly improving the accuracy, maintainability, and scalability of the third-party interface system.

[0080] S5: Dynamically invokes specific implementation methods and assembles business data parameters based on third-party system interface specifications.

[0081] Among them, the third-party system interface specification refers to the request structure, field format, parameter requirements, encoding rules or communication protocol defined by the external system, which is used to guide the conversion of internal business data to an externally recognizable format.

[0082] Among them, parameter assembly refers to processing internal business data according to the requirements of external system interfaces, such as field mapping, structure reorganization, format conversion, and enumeration adaptation, so that it conforms to the interface protocol standards of third-party systems.

[0083] In one possible implementation, S5 specifically includes:

[0084] S501: Based on the application context, the capability point registration module identifies processors of multiple external third-party applications by scanning processor classes with predefined external route identifier annotations.

[0085] The application context refers to the set of global information that can be accessed in the system runtime environment, including loaded classes, beans, configurations, etc., which are used to support component scanning and instance management.

[0086] Among them, the processor class is responsible for executing the code class of a specific business capability of an external third-party system, and contains the logical methods for handling interface calls.

[0087] S502: Based on each processor, and combined with the method object, method name, and method parameter type information, construct the capability point mapping relationship.

[0088] Among them, the capability point mapping relationship refers to the mapping of "capability point identifier → corresponding processing method (class, method name, parameter type)" automatically generated by the system, which is used to determine the specific execution method of the capability point.

[0089] S503: The routing execution module determines the capability point description entity based on the unique definition of the external application, the capability points, and the capability point mapping relationship.

[0090] Specifically, after determining the unique definition and capability point identifier of the target external application, the routing execution module quickly retrieves the corresponding capability point description entity from the above-mentioned secondary mapping based on the unique definition and capability point identifier of the external application.

[0091] S504: Based on the capability point description entity, perform compatibility verification on the parameter types and business data objects of the target strategy.

[0092] Specifically, before the call, a compatibility check is performed on the parameter types of the target method and the actual type of the business data object to be passed in. If the parameter types are incompatible, the error is recorded and the call is terminated. If the check passes, the target method is executed on the corresponding processor instance using the reflection call mechanism. This allows for dynamic invocation of the third-party system capability implementation method at runtime without explicitly binding the third-party system implementation class at compile time.

[0093] S505: Determine if the compatibility check passes. If yes, execute the target policy on the corresponding processor instance using reflection, and proceed to step S506. Otherwise, record the error reason and terminate the dynamic call.

[0094] S506: Assemble business data parameters based on third-party system interface specifications.

[0095] It should be noted that annotation scanning automatically identifies the processor classes of third-party systems and constructs capability point mapping relationships, achieving automation and scalability in capability point registration. Capability point description entities and compatibility verification mechanisms ensure accurate matching between the target method executed in the routing process and the business data, avoiding invocation errors. Dynamically invoking capability points through reflection allows the system to flexibly support multiple third-party systems and their different capability points without modifying the core code. Furthermore, parameter assembly is completed in conjunction with third-party interface specifications, ensuring that the final data format fully complies with the requirements of external systems. Overall, this process significantly improves the automation, flexibility, stability, and maintainability of third-party integration.

[0096] In one possible implementation, S506 specifically includes:

[0097] S5061: Based on the external warehouse number and external cargo owner number, convert the warehouse number and cargo owner information in the internal business data into warehouse code and cargo owner code recognized by the third-party system.

[0098] Specifically, based on the external warehouse number and external cargo owner number recorded in the route matching results, the warehouse number and cargo owner information in the internal business data are converted into warehouse codes and cargo owner codes recognized by the third-party system. When the external warehouse number or external cargo owner number is not specified in the route configuration, the internal code is used as the default value.

[0099] S5062: Based on the warehouse code and owner code, and in conjunction with the requirements of the third-party system interface for the business document structure, reorganize the document information in the internal business objects.

[0100] The document information includes, but is not limited to, fields such as: document number, task number, business source document number, product code of the detail line, customer product code, quantity, batch number, production date, and expiration date.

[0101] S5063: Construct the reorganization result into a detailed list defined by the external interface.

[0102] S5064: Convert the format of numeric fields in the details list to obtain a string format or numeric precision that meets the requirements of the third-party system interface.

[0103] Numeric fields include time and quantity.

[0104] S5065: Based on the string format or numerical precision, and combined with the preset mapping relationship, convert the internal enumeration value into the enumeration code defined by the third-party system.

[0105] S5066: Supplementing general control fields based on enumeration encoding.

[0106] The common control fields include: idempotency flag, call timestamp, and business source flag.

[0107] Specifically, to ensure idempotency and security of the call, common control fields are added when assembling parameters, including idempotency flags, call timestamps, and business source flags, which are used to identify duplicate requests and trace call chains on the third-party system side.

[0108] S5067: Pass the supplementary results and transformed parameter objects as external business data to the target capability point strategy, and combine the HTTP communication protocol of the third-party system to assemble the parameters of the business data.

[0109] S6: Record the execution status and return results of dynamic calls.

[0110] After the dynamic call is completed, the present invention uniformly captures, classifies and records, and controls retry for the exceptions generated during the call process, so as to ensure automatic retry in recoverable exception scenarios such as network jitter, and fast failure to avoid invalid retries in unrecoverable scenarios such as business rule errors.

[0111] S7: Based on the execution status and return results, exceptions generated during the call process are classified and handled through the business system.

[0112] Among them, the execution status refers to the execution result status generated when the routing system calls external third-party capabilities, such as success, failure, timeout, parameter error, network abnormality, etc., which is an important basis for judging whether the calling process is normal.

[0113] The returned result refers to the business response content returned by the external third-party system, including status codes, error messages, business data, prompts, etc., which are used to determine the processing method of subsequent business processes.

[0114] It's important to note that by categorizing exceptions based on execution status and third-party system responses, the system can adopt targeted strategies for different types of call problems, avoiding the risks of treating all exceptions indiscriminately. This mechanism not only improves the robustness and automated recovery capabilities of the call chain but also reduces manual troubleshooting costs and enhances the fault tolerance and continuity of the business system against external failures. By categorizing exceptions before processing them, the system can achieve fine-grained control in the face of different situations such as network fluctuations, parameter errors, and third-party service failures, thereby ensuring the stability and reliability of the overall business process.

[0115] In one possible implementation, S7 specifically refers to:

[0116] Exceptions generated during the call process are uniformly captured, categorized, recorded, and retry controlled.

[0117] In one possible implementation, exceptions specifically include: configuration and parameter exceptions, business exceptions, and system exceptions.

[0118] Specifically, configuration and parameter exceptions include situations such as not finding external capability point mappings or mismatched method parameter types. When it is detected that the unique definition of the external application does not exist, the capability point identifier does not exist, or the type of the reflection method parameter is incompatible with the data type of the business to be passed in, an error log is recorded and the process is returned directly without initiating a retry.

[0119] Business exceptions refer to business exceptions explicitly thrown by the capability implementation method, such as validation failures or business state conflicts, and are identified by business exception type (e.g., BizException). When the system captures such exceptions, it logs them at the alarm level and re-throws them upwards as is for business chain awareness. However, in the retry strategy, it treats them as errors that cannot be repaired by retries and no longer automatically retryes the same request.

[0120] System exceptions include, but are not limited to, network timeouts, connection failures, and runtime exceptions caused by internal errors in third-party interfaces. These exceptions are typically thrown as target exceptions in reflection calls (such as the internal cause of InvocationTargetException) or general runtime exceptions. After the system catches such exceptions, it logs them at the error level and encapsulates them as runtime exceptions for retry, which is then driven by the message middleware (such as RocketMQ).

[0121] Retry control specifically involves driving and controlling retrying routing calls through message queue middleware.

[0122] In this embodiment of the invention, a message queue middleware (such as RocketMQ) is preferably used to drive and control retry of routing calls. On the consumer side, the maximum number of retries and alarm thresholds are set through annotations or a configuration center. For example, in one specific embodiment, the maximum number of retries for a certain business event consumer is set to 5 through a message listening configuration item. If the same message fails to be consumed due to system abnormalities after 5 attempts, it will no longer be automatically delivered by the middleware.

[0123] (1) The retry interval is controlled by the message middleware according to the preset retry strategy. A fixed retry interval or an exponential backoff strategy can be adopted (such as gradually increasing from tens of seconds to several minutes). This invention does not limit the specific interval, but only needs to ensure that a reasonable recovery window can be covered in the scenario of short-term network jitter or short-term unavailability of third-party systems.

[0124] (2) Parameters such as the maximum number of retries and the retry interval strategy can be dynamically adjusted through configuration files, configuration centers or the management console of message middleware without modifying the business code.

[0125] (3) During each retry, the same idempotent identifier is reused, and a distributed lock mechanism is used on the consumer side to protect requests with the same idempotent identifier, so as to prevent repeated business side effects caused by multiple retries to the downstream third-party system.

[0126] (4) After the maximum number of retries is reached, it will no longer automatically retry and will push the failure event to the monitoring and alarm channel to prompt relevant personnel to intervene manually.

[0127] The beneficial effects of the technical solutions provided in the embodiments of the present invention include at least the following:

[0128] In this embodiment of the invention, by sequentially combining the routing configuration module, capability point definition module, capability point registration module, routing matching module, and routing execution module into a unified routing system, the system achieves complete decoupling and automation of external integration processes for warehousing operations. By constructing configurable routing relationships based on warehouse number, business type, capability points, and external third-party applications, the system can flexibly adapt to the selection requirements of third-party systems in different warehouses and business scenarios. Through the dynamic matching mechanism of the routing matching module, it ensures that business requests accurately locate the corresponding external third-party system configuration in a multi-system coexistence environment. Furthermore, through the dynamic capability point invocation method of the routing execution module, the system can automatically trigger the interface capability points of the target third-party system based on the matching results, achieving standardization and automation of data interaction. In summary, this solution significantly improves the flexibility, scalability, and operational efficiency of third-party integration in warehousing operations through configuration-based management, multi-dimensional routing matching, and dynamic execution mechanisms. It avoids the high maintenance costs associated with hard coding and enables the system to maintain stable and efficient integration capabilities in a complex and ever-changing warehousing ecosystem.

[0129] The above embodiments can be implemented, in whole or in part, by software, hardware (such as circuits), firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the flow or function according to the embodiments of the present invention is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. Computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. A computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. Available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media. Semiconductor media can be solid-state drives.

[0130] It should be understood that, in various embodiments of the present invention, the order of the above-mentioned process numbers does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0131] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0132] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the devices, apparatuses, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0133] In the several embodiments provided by this invention, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0134] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0135] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0136] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0137] This invention provides a readable storage medium that stores a program or instructions on the storage medium. When the program or instructions are executed by a processor, they implement the steps of the above-described method for three-way docking of a warehouse system based on multi-dimensional routing, and achieve the same technical effect. To avoid repetition, this invention will not repeat the above description.

[0138] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the embodiments of the present invention, and are not intended to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the protection scope of the present invention.

Claims

1. A three-party routing system for warehousing operations, characterized by, The system comprises a routing configuration module, a capability point definition module, a capability point registration module, a routing matching module and a routing execution module; The routing configuration module, the capability point definition module, the capability point registration module, the routing matching module and the routing execution module are sequentially connected; The routing configuration module is configured to establish routing configuration relationships according to warehouse numbers, business types, capability points and dimensions defined by external third-party applications; The routing matching module is configured to match in the routing configuration mapping according to the warehouse numbers, the business types and the capability point information in the business request, determine the external application unique definition and the capability points corresponding to the external application unique definition; The routing execution module is configured to locate the specific implementation mode of the corresponding capability points in the capability point mapping relationship based on the routing matching result and the external application unique definition, dynamically call the specific capability point implementation of the corresponding third-party system, and complete the data interaction with the external system.

2. A three-party routing method for warehouse business, characterized by, The method applied to the third-party routing system for warehouse business in claim 1 comprises: S1: receiving an external routing call request of a business system; S2: extracting routing matching parameters in the external routing call request; S3: determining the external application unique definition and the capability points corresponding to the external application unique definition according to the routing matching parameters and in combination with a routing configuration table; S4: locating the specific implementation mode of the corresponding capability points in a capability point mapping relationship based on the external application unique definition; S5: dynamically calling the specific implementation mode and assembling parameters of business data based on a third-party system interface specification; S6: recording an execution state and a return result of the dynamic call; S7: based on the execution state and the return result, classifying and processing exceptions generated in the calling process through the business system.

3. The three-party routing method for warehouse business according to claim 2, wherein, The routing matching parameters comprise warehouse numbers, business types and capability point identifiers.

4. The three-party routing method for warehouse business according to claim 2, wherein, The S2 specifically comprises: S201: receiving a call request from an HTTP interface, performing protocol analysis on a message in the call request, and determining an internal business request object; S202: extracting a basic routing factor from the internal business request object according to the business type in the external routing call request; S203: constructing a unified routing request object based on the basic routing factor; S204: verifying the unified routing request object; S205: determining whether the verification result is passed; if yes, taking the unified routing request object as the routing matching parameters; otherwise, recording an exception and terminating the routing process.

5. The three-party routing method for warehouse business according to claim 2, wherein, The S3 specifically comprises: S301: providing a routing configuration interface to set routing rules according to business requirements on a management end; S302: storing the routing rules in a routing configuration table to form a multi-dimensional routing configuration mapping; S303: loading routing configuration records in an enabled state from the routing configuration table in the case of system startup or routing rule change; S304: based on the loading result, the capability point registration module constructs a secondary capability point mapping relationship by scanning third-party system processor classes with a predefined identifier. S305: According to the secondary capability point mapping relationship, the loaded routing record is filtered in the multi-dimensional routing configuration mapping to determine a globally unique routing record meeting the primary dimension condition, i.e., the external application uniquely defines the corresponding capability point. 6.The three-party routing method for warehouse business of claim 2, wherein, The S5 specifically includes: S501: Based on the application context, the capability point registration module identifies a plurality of processors of external third-party applications by scanning the processor classes with pre-defined external routing identifier annotations; S502: According to each processor, the capability point mapping relationship is constructed in combination with the method object, method name, and method parameter type information; S503: The routing execution module determines the capability point description entity according to the external application unique definition, the capability point, and the capability point mapping relationship; S504: The parameter type and business data object of the target strategy are subjected to compatibility verification according to the capability point description entity; S505: It is judged whether the compatibility verification passes; if yes, the target strategy is executed on the corresponding processor instance by using the reflection calling mechanism, and step S506 is entered; otherwise, the error reason is recorded and the dynamic calling is terminated; S506: The business data is subjected to parameter assembly based on the third-party system interface specification.

7. The three-party routing method for warehouse business according to claim 6, wherein, The S506 specifically includes: S5061: According to the external warehouse number and external consignor number, the warehouse number and consignor information in the internal business data are converted into the warehouse code and consignor code recognized by the third-party system; S5062: According to the warehouse code and the consignor code, the document information in the internal business object is reorganized in combination with the requirement of the third-party system interface on the business document structure; S5063: The reorganization result is structured into a detail list defined by the external interface; S5064: The numerical value type field in the detail list is subjected to format conversion to obtain a string format or numerical precision conforming to the requirement of the third-party system interface; S5065: According to the string format or the numerical precision, the internal enumeration value is converted into an enumeration code defined by the third-party system in combination with a pre-set mapping relationship; S5066: Based on the enumeration code, a general control field is supplemented; S5067: The supplemented result and the converted parameter object are transmitted to the target capability point strategy as external business data, and the business data is subjected to parameter assembly in combination with the HTTP communication protocol of the third-party system. 8.The three-party routing method for warehouse business of claim 2, wherein, The S7 specifically includes: The exceptions generated in the calling process are uniformly captured, classified, recorded, and subjected to retry control.

9. The three-party routing method for warehouse business according to claim 8, wherein, The exceptions specifically include: configuration and parameter class exceptions, business exceptions, and system exceptions; The retry control specifically includes: the routing calling is driven and subjected to retry control by the message queue middleware.

10. A readable storage medium, characterized by, The program or instruction is stored on the readable storage medium, and the program or instruction is executed by the processor to implement the steps of the third-party routing method for warehouse business according to any one of claims 2 to 8.

Images