ERP接口和测试工具介绍
一、ERP接口概况
我们增加了ERP接口,接口的作用有:
简化天思ERP与外围系统的集成
将ERP、TCODE 、TBOSS协调成一个整体
与ERP一起维护
.......
ERP接口方便与外围程序集成,是现在很通用的一种模式,那么接口是什么意思,我们怎么使用它?
我们经常说的接口,其实就是一个API。
而API,我们可能经常听到,但是不是很明白,先看它的百科介绍:
API,英文全称Application Programming Interface,翻译为“应用程序接口”,是一些预先定义的函数,目的是提供应用程序与开发人员基于某软件或硬件得以访问的一组例程,而又无需访问源码,或理解内部工作机制的细节。
那么实际工作中怎么使用呢,举我们现在软件的例子:
我们的ERP是一个很完善很完整的系统软件,随着手机的便携性越来越高,价位越来越低,客户越来越希望我们ERP中仓库管理部分能在手机上直接使用,这样方便仓库人员及时处理出入库,但是我们的ERP不支持在手机上使用。怎么办?
我们开发了一套手机APP,也就是我们的TCODE仓库管理系统,也就是我们常说的TCODE。
那TCODE和ERP的数据怎么对接呢?总不能ERP做ERP的,TCODE做TCODE的吧?
这里就用到了API接口,通过ERP的API接口,把ERP系统和TCODE系统对接起来,让数据是相互通的。
再举一个实际的例子,以采购入库单存盘为例:
ERP写好了【登录接口】和【单据保存接口】,其中单据保存接口支持采购入库单,TCODE开发了一张采购入库单,在TCODE中先登录,然后录好采购入库单,保存这张单据的时候,直接调用我们ERP的【单据保存接口】,通过这个接口生成一张采购入库单,生成的这张单在ERP中就能看到,并不需要TCODE重新写一段采购入库存盘的代码。
同样,以采购入库新增接口为例,我们了解一下实际的接口使用,接口是一段定义好的函数,我们提供好了接口的种类和接口的模式,如果有其他系统需要调用我们的接口,直接根据我们的格式传好参数后调用就行。
现在很多客户有一些特殊的需求,比如需要用其他来源数据做入库,客户写了一个小程序,这个小程序有自己的数据库用来存放数据,他希望存盘能同时生成一张我们系统的采购入库单,那这时候就可以用到我们的【登录接口】和【单据保存接口】。
二、ERP接口实例介绍
首先,我们需要使用【登录接口】来模拟用户登录,得到返回的LoginId,这个LoginId可以理解成此次登录的身份标识,其他接口调用的时候必须用到这个身份标识。比如我们需要用到【单据保存接口】,那么就必须先取得这个LoginId。
2.1 【登录接口】的介绍
| 基本信息
信息 | 值 | 备注 |
---|---|---|
接口名称 | 用户登录 | 根据语言别、授权凭证等实现用户登录 |
请求状态 | POST | 请求状态一般有四种:使用时可简单理解为 1、POST /url 创建 2、DELETE /url/xxx 删除 3、PUT /url/xxx 更新 4、GET /url/xxx 查看 |
接口路径 | http://localhost:23798/api/User/login | 向服务器地址发送POST请求 |
| 请求参数
Headers
参数名称 | 参数值 | 是否必须 | 示例 | 备注 |
---|---|---|---|---|
Languageid | 0 | 是 | 客户端语言别,0:简体 1:繁体 2:英文 | |
Authorization | 是 | Basic REVNT19BRE1JTjoxMjM= | 授权凭证,由”登录代号_ 操作员代号:密码“组成字符串的Base64加密值,比如 Basic DEMO_ADMIN:123 | |
ClientType | 否 | TestMgr | 用户自定义的客户端识别号,比如客户是WMS系统,可以自定义ClientType=“WMS” | |
Content-Type | 否 | application/json | 用于指定数据的传输类型,其他接用调用时必须用到,现在默认使用“application/json”格式,以后会支持其他格式 | |
Key | 否 | ccd105791a7447e58638b43XXXXXXX46 | 验证注册网上的授权码,如果是员工号的无需传值 |
| 返回数据
名称 | 类型 | 是否必须 | 默认值 | 备注 | 其他信息 |
---|---|---|---|---|---|
LoginId | string | 否 | 返回的LoginId | ||
CompNo | string | 否 | 帐套代号 | ||
UserNo | string | 否 | 操作员代号 | ||
LoginIdExpiry | number | 否 | 登录超时时间(秒) | ||
ClientType | string | 否 | 客户端自定义识别号 | ||
LanguageId | number | 否 | 客户端语言别 |
| 调用范例
返回的Json:
{
"LoginId": "e835943e-55c2-4bf0-832d-6f4166592941", //返回的LoginId
"CompNo": "DEMO", //帐套代号
"UserNo": "ADMIN", //操作员代号
"LoginIdExpiry": 604800, //登录超时时间(秒)
"ClientType": "WMS", //客户端自定义识别号
"LanguageId": 0 //客户端语言别
}
| 备注
以上介绍说的我们向服务器发送POST请求,请求参数是Languageid、Languageid、ClientType、ClientType,参数的值根据实际的情况录入,运行后返回LoginId、CompNo等字段的值,通过得出的值,我们可以进行后续新增采购入库的操作。
需要注意:
先判断返回的HttpStatusCode是否等于200,如果是则表示调用成功,否则返回错误信息
登录接口不需要频繁调用,只有当没有获得LoginId或登录已超时后才需要再次调用
登录接口返回的LoginIdExpiry以秒为单位,调用方在调用前先记录本地时间,接口返回后将记录的本地时间加上LoginIdExpiry的值,即是下次需要再次调用登录接口的时机
除了登录接口,其它接口调用必须在Headers里面传入LoginId
所有接口都以JSON格式返回
2.2 【单据保存接口】的介绍
| 基本信息
信息 | 值 | 备注 |
---|---|---|
接口名称 | 单据保存、修改 | 根据单据ID来新增或修改单据 |
请求状态 | POST | 请求状态一般有四种:使用时可简单理解为 1、POST /url 创建 2、DELETE /url/xxx 删除 3、PUT /url/xxx 更新 4、GET /url/xxx 查看 |
接口路径 | http://localhost:23798/api/Bill/SaveBill | 向服务器地址发送POST请求 |
| 请求参数
Headers
参数名称 | 参数值 | 是否必须 | 示例 | 备注 |
---|---|---|---|---|
Content-Type | application/json | 是 | 用于指定数据的传输类型 | |
LoginId | 是 | e835943e-55c2-4bf0-832d-6f4166592941 | 用户登录的LoginId |
Body
数据名称 | 字段名称 | 类型 | 是否必须 | 默认值 | 示例 | 备注 | 其他信息 |
---|---|---|---|---|---|---|---|
HeadData | object | 必须 | 表头数据 | ||||
EntryOrderId | string | 非必须 | WMS | 调用方业务编码 | 调用方唯一编码,关联ERP单据,且避免重复提交,当提交的EntryOrderId重复时返回提示。为空则没有该项检测 | ||
CallId | string | 必须 | PC | 调用的单据识别号 | 调用的单据识别号,比如"SA":表示销售出库单 "PC":表示采购入库单 | ||
CusNo | string | 非必须 | CS001 | 厂商代号 | |||
DepNo | string | 非必须 | CGB | 部门代号 | |||
SalNo | string | 非必须 | CG001 | 业务员代号 | |||
Rem | string | 非必须 | 这是表头备注 | 备注 | |||
UsrNo | string | 非必须 | ADMIN | 制单人 | 账套验证的LoginId需添加UsrNo,用户登录的LoginId则无需添加UsrNo | ||
ExtendProps | object | 非必须 | "CUS_OS_NO":"OS0C220001", “ZDY": "自定义" | 扩展功能 | 包括表头的其他字段以及用户自定义字段,字段名需与数据库表名一致 | ||
BodyData | object [] | 必须 | 表身数据 | item 类型: object | |||
BilId | string | 非必须 | PO | 转入来源单识别号 | "PO":表示采购订单 | ||
BilNo | string | 非必须 | PO0C220001 | 转入来源单单号 | |||
BilItm | number | 非必须 | 1 | 转入来源单项次 | |||
PrdNo | string | 非必须 | YL1 | 货品代号 | |||
WhNo | string | 非必须 | 003 | 仓库代号 | |||
BatNo | string | 非必须 | PH01 | 批号 | |||
PrdMark | string | 非必须 | TZ01 | 特征 | |||
PrdLoc | string | 非必须 | CW01 | 储位 | |||
Unit | string | 非必须 | 1 | 单位 | |||
Qty | number | 非必须 | 3 | 主数量 | |||
Qty1 | number | 非必须 | 6 | 副数量 | |||
Up | number | 非必须 | 2 | 主单价 | |||
Up1 | number | 非必须 | 1 | 副单价 | |||
Tax | number | 非必须 | 1 | 税金 | |||
DisCnt | number | 非必须 | 9 | 折扣 | |||
Rem | string | 非必须 | 这是表身摘要 | 摘要 | |||
ExtendProps | object | 非必须 | "Valid_DD":"2020-12-23", “ZDY": "自定义", "SEQ_ITM":1 | 扩展功能 | 包括表身的其他字段以及用户自定义字段,字段名需与数据库表名一致 |
| 返回数据
名称 | 类型 | 是否必须 | 示例 | 备注 | 其他信息 |
---|---|---|---|---|---|
EntryOrderId | string | 非必须 | WMS | 调用方业务编码 | |
CallID | string | 非必须 | PC | 调用的单据识别号 | |
CallNO | string | 非必须 | PC0C240001 | 生成的单据号码 | |
CallOK | string | 非必须 | T | 执行是否成功, 是:"T" 否:"F" | |
Data | object | 非必须 | "TF_TABNAME": "TF_PSS", "BIL_ITM": "0", "MF_TABNAME": "MF_PSS", "BIL_NO": "PC0C100005", "BIL_ID": "PC" | 单据信息,JOSN字符串格式 | |
ErrorStr | string | 非必须 | 错误信息 |
| 调用范例
Body Json
使用的是数据库表字段名作为参数名传参,根据实际需求传需要的字段即可
无来源
{
"HeadData":{ //必须,表头数据
"EntryOrderId":"WMS", //非必须,调用方业务编码
"CallId":"PC", //必须,调用的单据识别号,"PC":表示采购入库单
"CusNo":"CS001", //必须,厂商代号
"DepNo":"0000" //必须,部门代号
},
"BodyData":[ //必须,表身数据
{
"PrdNo":"1001", //必须,第一个货品代号
"Qty":12.5 //必须,主数量
},
{
"PrdNo":"1002", //必须,第二个货品代号
"Qty":1 //必须,主数量
}
]
}
有来源,当添加了其它参数时代表修改转入的数据,例如"BodyData"添加"Qty":3代表修改来源单的数量为3
{
"HeadData":{//必须,表头数据
"EntryOrderId":"WMS", //非必须,调用方业务编码
"CallId":"PC", //必须,调用的单据识别号,"PC":表示采购入库单
"CusNo":"CS001", //必须,厂商代号
"DepNo":"0000" //必须,部门代号
},
"BodyData":[ //必须,表身数据
{
"BilId":"PO", //必须,转入来源单识别号,"PO":表示采购订单
"BilNo":"PO0C210001", //必须,转入来源单单号
"BilItm":1 //必须,转入来源单项次
}
]
}
返回的Json
{
"EntryOrderId": "WMS", // 调用方业务编码
"CallID":"PC", // 调用的单据识别号
"CallNO": "PC0C240001", //生成的单据号码
"CallOK":"T", // 执行是否成功, 是:"T" 否:"F"
"Data": "{\r\n \"TF_TABNAME\": \"TF_PSS\",\r\n \"BIL_ITM\": \"0\",\r\n \"MF_TABNAME\": \"MF_PSS\",\r\n \"BIL_NO\": \"PC0C240001\",\r\n \"BIL_ID\": \"PC\"\r\n}", // 单据信息,JOSN字符串格式
"ErrorStr":"" // 错误信息
}
| 备注
必须在Headers里面传入账套验证LoginId。
当采用的是账套验证获取的LoginId,那么HeadData中UsrNo就是制单人,不能为空。采用用户登录的LoginId则无需添加UsrNo,用户即制单人。
Body中Json字段,尽量不要添加赋空值的字段。
ExtendProps中为拓展字段,需要对应数据库表的字段,自定义字段同样在这里处理。
统一字段与接口所需数据库表字段重复时,只取统一字段的值。
接口程序不处理审核,没有审核流直接终审,有审核流就处于未审状态。
可查看后台表LOG_BILLSAVE查看执行信息。
当HeadData中EntryOrderId不为空时,可查看后台表LOG_OTHERSAVE查看单据关联信息。
2.3 代码示例
以C# 语言为例,举例说明实际开发过程中调用【登录接口】、【单据保存接口】的代码
//登录按钮点击事件(登录接口)
private void btnGetLoginId_Click(object sender, EventArgs e)
{
//Basic 64加密 帐套代号_操作员代号:密码
string authorization = "DEMO_ADMIN:";
byte[] b = System.Text.Encoding.Default.GetBytes(authorization);
authorization = "Basic " + Convert.ToBase64String(b);
//接口路径
HttpWebRequest request = (HttpWebRequest)WebRequest.Create("http://localhost:23798/api/User/login");
//Headers
request.Headers["Authorization"] = authorization;//Basic REVNT19BRE1JTjo=
request.Headers["Languageid"] = "0"; //语言别
request.Headers["ClientType"] = "WMS"; //用户自定义的调用识别
request.Method = "POST"; //请求类型
request.ContentType = "application/json"; //传输类型
//Body
string bodyString = ""; //bodyJson
byte[] buffer = Encoding.UTF8.GetBytes(bodyString);
request.ContentLength = buffer.Length;
try
{
request.GetRequestStream().Write(buffer, 0, buffer.Length);
//执行调用
using (HttpWebResponse response = (HttpWebResponse)request.GetResponse())
{
using (StreamReader reader = new StreamReader(response.GetResponseStream(), Encoding.UTF8))
{
MessageBox.Show(reader.ReadToEnd()); //返回数据
}
}
}
catch (Exception ex)
{
MessageBox.Show(ex.Message); //错误信息
}
}
//保存按钮点击事件(保存接口)
private void btnSaveBill_Click(object sender, EventArgs e)
{
//接口路径 传入调用的单据识别号、是否确认单标识
HttpWebRequest request = (HttpWebRequest)WebRequest.Create("http://localhost:23798/api/Bill/SaveBill?CallID=PC&isConfirm=F");
//Headers
request.Headers["LoginId"] = "e835943e-55c2-4bf0-832d-6f4166592941";//用户登录的LoginId
request.Headers["ClientType"] = "WMS"; //调用方标识
request.Method = "POST"; //请求类型
request.ContentType = "application/json"; //传输类型
//Body
string bodyString = "{ \"HeadData\": { \"EntryOrderId\":\"WMS\", \"CallId\":\"PC\", \"CusNo\": \"CS01\", \"DepNo\": \"0001\" }, \"BodyData1\": [ { \"PrdNo\": \"1001\", \"Qty\": \"12.5\"" }, { \"PrdNo\": \"1002\", \"Qty\": \"1\"} ]}" ; //bodyJson
byte[] buffer = Encoding.UTF8.GetBytes(bodyString);
request.ContentLength = buffer.Length;
try
{
request.GetRequestStream().Write(buffer, 0, buffer.Length);
//执行调用
using (HttpWebResponse response = (HttpWebResponse)request.GetResponse())
{
using (StreamReader reader = new StreamReader(response.GetResponseStream(), Encoding.UTF8))
{
MessageBox.Show(reader.ReadToEnd()); //返回数据
}
}
}
catch (Exception ex)
{
MessageBox.Show(ex.Message); //错误信息
}
}
程序执行后,就可以生成一张采购入库单,这一段代码里描述了我们ERP接口调用的传入参数和返回数据。这只是一段简单的有其他参数需求时,根据实际需求写入调用参数即可。
三、JSON介绍
现阶段我们所有接口都以JSON格式返回,那么JSON是什么,怎么使用它?
JSON 英文全称 JavaScript Object Notation , 翻译为“ JavaScript 对象表示法”,是一种与开发语言无关的、轻量级的数据存储格式。是用来存储和交换文本信息的语法。一种数据格式的标准规范,起初来源于JavaScript这门语言,后来随着使用的广泛,几乎每门开发语言都有处理JSON的API。
优点:易于人的阅读和编写,易于程序解析与生产。
数据结构表示
数据结构 | Object(无序的「键-值」集合) | Array(有序的值集合) | ... |
---|---|---|---|
结构样式 | {key:value,key:value...} | [value,value...] | |
举例 | {"小明": "50分", "小红": "99分"} | [1,"hi"] | |
JSON数据示例:首先一个花括号{},整个代表一个对象,同时里面是一种Key-Value「键-值」的存储形式,它还有不同的数据类型来区分。
//这个 “APP“是包含 2个“对象”的数组,而每个对象下包含多个键值对和一个数组,数组下又包含多个键值对
{
"APP":[
{
"name":"天猫",
"role":"买买买",
"carts": [
{ "name":"洗发水" , "price":"50" },
{ "name":"沐浴露" , "price":"60" }
]
},
{
"name":"京东",
"role":"买买买",
"carts": [
{ "name":"键盘" , "price":"300" },
{ "name":"鼠标" , "price":"300" }
]
}
]
}
四、接口测试
我们了解了接口、JSON格式,接下来说一下怎么测试、使用接口。
假设有一个需求,需要开发出查询采购订单的功能,开发写了一个【单据查询接口】,这个接口支持查询采购订单,完成后,我们需要测试这个是否可以正确执行查询采购订单的操作,以及返回的数据是否正确,开发可以在开发环境下查看,那测试、实施人员日常测试、调用调试的时候可以怎么办呢?
4.1 调用准备
- 运行ServrConfig启动ERP服务
- 云主机上防火墙开通23788 、23798端口
- ERP序列号需要注册接口系统或条码系统
- 如果需要使用单据打印接口,请配置服务的模拟帐户
- 可访问: http://localhost:23798/api/help 获取帮助
4.2【单据查询接口】的介绍
做好了调用准备后,我们还需要知道【登录接口】和【单据查询接口】的说明介绍,以及我们需要确认【单据查询接口】是否支持采购订单,这里因为是开发完成采购订单查询接口,需要测试这个接口,所以我们只需要知道【单据查询接口】文档即可。
【登录接口】在上面已经有介绍了,【单据查询接口】可以找研发提供,或者在 https://doc.attnserver.com/docs/category/%E5%8D%95%E6%8D%AE%E6%9F%A5%E8%AF%A2 帮助页下找到帮助,点击去查看这个接口的请求类型、请求地址、请求参数等。
查询接口点进去只能看到四个参数,暂时这里还不完善。
因帮助页文档不完善,另外找了研发提供了【采购订单查询接口】的说明,整理如下:(后续完善后文档同下面列示的样式相同,且不需要在找研发提供)
| 基本信息
信息 | 值 | 备注 |
---|---|---|
接口名称 | 单据查询 | 根据单据ID、单据号码、单据项次查询单据信息 |
请求状态 | GET | 请求状态一般有四种:使用时可简单理解为 1、POST /url 创建 2、DELETE /url/xxx 删除 3、PUT /url/xxx 更新 4、GET /url/xxx 查看 |
接口路径 | http://localhost:23798/api/Bill/QueryBill | 向服务器地址发送GET请求 |
| 请求参数
Headers
参数名称 | 参数值 | 是否必须 | 示例 | 备注 |
---|---|---|---|---|
Content-Type | application/json | 是 | 用于指定数据的传输类型 | |
LoginId | 679e0b11-8483-428c-82bd-83383b57e9f5 | 是 | 用户登录的LoginId |
Query
参数名称 | 是否必须 | 示例 | 备注 |
---|---|---|---|
CallID | 是 | CallID=PO | 调用的单据识别号,比如"SA":表示销售出库单 "PC":表示采购入库单 |
Bil_Id | 是 | Bil_Id=PO | 查询单据ID |
Bil_No | 是 | Bil_No=PO0C110001 | 查询单据号码 |
Bil_Itm | 是 | Bil_Itm=0 | 查询单据项次 |
| 返回数据
4.3 Postman测试工具
做好前面的准备工作后,就可以开始测试了,用什么测试工具,怎么操作?
这里我们介绍一种测试工具,叫PostMan ,其他的工具同理。
下面详细介绍一下PostMan 的用法。
PostMan 是一款网页调试和接口测试的工具,能够发送任何类型的 HTTP 请求,支持 GET/PUT/POST/DELETE 等方法,通过直接填写 URL,headers,body 等,就可以发送一个请求,非常简单易用,是接口测试必备利器。这里我们用它来做接口测试。
下载PostMan ,下载地址可以找我们提供,打开PostMan 程序就可以直接使用了,跳过登录账户步骤、跳过更新提示,当弹出创建提示框时,可以选择创建”Collection“,弹出新建接口窗口,在这个窗口上录入一个名称,点击“Create“创建即可。
若不小心关掉了这一步,在主界面上点击”New“按钮,或者点击新增的小图标也可以打开创建窗口。
创建好接口后,就可以在右边进行请求了,此时我们需要创建两个请求,一个是进行”用户登录“请求、一个是进行”采购订单查询“请求,先创建一个登录请求,通过登录请求的得出LoginId,然后传入LoginId到采购订单查询请求中,进行查询请求。
先建立一个请求,选择请求类型为“POST”,输入请求地址“http://localhost:23798/api/User/login”,点击到“Authorization”授权页签,在“TYPE”下选择“Basic Auth",然后在Username下输入”DEMOADMIN"(这里**输入个人的测试账套、用户名,用""符号链接,注意拼接方式**),在Password下输入密码,点击“Preview Request”后自动在“Headers"请求头页签下生一个key为”Authorization“,VALUE为”Basic REVNT19BRE1JTjo=“的请求头参数。
继续在”Headers“请求头页签下,输入其他的请求头参数,比如必须输入的”Languageid‘参数,不必须输入的“ClientType”、“Content-Type”页可以填入也可以不填入。手动输入的参数可以上移、下移、取消勾选、删除等。自动生成的参数不可以移动、修改、删除。
录入好参数后,点击“Send”按钮,界面下面“Body”页签下显示返回的数据。在返回数据下找到“LoginId”,LoginId后面的那一串字符就是我们后面需要用的参数。
若想以后继续使用这个请求,可以点击“Save”进行保存,保存时可以给这个请求录入名称,选择保存到哪一个接口,点击“save to"按钮保存即可。
保存好”用户登录"请求后,在点击“加号”小图标按钮,在新建一个请求,选择请求类型为“GET”,输入请求地址“http://localhost:23798/api/Bill/QueryBill“,在”Params“参数页签下,输入参数CallID、Bil_Id、Bil_No、Bil_Itm,以及这些参数对应的值。输入的参数会体现在地址后面,所以输入请求地址的时候,可以直接录入”http://localhost:23798/api/Bill/QueryBill?CallID=PO&Bil_Id=PO&Bil_No=PO0C110001&Bil_Itm=0“,输入这样的地址,”Params“参数页签下会自动显示这四个参数。所以输入地址时如果知道参数可以直接把参数带上。
填好地址和参数后,在点击”Headers“请求头页签,输入请求头参数Content-Type、LoginId以及对应的值。”Content-Type“参数的值现在一般是”application/json“,”LoginId“的值是前面”用户登录“请求后得出的LoginId值。录好后,点击”Send“按钮,界面下面“Body”页签下显示返回的数据。返回数据是JSON数据,能看到有”HEADDATA“、”BODYDATA1“等字段时,表示获取到表头、表身信息,此时就表示接口调用正确。也可以看”Status“状态,”Status“状态为200时,也表示这个接口请求是通过的。但是”Status“只能表示接口正常,并不能看出结果是否正常。
上面我们返回的数据特别多,判断返回数据正确是去判断能看到有”HEADDATA“、”BODYDATA1“等字段,这样不便于我们很直观的确认返回是否正确,我们可以在”Tests“测验页签下写入判断,判断返回数据是否有”HEADDATA“字段,有时提示”PASS“通过,没用时提示”FAIL“失败。
点击到”Tests“测验页签,在右方红色字体处下拉点击“Response body:contains string",点击后,在左边框内自动生成一串代码:代码如下:
(不同的版本或设置显示的代码不同,但是意思都是一样的,修改时对应着改即可)
pm.test("Body matches string", function () {
pm.expect(pm.response.text()).to.include("string_you_want_to_search");
});
修改测试命名以及检测测HEADDATA字段是否存在,修改的代码如下:
pm.test("检测是否返回HEADDATA字段", function () {
pm.expect(pm.response.text()).to.include("HEADDATA");
});
写好判断后,点击”Send“按钮运行接口,查看下方的”Test Results“页签后面的文字是什么颜色,绿色表示存在,红色表示不存在。点击到”Test Results“页签后,可以看到下面有是否通过的标志,当返回数据有”HEADDATA“字段时提示”PASS“通过,没用时提示”FAIL“失败。
此时,我们得到了采购订单查询接口返回的数据,但是这个数据的模式我们看起来不直观,这里我们需要用JSON解析工具,将这一段JSON数据解析成比较直观的JSON格式。
这里使用的是JSON解析,有很多JSON解析的工具,也有很多在线解析的网址,这里不做深入介绍,我们随便搜索了一个JSON在线解析网址:https://www.sojson.com/,打开后,选择”JSON解析“页签,将我们通过执行【单据查询接口】得到的返回数据填入到代码框,点击”检验/格式化“按钮,弹出”当前内容是一个字符串,是否需要转成JSON对象“,点击”确认“,就可以得出比较直观的JSON格式的数据了。
转换后的数据,如下图,这个格式可以清晰的看到表头信息,表身信息,以及每个信息的值。这个方式比较清晰直观,便于我们判断数据正确性。
同用户登录请求一样,若想以后继续使用这个请求,可以点击“Save”进行保存,保存时可以给这个请求录入名称,选择保存到哪一个接口,点击“save to"按钮保存即可。
保存请求后,在Postman左边接口点击会展开这个接口下保存的请求,点击请求后显示时也显示的时名称。
Postman还有很多其他用法,这里就不一一介绍了。网上也有很多教程,有兴趣的可以去查看以下。
接口测试工具还有很多,比如Restlet Client、Mockbin等工具,这些公允运行道理都是差不多,根据实际需求选择一个使用即可。
4.4 现有接口的类型
列示几个常用类型,还有很多接口,这里没用一一列示。
接口名称 | 接口类型 | 请求类型 | 接口路径 |
---|---|---|---|
用户登录 | 登录 | POST | http://localhost:23798/api/User/login |
账套验证 | 账套验证 | POST | http://localhost:23798/api/WMS/GetToken |
单据保存、修改 | 单据操作 | POST | http://localhost:23798/api/Bill/SaveBill |
单据打印 | 单据操作 | POST | http://localhost:23798/api/Bill/PrintBillReport |
单据审核 | 单据操作 | POST | http://localhost:23798/api/audit/executeaudit |
单据查询 | 单据操作 | GET | http://localhost:23798/api/Bill/QueryBill |
单据删除 | 单据操作 | POST | http://localhost:23798/api/Bill/DeleteBill |
查询视窗 | 查询 | GET | http://localhost:23798/api/Bill/QueryWin_GetData |
货品履历查询 | 查询 | GET | http://localhost:23798/api/MrpCZ/GetMrpCZData |
货品库存查询 | 查询 | GET | http://localhost:23798/api/TbrECC/GetPrdStock_One |
详细资料查询 | 查询 | GET | http://localhost:23798/api/Bill/QueryDataDetail |
4.5 现有接口的单据
这些单据都有新增、删除、修改、查询的接口
单据识别号CallID | 单据名称 | 单据识别号CallID | 单据名称 | |
---|---|---|---|---|
PO | 采购订单 | IJ | 库存调整单 | |
SO | 销售订单 | T6 | 采购入库送检 | |
PC | 采购入库单 | TY | 采购入库验收 | |
PB | 采购入库退回单 | TP | 生产缴库验收 | |
SB | 销售出库退回单 | W1 | 库存入仓单 | |
TW | 托外加工单 | WO | 库存出仓单 | |
WT | 批次托外单 | MM | 成品缴库单 | |
TC | 托工退回单 | M2 | 生产退料 | |
M4 | 托工领料 | M3 | 生产补料 | |
M5 | 托工退料 | YB | 采购验收退回 | |
M6 | 托工补料 | YM | 制成品验收退回 | |
M7 | 非生产领料 | YK | 托工验收退回 | |
M8 | 非生产退料 | MB | BOM组合生产单 | |
IC | 库存调拨单 | MD | BOM切割分装单 | |
MC | 原料调拔单 | MX | 入不良品仓 | |
PI | 盘点单 | CK | 备货单 | |
PJ | 盘点单(批号) | PN | 订单变更 |
五、扩展知识
5.1 HTTP 协议
上面所提到的请求类型,Headers(请求头)、query(参数)、Body(请求体),这些都是HTTP 协议下的东西。
HTTP协议英文全称HyperText Transfer Protocol翻译为超文本传输协议。HTTP协议是一个简单的请求-响应协议,是基于TCP/IP协议之上的应用层协议。HTTP协议定义Web客户端如何从Web服务器请求Web页面,以及服务器如何把Web页面传送给客户端。HTTP协议遵循请求(Request)/响应(Response)模型。客户端向服务器发送一个请求报文,请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。服务器以一个状态行作为响应,响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。
请求报文构成
- 请求行(Request line):包括请求方法、URL、协议/版本
- 请求头(Request Header)
- 请求正文(Request Body)
POST /test.html HTTP/1.1 //请求行 包括请求方法、URL、协议/版本
//请求头 Header
HOST:www.test.com?indexid=2 //query query一般指URL中的参数
Content-Length: 16
Content-Type: text/html
//空白行,代表请求头结束
//请求正文 body,请求体中的数据
Username=admin&password=admin
响应报文构成
- 响应行(Response line)
- 响应头(Response Header)
- 响应正文(Response Body)
HTTP/1.1 200 OK //响应行 包括协议版本 状态码 状态码原因短语
//响应头 Header
Date: Sun, 15 Nov 2015 11:02:04 GMT
Content-Length: 360
Content-Type: text/html
//空白行,代表响应头结束
//响应正文 body,响应体中的数据
<html>
<body>Hello World</body>
</html>
5.2 HTTPS 协议
一般http中存在如下问题:
- 请求信息明文传输,容易被窃听截取
- 数据的完整性未校验,容易被篡改
- 没有验证对方身份,存在冒充危险
为了解决上述HTTP存在的问题,就用到了HTTPS。
HTTPS 协议英文全称是 HyperText Transfer Protocol over Secure Socket Layer,翻译为超文本传输安全协议。一般理解为在HTTP的基础上加入了SSL/TLS,通过 SSL证书来验证服务器的身份,并为浏览器和服务器之间的通信进行加密。
SSL(Secure Socket Layer,安全套接字层):SSL 协议位于 TCP/IP 协议与各种应用层协议之间,为数据通讯提供安全支持。
TLS(Transport Layer Security,传输层安全):其前身是 SSL,目前使用最广泛的是TLS 1.1、TLS 1.2。
HTTPS的缺点:
- HTTPS协议多次握手,导致页面的加载时间延长近50%;
- HTTPS连接缓存不如HTTP高效,会增加数据开销和功耗;
- 申请SSL证书需要钱,功能越强大的证书费用越高。
- SSL涉及到的安全算法会消耗 CPU 资源,对服务器资源消耗较大。
总结HTTPS和HTTP的区别:
- HTTPS是HTTP协议的安全版本,HTTP协议的数据传输是明文的,是不安全的,HTTPS使用了SSL/TLS协议进行了加密处理。
- http和https使用连接方式不同,默认端口也不一样,http是80,https是443。
对于http和https这里都只是做了浅显的介绍,有需要的可以自己去学习。
参考网址:
https://zhuanlan.zhihu.com/p/72616216
https://www.cnblogs.com/an-wen/p/11180076.html
5.3 Base64加密工具
在我们使用Postman工具测试的时候,是通过自带的Base64加密来对账套用户密码来加密,如果工具不带,可以直接下载加密工具或者找在线的加密网址来进行加密。
下面介绍一个在线加密的方式,打开站长工具在线加密网址:http://tool.chinaz.com/Tools/Base64.aspx?jdfwkey=np1b4(还有很多其他在线加密网址,这里只是随便选了一个),将“账套代号_用户代号:密码”这一串字符录入到左边,点击“Base64加密”按钮,右边就会显示加密后的内容,把”Base64“字符串与得出的字符串用空格组合,得到的就是Authorization的参数值了。
例如账套代号是DEMO,用户代号是ADMIN,密码为123,加密后得到的字符串为“REVNT19BRE1JTjoxMjM=”,与”Base64“字符串用空格组装后,得到的字符串为“Base REVNT19BRE1JTjoxMjM=”,这个就是Authorization的参数值。