联调任务创建、系统联调方法及装置与流程

本申请涉及系统联调
技术领域：
，特别是涉及联调任务创建、系统联调方法及装置。
背景技术：
：为了更好的适应电子商务应用的快速发展，有些销售平台构建了大型的物流系统。例如，阿里巴巴公司的“菜鸟”物流宝系统等，这种系统通过自建、共建、合作、改造等多种模式，形成一套开放的社会化仓储设施网络。同时利用先进的互联网技术，建立开放、透明、共享的数据应用平台，为电子商务企业、第三方物流服务商、供应链服务商等各类企业提供优质服务。其中，第三方物流服务商包括快递、配送、仓储、航空干线、中转仓等，地理位置分布在国内外各地，在“菜鸟”系统中称为菜鸟合作伙伴(CainiaPartner，简称为“CP”)。也就是说，“菜鸟”并不是一家快递公司，而是将CP的仓库及配送资源进行统一管理，并为商家用户提供物流服务。从系统实现角度而言，而是基于已有的大数据存储并根据卖家、CP的诉求和行业发展等提供专业的解决方案。因此，会不断有系统和业务滋生，当这些业务和系统上线后就要求CP与“菜鸟”系统进行对接。例如，在交易出库场景下，业务系统中生成交易订单，到菜鸟系统生成物流订单，该物流订单需要下发给CP系统，这就要求CP系统能够处理菜鸟系统下发的该物流订单，进而才能执行后续的出库等处理。在现有技术中，“菜鸟”系统以及CP系统中的业务处理逻辑一般是独立开发的，也即，“菜鸟”系统的业务处理逻辑由菜鸟的技术人员开发，而CP系统中的业务处理逻辑则由CP自己的开发人员进行开发。“菜鸟”系统的开发人员一般对于一些常用的API等更为熟悉。但是，CP系统开发人员的开发资源有限，经常存在主流程缺陷(bug)，并且，经常改好一个bug引起其他bug，等等。可见，现有技术中的CP联调方式效率很低，并且严重依赖详情页(detail)、 购买(buy)购物车(cart)、支付宝、菜鸟等系统日常环境的稳定性，而这些系统的日常部署权限分别控制在不同部门，各自部门的部署时间不受统一时间约束且容易代码冲突。日常环境一旦出现问题，联调则无法进行。并且，联调的过程也会对实际业务系统的正常运行造成影响。技术实现要素：本申请实施例提供了联调任务创建、系统联调方法及装置，能够使得联调的过程不再依赖于实际业务系统日常环境的稳定性，也不会对实际业务系统的正常运行造成影响。本申请实施例提供了如下方案：一种联调任务创建方法，包括：预先保存第一数据表以及第二数据表，所述第一数据表中保存有至少一条参数值生成规则，以及所述规则的名称、生成参数值时所需执行的脚本信息；所述规则用于模拟业务系统中实际的相关操作，并产生参数值；所述第二数据表中保存有至少一个用例、所述用例关联的目标应用程序编程接口API、所述目标API包含的参数以及各参数的参数值信息；其中，所述API为网关中预先定义的API；所述参数值信息包括参数值类型，所述参数值类型包括动态型以及固定型；接收到创建任务并为所述任务添加关联用例的请求时，确定待添加的目标用例；根据所述第二数据表，提供所述目标用例关联的API中参数值类型为动态型的目标参数；接收到为所述目标参数选择规则的请求时，提供所述第一数据表中保存的所述参数值生成规则，并在目标规则被选中后，建立所述目标参数与所述目标规则之间的对应关系；在关联的目标用例添加完毕后，生成任务，并添加到第三数据表中，所述第三数据表中保存所述任务关联的至少一个目标用例以及所述对应关系信息，以便通过所述第三数据表中保存的各任务，对第三方物流服务提供方系统进行联调。一种系统联调方法，包括：接收领取任务的请求；利用第三数据表中记录的信息提供可领取任务列表，其中，所述第三数据表中保存有至少一个任务、任务关联的至少一个目标用例以及目标参数与目标规则之间的对应关系信息，所述目标用例与目标API关联，所述目标参数为所述目标用例关联的目标API中被设定为动态型的参数，所述目标规则为创建所述任务时为所述目标参数设定的规则，该规则用于模拟业务系统中实际的相关操作，并产生参数值；目标任务被领取后，接收到对所述目标任务关联的指定目标用例进行执行的请求时，利用预置的第二数据表确定所述指定目标用例关联的目标API包含的参数值信息；其中，如果该目标API中带有动态型参数，则利用所述第三数据表中记录的对应关系，确定该动态型参数对应的目标规则，并通过预置的第一数据表确定所述目标规则对应的脚本信息，以便通过执行所述脚本信息生成参数值；根据所述参数值信息对第三方物流服务提供方系统进行联调。一种联调任务创建装置，包括：数据表保存单元，用于预先保存第一数据表以及第二数据表，所述第一数据表中保存有至少一条参数值生成规则，以及所述规则的名称、生成参数值时所需执行的脚本信息；所述规则用于模拟业务系统中实际的相关操作，并产生参数值；所述第二数据表中保存有至少一个用例、所述用例关联的目标应用程序编程接口API、所述目标API包含的参数以及各参数的参数值信息；其中，所述API为网关中预先定义的API；所述参数值信息包括参数值类型，所述参数值类型包括动态型以及固定型；目标用例确定单元，用于接收到创建任务并为所述任务添加关联用例的请求时，确定待添加的目标用例；目标参数提供单元，用于根据所述第二数据表，提供所述目标用例关联的API中参数值类型为动态型的目标参数；对应关系建立单元，用于接收到为所述目标参数选择规则的请求时，提供所述第一数据表中保存的所述参数值生成规则，并在目标规则被选中后，建立所述目标参数与所述目标规则之间的对应关系；任务生成单元，用于在关联的目标用例添加完毕后，生成任务，并添加到第三数据表中，所述第三数据表中保存所述任务关联的至少一个目标用例以及所述对应关系信息，以便通过所述第三数据表中保存的各任务，对第三方物流服务提供方系统进行联调。一种系统联调装置，包括：请求接收单元，用于接收领取任务的请求；可领取任务列表提供单元，用于利用第三数据表中记录的信息提供可领取任务列表，其中，所述第三数据表中保存有至少一个任务、任务关联的至少一个目标用例以及目标参数与目标规则之间的对应关系信息，所述目标用例与目标API关联，所述目标参数为所述目标用例关联的目标API中被设定为动态型的参数，所述目标规则为创建所述任务时为所述目标参数设定的规则，该规则用于模拟业务系统中实际的相关操作，并产生参数值；参数值信息确定单元，用于目标任务被领取后，接收到对所述目标任务关联的指定目标用例进行执行的请求时，利用预置的第二数据表确定所述指定目标用例关联的目标API包含的参数值信息；其中，如果该目标API中带有动态型参数，则利用所述第三数据表中记录的对应关系，确定该动态型参数对应的目标规则，并通过预置的第一数据表确定所述目标规则对应的脚本信息，以便通过执行所述脚本信息生成参数值；联调单元，用于根据所述参数值信息对第三方物流服务提供方系统进行联 调。根据本申请提供的具体实施例，本申请公开了以下技术效果：通过本申请实施例，可以创建用于联调的任务，在一个任务中可以关联至少一个用例，而一个用例与网关中定义的API关联，对于API中的动态参数，可以通过预先建立的规则来动态生成，其中，该规则可以用于模拟业务系统中实际的相关操作，并产生参数值。这样，在对CP进行联调时，就可以通过执行这种任务来生成联调所需的报文，或者对CP回传的报文进行校验，整个联调的过程不再依赖于实际业务系统日常环境的稳定性，也不会对实际业务系统的正常运行造成影响。另外，具体在进行系统联调时，可以根据不同的业务需求直接在联调平台生成报文，不再依赖业务系统日常环境的稳定性，下发CP接口生成的数据不再通过联调人员在测试环境购买宝贝产生交易订单，CP回调接口校验也不再通过业务系统，而是直接在联调系统内部通过规则模拟的方式来实现，因此，使得效率得到提高。当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。附图说明为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。图1-1至1-6是本申请实施例提供的用例创建过程中的用户界面示意图；图2是本申请实施例提供的方法的流程图；图3-1至3-3是本申请实施例提供的联调任务创建过程中的用户界面示意图；图4是本申请实施例提供联调模型示意图；图5是本申请实施例提供的系统联调方法的流程图；图6-1至6-9是本申请实施例提供的系统联调过程中的用户界面的示意图；图7-1至7-4是本申请实施例提供的CP侧用户界面示意图；图8是本申请实施例提供的装置的示意图；图9是本申请实施例提供的另一装置的示意图。具体实施方式下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。为了使得系统之间对接时能够顺利完成，一般需要在菜鸟系统与CP系统之间进行“联调”，联调的目的主要是，对CP系统中报文的加解密方式、CP系统是否能够处理菜鸟系统下发的报文、CP系统回传的报文是否符合要求等等进行验证。其中，CP联调的时机一般分为以下几种：(1)“菜鸟”新业务系统上线，CP需要联调；(2)“菜鸟”洽谈成功，新发展的CP需要联调；(3)业务变更，导致“菜鸟”与CP对接的接口变更需要联调；(4)CP系统升级或者改造，需要联调以保障系统稳定。也就是说，在很多种情况下，都需要进行CP联调，尤其是在“菜鸟”业务大力发展阶段，据统计，每周平均8.2家CP需要联调。现有技术中一般通过“人肉”的方式进行CP联调，以与仓库CP联调为例，联调过程如下：a、联调人员在测试环境模拟买家购买宝贝生成交易单，使用详情页(detail)、购买(buy)、购物车(cart)、“支付宝”等系统(有的业务场景还需要使用其他系统)；b、“菜鸟”的订单中心系统监听到交易消息生成物流订单后，物流订单经过仓储中心、调度中心、发货中心、接入中心依次处理，处理成功后下发给指定的CP系统。整个过程通常需要经历8-9个系统，在联调过程中，如果有一个系统处于部署或者代码冲突阶段都会导致联调终止。在本申请实施例中，提供了联调系统，通过该联调系统就可以实现对第三方物流服务提供方系统(为了便于描述，在本申请实施例中，将销售平台侧的物流系统称为“菜鸟”，第三方物流服务提供方简称为“CP”)进行联调，而不需要再依赖实际业务系统日常环境的稳定性，也不会对实际业务系统的正常运行造成影响。具体实现时，该联调系统的使用方分别为菜鸟的工作人员(一般称为“小二”)，以及CP工作人员，菜鸟工作人员可以登录到联调系统，创建具体的联调任务，CP工作人员也可以登录到该联调系统，通过领取具体的联调任务并执行，来完成对CP系统的联调。在本申请实施例中，一个联调任务一般是由至少一个用例构成，而用例与菜鸟网关中定义的API对应。其中，任务一般可以是普通入库单、调拨入库单、交易出库单等等，而用例则一般是涉及更细化的单据信息的生成，例如，普通入库单下发仓库、仓库回传接单状态、调拨入库单下发仓库，等等。其中，菜鸟网关中定义的API可以是预先开发好的，并被实际的业务系统使用。而在本申请实施例中，则可以首先利用网关定义的API创建用例，然后在创建任务时，就可以从用例表中选取至少一个用例进行关联，这样就可以完成任务的创建。为了便于理解，下面结合前端的界面展示对用例的创建过程进行描述。需要说明的是，这里的前端界面可以通过单独开发的客户端程序呈现，或者，还可以通过浏览器页面的方式呈现。在菜鸟系统侧，以菜鸟工作人员的身份登录到联调系统后，显示出的界面可以如图1-1所示，其中左侧的主菜单中包括“用例管理”、“任务管理”、“规则管理”、“CP管理”等，在选择“用例管理”后，就可以进入创建用例的界面，如图1-1右侧所示。在该界面中，可以填写用例名称，并选择与用例关联的API。具体的，当操作焦点进入到API对应的输入框时，联调系统可以将网关中定义的API提供出来供选择。当然，在网关中可能会将API进行分类，例如，API类别可以包括“电子面单”、“快递面单”等等，因此，从图1-1中可以看出，还可以提供用于选择API类别的输入框，对于联调系统而言，在操作焦点进入该输入框后，就可以将网关中定义的API类别列表展示出来，如图 1-2所示。在选中某一API类别后，在输入焦点进入API输入框时，就可以仅展示出该API类别下的各个API供选择，这样可以提高效率。另外，关于API还可以通过直接输入API名称的方式来选择具体的API，并且可以支持模糊查询。例如，输入“wms”，则联调系统可以将所有以“wms”开头的API列出来供选择，如图1-3所示。其中，关于网关中定义的API以及API类别等信息可以是预先从网关获取到，并保存到联调系统本地，以便提高效率，避免对网关的多次重复访问。当然，如图1-1所示，在创建用例时，还可以提供用于设定“调用方向”的操作选项，这是因为，在实际对CP系统进行联调时，根据具体业务场景、具体任务的不同，有些报文时由菜鸟发送给CP，而有些报文时要由CP回传给菜鸟，因此，除了要验证CP是否能够处理菜鸟系统下发给CP的报文，可能还会需要验证CP回传的报文是否满足要求。因此，在创建用例时，可以分别创建不同调用方向的用例。在选定某API之后，由于网关中一般还为API定义了多个参数，因此，就可以将网关为该API定义的各个参数的名称等信息提供给菜鸟侧的工作人员。此时，可以由工作人员对各个参数的参数值类型以及参数值进行配置。因此，在创建用例的过程中，当目标API被选中时，可以提供出网关中为该目标API定义的至少一个参数，并提供用于设置参数值类型以及参数值的第一操作选项。其中，参数值类型一般包括固定、动态等等。其中，如果是固定值，则还可以同时设定具体的参数值。其中，关于参数值类型为“动态”的参数，则可以由预先建立的参数值生成规则来动态生成。在创建用例时，在关联某个API之后，如果该API中某个参数的参数值类型为动态，则可以为该参数的参数值选取对应的规则。当然，对于同一个API下的同一个参数而言，在关联不同规则的情况下，可能会对应生成不同的用例。也就是说，如果在创建用例时，就为其中的动态参数关联具体的规则，那么可能会意味着用例数量会非常多，这对于数据的存储以及查询，都是不利的。因此，在本申请实施例中，在创建用例时，可以仅针对固定参数给出具体的参数值，对于动态参数，只需要指定具体的参数值类型即可，后续在具体创建任务时，选择了关联的用例之后，再根据任务的具体需求，为用例对应的API中的动态参数选择具体的规则。这样，创建用例的过程就包括：首先选择关联的API，然后对API中包含的参数进行参数值类型设置，其中，被设置为固定型的参数，可以直接设置参数值，被设置为动态型的参数，则可以暂时不进行参数值设置。例如，如图1-4所示，在选择了关联的API为“WMS_STOCK_IN_ORDER_NOTIFY”时，网关为该API定义的参数有货主ID、仓储编码、仓储中心订单编码等等。其中，在某用例中，可以将货主ID、仓储编码的参数值设置为固定型，此时，还可以同时设置这两个参数的参数值，而将仓储中心订单编码等的参数值设置为动态型，此时，可以暂时不设置该参数值关联的规则。之后，就可以完成该用例的创建过程，保存在第二数据表中。也就是说，第二数据表中保存有至少一个用例、用例关联的目标API、目标API包含的参数以及各参数的参数值信息，参数值信息具体包括参数值类型，该参数值类型包括动态型以及固定型，当某参数为固定型时，第二数据表中还保存有该参数具体的参数值。另外，在调用方向为从CP回传的情况下，由于这种用例在执行时，是需要由联调系统对CP返回的报文进行判断，判断的对象就可以是API中各个参数。为此，对于这种情况，在创建用例时，还可以提供用于设置需要校验的参数的第二操作选项，以及用于设置校验时所使用运算信息的第三操作选项。这样，在通过对第二操作选项以及第三操作选项的操作结果后，就可以确定出需要校验的参数以及运算信息，其中，运算信息包括运算符类型，该运算符类型可以是“存在(exist)”、“等于(＝＝)”或“包含于”等。其中，当运算符类型为“等于”或者“包含于”时，运算信息还可以包括校验基准值，也就是说，只有当CP返回的报文中，这种参数的参数值等于或者包含于设定的基准值时，才能校验通过。而对于运算符为存在的情况，则只要CP返回的报文中存在该参数的参数值即可。例如，参见图1-5，对于调用方向为“回传”的情况，在API被选中之后，展示出的参数列表中，可以提供用于选择“是否校验”、“运算符”、“值”的操作选项，这里的“值”即为前述校验基准值。也就是说，在生成用例时，可以选择对API中的部分参数进行校验，如果需要校验，则可以设定校验时所使用的运算信息，包括运算符以及具体的基准值等。例如，图1-5中的货主ID、仓储编码、仓库订单编码、订单类型等参数都是需要校验的，其中，前三个参 数对应的运算符为“exist”，也即“存在”，而订单类型对应的运算符为“＝＝”，也即“等于”，此时，还可以在“值”中填写具体的基准值，如图1-5中的201。以上对创建用例的过程进行了介绍，在实际应用中，创建用例的过程也可以不必按照上述方式执行，总之，可以得到一第二数据表，其中保存联调系统中CP仿真联调所需的用例。例如，在一种实现方式下，第二数据表的结构可以如以下表1所示：表1如前文所述，对于用例关联的API中被设定的动态参数，在确定其具体的参数值时可以使用预先创建的参数值生成规则，下面对于这种规则进行详细介绍。其中，所谓的规则就是用于模拟业务系统中实际的相关操作来产生参数值。 具体实现时，规则可以有多条，并且也可以是通过该联调系统创建的。具体的，在主菜单中选择“规则管理”后，就可以展示出如图1-6所示，可以定义出规则名称、规则描述以及执行脚本。其中，规则名称可以是由菜鸟工作人员自行确定的，规则描述是对该规则的作用等进行描述，例如，对于“宅配运单号”规则，可以描述为“动态创建宅配运单号，16位字符串，要根据时间生成”，执行脚本对应的可以是一段代码，通过该代码可以将具体的规则描述出来，在执行该脚本就可以按照对应的规则生成相应的参数值。这样，通过规则的建立并将规则应用在API参数中，就可以对原来通过上层业务系统生成联调报文的方式进行模拟仿真。例如WLB订单号在发货中心的生成规则是：16位字符串，以“LBX”开头，连接订单生成的时间戳，则在联调平台生成的规则脚本可以为：“LBX”+time，被命名为“WLB订单号生成规则”，可以应用在WMS_STOCK_IN_ORDER_NOTIFY、WMS_CONSIGN_ORDER_NOTIFY等多个API的orderCode字段。其他如：运单号生成规则：NO+16位字符串；交易订单号：15位字符串；航空包裹号：HK+10位字符串等等由业务系统生成的有特定规则、非常重要的参数都可以由规则录入、引用规则的方式达到仿真效果。通过上述方式，可以创建出多条规则，并且可以保存在第一数据表中，其中保存有至少一条参数值生成规则，以及规则的名称、生成参数值时所需执行的脚本信息。这样在后续创建任务时，就可以从该第一数据表中提供可选的规则，与用例中的动态参数进行关联，具体执行联调任务时，就可以利用该关联的规则为动态参数生成具体的参数值。例如，在一种具体实现方式下，第一数 据表的结构可以如以下表2所示：表2总之，在保存了前述第一数据表以及第二数据表的情况下，就可以创建具体的联调任务。下面对创建任务的具体过程进行介绍。实施例一参见图2，本申请实施例一首先提供了一种联调任务创建方法，该方法可以包括以下步骤：S201：预先保存第一数据表以及第二数据表，所述第一数据表中保存有至少一条参数值生成规则，以及所述规则的名称、生成参数值时所需执行的脚本信息；所述规则用于模拟业务系统中实际的相关操作，并产生参数值；所述第二数据表中保存有至少一个用例、所述用例关联的目标应用程序编程接口API、所述目标API包含的参数以及各参数的参数值信息；其中，所述API为网关中预先定义的API；所述参数值信息包括参数值类型，所述参数值类型包括动态型以及固定型；关于第一数据表以及第二数据表已经在前文中有所介绍，这里不再赘述。S202：接收到创建任务并为所述任务添加关联用例的请求时，确定待添加的目标用例；如图1-1所示，在以菜鸟工作人员登录联调系统的情况下，在主菜单中存在“任务管理”选项，创建任务的操作就可以通过该选项进行。参见图3-1，在选择“任务管理”后就可以进入到创建任务的界面，在创建任务时，可以设 定任务的名称，便于领取任务时参考。并且，还可以提供用于添加关联用例的操作选项，如图3-1中的“+关联用例”，可以通过该选项触发添加关联用例的请求。联调系统在收到该请求之后，可以提供用于输入用例名称、API名称等信息的输入框，可以通过输入用例名称、API名称的方式，来输入待添加的目标用例。或者，联调系统还可以根据第二数据表提供可选择的用例，例如，如图3-2所示，这样可以通过选择的方式来指定待添加的目标用例。总之，对于联调系统而言，可以确定出待添加的目标用例，由于在第二数据表中，用例与API相关联，因此，也可以确定出该目标用例关联的目标API。S203：根据所述第二数据表，提供所述目标用例关联的API中参数值类型为动态型的目标参数；由于在第二数据表中，目标用例关联的API中，有些参数的参数值被设定为动态，但是还没有关联具体的规则，因此，还可以从第二数据表中将这种动态参数提取出来，并提供用于为这种动态参数添加关联规则的操作选项。S204：接收到为所述目标参数选择规则的请求时，提供所述第一数据表中保存的所述参数值生成规则，并在目标规则被选中后，建立所述目标参数与所述目标规则之间的对应关系；如图3-3所示，在接收到为目标参数选择规则的请求时，就可以展示出多个可以选择的规则，目标规则被选中后，就可以建立目标参数与目标规则之间的对应关系。S205：在关联的目标用例添加完毕后，生成任务，并添加到第三数据表中，所述第三数据表中保存所述任务关联的至少一个目标用例以及所述对应关系信息，以便通过所述第三数据表中保存的各任务，对第三方物流服务提供方系统进行联调。通过上述方案，添加完一个关联的目标用例之后，还可以通过类似的方式添加其他关联用例，当添加完毕后，就可以生成任务，并保存到第三数据表中。也就是说，第三数据表中保存的信息包括：任务关联的至少一个目标用例以及 步骤S204中确定出的对应关系信息。例如，在一种具体实现方式下，第三数据表的结构可以如以下表3所示：表3在创建任务并保存到第三数据表之后，就可以由CP方登录到该联调系统，领取任务，对其系统进行联调。在具体实现时，需要创建的任务数量可能是众多的，而对于CP方而言，根据其具体业务类别的不同，需要领取的联调任务可能是不同的。也就是说，一个CP可能只需要领取其中的一部分任务。另外，对于某具体的CP而言，一般需要对与其具体业务相关的所有任务都需要进行领取并执行联调，但是，CP在众多任务中选择时，可能会存在遗漏等情况。因此，为了便于对第三数据表中的任务进行管理，也为了便于CP进行任务领取，还可以对创建的任务进行分级分层管理。在具体实现时，还可以预先创建第四数据表，其中，第四数据表中保存有至少一个业务类别，以及至少一个业务场景，一个业务类别下包括至少一个业务场景。这样，在创建任务时，就可以先选择具体的业务类别，然后选择该类别下的某具体业务场景，然后再进行具体的任务创建过程。这样，在创建完一个任务之后，自然与之前选择的业务类别、业务场景产生关联，也即，属于该业务类别、业务场景下的具体任务。后续在CP领取任务时，CP 也可以先选择具体的业务类别，并选择该类别下的具体业务场景，这样，联调系统就可以将该业务类别、业务场景下相关的任务提供给CP，CP对这些任务进行领取并执行即可。例如，第四数据表的结构可以如表4所示：表4序号业务类别业务场景1仓储入库单正常场景2仓储入库单取消场景3仓储出库单正常流程4快递配送场景………………这样，可以将联调系统的联调用例抽象出“业务类别->业务场景->任务->用例”四层模型，“业务类别”是第一层，指仓储、快递、海外等不交叉的垂直业务；“业务场景”是第二层，指每个业务类别下要联调的业务场景，所有的业务场景支撑起一个业务类别；“任务”是第三层，指每个业务场景下CP要执行的多个任务；“用例”是第四层，每一个用例即一个API，由多个API的调用组成一个任务。以“仓储”这个业务类别为例，上述四层模型在该类别上的体现如图4所示，可以看到：(1)业务类别包含多个业务场景；(2)每个业务场景由不同的任务构成；(3)任务由至少1个用例构成；(4)用例和API是一对一的关系；(5)同一个API可以应用于不同的用例。可见，通过本申请实施例一，可以创建用于联调的任务，在一个任务中可以关联至少一个用例，而一个用例与网关中定义的API关联，对于API中的动态参数，可以通过预先建立的规则来动态生成，其中，该规则可以用于模拟业务系统中实际的相关操作，并产生参数值。这样，在对CP进行联调时，就 可以通过执行这种任务来生成联调所需的报文，或者对CP回传的报文进行校验，整个联调的过程不再依赖于实际业务系统日常环境的稳定性，也不会对实际业务系统的正常运行造成影响。在完成实施例一中的任务创建之后，就可以利用联调系统对CP系统进行联调，下面对具体的实现方式进行介绍。实施例二参见图5，该实施例二提供了一种系统联调方法，该方法可以包括以下步骤：S501：接收领取任务的请求；在CP侧，可以通过客户端或者浏览器，以CP工作人员的身份登录到联调系统，此时，展示出的用户界面可以如图6-1所示，在选择主菜单中的“我的任务”后，就可以进入到右侧的界面，其中，在右上方提供有“领取任务”的操作选项，可以通过该操作选项发出领取任务的请求。S502：利用第三数据表中记录的信息提供可领取任务列表，其中，所述第三数据表中保存有至少一个任务、任务关联的至少一个目标用例以及目标参数与目标规则之间的对应关系信息，所述目标用例与目标API关联，所述目标参数为所述目标用例关联的目标API中被设定为动态型的参数，所述目标规则为创建所述任务时为所述目标参数设定的规则，该规则用于模拟业务系统中实际的相关操作，并产生参数值；如实施例一中所述，预先建立了第三数据表，其中保存有多个联调任务，因此，可以将这些任务提供给CP工作人员，由工作人员从中选择需要领取的任务。当然，具体实现时，如果第三数据表中保存了业务类别、业务场景信息，则CP可以首先选取具体的目标业务类别，以及目标业务场景，这样，联调系统就可以提供该目标业务类别、目标业务场景下的任务，并且可以默认将这些任务置为选中状态，CP工作人员直接领取这些任务即可。例如，如图6-2所示，在选取了家装CP下的订单下发与回传场景后，就可以展示出该场景下的各个任务。关于该第三数据表的相关信息，以及关联的第一数据表、第二数据表的具体信息可以参见实施例一中的介绍，这里不再赘述。S503：目标任务被领取后，接收到对所述目标任务关联的指定目标用例进行执行的请求时，利用预置的第二数据表确定所述指定目标用例关联的目标API包含的参数值信息；其中，如果该目标API中带有动态型参数，则利用所述第三数据表中记录的对应关系，确定该动态型参数对应的目标规则，并通过预置的第一数据表确定所述目标规则对应的脚本信息，以便通过执行所述脚本信息生成参数值；在任务被领取后，就可以在“我的任务”界面中展示已经领取的各个任务，并且可以分别为各个任务提供查看详情的操作选项，如图6-3中的“详情”按钮。在通过“详情”按钮选中了某任务后，就可以展示出该任务关联的各用例信息，例如某在将图6-3中的第一条任务选中后，展示出的详情页面可以如6-4所示，其中显示有关联的各个用例的信息，并且分别为提供了执行各个用例的操作选项，如图6-4中的“执行”按钮。在某用例对应的“执行”按钮被操作后，联调系统就可以收到对目标任务关联的指定目标用例进行执行的请求。在接收到上述请求后，联调系统就可以通过实施例一中的第二数据表确定该指定目标用例关联的目标API包含的参数值信息，其中，对于固定参数，可以直接从第二数据表中取出具体的参数值。而对于动态参数，可以首先从第三数据表中确定出动态参数关联的规则，进而，就可以从第一数据表中取出该规则的执行脚本，通过执行该脚本，即可生成该动态参数的参数值。S504：根据所述参数值信息对第三方物流服务提供方系统进行联调。在确定出用例关联的API中的参数值信息后，就可以利用这种参数值信息进行具体的联调。具体的，由于第二数据表中还可以保存有目标用例的调用方向信息，该调用方向包括下发到第三方物流服务提供方系统，或者从第三方物流服务提供方系统回传，因此，具体在进行联调时，可以根据调用方向信息以及参数值信息对CP系统进行联调。其中，如果调用方向为下发到CP系统，则当接收到生成报文的请求时，可以利用参数值信息生成报文。例如，对于图 6-4中的第一个用例，其调用方向是下发，则在发出执行该用例的请求后，系统给出的界面可以如图6-5所示，其中包括用于生成报文的操作选项，例如“生成报文”按钮，在触发该按钮后，联调系统就可以利用之前确定出的参数值信息生成报文。该报文就是通过模拟实际业务系统中的操作生成的报文，可见，在本申请实施例中，完全在联调系统内部通过模拟的方式就可以生成报文，而在现有技术中，如果要生成该报文，则需要由工作人员在实际业务系统的buy页面中购买业务对象，生成交易订单，菜鸟系统再生成物流订单，根据已经配置的系统参数经系统调度路由出要联调的CP，等等。在生成报文后，可以直接在界面中展示报文内容，如图6-6所示，“报文发放”框内展示出的内容就是生成的报文，这样CP工作人员可以直观的看到报文的具体内容，便于在出现问题时进行问题定位。另外，界面中还可以提供用于下发报文的操作选项，如图6-6中的“执行下发”按钮，该按钮被操作后，联调系统就可以将该报文下发到CP系统，由CP系统对该报文进行处理。在CP系统将报文处理完毕后，可以返回处理“正确”或者“错误”的结果，并且，同样可以展示在界面上，如图6-7所示，在“报文结果”框中就展示了CP系统对这段报文的处理结果。这样，CP工作人员就可以直观的看到联调的结果，当发现“错误”结果时，可以及时进行修改。其中，在向CP系统下发报文时，可以是根据预先确定出的CP的URL(UniformResourceLocator，统一资源定位符)进行的，或者，还可以在需要执行下发时，由CP工作人员填写CP系统的URL。另外，还可以预先确定CP系统的报文格式、编码信息等，这样，可以根据这种报文格式、编码信息生成报文，以便CP系统能够识别。再者，为了更好的模拟实际业务系统与CP系统的对象，对在下发报文时，还可以通过网关对报文进行签名，此时，还可以预先确定CP系统的签名算法，这样，网关可以使用同样的签名算法对报文进行签名后，再下发到CP系统。其中，关于CP的URL、报文格式、编码信息、签名算法等，都可以是在联调系统的“应用信息”中进行配置。例如，如图6-8所示，在CP工作人员登录到联调系统后，可以首先进入该页面，进行上述各项信息的配置。当然， 在具体实现时，也可以通过其他方式实现。前述对调用方向为下发的用例的执行过程进行了介绍，而对于调用方向为回传的用例，则在触发对用例的执行请求后，可以进入图6-9所示的界面，此时，可以由CP系统首先产生一段报文，然后将该报文回传给联调系统。联调系统接收到CP系统回传的报文后，可以利用当前用例对应的API中的参数值信息对回传的报文进行校验。具体的，由于第二数据表中还保存有用例关联的API中需要校验的参数以及运算信息，该运算信息包括运算符类型，并且运算符类型包括存在、等于或包含于，当运算符类型为等于或者包含于时，运算信息还包括校验基准值；因此，就可以利用前述需要校验的参数以及运算信息，对回传的报文进行校验。例如，从回传的报文中找出需要校验的参数，并确定其参数值，然后利用运算信息进行判断，判断的结果就可以作为联调的结果，得出的“正确”或者“错误”的校验结果，就可以作为对CP系统的联调结果，同样可以展示在用户界面中。这种通过CP系统执行任务轨迹得到书面联调报告的方式，可以方便、直观、多维度得到联调结果和CP系统性能状况，能够更准确的判断CP系统能否上线。可见，在本申请实施例中，可以根据不同的业务需求直接在联调平台生成报文，不再依赖业务系统日常环境的稳定性，下发CP接口生成的数据不再通过联调人员在测试环境购买宝贝产生交易订单，CP回调接口校验也不再通过业务系统，而是直接在联调系统内部通过规则模拟的方式来实现，因此，使得效率得到提高。另外，在实际应用中，虽然CP系统的业务逻辑，应该根据销售平台提供的“白皮书”(其中包括菜鸟网关中定义的各个API，另外还包括各种业务类别下使用的报文格式、编码类型、签名算法等)进行开发，但是算法的具体的代码还是由CP工作人员自行开发或者编写的，因此，经常会出现CP系统签名不正确等情况。例如，同样是使用MD5算法，但是不同的加密长度得到的签名结果是不同的，如果白皮书中规定使用64位，菜鸟系统中也会严格按照63位的长度进行签名，但实际在CP系统中使用的却可能是32位，使得CP系统无法对菜鸟系统下发的报文解密，等等。为了便于CP侧工作人员确定其签名算法是否存在问题，还可以提供“签名校验”选项，例如，当该选项被选中后，可以展示出如图7-1所示的界面，其中，可以根据当前CP的业务类别等信息确定出签名算法、字符编码的名称，另外还可以确定出与菜鸟系统约定的密钥(secretkey)，此时，CP工作人员可以在“目标报文”输入框中输入测试用的报文，例如，如图7-2所示的一串数字，在点击“生成签名”按钮后，联调系统就可以利用其系统内对应的算法代码以及密钥等，对该报文进行运算，得到数字签名，如图7-2中“数字签名”栏所示。之后，CP工作人员就可以利用其CP系统内的算法代码以及该密钥，对同样的目标报文进行运算，也可以得到数字签名，通过与联调系统给出的数字签名进行比对，就可以确定出CP系统的前面算法是否正确。为了便于帮助CP工作人员定位签名算法代码中存在的问题，还可以提供“查看算法说明”的操作选项，当通过该选项接收到查看请求时，可以给出具体的说明，如图7-3所示。另外，对于一个任务而言，由于一般会包括多个用例，而且只有一个任务下所有用例都执行完成之后，才算该任务成功被执行，但是，在实际应用中，可能会在执行完某个用例后发现出错，但是一时间可能又找不出原因，这就会导致整个测试流程的中断。为了在这种情况下帮助CP工作人员进行错误定位，还可以提供“自测”功能。例如，如图7-4所示，在主菜单中包括“自测工具”选项，该选项被选中后，可以展示出右侧的界面，在该界面中，可以对单个用例关联的API进行自测。自测的过程与小二配置用例时类似，可以选取具体的API，此时，联调系统可以从网关中拉取该API的参数，CP工作人员可以对各个参数的参数值信息进行配置，包括参数值类型、参数值等等。配置完成后，可以执行该用例，生成报文，并下发到自己的CP系统，并查看执行的结果。如果执行结果正确，则代表CP自测的这个API自测通过；如果执行结果错误，则代表CP自测的这个API有bug(缺陷)，需要CP修改代码，之后还可以再进行自测。需要说明的是，本申请实施例一以及实施例二中的各个步骤，其执行主体均可以为运行于销售平台服务器中的联调系统，也即，通过销售平台服务器侧 运行的软硬件系统，实现销售平台物流系统与第三方物流系统之间的联调。与实施例一相对应，本申请实施例还提供了一种联调任务创建装置，参见图8，该装置可以包括：数据表保存单元801，用于预先保存第一数据表以及第二数据表，所述第一数据表中保存有至少一条参数值生成规则，以及所述规则的名称、生成参数值时所需执行的脚本信息；所述规则用于模拟业务系统中实际的相关操作，并产生参数值；所述第二数据表中保存有至少一个用例、所述用例关联的目标应用程序编程接口API、所述目标API包含的参数以及各参数的参数值信息；其中，所述API为网关中预先定义的API；所述参数值信息包括参数值类型，所述参数值类型包括动态型以及固定型；目标用例确定单元802，用于接收到创建任务并为所述任务添加关联用例的请求时，确定待添加的目标用例；目标参数提供单元803，用于根据所述第二数据表，提供所述目标用例关联的API中参数值类型为动态型的目标参数；对应关系建立单元804，用于接收到为所述目标参数选择规则的请求时，提供所述第一数据表中保存的所述参数值生成规则，并在目标规则被选中后，建立所述目标参数与所述目标规则之间的对应关系；任务生成单元805，用于在关联的目标用例添加完毕后，生成任务，并添加到第三数据表中，所述第三数据表中保存所述任务关联的至少一个目标用例以及所述对应关系信息，以便通过所述第三数据表中保存的各任务，对第三方物流服务提供方系统进行联调。具体实现时，该装置还可以包括：可选API提供单元，用于接收到创建用例的请求时，提供网关中定义的可选API；第一操作选项提供单元，用于当目标API被选中时，提供所述网关中为所 述目标API定义的至少一个参数，并提供用于设置参数值类型以及参数值的第一操作选项；用例生成单元，用于通过所述第一操作选项接收到参数设置信息后，生成用例，并在所述第二数据表中保存该用例关联的所述目标API，以及所述参数设置信息。其中，所述创建用例的请求中还携带有用例的调用方向信息，所述调用方向包括下发到第三方物流服务提供方系统，或者从第三方物流服务提供方系统回传；所述装置还可以包括：调用方向信息保存单元，用于在所述第二数据表中保存该用例的调用方向信息。其中，该装置还可以包括：第二操作选项提供单元，用于当所述调用方向为从第三方物流服务提供方系统回传时，提供用于设置需要校验的参数的第二操作选项，以及用于设置校验时所使用运算信息的第三操作选项；运算信息确定单元，用于通过对所述第二操作选项以及所述第三操作选项的操作结果，确定需要校验的参数以及运算信息，所述运算信息包括运算符类型，所述运算符类型包括存在、等于或包含于，其中，当所述运算符类型为等于或者包含于时，所述运算信息还包括校验基准值；运算信息保存单元，用于将所述需要校验的参数以及运算信息保存到所述第二数据表中。另外，还可以包括：第四数据表保存单元，用于预先保存第四数据表，所述第四数据表中保存有至少一个业务类别，以及至少一个业务场景，其中，一个业务类别下包括至少一个业务场景；业务类别提供单元，用于所述接收到创建任务的请求时，根据所述第四数据表提供可选的业务类别；可选业务场景提供单元，用于目标业务类别被选中后，根据所述第五数据表，提供该业务类别下可选的业务场景；关联关系保存单元，用于目标业务场景被选中，并且所述任务生成后，在所述第三数据表中保存所述目标业务类别、目标业务场景、任务之间的关联关系，以便对第三方物流服务提供方系统进行联调时，第三方物流服务提供方系统根据指定的业务类别以及业务场景，领取关联的任务，并通过执行所述关联的任务进行联调。通过上述装置，可以创建用于联调的任务，在一个任务中可以关联至少一个用例，而一个用例与网关中定义的API关联，对于API中的动态参数，可以通过预先建立的规则来动态生成，其中，该规则可以用于模拟业务系统中实际的相关操作，并产生参数值。这样，在对CP进行联调时，就可以通过执行这种任务来生成联调所需的报文，或者对CP回传的报文进行校验，整个联调的过程不再依赖于实际业务系统日常环境的稳定性，也不会对实际业务系统的正常运行造成影响。与实施例二相对应，本申请实施例还提供了一种系统联调装置，参见图9，该装置可以包括：请求接收单元901，用于接收领取任务的请求；可领取任务列表提供单元902，用于利用第三数据表中记录的信息提供可领取任务列表，其中，所述第三数据表中保存有至少一个任务、任务关联的至少一个目标用例以及目标参数与目标规则之间的对应关系信息，所述目标用例与目标API关联，所述目标参数为所述目标用例关联的目标API中被设定为动态型的参数，所述目标规则为创建所述任务时为所述目标参数设定的规则，该规则用于模拟业务系统中实际的相关操作，并产生参数值；参数值信息确定单元903，用于目标任务被领取后，接收到对所述目标任务关联的指定目标用例进行执行的请求时，利用预置的第二数据表确定所述指定目标用例关联的目标API包含的参数值信息；其中，如果该目标API中带有动态型参数，则利用所述第三数据表中记录的对应关系，确定该动态型参数对应的目标规则，并通过预置的第一数据表确定所述目标规则对应的脚本信息，以便通过执行所述脚本信息生成参数值；联调单元904，用于根据所述参数值信息对第三方物流服务提供方系统进行联调。其中，所述第三数据表中保存业务类别、业务场景、任务之间的关联关系，所述请求接收单元具体用于：接收客户端发送的领取指定业务类别、指定业务场景下的任务的请求；所述可领取任务列表提供单元具体用于：利用第三数据表中记录的信息，提供所述指定业务类别、指定业务场景下的可领取任务列表。所述第二数据表中还保存有所述目标用例的调用方向信息，所述调用方向包括下发到第三方物流服务提供方系统，或者从第三方物流服务提供方系统回传；所述联调单元具体用于：根据所述调用方向信息以及所述参数值信息对第三方物流服务提供方系统进行联调。具体实现时，所述联调单元可以包括：报文生成子单元，用于如果所述调用方向为下发到第三方物流服务提供方系统，则当接收到生成报文的请求时，利用所述参数值信息生成报文；报文下发子单元，用于将所述生成的报文下发到第三方物流服务提供方系统，以便由所述第三方物流服务提供方系统的相关业务逻辑对所述报文进行处 理。具体实现时，该装置还可以包括：URL信息确定单元，用于预先确定所述第三方物流服务提供方系统的统一资源定位符URL信息；所述报文下发子单元具体用于：根据所述预先确定的URL信息，将所述生成的报文下发到第三方物流服务提供方系统。格式及编码信息确定单元，用于预先确定所述第三方物流服务提供方系统的报文格式及资源编码信息；所述报文生成子单元具体用于利用所述参数值信息生成符合所述报文格式及资源编码的报文。签名算法确定单元，用于预先确定所述第三方物流服务提供方系统的签名算法信息；所述报文下发子单元具体用于：通过网关利用所述签名算法对所述报文进行签名后，下发到第三方物流服务提供方系统。其中，所述联调单元包括：报文接收子单元，用于如果所述调用方向为从第三方物流服务提供方系统回传，则接收到第三方物流服务提供方系统回传的报文；校验子单元，用于利用所述参数值信息对回传的报文进行校验。如果所述调用方向为从第三方物流服务提供方系统回传，所述第二数据表中还保存有用例关联的API中需要校验的参数以及运算信息，所述运算信息包括运算符类型，所述运算符类型包括存在、等于或包含于，其中，当所述运算符类型为等于或者包含于时，所述运算信息还包括校验基准值；所述校验子单元具体用于：利用所述需要校验的参数以及运算信息，对所述回传的报文进行校验。另外，该装置还可以包括：签名算法校验请求接收单元，用于接收签名算法校验请求；签名信息确定单元，用于确定待检测的签名算法类型、编码类型；目标报文接收单元，用于接收目标报文；运算单元，用于利用网关定义的该签名算法类型、编码类型对应的算法内容，以及预置的密钥对所述目标报文进行运算，并提供数字签名结果，以便通过与CP系统对所述目标报文的数字签名结果进行比对，判断CP系统的签名算法内容是否正确。查看请求接收单元，用于接收查看签名算法说明的请求；说明信息提供单元，用于提供所述签名算法类型、编码类型对应的算法说明信息。自测请求接收单元，用于接收对指定API进行自测的请求；选项提供单元，用于从网关拉取该指定API的参数，并提供用于对各参数的参数值信息进行配置的操作选项；用例生成单元，用于通过所述操作选项接收到参数值信息后，生成用例并执行，得到报文；处理单元，用于将所述报文下发到所述第三方物流服务提供方系统进行处理，以便根据处理结果进行自测。通过该装置，可以根据不同的业务需求直接在联调平台生成报文，不再依赖业务系统日常环境的稳定性，下发CP接口生成的数据不再通过联调人员在测试环境购买宝贝产生交易订单，CP回调接口校验也不再通过业务系统，而是直接在联调系统内部通过规则模拟的方式来实现，因此，使得效率得到提高。通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。以上对本申请所提供的联调任务创建、系统联调方法及装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。当前第1页1 2 3