A method and system for bulk docking logistics providers

Abstract

The application discloses a method and system for batch docking logistics merchant system, comprising: creating a docking table for recording basic information of each logistics merchant interface, the basic information of each logistics merchant interface is respectively created as corresponding basic information groups; defining general strategies of each logistics merchant interface, each general strategy rule pre-configures one or more strategy rule items, the strategy rule items and corresponding strategy rule item identifiers in the docking table correspond; creating corresponding strategy implementation classes according to specification requirements of each logistics merchant interface, mapping the general strategies and the strategy implementation classes to a factory mode; configuring a public interface for uniformly calling each logistics merchant interface; in response to initial logistics data returned by the logistics merchant interface, performing a twist operation on the initial logistics data. The method and system can greatly reduce the code programming amount of the docking process, shorten the interface configuration time, and improve the stability and scalability of the docking interface.

Description

Technical Field

[0001] This application relates to the field of Internet software technology, and in particular to a method for batch connecting to logistics provider systems, a method for acquiring logistics data, and the corresponding systems for each method. Background Technology

[0002] Overseas warehouse systems are internet software systems used to perform online warehousing management, logistics management, and shipping management. When managing logistics, they typically need to connect to hundreds of logistics provider systems. However, due to the lack of a unified interface standard among these logistics provider systems, overseas warehouse systems need to develop separate interfaces for each logistics provider.

[0003] During the interface configuration phase, when new interfaces are added or upgraded, developers need to write a lot of code, resulting in long development cycles, low integration efficiency, redundant code, poor code readability, and difficulty in maintenance.

[0004] Furthermore, during the API call phase, when executing different types of request tasks, the different execution logic of the various interfaces connected to the overseas warehouse makes it easy for issues such as parameter mismatch and format errors to occur during the connection process, resulting in a high error rate.

[0005] Other technical issues related to this application will be further elaborated below. The above content is only for assisting in understanding the technical solutions of this application and does not imply that all of the above content is prior art. Summary of the Invention

[0006] The main objective of this application is to provide a method and system for batch integration with logistics provider systems. This method allows for batch configuration of integration interfaces during the interface configuration phase, significantly reducing the amount of code required for integration, shortening interface configuration time, and improving the stability and scalability of the integration interfaces. Furthermore, this application also provides a method and system for acquiring logistics data. This method allows for the execution of different types of task requests during the interface call phase, unifying the data assembly method and data manipulation operations for logistics providers, thereby improving the accuracy of the target logistics data.

[0007] To achieve the above objectives, this application proposes a method for batch integration with logistics provider systems, comprising:

[0008] Step S1: Create a connection table to record the basic information of each logistics provider's interface. The basic information includes logistics provider identifier, logistics provider interface identifier, interface request address, interface request parameters, parameter mapping rules and policy rule item identifiers. The basic information of each logistics provider's interface is created as a corresponding basic information group.

[0009] Step S2: Define the general strategy for each logistics provider's interface. The general strategy rules include encryption rules, request header format setting rules, and return content encapsulation rules. Each general strategy rule is pre-configured with one or more strategy rule items. The strategy rule items correspond to the corresponding strategy rule items in the interface table.

[0010] Step S3: Create corresponding strategy implementation classes according to the specification requirements of each logistics provider's interface, which differ from the general strategy rules. The execution priority of the strategy implementation classes is higher than that of the general strategy rules; map the general strategy and the strategy implementation classes to the factory pattern.

[0011] Step S4: Configure a common interface for unified invocation of interfaces from various logistics providers, including:

[0012] Step S41: Create the first logic to obtain the target basic information group from the docking table based on the request task, logistics provider identifier and logistics provider interface identifier. The first logic also includes identifying the corresponding logistics provider identifier and logistics provider interface identifier according to the type of request task.

[0013] Step S42: Create the second logic based on the strategy rule item identifier of the request task, logistics provider identifier, and target basic information group to obtain the corresponding target strategy rule item and target strategy implementation class from the factory pattern;

[0014] Step S43: Assemble logistics provider data based on the obtained target basic information group, all target strategy rule items, and target strategy implementation class;

