CN106406826B

CN106406826B - Joint debugging task creation method, system joint debugging method and device

Info

Publication number: CN106406826B
Application number: CN201510447146.5A
Authority: CN
Inventors: 宋艳雪
Original assignee: Cainiao Smart Logistics Holding Ltd
Current assignee: Cainiao Smart Logistics Holding Ltd
Priority date: 2015-07-27
Filing date: 2015-07-27
Publication date: 2019-12-31
Anticipated expiration: 2035-07-27
Also published as: CN106406826A

Abstract

The embodiment of the application discloses a joint debugging task creation method, a system joint debugging method and a system joint debugging device, wherein the method comprises the following steps: the method comprises the steps that a first data table and a second data table are saved in advance, and when a request for creating a task and adding a related use case for the task is received, a target use case to be added is determined; according to the second data table, providing the target parameters of which the parameter value types in the API associated with the target use case are dynamic; when a request for selecting a rule for the target parameter is received, providing a parameter value generation rule stored in the first data table, and establishing a corresponding relation between the target parameter and the target rule after the target rule is selected; and generating a task, and adding the task into a third data table, wherein at least one target use case associated with the task and the corresponding relation information are saved in the third data table. By the embodiment of the application, the process of joint debugging can not influence the normal operation of an actual service system.

Description

Joint debugging task creation method, system joint debugging method and device

Technical Field

The present application relates to the field of system joint debugging technologies, and in particular, to a joint debugging task creation method, a system joint debugging method, and an apparatus.

Background

In order to better adapt to the rapid development of electronic commerce application, some sales platforms construct large-scale logistics systems. For example, a "bird rape" logistics treasure system of the company Alibarba forms an open social storage facility network through a plurality of modes such as self-construction, co-construction, cooperation and modification. Meanwhile, an open, transparent and shared data application platform is established by utilizing the advanced internet technology, and high-quality services are provided for various enterprises such as e-commerce enterprises, third-party logistics service providers, supply chain service providers and the like. The third-party logistics service providers comprise express delivery, distribution, storage, aviation trunks, transfer warehouses and the like, the geographic positions of the third-party logistics service providers are distributed at home and abroad, and the third-party logistics service providers are called as cabbage bird partners (Cainia Partner, abbreviated as 'CP') in a 'cabbage bird' system. That is, the 'vegetable and bird' is not an express company, but a warehouse and distribution resources of the CP are uniformly managed, and logistics service is provided for business users. From the system implementation perspective, professional solutions are provided according to requirements of sellers, CP and industry development based on existing big data storage. Therefore, there is a constant proliferation of systems and services that require the CP to interface with the "bird and dish" system when they come online. For example, in a trading ex-warehouse scenario, a trading order is generated in the service system, a logistics order is generated in the vegetable and bird system, and the logistics order needs to be issued to the CP system, which requires that the CP system can process the logistics order issued by the vegetable and bird system, and then can perform subsequent ex-warehouse processing and the like.

In the prior art, the business processing logic in the "vegetable bird" system and the CP system are generally developed independently, that is, the business processing logic in the "vegetable bird" system is developed by technical personnel of vegetable birds, and the business processing logic in the CP system is developed by developers of the CP. Developers of the "vegetable bird" system are generally more familiar with some commonly used APIs and the like. However, the development resources of CP system developers are limited, a main flow bug (bug) often exists, and often modifying one bug causes other bugs, and so on.

It can be seen that the CP joint debugging method in the prior art is very inefficient and depends heavily on the stability of the daily environments of the systems such as the detail page (detail), the shopping cart (cart), the pay bank, the vegetable and bird, etc., and the daily deployment authorities of these systems are controlled in different departments respectively, and the deployment time of each department is not constrained by uniform time and is easy to code conflict. Once a problem occurs in the daily environment, joint debugging cannot be performed. In addition, the joint debugging process also affects the normal operation of the actual service system.

Disclosure of Invention

The embodiment of the application provides a joint debugging task creating method, a system joint debugging method and a system joint debugging device, so that the joint debugging process does not depend on the stability of the daily environment of an actual service system any more, and the normal operation of the actual service system is not affected.

The embodiment of the application provides the following scheme:

a joint debugging task creation method, comprising:

pre-storing a first data table and a second data table, wherein at least one parameter value generation rule, the name of the rule and script information required to be executed when the parameter value is generated are stored in the first data table; the rules are used for simulating actual relevant operations in the business system and generating parameter values; at least one use case, a target Application Programming Interface (API) associated with the use case, parameters contained in the target API and parameter value information of each parameter are stored in the second data table; the API is an API which is predefined in the gateway; the parameter value information comprises parameter value types, and the parameter value types comprise a dynamic type and a fixed type;

when a request for creating a task and adding a related use case for the task is received, determining a target use case to be added;

according to the second data table, providing the target parameters of which the parameter value types in the API associated with the target use case are dynamic;

when a request for selecting a rule for the target parameter is received, providing a parameter value generation rule stored in the first data table, and establishing a corresponding relation between the target parameter and the target rule after the target rule is selected;

and after the associated target use cases are added, generating a task, and adding the task into a third data table, wherein at least one target use case associated with the task and the corresponding relation information are stored in the third data table, so that the third-party logistics service provider system is jointly dispatched through each task stored in the third data table.

A system joint debugging method comprises the following steps:

receiving a request for picking up a task;

providing a retrievable task list by using information recorded in a third data table, wherein at least one task, at least one target case associated with the task and corresponding relation information between target parameters and target rules are stored in the third data table, the target case is associated with a target API, the target parameters are parameters set to be dynamic in the target API associated with the target case, the target rules are rules set for the target parameters when the task is created, and the rules are used for simulating actual related operations in a business system and generating parameter values;

after the target task is picked up, when a request for executing a specified target use case associated with the target task is received, parameter value information contained in a target API associated with the specified target use case is determined by using a preset second data table; if the target API has dynamic parameters, determining target rules corresponding to the dynamic parameters by using the corresponding relation recorded in the third data table, and determining script information corresponding to the target rules through a preset first data table so as to generate parameter values by executing the script information;

and performing joint debugging on the third-party logistics service provider system according to the parameter value information.

A joint debugging task creation apparatus comprising:

the device comprises a data table storage unit, a parameter value generation unit and a parameter value generation unit, wherein the data table storage unit is used for storing a first data table and a second data table in advance, and the first data table stores at least one parameter value generation rule, the name of the rule and script information required to be executed when the parameter value is generated; the rules are used for simulating actual relevant operations in the business system and generating parameter values; at least one use case, a target Application Programming Interface (API) associated with the use case, parameters contained in the target API and parameter value information of each parameter are stored in the second data table; the API is an API which is predefined in the gateway; the parameter value information comprises parameter value types, and the parameter value types comprise a dynamic type and a fixed type;

the system comprises a target use case determining unit, a task creating unit and a task adding unit, wherein the target use case determining unit is used for determining a target use case to be added when receiving a request for creating a task and adding a related use case for the task;