[0015] Step S44: Create a third logic that automatically calls the corresponding logistics provider interface based on the assembly-based logistics provider data;

[0016] Step S5: In response to the logistics provider interface returning initial logistics data, perform the reversal operation on the initial logistics data.

[0017] Other technical features and effects of the method for batch integration with logistics provider systems in this application are described in the latter part of the specification. The technical problem-solving approach and related product design scheme of this application are as follows:

[0018] Overseas warehouse systems need to interface with hundreds of logistics provider systems. Currently, the conventional method for interface integration is to programmatically generate interface codes for each logistics provider system according to their data interface specifications. This direct programming approach requires developers to write a large amount of code, resulting in low interface configuration efficiency and poor interface scalability. Furthermore, this method necessitates configuring a separate interface for each logistics provider on the overseas warehouse system, further increasing the difficulty of upgrading and maintaining the interface code due to the large number of interfaces.

[0019] In related solutions, automated programming tools can be used to automate software programming, avoiding manual coding. The working principle involves pre-defining the relationships between parameters and programming requirements to form specific logical relationships, and then generating corresponding interface code based on these relationships. However, different logistics provider systems lack a unified architecture and standards, and the specification requirements for interfaces vary significantly. Furthermore, each logistics provider system typically contains multiple interfaces that need to be integrated, and compatibility with other logistics provider interfaces to be integrated later must also be considered, resulting in extremely complex logical relationships in the integration scenarios. Pre-defining the parameter relationships and programming requirements for each interface would be more labor-intensive and difficult than direct programming, with even worse results. Therefore, using automated programming tools (automated programming method) remains undesirable.

[0020] The applicant discovered that if a common interface could be configured to uniformly call all logistics provider interfaces, it might simplify the integration of logistics provider interfaces. However, it is still necessary to further address important issues such as the allocation of the common interface and logistics provider interfaces, the simplification of the logical relationships between different logistics provider interfaces, the expansion of logistics provider interfaces, and the retrieval of logistics provider data.

[0021] To address this, the applicant further proposes the following solution: First, classify and configure the interface information of all logistics provider interfaces according to basic information, general strategies, and strategy implementation classes, thereby simplifying the logical relationships between various logistics provider interfaces. Basic information includes logistics provider identifier, logistics provider interface identifier, interface request address, interface request parameters, parameter mapping rules, strategy rule item identifiers, and request methods (such as GET, POST, etc.). The basic information of each logistics provider interface constitutes a basic information group, and each basic information group is stored in the interface table. Interface request parameters refer to the interface parameters corresponding to the request task for each interface type (including authorization verification interface, logistics order creation interface, logistics tracking number retrieval interface, logistics waybill retrieval interface, and logistics fee retrieval interface, etc.) during interface integration. Parameter mapping rules refer to the correspondence between field parameters in the overseas warehouse system and field parameters in the logistics provider system. Furthermore, the interface table can be set to an editable state, and information on multiple logistics provider interfaces that need to be integrated can be pre-entered into the interface table to achieve batch configuration of integrated interfaces and facilitate subsequent expansion to add other logistics provider interfaces.

[0022] The general strategy includes general policy rules such as encryption rules, request header formatting rules, and return content encapsulation rules. Each general policy rule is pre-configured with one or more policy rule items (for example, encryption rules such as MD5 and SHA256 can be pre-configured for encryption rules). The identifiers of each policy rule item in the basic information correspond to the corresponding policy rule items, thus preparing for the subsequent invocation of the corresponding policy rule items based on the policy rule item identifiers.

[0023] Strategy implementation classes are used to create separate implementations for logistics provider interfaces with special requirements. Specifically, they can be created based on the specifications of the logistics provider interface that differ from the general strategy rules. These implementations supplement the general strategy rules, allowing them to replace the original general strategy rules during interface integration, thus ensuring compatibility with various logistics provider interfaces with different specifications. For example, if a logistics provider interface specification requires encryption rules, request header formatting rules, return content encapsulation rules, or other rules that differ from the corresponding rules in the general strategy, then corresponding strategy implementation classes need to be created for each different rule. In this case, only the different rule parts need to be added with the corresponding programming code; the same rule parts can continue to use the strategy rule items to avoid additional programming, thereby significantly reducing the workload.