a target parameter providing unit, configured to provide, according to the second data table, a target parameter for which a parameter value type in the API associated with the target use case is a dynamic type;

a corresponding relation establishing unit, configured to provide the parameter value generation rule stored in the first data table when receiving a request for selecting a rule for the target parameter, and establish a corresponding relation between the target parameter and the target rule after the target rule is selected;

and the task generating unit is used for generating a task and adding the task into a third data table after the addition of the associated target use case is finished, wherein the third data table stores at least one target use case associated with the task and the corresponding relation information so as to perform joint debugging on the third-party logistics service provider system through each task stored in the third data table.

A system joint debugging device comprising:

a request receiving unit, configured to receive a request for picking up a task;

the system comprises a retrievable task list providing unit, a service system and a service system, wherein the retrievable task list providing unit is used for providing a retrievable task list by utilizing information recorded in a third data table, at least one task, at least one target case associated with the task and corresponding relation information between target parameters and target rules are stored in the third data table, the target case is associated with a target API, the target parameters are parameters set to be dynamic in the target API associated with the target case, the target rules are rules set for the target parameters when the task is created, and the rules are used for simulating actual relevant operations in a service system and generating parameter values;

the parameter value information determining unit is used for determining parameter value information contained in a target API (application program interface) associated with a specified target use case by using a preset second data table when a request for executing the specified target use case associated with the target task is received after the target task is picked up; if the target API has dynamic parameters, determining target rules corresponding to the dynamic parameters by using the corresponding relation recorded in the third data table, and determining script information corresponding to the target rules through a preset first data table so as to generate parameter values by executing the script information;

and the joint debugging unit is used for performing joint debugging on the third-party logistics service provider system according to the parameter value information.

According to the specific embodiments provided herein, the present application discloses the following technical effects:

by the embodiment of the application, tasks for joint debugging can be created, at least one use case can be associated in one task, one use case is associated with the API defined in the gateway, and dynamic parameters in the API can be dynamically generated through a pre-established rule, wherein the rule can be used for simulating actual relevant operations in a business system and generating parameter values. Therefore, when the CP is in joint debugging, the message required by joint debugging can be generated by executing the task, or the message returned by the CP is verified, the whole joint debugging process does not depend on the stability of the daily environment of the actual service system, and the normal operation of the actual service system is not influenced.

In addition, when the system is specifically debugged, messages can be directly generated on the debugging platform according to different service requirements, the stability of the daily environment of the service system is not relied on, data generated by the issued CP interface is not used for purchasing a baby in a test environment to generate a transaction order by debugging personnel, verification of the CP callback interface is not used for verifying the service system, but is directly realized in the debugging system in a rule simulation mode, and therefore efficiency is improved.

Of course, it is not necessary for any product to achieve all of the above-described advantages at the same time for the practice of the present application.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings without creative efforts.

1-1 to 1-6 are schematic diagrams of user interfaces in a use case creation process provided by an embodiment of the present application;

FIG. 2 is a flow chart of a method provided by an embodiment of the present application;

3-1 to 3-3 are schematic diagrams of user interfaces in a joint debugging task creation process provided by the embodiment of the application;

FIG. 4 is a schematic diagram of a joint debugging model provided by the embodiment of the present application;

fig. 5 is a flowchart of a system joint debugging method provided in the embodiment of the present application;

6-1 to 6-9 are schematic diagrams of user interfaces in a system joint debugging process provided by the embodiment of the application;

7-1 to 7-4 are schematic diagrams of a CP-side user interface provided by an embodiment of the present application;

FIG. 8 is a schematic view of an apparatus provided by an embodiment of the present application;

fig. 9 is a schematic diagram of another apparatus provided in an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments that can be derived from the embodiments given herein by a person of ordinary skill in the art are intended to be within the scope of the present disclosure.

In order to smoothly complete the butt joint between the systems, joint debugging is generally required to be performed between the vegetable and bird system and the CP system, and the joint debugging is mainly performed to verify the encryption and decryption modes of the messages in the CP system, whether the CP system can process the messages sent by the vegetable and bird system, whether the messages returned by the CP system meet the requirements, and the like.

The timing of CP joint modulation is generally divided into the following: (1) a new business system of the vegetable and bird is on line, and the CP needs to be jointly adjusted; (2) the negotiation of the vegetable and bird is successful, and newly developed CP needs to be adjusted together; (3) the service change causes that the joint adjustment is needed for the interface change of the 'vegetable bird' and CP butt joint; (4) and (3) upgrading or reconstructing the CP system, and requiring joint debugging to ensure the stability of the system. That is, in many cases, CP joint debugging is required, especially in the vigorous development stage of the "bird and rape" business, where statistically, on average 8.2 CPs per week are required.

In the prior art, joint debugging of CP is generally performed in a "meat by man" manner, taking the joint debugging with CP in a warehouse as an example, the joint debugging process is as follows: a. the joint debugging personnel simulate a buyer to buy a baby to generate a transaction list in a test environment, and use systems (some service scenes also need to use other systems) such as a detail page (detail), a purchase (buy), a shopping cart (cart), a payment device and the like; b. after an order center system of the 'vegetable bird' monitors transaction information to generate a logistics order, the logistics order is sequentially processed by a storage center, a scheduling center, a delivery center and an access center, and the logistics order is issued to a designated CP system after being successfully processed. The whole process usually needs to go through 8-9 systems, and in the joint debugging process, if one system is in a deployment or code conflict stage, the joint debugging is terminated.

In the embodiment of the present application, a joint debugging system is provided, and joint debugging can be performed on a third-party logistics service provider system (for convenience of description, in the embodiment of the present application, a logistics system on a sales platform side is referred to as "bird rape", and a third-party logistics service provider is referred to as "CP" for short) through the joint debugging system, without depending on the stability of the daily environment of an actual business system, and without affecting the normal operation of the actual business system.

In specific implementation, the using parties of the joint debugging system are respectively a vegetable and bird staff (generally called as 'Xiaobi') and a CP staff, the vegetable and bird staff can log in the joint debugging system to create a specific joint debugging task, the CP staff can also log in the joint debugging system, and joint debugging of the CP system is completed by getting and executing the specific joint debugging task.

In the embodiment of the application, a joint debugging task is generally composed of at least one use case, and the use case corresponds to the API defined in the vegetable and bird gateway. The task may be a general warehousing entry, a transfer warehousing entry, a transaction ex-warehouse entry, and the like, and the use case generally relates to the generation of more detailed document information, such as a general warehousing entry issuing warehouse, a warehouse return receipt receiving state, a transfer warehousing entry issuing warehouse, and the like. The API defined in the gateway for birds and rape can be pre-developed and used by the actual business system. In the embodiment of the application, the application case can be created by using the API defined by the gateway, and then at least one application case can be selected from the application case table for association when the task is created, so that the creation of the task can be completed.

For ease of understanding, the following describes the creation process of a use case in connection with an interface presentation of the front end. It should be noted that the front-end interface here can be presented by a separately developed client program, or can also be presented by means of a browser page.

On the side of the vegetable bird system, after logging in the joint debugging system with the identity of the vegetable bird staff, the displayed interface can be as shown in fig. 1-1, wherein the main menu on the left side comprises use case management, task management, rule management, CP management and the like, and after selecting use case management, the interface for creating use cases can be accessed, as shown on the right side of fig. 1-1. In this interface, a use case name may be filled in and an API associated with the use case may be selected. Specifically, when the operation focus enters an input box corresponding to the API, the joint debugging system may provide the API defined in the gateway for selection. Of course, the APIs may be classified in the gateway, for example, the API categories may include "electronic bill", "express bill", and so on, and therefore, as can be seen from fig. 1-1, an input box for selecting the API categories may also be provided, and for the joint debugging system, after the operation focus enters the input box, the API category list defined in the gateway may be displayed, as shown in fig. 1-2. After a certain API category is selected, when the input focus enters an API input box, only various APIs in the API category can be shown for selection, and therefore efficiency can be improved. In addition, the specific API can be selected by directly inputting the name of the API, and the fuzzy query can be supported. For example, if "wms" is entered, the joint debugging system may list all APIs beginning with "wms" for selection, as shown in fig. 1-3. The information about the API defined in the gateway, the API category, and the like may be obtained from the gateway in advance and stored locally in the joint debugging system, so as to improve efficiency and avoid multiple repeated accesses to the gateway. Of course, as shown in fig. 1-1, when creating a use case, an operation option for setting a "calling direction" may also be provided, because when actually performing joint debugging on the CP system, some messages are sent to the CP by the birds and some messages are returned to the birds by the CP according to different specific service scenarios and specific tasks, and therefore, it may be necessary to verify whether the messages returned by the CP meet requirements, in addition to verifying whether the CP can process the messages sent to the CP by the birds and dishes system. Therefore, when creating use cases, use cases with different call directions can be created respectively.

After selecting a certain API, since the gateway generally defines a plurality of parameters for the API, information such as the names of the parameters defined by the gateway for the API can be provided to the staff at the side of the birds and the rape. At this time, the parameter value types and the parameter values of the respective parameters may be configured by the staff. Therefore, in the process of creating the use case, when the target API is selected, at least one parameter defined for the target API in the gateway can be provided, and a first operation option for setting a parameter value type and a parameter value is provided. The parameter value types generally include fixed, dynamic, and the like. Wherein, if the value is a fixed value, specific parameter values can also be set at the same time.

The parameters with the parameter value type being "dynamic" can be dynamically generated by a pre-established parameter value generation rule. When a use case is created, after a certain API is associated, if the parameter value type of a certain parameter in the API is dynamic, a corresponding rule can be selected for the parameter value of the parameter. Of course, for the same parameter under the same API, different use cases may be generated correspondingly under the condition of associating different rules. That is, if a specific rule is associated with a dynamic parameter when a use case is created, it may mean that the number of use cases is very large, which is disadvantageous for data storage and query. Therefore, in the embodiment of the application, when a use case is created, a specific parameter value can be given only for a fixed parameter, and for a dynamic parameter, only a specific parameter value type needs to be specified.

Thus, the process of creating a use case includes: firstly, selecting a related API, and then setting the type of a parameter value of a parameter contained in the API, wherein the parameter value can be directly set as a fixed parameter, and the parameter value can be temporarily not set as a dynamic parameter. For example, as shown IN fig. 1-4, when the associated API is selected as "WMS _ STOCK _ IN _ ORDER _ NOTIFY", the parameters defined by the gateway for the API are the owner ID, the warehouse code, the warehouse center ORDER code, and so on. In a certain example, parameter values of the goods owner ID and the storage code may be set to be fixed, at this time, parameter values of the two parameters may be set simultaneously, and parameter values of the storage center order code and the like may be set to be dynamic, at this time, a rule associated with the parameter values may not be set temporarily. Then, the creation process of the use case can be completed and stored in the second data table. That is, the second data table stores at least one use case, a target API associated with the use case, parameters included in the target API, and parameter value information of each parameter, where the parameter value information specifically includes a parameter value type, the parameter value type includes a dynamic type and a fixed type, and when a certain parameter is a fixed type, the second data table also stores a parameter value specific to the parameter.

In addition, when the calling direction is from the CP, since the message returned by the CP needs to be judged by the joint debugging system during execution of the use case, the judgment object may be each parameter in the API. For this reason, for this case, at the time of creating a use case, a second operation option for setting a parameter that needs to be verified, and a third operation option for setting operation information used at the time of verification may also be provided. In this way, after the operation results of the second operation option and the third operation option are passed, the parameters to be checked and the operation information may be determined, where the operation information includes an operator type, and the operator type may be "present", "equal to" (or "included"), or the like. When the operator type is "equal to" or "included in", the operation information may further include a check reference value, that is, the check is passed only when the parameter value of the parameter is equal to or included in the set reference value in the message returned by the CP. If the operator exists, the CP only needs to return the message with the parameter value of the parameter.

For example, referring to fig. 1-5, for the case that the calling direction is "pass back", after the API is selected, an operation option for selecting "check whether", "operator", and "value" may be provided in the exposed parameter list, where the "value" is the aforementioned check reference value. That is, when generating a use case, it may be selected to verify a part of parameters in the API, and if verification is required, operation information used in verification, including an operator and a specific reference value, may be set. For example, the parameters such as the owner ID, the warehouse code, the warehouse order code, the order type, etc. in fig. 1 to 5 are all required to be checked, wherein the operator corresponding to the first three parameters is "exist", that is, "existing", and the operator corresponding to the order type is "equals", that is, "equal", at this time, a specific reference value, such as 201 in fig. 1 to 5, may also be filled in the "value".

In practical application, the process of creating a use case does not need to be executed in the above manner, and in short, a second data table can be obtained, in which the use case required by CP simulation joint debugging in the joint debugging system is stored. For example, in one implementation, the structure of the second data table may be as shown in table 1 below:

TABLE 1

As described above, for the dynamic parameters set in the API associated with use cases, a rule may be generated by using the pre-created parameter values when determining the specific parameter values, and the following describes the rule in detail.

Among them, the so-called rule is used to simulate the actual relevant operation in the business system to generate the parameter value. In particular, the rules may be multiple and may be created by the joint debugging system. Specifically, after "rule management" is selected in the main menu, it is shown in fig. 1-6 that a rule name, a rule description, and an execution script can be defined. The rule name may be determined by a bird and a vegetable staff, and the rule description describes the role of the rule, for example, for the rule "home delivery manifest number", the rule may be described as "dynamically creating a home delivery manifest number, a 16-bit string, and generating according to time", and the execution script may correspond to a section of code, and a specific rule may be described by the code, and a corresponding parameter value may be generated according to the corresponding rule when the script is executed. Therefore, through the establishment of the rules and the application of the rules in the API parameters, the simulation can be carried out on the original mode of generating the joint debugging message through the upper-layer service system. For example, the WLB order number is generated at the shipping center according to the following rules: a 16-bit string, beginning with "LBX", connecting the timestamps generated by the orders, the rule script generated in the joint debugging platform may be:

"LBX" + time, named "WLB ORDER number generation rule", may be applied to the orderCode field of a plurality of APIs such as WMS _ check _ IN _ ORDER _ NOTIFY, WMS _ confirm _ ORDER _ NOTIFY. Others are as follows: generation rule of waybill number: a NO +16 bit string; transaction order number: a 15-bit string; aviation package number: HK +10 bit strings and other parameters which are generated by a business system and have specific rules and are very important can achieve the simulation effect in a rule inputting and rule quoting mode.

In this way, a plurality of rules can be created and can be stored in the first data table, in which at least one parameter value generation rule, the name of the rule, and script information to be executed when generating the parameter value are stored. Therefore, when a task is subsequently created, an optional rule can be provided from the first data table and is associated with the dynamic parameter in the use case, and when a joint debugging task is specifically executed, a specific parameter value can be generated for the dynamic parameter by using the associated rule. For example, in one specific implementation, the structure of the first data table may be as shown in table 2 below:

TABLE 2

In summary, a specific joint debugging task can be created when the first data table and the second data table are saved. The specific process of creating a task is described below.

Example one

Referring to fig. 2, in one embodiment, a method for creating a joint debugging task is provided, where the method may include the following steps:

s201: pre-storing a first data table and a second data table, wherein at least one parameter value generation rule, the name of the rule and script information required to be executed when the parameter value is generated are stored in the first data table; the rules are used for simulating actual relevant operations in the business system and generating parameter values; at least one use case, a target Application Programming Interface (API) associated with the use case, parameters contained in the target API and parameter value information of each parameter are stored in the second data table; the API is an API which is predefined in the gateway; the parameter value information comprises parameter value types, and the parameter value types comprise a dynamic type and a fixed type;

the first data table and the second data table have been described in the foregoing, and are not described in detail here.

S202: when a request for creating a task and adding a related use case for the task is received, determining a target use case to be added;

as shown in fig. 1-1, in the case of logging in the joint tone system with a bird and rape worker, there is a "task management" option in the main menu, through which the operation of creating a task can be performed. Referring to fig. 3-1, after "task management" is selected, an interface for creating a task may be entered, and when a task is created, a name of the task may be set, which is convenient for reference when the task is picked up. Moreover, an operation option for adding an associated use case, such as "+ associated use case" in fig. 3-1, may also be provided, and a request for adding an associated use case may be triggered through the option.

After receiving the request, the joint debugging system can provide an input box for inputting information such as a use case name, an API name and the like, and can input a target use case to be added in a mode of inputting the use case name and the API name. Alternatively, the joint debugging system may also provide selectable use cases according to the second data table, for example, as shown in fig. 3-2, so that the target use case to be added may be specified in a selected manner. In short, for the joint debugging system, the target use case to be added can be determined, and since the use case is associated with the API in the second data table, the target API associated with the target use case can also be determined.

S203: according to the second data table, providing the target parameters of which the parameter value types in the API associated with the target use case are dynamic;

since in the second data table, in the API associated with the target use case, the parameter values of some parameters are set to be dynamic, but no specific rule is associated yet, it is also possible to extract such dynamic parameters from the second data table and provide operation options for adding an associated rule to such dynamic parameters.

S204: when a request for selecting a rule for the target parameter is received, providing a parameter value generation rule stored in the first data table, and establishing a corresponding relation between the target parameter and the target rule after the target rule is selected;

as shown in fig. 3-3, upon receiving a request to select a rule for a target parameter, a plurality of selectable rules may be exposed, and after a target rule is selected, a correspondence between the target parameter and the target rule may be established.

S205: and after the associated target use cases are added, generating a task, and adding the task into a third data table, wherein at least one target use case associated with the task and the corresponding relation information are stored in the third data table, so that the third-party logistics service provider system is jointly dispatched through each task stored in the third data table.

Through the scheme, after one associated target use case is added, other associated use cases can be added in a similar mode, and after the addition is finished, a task can be generated and stored in the third data table. That is, the information held in the third data table includes: at least one target use case associated with the task and the corresponding relation information determined in step S204. For example, in a specific implementation, the structure of the third data table may be as shown in table 3 below:

TABLE 3

After creating and saving the task to the third data table, the CP side can log in the joint debugging system, pick up the task, and perform joint debugging on the system.

In a specific implementation, the number of tasks to be created may be numerous, and for the CP side, the joint debugging tasks to be retrieved may be different according to the specific service class. That is, a CP may only need to take a portion of its tasks. In addition, for a specific CP, it is generally necessary to acquire all tasks related to its specific service and perform joint debugging, but when the CP is selected from a large number of tasks, omission may occur. Therefore, in order to facilitate the management of the tasks in the third data table and the task acquisition of the CP, the created tasks may be hierarchically and hierarchically managed. In a specific implementation, a fourth data table may be created in advance, where the fourth data table stores at least one service category and at least one service scenario, and one service category includes at least one service scenario. Therefore, when a task is created, a specific service category can be selected first, then a specific service scene under the category is selected, and then a specific task creating process is carried out. Thus, after a task is created, the task is naturally associated with the previously selected service class and service scene, that is, belongs to the specific task under the service class and service scene. Subsequently, when the CP receives the task, the CP may also select a specific service category and a specific service scenario under the category, so that the joint debugging system may provide the CP with the service category and the related task under the service scenario, and the CP receives and executes the tasks.

For example, the structure of the fourth data table may be as shown in table 4:

TABLE 4

Serial number	Class of service	Business scenario
			1	Storage warehouse	Normal scene of warehousing entry
2	Storage warehouse	Warehousing entry cancellation scenario
			3	Storage warehouse	Normal flow of delivery order
4	Express delivery	Delivery scenario
			……	……	……

Thus, the joint call case of the joint call system can be abstracted into a four-layer model of 'business category- > business scene- > task- > use case', wherein the 'business category' is the first layer and refers to non-crossed vertical businesses such as warehousing, express delivery, overseas and the like; the "service scene" is a second layer and refers to a service scene to be associated and dispatched under each service category, and all service scenes support one service category; "task" is a third layer, which refers to a plurality of tasks to be executed by the CP in each service scenario; the 'use case' is a fourth layer, each use case is an API, and a task is formed by calling of a plurality of APIs.

Taking the business category of "warehouse" as an example, the embodiment of the above four-layer model in this category is shown in fig. 4, and it can be seen that: (1) the service category comprises a plurality of service scenes; (2) each service scene is composed of different tasks; (3) the task is composed of at least 1 use case; (4) use cases and APIs are in a one-to-one relationship; (5) the same API may apply to different use cases.