[0024] Secondly, the general strategy and strategy implementation class are mapped to the factory pattern, and the association between each strategy rule and each strategy implementation class is stored in the virtual machine. This allows the system to accurately obtain callable and assemblable logistics provider data from a large amount of logistics provider data of different types, levels, formats, and storage methods (data corresponding to the interface specifications of different types of logistics providers) through the factory pattern, logistics provider identifier, logistics provider interface identifier, and strategy rule item identifier. This solves the problem of calling large amounts of logistics provider data and reduces the difficulty of creating shared logical relationships between different logistics provider interfaces.

[0025] Furthermore, a common interface is configured for unified invocation of various logistics provider interfaces. This allows a temporary interface to be assembled precisely for each logistics provider system that needs to connect to a specific logistics provider system to execute a request task. After the interface connection and request task are completed, the assembled logistics provider data is cleared, and the temporary interface is released for use by other request tasks, thus resolving the issue of interface allocation between the common interface and the logistics provider interface. For the specific configuration scheme of the common interface, please refer to steps S41-S42.

[0026] Finally, configure the automatic execution logic of the data reversal operation (fourth logic), that is, perform a unified reversal operation on the data returned by all logistics provider interfaces to obtain target logistics data with a unified format (see step S5).

[0027] This public interface-based integration method (referred to as the batch integration method) allows for batch configuration of interfaces during the interface configuration phase, significantly reducing the amount of code required for the integration process, shortening interface configuration time, and improving the stability and scalability of the interfaces. In contrast, configuring an interface for a logistics provider system using the direct programming method typically takes about 2-3 days, while this batch integration method can reduce the configuration time for expanding a new logistics provider interface to about 20 minutes. The new method significantly improves the configuration efficiency of logistics provider interfaces and enhances the flexibility and compatibility of interface expansion and maintenance.

[0028] Furthermore, this application also proposes a method for acquiring logistics data, including:

[0029] Step K1: Pre-configure the interface table, general strategy, and strategy implementation class according to the specification requirements of each logistics provider's interface. The interface table contains several basic information groups, each of which records the basic information of the corresponding logistics provider's interface. The general strategy contains multiple general strategy rules composed of different strategy rule items. The strategy implementation class is configured to have a higher execution priority than the general strategy rules.

[0030] Step K2: Based on the request task to obtain logistics data, retrieve the corresponding target basic information group, target strategy rule item, and target strategy implementation class from the docking table, general strategy, and strategy implementation class, respectively;

[0031] Step K3: Perform logistics provider data assembly, including:

[0032] Step K31: Based on the parameter mapping rules in the target basic information group, convert the interface request parameters of the docking system into the interface request parameters of the logistics provider system, and adapt the parameter values ​​of the converted interface request parameters based on the business data associated with the request task.

[0033] Step K32: Assemble the request header based on the request header format setting rules in the target policy rule item or the target policy implementation class, and assemble the request body based on the converted interface request parameters;

[0034] Step K33: Encrypt the request header and request body based on the encryption rules in the target policy rule item or the target policy implementation class;

[0035] Step K4: Based on the assembled logistics provider data, send a connection request to the corresponding logistics provider interface and obtain the initial logistics data returned by the logistics provider interface;

[0036] Step K5: Based on the return content of the target strategy rule item or the target strategy implementation class, perform the reversal operation of the initial logistics data to generate the target logistics data.

[0037] This logistics data acquisition method can unify the data assembly method and data reversal operation of logistics providers when executing different types of task requests during the logistics data acquisition stage, thereby improving the accuracy of target logistics data, simplifying the operation of centralized calibration of various unified parameters, and improving system security.

[0038] Furthermore, this application also includes systems corresponding to various methods. These systems contain the functional modules involved in this application, execute operation instructions for the corresponding functional modules or methods, and output relevant data information to the system front-end interface. The system is stored in a server and / or computer device containing a processor, which executes the system's operation instructions.

[0039] Declaration: The functional modules of this application can be integrated with each other, or they can exist independently, or one functional module can be a sub-module of another functional module; the step numbers S1, S2, etc. do not limit the order of the corresponding operation steps.

[0040] The following is an explanation of some of the technical terms used in this application.

[0041] (1) Factory Pattern is a creational design pattern that separates instantiation logic from usage logic by encapsulating the object creation process, thereby improving the flexibility and maintainability of the code.

[0042] (2) The implementation class is the basic unit for encapsulating data and behavior in object-oriented programming; dependency injection is the process of passing the dependency relationship to the object when the object is created, and the technology of managing the component dependency relationship through the external container.

[0043] (3) JSON (JavaScript Object Notation) is an open standard file format and data exchange format that is easy for humans to read and write, and machines to parse and generate; Cookie refers to simple text data stored on a client machine for purposes such as session state management, personalization settings, and user behavior tracking. Attached Figure Description

[0044] The accompanying drawings are provided to further understand this application and do not constitute a limitation thereof; the content shown in the drawings may be actual data of the embodiments and falls within the protection scope of this application.

[0045] Figure 1 This is a schematic diagram illustrating the working principle of the common interface in one embodiment of this application.

[0046] Figure 2 This is a schematic diagram of a method for batch integration with a logistics provider system in one embodiment of this application.

[0047] Figure 3This is a schematic diagram of a logistics data acquisition method in one embodiment of this application. Detailed Implementation

[0048] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be further described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only for explaining this application and are not intended to limit this application.

[0049] refer to Figure 1 and Figure 2 This application proposes a method for batch integration of logistics provider systems, used for integrating overseas warehouse systems with logistics provider systems, including the following steps S1-S5.

[0050] Step S1: Create a connection table to record the basic information of each logistics provider's interface. The basic information includes the logistics provider identifier, logistics provider interface identifier, interface request address, interface request parameters, parameter mapping rules, and policy rule item identifiers. The basic information of each logistics provider's interface is created as a corresponding basic information group.

[0051] Step S2: In the general strategy module, define the general strategy for each logistics provider's interface. The general strategy rules include encryption rules, request header format setting rules, and return content encapsulation rules. Each general strategy rule is pre-configured with one or more strategy rule items, and these strategy rule items correspond to the corresponding strategy rule item identifiers in the interface table. Figure 1 In the table, A1-An, B1-Bn, and C1-Cn are the corresponding general strategy rule items, and each strategy rule item has a corresponding strategy rule item identifier in the basic information of the docking table.

[0052] Step S3: In the strategy implementation class module, create corresponding strategy implementation classes according to the specification requirements of each logistics provider's interface, which differ from the general strategy rules. The execution priority of the strategy implementation class is higher than that of the general strategy rules. Map the general strategy and the strategy implementation class to the factory pattern.

[0053] Step S4: Configure a common interface for unified invocation of interfaces of various logistics providers, including steps S41-S44.

[0054] Step S41: Create the first logic to retrieve the target basic information group from the interface table based on the request task, logistics provider identifier, and logistics provider interface identifier. The first logic also includes automatically identifying the corresponding logistics provider identifier and logistics provider interface identifier according to the type of the request task. The target basic information group is the basic information group corresponding to the execution of the corresponding request task. For example, when the request task is to retrieve a logistics waybill from logistics provider A, then the basic information group corresponding to the logistics waybill retrieval interface of logistics provider A's system is the target basic information group.

[0055] Step S42: Create the second logic based on the strategy rule item identifier of the request task, logistics provider identifier, and target basic information group to obtain the corresponding target strategy rule item and target strategy implementation class from the factory pattern. The target strategy rule item is the strategy rule item corresponding to the execution of the corresponding request task, that is, the strategy rule item corresponding to the strategy rule item identifier in the target basic information group; the target strategy implementation class is the strategy implementation class corresponding to the execution of the corresponding request task. If the execution of the corresponding request task does not require a corresponding strategy implementation class, then there is no need to obtain the strategy implementation class or the strategy implementation class is empty.

[0056] Step S43: After executing the first and second logics, assemble the logistics provider data based on the obtained target basic information group, target strategy rule items, and target strategy implementation class.