Therefore, by the first embodiment of the application, a task for joint debugging can be created, at least one use case can be associated in one task, one use case is associated with an API defined in a gateway, and dynamic parameters in the API can be dynamically generated through a pre-established rule, wherein the rule can be used for simulating actual related operations in a business system and generating parameter values. Therefore, when the CP is in joint debugging, the message required by joint debugging can be generated by executing the task, or the message returned by the CP is verified, the whole joint debugging process does not depend on the stability of the daily environment of the actual service system, and the normal operation of the actual service system is not influenced.

After the task creation in the first embodiment is completed, the joint debugging system may be used to perform joint debugging on the CP system, and a specific implementation manner is described below.

Example two

Referring to fig. 5, the second embodiment provides a system joint debugging method, which may include the following steps:

s501: receiving a request for picking up a task;

at the CP side, the user can log in to the joint debugging system through the client or the browser with the identity of the CP staff, at this time, the displayed user interface can be as shown in fig. 6-1, after selecting "my task" in the main menu, the user can enter into the interface on the right side, wherein an operation option of "picking up task" is provided on the upper right side, and a request for picking up task can be sent through the operation option.

S502: providing a retrievable task list by using information recorded in a third data table, wherein at least one task, at least one target case associated with the task and corresponding relation information between target parameters and target rules are stored in the third data table, the target case is associated with a target API, the target parameters are parameters set to be dynamic in the target API associated with the target case, the target rules are rules set for the target parameters when the task is created, and the rules are used for simulating actual related operations in a business system and generating parameter values;

as described in the first embodiment, the third data table is created in advance, in which a plurality of joint debugging tasks are stored, and therefore, these tasks can be provided to CP staff, and the staff can select tasks to be retrieved. Certainly, in specific implementation, if the service category and the service scene information are stored in the third data table, the CP may select a specific target service category and a target service scene at first, so that the joint debugging system may provide tasks under the target service category and the target service scene, and may set the tasks to a selected state by default, and the CP staff may directly obtain the tasks. For example, as shown in fig. 6-2, after the order issuing and returning scenario of the home decoration CP is selected, the tasks in the scenario can be exhibited.

For the related information of the third data table and the specific information of the associated first data table and second data table, reference may be made to the description in the first embodiment, and details are not described here.

S503: after the target task is picked up, when a request for executing a specified target use case associated with the target task is received, parameter value information contained in a target API associated with the specified target use case is determined by using a preset second data table; if the target API has dynamic parameters, determining target rules corresponding to the dynamic parameters by using the corresponding relation recorded in the third data table, and determining script information corresponding to the target rules through a preset first data table so as to generate parameter values by executing the script information;

after the task is picked up, each task that has been picked up may be presented in a "my tasks" interface, and each task may be provided with an operation option to view details, such as the "details" button in fig. 6-3. After a task is selected through the "details" button, information of each use case associated with the task can be displayed, for example, after a first task in fig. 6-3 is selected, a details page can be displayed as shown in fig. 6-4, wherein information of each use case associated with the task is displayed, and operation options for executing each use case are provided respectively, such as the "execute" button in fig. 6-4. After an execution button corresponding to a certain use case is operated, the joint debugging system can receive a request for executing a specified target use case associated with a target task.

After receiving the request, the joint debugging system may determine, through the second data table in the first embodiment, parameter value information included in the target API associated with the specified target use case, where for the fixed parameter, a specific parameter value may be directly extracted from the second data table. For the dynamic parameter, the rule associated with the dynamic parameter may be determined from the third data table, and then the execution script of the rule may be taken out from the first data table, and the parameter value of the dynamic parameter may be generated by executing the script.

S504: and performing joint debugging on the third-party logistics service provider system according to the parameter value information.

After parameter value information in the API associated with the use case is determined, the parameter value information can be used for carrying out specific joint debugging. Specifically, since the second data table may further store calling direction information of the target use case, where the calling direction includes a call direction issued to the third-party logistics service provider system or a call direction returned from the third-party logistics service provider system, the CP system may be co-tuned according to the calling direction information and the parameter value information during the co-tuning. If the calling direction is to be sent to the CP system, the message can be generated by using the parameter value information when a request for generating the message is received. For example, for the first use case in fig. 6-4, the calling direction is the down-sending direction, after the request for executing the use case is sent, the interface given by the system may be as shown in fig. 6-5, which includes an operation option for generating a message, such as a "generate message" button, and after the button is triggered, the joint debugging system may generate a message by using the parameter value information determined before. The message is generated by simulating the operation in the actual service system, and thus in the embodiment of the application, the message can be generated completely in the joint debugging system in a simulation mode, in the prior art, if the message is to be generated, a worker needs to purchase a service object in a buy page of the actual service system, generate a transaction order, regenerate a logistics order by a vegetable and bird system, route a CP to be joint debugged through system scheduling according to configured system parameters, and the like.

After the message is generated, the message content can be directly displayed in the interface, as shown in fig. 6-6, the content displayed in the "message distribution" frame is the generated message, so that the CP staff can visually see the specific content of the message, and the problem location is facilitated when a problem occurs. In addition, the interface may also provide an operation option for issuing a message, such as an "execute issue" button in fig. 6 to 6, and after the button is operated, the joint debugging system may issue the message to the CP system, and the CP system processes the message.

After the CP system finishes processing the packet, the result of "correct" or "incorrect" processing may be returned, and the result may also be displayed on the interface, as shown in fig. 6 to 7, and the processing result of the CP system on the packet is displayed in the "packet result" box. Thus, CP workers can visually see the joint debugging result, and can timely modify the result when finding an 'error' result.

When the message is sent to the CP system, the sending may be performed according to a predetermined URL (Uniform Resource Locator) of the CP, or when the sending needs to be performed, a CP worker may fill in the URL of the CP system. In addition, the message format, the coding information and the like of the CP system may be predetermined, so that the message may be generated according to the message format and the coding information, so that the CP system can recognize the message. Moreover, in order to better simulate the objects of the actual service system and the CP system, the message may be signed by the gateway when the message is sent, and at this time, the signature algorithm of the CP system may be predetermined, so that the gateway may sign the message by using the same signature algorithm and then send the signed message to the CP system.

The URL, message format, coding information, signature algorithm, etc. of the CP may be configured in the "application information" of the joint debugging system. For example, as shown in fig. 6-8, after the CP staff logs in to the joint debugging system, the page may be entered first to configure the above information. Of course, in specific implementation, the method can be implemented in other ways.