[0057] Step S44: Create a third logic that automatically calls the corresponding logistics provider interface based on the assembly-based logistics provider data.

[0058] Step S5: In response to the logistics provider interface returning initial logistics data, perform the reversal operation on the initial logistics data.

[0059] In one embodiment, the method further includes step S6: after performing the reversal operation, clearing the assembled logistics provider data, that is, clearing the temporarily assembled public interface data, and releasing the temporary interface to free up threads for other task requests.

[0060] In one embodiment, the parameter mapping rules of the interface table are stored in an encoded format, such as JSON or other specific formats, such as {"systemParam1":"logisticsParamA", "systemParam2":"logisticsParamB"}. Compared with directly storing the text information of each parameter field name, this method can speed up parameter parsing, thereby improving the execution speed of the interface interface code.

[0061] Furthermore, the code content of the parameter mapping rules in the docking table can be generated using an automated programming tool to prevent inconsistencies caused by manual editing when manually configuring the basic information of the docking table, and to improve the configuration efficiency of the docking table.

[0062] In one embodiment, the basic information further includes return result parsing rules, which define the parsing relationship using JSON path expressions. During a reversal operation, the relevant reversal data is stored in the corresponding path location based on the path expression of the return result parsing rules. The return result parsing rules allow for rapid expansion of the initial logistics data for new uses. For example, when retrieving logistics tracking number data via a tracking number retrieval interface, if the existing software code only supports returning the corresponding tracking number, but it's desired to further extract the tracking number's generation time from the returned initial logistics data, then simply adding the tracking number generation time field mapping relationship and data storage path location information to the return result parsing rules will yield the newly added logistics data. This operation method requires no adjustment to the interface code, making it flexible and fast.

[0063] In one embodiment, the interface table is configured to be editable, and the content of the interface table can be edited through the front-end interface of the system where the public interface is located.

[0064] In one embodiment, when executing a request task requires calling multiple logistics provider interfaces, the basic information of the multiple logistics provider interfaces is created as a shared basic information group, and the same general strategy rule items and strategy implementation classes are configured for the multiple logistics provider interfaces. In this way, without changing the architecture of the common interface, the target logistics data from multiple logistics provider interfaces can be obtained simultaneously by using the common interface to assemble the logistics provider data only once, thereby improving the efficiency of logistics data retrieval.

[0065] Furthermore, when editing the interface table, if a new logistics provider interface is added, the corresponding basic information group is added; if an existing logistics provider interface is upgraded, the corresponding basic information group is re-edited. In this way, the logistics provider interface can be expanded and maintained through the editing operation of the interface table, thereby improving the efficiency and flexibility of expansion and maintenance.

[0066] When adding or upgrading logistics provider interfaces, if the existing policy rules in the general policy module, after combination, still cannot meet the specification requirements of the logistics provider interface, then a new policy implementation class needs to be created for the corresponding logistics provider in the policy implementation class module. Creating new policy rules and new policy implementation classes requires backend code programming; otherwise, parameter editing is sufficient in the frontend interface corresponding to the interface table.

[0067] In one embodiment, the interface testing tool associated with the interface table (such as Postman) automatically invokes the tool to verify the validity of the interface request address when editing the interface request address in the interface table. If the validity verification fails, an error message is displayed indicating that the interface request address is abnormal. This avoids performing invalid connection operations on interfaces with abnormal addresses.

[0068] In one embodiment, the general strategy rule further includes parameter interception rules, which are used to intercept parameters that do not meet preset conditions. For example, if the target logistics data obtained according to a certain use case requires that the logistics address can only contain three levels of information: country, city, and street, and cannot contain province information, then a corresponding interception rule can be set to intercept the initial logistics data returned by the logistics provider's interface, so that the province information is intercepted after the reversal operation. In other implementations, corresponding interception rules can be set according to the actual use case, thereby improving the accuracy of the target logistics data.

[0069] Furthermore, the method and corresponding operating steps for connecting the overseas warehouse system (the connecting system) to the logistics provider system (the connected system) in this application can also be applied to other connecting systems connecting to other connected systems to achieve similar functional effects.