The foregoing introduces the execution process of the use case whose calling direction is issue, and for the use case whose calling direction is return, after triggering the execution request of the use case, the interface shown in fig. 6-9 may be entered, at this time, the CP system may first generate a segment of message, and then return the message to the joint debugging system. After the joint debugging system receives the message returned by the CP system, the returned message can be verified by using the parameter value information in the API corresponding to the current use case. Specifically, the second data table further stores parameters to be checked in the API associated with the use case and operation information, where the operation information includes an operator type, and the operator type includes existence, equal to, or included, and when the operator type is equal to or included, the operation information further includes a check reference value; therefore, the returned message can be verified by using the parameters and the operation information which need to be verified. For example, the parameter to be checked is found out from the returned message, the parameter value is determined, then the judgment is performed by using the operation information, the judgment result can be used as the joint debugging result, the obtained 'correct' or 'wrong' checking result can be used as the joint debugging result for the CP system, and the result can be displayed in the user interface. The mode of obtaining the written joint debugging report by the CP system executing the task track can conveniently, visually and multi-dimensionally obtain the joint debugging result and the performance condition of the CP system, and can more accurately judge whether the CP system can be on line or not.

Therefore, in the embodiment of the application, the message can be directly generated on the joint debugging platform according to different business requirements, the stability of the daily environment of the business system is not relied on, the data generated by the issued CP interface does not generate a transaction order by a joint debugging person purchasing a baby in a test environment, the verification of the CP callback interface is not realized by the business system, but is directly realized in the joint debugging system in a rule simulation mode, and therefore the efficiency is improved.

In addition, in practical application, although the service logic of the CP system should be developed according to a "white paper" provided by the sales platform (including APIs defined in the civet gateway and including message formats, encoding types, signature algorithms, etc. used under various service categories), specific codes of the algorithms are still developed or written by the CP staff, and thus, situations such as incorrect signature of the CP system often occur. For example, the MD5 algorithm is also used, but the signature results obtained by different encryption lengths are different, if 64 bits are specified to be used in the white paper, the signature is strictly performed according to the length of 63 bits in the vegetable bird system, but the signature actually used in the CP system may be 32 bits, so that the CP system cannot decrypt the message sent by the vegetable bird system, and so on.

In order to facilitate the CP-side staff to determine whether the signature algorithm is problematic, a "signature check" option may be provided, for example, when the option is selected, an interface as shown in fig. 7-1 may be displayed, wherein the name of the signature algorithm and the character code may be determined according to the information such as the service category of the current CP, and a key (secret key) agreed with the bird and vegetable system may also be determined, at this time, the CP staff may input a message for test in a "target message" input box, for example, a string of numbers as shown in fig. 7-2, and after clicking a "generate signature" button, the joint debugging system may operate on the message by using the corresponding algorithm code and key in the system to obtain a digital signature, as shown in a "digital signature" column in fig. 7-2. Then, the CP staff can use the algorithm code in the CP system and the key to operate the same target message, and also can obtain a digital signature, and by comparing the digital signature with the digital signature given by the joint debugging system, it can be determined whether the previous algorithm of the CP system is correct.

To facilitate the CP staff to locate the problems present in the signature algorithm code, an operation option of "view algorithm description" may also be provided, and when a view request is received through this option, a specific description may be given, as shown in fig. 7-3.

In addition, for a task, since a plurality of use cases are generally included, and only after all use cases under a task are executed, the task is executed successfully, however, in practical applications, an error may be found after a certain use case is executed, but a reason may not be found at any time, which may cause interruption of the whole test flow. To assist CP staff in error location in such situations, a "self-test" function may also be provided. For example, as shown in FIGS. 7-4, a "self-test tools" option is included in the main menu, which, when selected, presents a right-hand interface in which a single use case associated API can be self-tested. The self-test process is similar to that of the second-generation configuration case, a specific API can be selected, at the moment, the joint debugging system can pull parameters of the API from the gateway, and CP workers can configure parameter value information of each parameter, including parameter value types, parameter values and the like. After the configuration is completed, the use case can be executed, a message is generated and sent to the CP system of the user, and the execution result is checked. If the execution result is correct, the API self-test representing the CP self-test passes; if the execution result is wrong, the API representing CP self-test has bug (bug), and the CP is required to modify the code, and then the self-test can be carried out.

It should be noted that, in each step in the first and second embodiments of the present application, the execution main body may be a joint debugging system running in the sales platform server, that is, the joint debugging between the sales platform logistics system and the third-party logistics system is realized through a software and hardware system running on the sales platform server side.

In accordance with the first embodiment, an apparatus for creating a joint debugging task is further provided in the embodiments of the present application, and referring to fig. 8, the apparatus may include:

a data table storage unit 801, configured to store a first data table and a second data table in advance, where the first data table stores at least one parameter value generation rule, a name of the rule, and script information to be executed when generating a parameter value; the rules are used for simulating actual relevant operations in the business system and generating parameter values; at least one use case, a target Application Programming Interface (API) associated with the use case, parameters contained in the target API and parameter value information of each parameter are stored in the second data table; the API is an API which is predefined in the gateway; the parameter value information comprises parameter value types, and the parameter value types comprise a dynamic type and a fixed type;

a target use case determining unit 802, configured to determine a target use case to be added when receiving a request for creating a task and adding a related use case for the task;

a target parameter providing unit 803, configured to provide, according to the second data table, a target parameter whose parameter value type in the API associated with the target use case is a dynamic type;

a corresponding relationship establishing unit 804, configured to provide the parameter value generation rule stored in the first data table when receiving a request for selecting a rule for the target parameter, and establish a corresponding relationship between the target parameter and the target rule after the target rule is selected;

and a task generating unit 805, configured to generate a task after the associated target use case is added, and add the task to a third data table, where the third data table stores at least one target use case associated with the task and the correspondence information, so as to perform joint debugging on the third-party logistics service provider system through each task stored in the third data table.

In a specific implementation, the apparatus may further include:

an optional API providing unit, which is used for providing the optional API defined in the gateway when receiving the request of creating the use case;

a first operation option providing unit, configured to provide at least one parameter defined for a target API in the gateway when the target API is selected, and provide a first operation option for setting a parameter value type and a parameter value;

and the use case generating unit is used for generating a use case after receiving the parameter setting information through the first operation option, and storing the target API associated with the use case and the parameter setting information in the second data table.

The request for creating the use case also carries calling direction information of the use case, wherein the calling direction comprises the calling direction information which is issued to a third-party logistics service provider system or returned from the third-party logistics service provider system;

the apparatus may further include:

and the call direction information storage unit is used for storing the call direction information of the use case in the second data table.

Wherein, the device can also include:

the second operation option providing unit is used for providing a second operation option for setting parameters needing to be verified and a third operation option for setting operation information used in verification when the calling direction is returned from the third-party logistics service provider system;

an operation information determining unit, configured to determine, through operation results of the second operation option and the third operation option, a parameter and operation information that need to be checked, where the operation information includes an operator type, and the operator type includes existence, equal to, or included, and when the operator type is equal to or included, the operation information further includes a check reference value;

and the operation information storage unit is used for storing the parameters needing to be checked and the operation information into the second data table.

In addition, the method can also comprise the following steps:

a fourth data table storage unit, configured to store a fourth data table in advance, where the fourth data table stores at least one service category and at least one service scenario, and each service category includes at least one service scenario;

a service category providing unit, configured to provide a selectable service category according to the fourth data table when the request for creating the task is received;