[0070] refer to Figures 1-3 This application also proposes a logistics data acquisition method from the perspective of logistics data acquisition, which is used to connect the system to obtain logistics data from the logistics provider interface, including the following steps K1-K5.

[0071] Step K1: Pre-configure the interface table, general strategy, and strategy implementation class according to the specification requirements of each logistics provider's interface. The interface table contains several basic information groups, each of which records the basic information of the corresponding logistics provider's interface. The general strategy contains multiple general strategy rules composed of different strategy rule items. The strategy implementation class is configured to have a higher execution priority than the general strategy rules (that is, when both the strategy implementation class and the general strategy rules contain rules of the same category, only the rules of the same category in the strategy implementation class are executed).

[0072] Step K2: In the configuration information acquisition phase, based on the request task to acquire logistics data, the corresponding target basic information group, target strategy rule item and target strategy implementation class are obtained from the docking table, general strategy and strategy implementation class respectively.

[0073] Step K3: In the assembly request phase, logistics provider data assembly is performed based on the acquired configuration information and business data associated with the request task, including steps K31-K33.

[0074] Step K31: Based on the parameter mapping rules in the target basic information group, convert the interface request parameters of the docking system into interface request parameters of the logistics provider system (i.e., logistics provider interface parameters), and adapt the parameter values ​​for the converted interface request parameters based on the business data associated with the request task. During the assembly process, different processing is performed according to the parameter type of each request parameter (such as object, collection, etc.) to ensure the accuracy and completeness of the parameter values.

[0075] Business data refers to the data corresponding to various types of request tasks, including specific data values ​​such as authorization verification information and order information, which can be stored in the business data table. The business data associated with a request task is the interface request parameter value corresponding to each interface request parameter in the basic information group corresponding to the request task.

[0076] Step K32: Assemble the request header based on the request header formatting rules in the target policy rule item or the target policy implementation class, and assemble the request body based on the transformed interface request parameters. Since the policy implementation class is configured to have a higher execution priority than the general policy rules, the request header formatting rules in the target policy implementation class are used first when assembling the request header. If there are no request header formatting rules in the target policy implementation class, then the request header formatting rules in the target policy rule item are used.

[0077] Step K33: Encrypt the request header and request body based on the encryption rules in the target policy rule item or the target policy implementation class; wherein, the encryption rule in the target policy rule item is the encryption rule item corresponding to the policy rule item identifier in the target basic information group. Since the policy implementation class is configured to have a higher execution priority than the general policy rule, the encryption rule in the target policy implementation class is used first when performing encryption processing.

[0078] Step K4: Based on the assembled logistics provider data, send a connection request to the corresponding logistics provider interface and obtain the initial logistics data returned by the logistics provider interface (including normal logistics data and error codes for abnormal data).

[0079] Step K5: Based on the return content of the target strategy rule item or the target strategy implementation class, perform the reversal operation on the initial logistics data to generate the reversed target logistics data.

[0080] In one embodiment, before sending the docking request (corresponding to step K31), null value validation is performed on the interface request parameters (including the interface request parameters in the request body and request header) to adapt the parameter values. If the interface request parameter value is empty, the empty interface request parameter value is recorded in the docking system log, and a failure response is returned. In this way, the format of the interface request parameter value is calibrated through null value validation to improve the accuracy of logistics data acquisition; furthermore, the null value information recorded in the log can provide a reference for subsequent improvements to the interface scheme. Null value validation is performed automatically using preset programming code.

[0081] Furthermore, based on the null value validation results, the logistics provider data is reassembled, discarding interface request parameters with abnormal validation results (both the parameter and its value are discarded), and continuing to assemble interface request parameters with normal validation results. For example, if there were originally 10 interface request parameters for assembling logistics provider data, and after null value validation, one interface request parameter is abnormal (it is null), while the remaining 9 interface request parameters are normal (they are not null), then the data required for the common interface to run is assembled based on these 9 normal interface request parameters, while the 1 abnormal interface request parameter is discarded.

[0082] Furthermore, in step K31, interface configuration verification is performed on the interface request address and some interface request parameters with preset verification rules. This interface configuration verification includes verifying the configuration content of parameters such as the interface request address and request method. When verifying the interface request address, a scenario of inputting the interface request address into a browser is simulated. The configuration content of the interface request address is judged to be abnormal based on whether the browser access is abnormal. If the browser access is abnormal, the configuration content of the interface request address is determined to be abnormal. When verifying the request method, the configuration content of the request method is judged to be abnormal based on preset request method types. For example, if the preset request method types are only GET and POST, and the configuration content (configuration parameter value) is another request method, the configuration content of the request method is determined to be abnormal. Similarly, when verifying the configuration content of other interface request parameters, verification is performed according to preset rules from dimensions such as data type, character length, and default parameter method.

[0083] Furthermore, the applicant discovered that a very small number of logistics provider interfaces, even after passing null value validation and interface configuration validation, and with all adapted parameter values ​​correct, still failed to return data. After detailed investigation, it was found that the reason was that some users' browser environments cleared or disabled cookie data, causing the overseas warehouse system to fail to send cookie data to the logistics provider system, thus preventing the interface from returning data. Therefore, a special cookie request verification step was added to the overseas warehouse system to improve the success rate of logistics data retrieval. Specifically, in step K4, a cookie request verification is performed on the logistics provider interface that needs to send cookie data. This verification includes checking if the cookie data exists. If the cookie file exists, the cookie request verification is considered normal, and the connection request sending operation continues based on the normal cookie data. If the cookie file does not exist, the cookie request verification is considered abnormal, and the cookie data is regenerated (implemented through Java code). The connection request sending operation continues based on the regenerated cookie data. In addition, when the cookie request verification fails, the abnormal information can be logged and an error can be reported to the overseas warehouse system backend. Correspondingly, the logistics provider interfaces that need to send cookie data can be pre-marked in the interface table. When the system detects the corresponding cookie verification identifier, the cookie request verification operation will be initiated.

[0084] In one embodiment, the error code identifier and corresponding error message of the corresponding logistics provider interface are recorded in the basic information group of the docking table. In step K5, it is detected whether the initial logistics data contains an error code. When an error code is detected, the corresponding error message is generated on the front-end interface of the docking system according to the type of the detected error code. For example, the meaning identifier and prompt message rules of the error code can be pre-configured in the docking table according to the interface document provided by the logistics provider. For a logistics waybill acquisition interface, the error code identifier can be recorded as the identifiers such as "401" and "403" corresponding to the interface document, and the corresponding error message such as "order does not exist" and "order is invalid" can be preset according to their meanings. When the error code "401" is detected, the corresponding prompt message "order does not exist" is generated according to the meaning identifier and prompt message rules of the error code in the docking table.

[0085] Furthermore, a call record table can be configured in the docking system. This call record table records the interface call records of each logistics provider's interface (it can record multiple most recently acquired interface call records). The interface call records include historical logistics provider data that can be assembled and called normally. When an error code is detected in the initial logistics data in step K5, and the detected error code does not have a corresponding error code identifier in the basic information group of the corresponding logistics provider interface, the last recorded historical logistics provider data that can be assembled and called normally is retrieved from the call record table. Then, based on the retrieved historical logistics provider data, a docking request is sent to the corresponding logistics provider interface again to determine whether the re-acquired initial logistics data contains an error code. If an error code is found again, the logistics provider interface is determined to be abnormal, and a corresponding prompt message is sent to the docking system. If no error code is found, an error message is sent indicating that the interface call information configuration is abnormal. In this way, interface abnormalities on the logistics provider system side can be automatically detected.

[0086] In one embodiment, each basic information group in the interface table has a corresponding shutdown switch. When an anomaly is detected in the logistics provider's interface, the state of the corresponding shutdown switch is adjusted to disable the access permission to call the corresponding logistics provider's interface. Furthermore, the shutdown switches can also be configured to be manually activated and deactivated.

[0087] In one embodiment, in step K2, the corresponding logistics provider identifier and logistics provider interface identifier are determined based on the request task that needs to obtain logistics data. The target basic information group is obtained from the docking table based on the request task, logistics provider identifier, and logistics provider interface identifier. The corresponding target strategy rule item and target strategy implementation class are obtained from the general strategy and strategy implementation class based on the strategy rule item identifier of the request task, logistics provider identifier, and target basic information group.

[0088] When retrieving target policy rule items and target policy implementation classes, dependency injection is used to obtain them from the factory pattern: if the passed-in logistics provider identifier or policy rule item identifier is empty, an exception is displayed; if the corresponding target policy rule item and target policy implementation class cannot be found, an exception is displayed. In this way, relevant identifier information can be maintained based on the exception message, ensuring the stability of the system.

[0089] The above description is merely a preferred embodiment of this application and does not limit the patent scope of this application. All equivalent modifications made based on the inventive concept of this application and the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included within the patent protection scope of this application.

Claims

1. A method for bulk docking a logistics provider system, characterized by, A method for interfacing a logistics provider system with an overseas warehouse system, the method comprising: Step S1: creating an interface table for recording basic information of each logistics provider interface, the basic information including logistics provider identification, logistics provider interface identification, interface request address, interface request parameter, parameter mapping rule, and strategy rule item identification, the basic information of each logistics provider interface being respectively created as a corresponding basic information group; Step S2: defining a general strategy for each logistics provider interface, the general strategy rule of the general strategy including encryption rule, request header format setting rule, and return content encapsulation rule, each general strategy rule being pre-configured with one or more strategy rule items, the strategy rule items corresponding to the corresponding strategy rule item identification in the interface table; Step S3: creating a corresponding strategy implementation class according to the specification requirements of each logistics provider interface different from the general strategy rule, the execution priority of the strategy implementation class being higher than that of the general strategy rule; and mapping the general strategy and the strategy implementation class to a factory mode; Step S4: configuring a public interface for uniformly calling each logistics provider interface, including: Step S41: creating a first logic for obtaining a target basic information group from the interface table based on a request task, logistics provider identification, and logistics provider interface identification, the first logic further including identifying the corresponding logistics provider identification and logistics provider interface identification according to the type of the request task; Step S42: creating a second logic for obtaining a corresponding target strategy rule item and target strategy implementation class from the factory mode based on the request task, logistics provider identification, and target basic information group; Step S43: performing logistics provider data assembly based on the obtained target basic information group, target strategy rule item, and target strategy implementation class; Step S44: creating a third logic for automatically calling the corresponding logistics provider interface based on the assembled logistics provider data; Step S5: in response to the logistics provider interface returning initial logistics data, performing a twist operation on the initial logistics data.

2. The method of claim 1, wherein, The method further comprises Step S6: after performing the twist operation, clearing the assembled logistics provider data.

3. The method of claim 1, wherein, The parameter mapping rule of the interface table is stored in an encoded format.

4. The method of claim 1, wherein, The basic information further includes a return result analysis rule, the return result analysis rule defining an analysis relationship using a JSON path expression; and in the execution of the twist operation, relevant twist data is stored to a corresponding path location based on the path expression of the return result analysis rule.

5. The method of claim 1, wherein, The interface table is configured in an editable state, and the content of the interface table is edited through a front-end interface of a system where the public interface is located.

6. The method of claim 5, wherein, When a request task needs to call multiple logistics provider interfaces, the basic information of the multiple logistics provider interfaces is created as a common basic information group, and the same general strategy rule item and strategy implementation class are configured for the multiple logistics provider interfaces.

7. The method of claim 5, wherein, When editing the interface table, if a logistics provider interface is newly added, the corresponding basic information group is added; and if an original logistics provider interface is upgraded, the corresponding basic information group is re-edited.

8. The method of claim 5, wherein, The interface table is associated with an interface test tool, and when editing the interface request address of the interface table, the interface test tool is automatically called to verify the validity of the interface request address.

9. The method of claim 1, wherein, The general strategy rule further comprises a parameter interception rule for intercepting parameters that do not meet preset conditions.

10. An overseas warehouse system characterized by, The overseas warehouse system is used to execute the operation instructions contained in the bulk docking logistics merchant system method of any one of claims 1-9.

Images