the optional service scene providing unit is used for providing an optional service scene under the service category according to the fifth data table after the target service category is selected;

and the association relation storage unit is used for storing the association relation among the target business category, the target business scene and the tasks in the third data table after the target business scene is selected and the tasks are generated so that when the third-party logistics service provider system is jointly dispatched, the third-party logistics service provider system receives the associated tasks according to the specified business category and the business scene and executes the associated tasks for the joint dispatching.

By the device, tasks for joint debugging can be created, at least one use case can be associated in one task, one use case is associated with the API defined in the gateway, and dynamic parameters in the API can be dynamically generated through a pre-established rule, wherein the rule can be used for simulating actual relevant operations in a business system and generating parameter values. Therefore, when the CP is in joint debugging, the message required by joint debugging can be generated by executing the task, or the message returned by the CP is verified, the whole joint debugging process does not depend on the stability of the daily environment of the actual service system, and the normal operation of the actual service system is not influenced.

Corresponding to the second embodiment, the embodiment of the present application further provides a system joint debugging apparatus, and referring to fig. 9, the apparatus may include:

a request receiving unit 901, configured to receive a request for picking up a task;

a retrievable task list providing unit 902, configured to provide a retrievable task list by using information recorded in a third data table, where the third data table stores at least one task, at least one target use case associated with the task, and correspondence information between a target parameter and a target rule, the target use case is associated with a target API, the target parameter is a parameter set to be dynamic in the target API associated with the target use case, the target rule is a rule set for the target parameter when the task is created, and the rule is used to simulate an actual related operation in a business system and generate a parameter value;

a parameter value information determining unit 903, configured to determine, by using a preset second data table, parameter value information included in a target API associated with a specified target use case when a request for executing the specified target use case associated with the target task is received after the target task is picked up; if the target API has dynamic parameters, determining target rules corresponding to the dynamic parameters by using the corresponding relation recorded in the third data table, and determining script information corresponding to the target rules through a preset first data table so as to generate parameter values by executing the script information;

and the joint debugging unit 904 is configured to perform joint debugging on the third-party logistics service provider system according to the parameter value information.

Wherein, the third data table stores the association relationship among the service categories, the service scenes and the tasks, and the request receiving unit is specifically configured to:

receiving a request for picking up a task under a specified service type and a specified service scene sent by a client;

the retrievable task list providing unit is specifically configured to:

and providing the retrievable task list under the specified service category and the specified service scene by using the information recorded in the third data table.

The second data table also stores calling direction information of the target use case, and the calling direction comprises information issued to a third-party logistics service provider system or information returned from the third-party logistics service provider system;

the joint debugging unit is specifically used for:

and performing joint debugging on the third-party logistics service provider system according to the calling direction information and the parameter value information.

In a specific implementation, the joint debugging unit may include:

the message generation subunit is used for generating a message by using the parameter value information when receiving a request for generating the message if the calling direction is issued to a third-party logistics service provider system;

and the message issuing subunit is used for issuing the generated message to a third-party logistics service provider system so as to be processed by the related business logic of the third-party logistics service provider system.

In a specific implementation, the apparatus may further include:

the URL information determining unit is used for determining URL information of the uniform resource locators of the third-party logistics service provider system in advance;

the message issuing subunit is specifically configured to:

and issuing the generated message to a third-party logistics service provider system according to the predetermined URL information.

The format and coding information determining unit is used for determining the message format and the resource coding information of the third-party logistics service provider system in advance;

the message generating subunit is specifically configured to

And generating a message which accords with the message format and the resource coding by using the parameter value information.

The signature algorithm determining unit is used for determining the signature algorithm information of the third-party logistics service provider system in advance;

the message issuing subunit is specifically configured to:

and signing the message by using the signature algorithm through the gateway, and then issuing the message to a third-party logistics service provider system.

Wherein, the joint debugging unit includes:

the message receiving subunit is configured to receive a message returned by the third-party logistics service provider system if the calling direction is returned from the third-party logistics service provider system;

and the checking subunit is used for checking the returned message by using the parameter value information.

If the calling direction is returned from the third-party logistics service provider system, parameters needing to be checked in the API associated with the use case and operation information are also stored in the second data table, the operation information comprises an operator type, and the operator type comprises existence, equal to or contained in the operator type, wherein when the operator type is equal to or contained in the operator type, the operation information further comprises a check reference value;

the syndrome unit is specifically configured to:

and checking the returned message by using the parameters to be checked and the operation information.

In addition, the apparatus may further include:

a signature algorithm verification request receiving unit for receiving a signature algorithm verification request;

the signature information determining unit is used for determining the type of a signature algorithm to be detected and the type of a code;

a target message receiving unit, configured to receive a target message;

and the operation unit is used for operating the target message by using the algorithm content corresponding to the signature algorithm type and the coding type defined by the gateway and a preset key and providing a digital signature result so as to judge whether the signature algorithm content of the CP system is correct or not by comparing the digital signature result of the target message with the digital signature result of the CP system.

A viewing request receiving unit for receiving a request for viewing the signature algorithm description;

and the description information providing unit is used for providing the algorithm description information corresponding to the signature algorithm type and the coding type.

A self-test request receiving unit, configured to receive a request for performing self-test on a specified API;

an option providing unit, configured to pull the parameters of the specified API from the gateway, and provide operation options for configuring parameter value information of each parameter;

the case generating unit is used for generating a case and executing the case to obtain a message after the parameter value information is received through the operation options;

and the processing unit is used for issuing the message to the third-party logistics service provider system for processing so as to carry out self-test according to a processing result.

By the device, messages can be directly generated on the joint debugging platform according to different business requirements, the stability of the daily environment of a business system is not relied on, data generated by the issued CP interface is not required to be purchased by joint debugging personnel in a test environment to generate a transaction order, and the verification of the CP callback interface is not required to be realized by the business system but directly realized in the joint debugging system in a rule simulation mode, so that the efficiency is improved.

From the above description of the embodiments, it is clear to those skilled in the art that the present application can be implemented by software plus necessary general hardware platform. Based on such understanding, the technical solutions of the present application may be essentially or partially implemented in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method according to the embodiments or some parts of the embodiments of the present application.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, the system or system embodiments are substantially similar to the method embodiments and therefore are described in a relatively simple manner, and reference may be made to some of the descriptions of the method embodiments for related points. The above-described system and system embodiments are only illustrative, wherein the units described as separate parts may or may not be physically separate, and the parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.

The method and the device for creating the joint debugging task and the system joint debugging provided by the application are introduced in detail, specific examples are applied in the method to explain the principle and the implementation mode of the application, and the description of the embodiments is only used for helping to understand the method and the core idea of the application; meanwhile, for a person skilled in the art, according to the idea of the present application, the specific embodiments and the application range may be changed. In view of the above, the description should not be taken as limiting the application.

Claims

1. A joint debugging task creation method, comprising:

2. The method of claim 1, further comprising:

when a request for creating a use case is received, providing an optional API defined in a gateway;

when a target API is selected, providing at least one parameter defined for the target API in the gateway, and providing a first operation option for setting a parameter value type and a parameter value;

and generating a use case after parameter setting information is received through the first operation option, and storing the target API associated with the use case and the parameter setting information in the second data table.

3. The method according to claim 2, wherein the request for creating a use case further carries call direction information of the use case, and the call direction includes sending to a third-party logistics service provider system or returning from the third-party logistics service provider system;

the method further comprises the following steps:

and saving the call direction information of the use case in the second data table.

4. The method of claim 3, further comprising:

when the calling direction is returned from a third-party logistics service provider system, providing a second operation option for setting parameters needing to be verified and a third operation option for setting operation information used in verification;

determining parameters and operation information which need to be checked through operation results of the second operation option and the third operation option, wherein the operation information comprises an operator type, and the operator type comprises existence, equal or contained, and when the operator type is equal to or contained, the operation information further comprises a check reference value;

and storing the parameters to be checked and the operation information into the second data table.

5. The method of any of claims 1 to 4, further comprising:

a fourth data table is pre-stored, wherein at least one service category and at least one service scene are stored in the fourth data table, and one service category comprises at least one service scene;

when receiving a request for creating a task, providing selectable service types according to the fourth data table;

after the target service category is selected, providing selectable service scenes under the service category according to a fifth data table;

and after the target business scene is selected and the task is generated, storing the association relation among the target business category, the target business scene and the task in the third data table so as to lead the third-party logistics service provider system to obtain the associated task according to the specified business category and the business scene and perform the association regulation by executing the associated task when the third-party logistics service provider system performs the association regulation.

6. A system joint debugging method is characterized by comprising the following steps:

receiving a request for picking up a task;

7. The method of claim 6, wherein the third data table stores the association relationship among the service category, the service scenario and the task, and the receiving the request for picking up the task comprises:

the providing of the retrievable task list using the information recorded in the third data table includes:

8. The method according to claim 6, wherein the second data table further stores invocation direction information of the target use case, and the invocation direction includes being issued to a third-party logistics service provider system or being returned from the third-party logistics service provider system;

the joint debugging of the third-party logistics service provider system according to the parameter value information comprises the following steps:

9. The method of claim 8, wherein the joint debugging the third-party logistics service provider system according to the invocation direction information and the parameter value information comprises:

if the calling direction is issued to a third-party logistics service provider system, generating a message by using the parameter value information when receiving a request for generating the message;

and issuing the generated message to a third-party logistics service provider system so as to be processed by the related business logic of the third-party logistics service provider system.

10. The method of claim 9, further comprising:

pre-determining Uniform Resource Locator (URL) information of the third-party logistics service provider system;

the issuing of the generated message to a third-party logistics service provider system comprises:

11. The method of claim 9, further comprising:

the message format and the resource coding information of the third-party logistics service provider system are predetermined;

the generating a message by using the parameter value information includes:

12. The method of claim 9, further comprising:

pre-determining signature algorithm information of the third-party logistics service provider system;

13. The method of claim 8, wherein the joint debugging the third-party logistics service provider system according to the invocation direction information and the parameter value information comprises:

if the calling direction is returned from the third-party logistics service provider system, receiving a message returned by the third-party logistics service provider system;

and checking the returned message by using the parameter value information.

14. The method according to claim 13, wherein if the calling direction is from a third-party logistics service provider system, the second data table further stores parameters to be checked in an API associated with a use case and operation information, the operation information includes an operator type, the operator type includes existence, equal to, or included in, wherein when the operator type is equal to or included in, the operation information further includes a check reference value;

the verifying the returned message by using the parameter value information includes:

15. The method of any of claims 7 to 14, further comprising:

receiving a signature algorithm verification request;

determining the type of a signature algorithm to be detected and the type of a code;

receiving a target message;

and calculating the target message by using the algorithm content corresponding to the signature algorithm type and the coding type defined by the gateway and a preset key, and providing a digital signature result so as to judge whether the signature algorithm content of the third-party logistics service provider system is correct or not by comparing the digital signature result of the target message with the digital signature result of the third-party logistics service provider system.

16. The method of claim 15, further comprising:

receiving a request to view a signature algorithm description;

and providing algorithm description information corresponding to the signature algorithm type and the coding type.

17. The method of any of claims 7 to 14, further comprising:

receiving a request for self-testing a specified API;

pulling the parameters of the specified API from the gateway, and providing operation options for configuring parameter value information of each parameter;

after parameter value information is received through the operation options, generating a use case and executing the use case to obtain a message;

and sending the message to the third-party logistics service provider system for processing so as to carry out self-test according to a processing result.

18. A joint debugging task creation apparatus comprising:

19. The apparatus of claim 18, further comprising:

20. The apparatus according to claim 19, wherein the request for creating a use case further carries invocation direction information of the use case, and the invocation direction includes being issued to a third-party logistics service provider system or being returned from the third-party logistics service provider system;

the device further comprises:

21. The apparatus of claim 20, further comprising:

22. The apparatus of any one of claims 18 to 21, further comprising:

the optional service scene providing unit is used for providing optional service scenes under the service category according to the fifth data table after the target service category is selected;

23. A system joint debugging device, comprising:

24. The apparatus according to claim 23, wherein the third data table stores association relationships among service classes, service scenarios, and tasks, and the request receiving unit is specifically configured to:

the retrievable task list providing unit is specifically configured to:

25. The apparatus according to claim 23, wherein the second data table further stores invocation direction information of the target use case, and the invocation direction includes being issued to a third-party logistics service provider system or being returned from the third-party logistics service provider system;

the joint debugging unit is specifically used for:

26. The apparatus of claim 25, wherein the joint debugging unit comprises:

27. The apparatus of claim 26, further comprising:

the message issuing subunit is specifically configured to:

28. The apparatus of claim 26, further comprising:

the message generating subunit is specifically configured to

29. The apparatus of claim 26, further comprising:

the message issuing subunit is specifically configured to:

30. The apparatus of claim 25, wherein the joint debugging unit comprises:

31. The apparatus according to claim 30, wherein if the calling direction is from a third-party logistics service provider system, the second data table further stores parameters to be checked in an API associated with a use case and operation information, the operation information includes an operator type, the operator type includes existence, equal to, or included in, and wherein when the operator type is equal to or included in, the operation information further includes a check reference value;

the syndrome unit is specifically configured to:

32. The apparatus of any one of claims 24 to 31, further comprising:

a target message receiving unit, configured to receive a target message;

and the operation unit is used for operating the target message by using the algorithm content corresponding to the signature algorithm type and the coding type defined by the gateway and a preset key and providing a digital signature result so as to judge whether the signature algorithm content of the third-party logistics service provider system is correct or not by comparing the digital signature result of the target message with the digital signature result of the third-party logistics service provider system.

33. The apparatus of claim 32, further comprising:

34. The apparatus of any one of claims 24 to 31, further comprising: