|
在《接口取数不再慌张，API取数原来这么简单》一文中我们已经详细了解了API取数节点的使用，本文再结合包含身份认证的循环分页取数场景案例再具体讲解介绍
一、接口准备
1、登录接口-获取token
请求地址：http://localhost:6060/api/doLogin
请求方法：POST
Body请求体格式：application/json
Body请求参数：
参数
|
含义
|
username
|
用户名
|
password
|
用户密码
|
请求参数参考示例：
{
"username": "admin",
"password": "admin"
}
接口返回示例：
{
"success": true,
"code": 200,
"message": "成功",
"data": "41ca340b-4435-4949-bf1a-7bb66ddcae78"
}
2、分页取数接口
请求地址：http://localhost:6060/api/order/getOrdersByPage
请求方法：GET
请求参数：
参数
|
含义
|
pageNo
|
页码
|
pageSize
|
分页条数
|
请求参数参考示例：
http://localhost:6060/api/order/getOrdersByPage?pageNo=1&pageSize=2
接口返回示例：
{
"success": true,
"code": 200,
"message": "成功",
"data": {
"pageNo": 1,
"pageSize": 2,
"total": 830,
"totalPages": 415,
"result": [
{
"orderid": 10248,
"customerid": "VINET",
"employeeid": 5,
"orderdate": "2020-07-04T16:00:00.000+00:00",
"requireddate": "2020-07-31T16:00:00.000+00:00",
"shippeddate": "2020-07-15T16:00:00.000+00:00",
"shipvia": 3,
"freight": 32.38,
"shipname": "余小姐",
"shipaddress": "光明北路 124 号",
"shipcity": "北京",
"shipprovince": "北京市",
"shipregion": "华北",
"shippostalcode": "111080",
"shipcountry": "中国"
},
{
"orderid": 10250,
"customerid": "HANAR",
"employeeid": 4,
"orderdate": "2020-07-07T16:00:00.000+00:00",
"requireddate": "2020-08-04T16:00:00.000+00:00",
"shippeddate": "2020-07-11T16:00:00.000+00:00",
"shipvia": 2,
"freight": 65.83,
"shipname": "谢小姐",
"shipaddress": "光化街 22 号",
"shipcity": "秦皇岛",
"shipprovince": "河北省",
"shipregion": "华北",
"shippostalcode": "754546",
"shipcountry": "中国"
}
],
"start": 1,
"end": 2
}
}
二、操作步骤
（一）添加API节点配置登录接口获取令牌
按照登录接口配置如下：
（二）添加JSON节点解析令牌
（三）添加循环API节点进行循环取数
（1）API配置-参数配置：
按照上述分页取数接口配置如下：
（2）API配置-令牌配置：
在进行API配置之前，我们先了解下存在身份认证的情况下令牌的获取传递方式及API配置的支持情况：
注意：下面支持情况仅代表smartBI产品的支持情况，非第三方认证的支持情况，例如：某些第三方认证为避免业务数据与认证数据的耦合，并没有开启对从请求体中获取token令牌的支持，则此情况下即使配置也是无法认证成功的。
方式
|
示例
|
支持情况
|
从请求头中获取
|
Authorization: Bearer
|
支持
|
从请求参数中获取
|
https://api.example.com/data?access_token=
|
支持
|
从请求体中获取
|
{
"access_token": "",
"data": { ... }
}
|
支持
|
从Cookie中获取
|
Cookie: access_token=
|
支持（特别说明：虽无法直接配置Cookie，但由于Cookie本身是在Headers头上，所以也可支持配置）
|
注意：由于token令牌都是来自上一节点解析出来的动态值，所以下述${token}均以参数形式配置，后续会在循环配置中映射参数值。
1、从请求头中获取配置参考：
以OAuth 2.0标准为例，其令牌位置在Authorization头上，格式为 Bearer ，则可在Authorization中选择Bearer Token，配置后会自动在Headers请求头中添加Authorization头配置：
Authorization: Bearer
若项目当前使用的是非OAuth 2.0标准或其它自定义的令牌（自定义令牌位置及格式）如：Auth-Token: ，表示令牌位置在自定义的Auth-Token头上，格式直接是令牌值，则配置如下：
当然在Authorization中也是支持标准认证Basic Auth认证，只是这种已不属于token认证方式，在配置后会自动在Headers请求头中添加Authorization头配置：Authorization: Basic
2、从请求参数中获取配置参考：
从请求参数中获取token适用于token配置在url地址上的场景，配置方式和普通参数一样：
3、从请求体中获取配置参考：
4、从Cookie中获取
（3）循环配置：
循环方式配置：分页取数一般是在后端依赖分页页码pageNo（具体以实际参数为准）和每页条数pageSize（具体以实际参数为准）在数据库层面进行分页，所以此场景下想将全部的数据取出就需要依次取第1页的数据、第2页的数据......直到取完最后一页数据。即为每次请求时让页码参数pageNo+1即可。所以在循环配置时选按序号循环，每次循环序号+1，然后让序号值映射为页码参数pageNo值。
参数映射配置：由于token是从上一个节点解析出来的动态值，所以需要将对应值映射到token参数参数上，支持一键识别映射，然后根据实际情况修改即可。
退出条件配置：在分页取数时，当某页查询的结果为空或者是查询的行数<每页的行数时即可认为取完全部数据。则可配置方便对JSON数据结构进行内容提取的JSONPath表达式来提取内容进行判断。JSONPath表达式可参考学习：JSONPath 表达式 - Smartbi Insight V11帮助中心 -
结合接口返回示例相应的JSONPath表达式为：$['data']['result'].length()，则配置如下：
（四）其它参数配置
在上述配置完后，其实还发现有一个pageSize参数没有进行映射，此时可直接在ETL的参数设置的进行配置添加：
（五）运行结果展示：
共830条数据，每页50条，共需循环17次，显示返回17条数据。
后端日志记录：
需注意若刚好发生：总行数/每页行数=整数页，则会多一条为空的数据，需在后续节点中将空数据过滤掉。
三、问题排查
（一）http状态码
在看具体问题前我们先来了解下http响应状态类型，当API调用失败、功能出现异常时，状态码是问题的第一信号，而在调用API的过程中通常遇到的错误状态码就是4xx和5xx状态码。
类别
|
分类描述
|
状态码含义说明
|
常见排查建议
|
1xx
|
Information（信息状态码）
|
接受的请求正在处理
|
|
2xx
|
Success（成功状态码）
|
请求正常处理完毕
|
|
3xx
|
Redirection（重定向状态码）
|
需要进行附加操作以完成请求
|
|
4xx
|
Client Error（客户端错误状态码）
|
服务器无法处理请求
|
客户端错误，需检查请求头、请求体及参数是否配置正确
|
5xx
|
Server Error（服务端错误状态码）
|
服务器处理请求出错
|
服务端错误，通常需对应接口开发人员获取服务器日志排查，少数也可以直接通过返回的错误信息排查
|
（二）常见问题解答
（1）为什么API节点执行成功了但是返回的结果却没有达到预期？
有以下两个场景场景一：节点执行成功，statusCode结果也是200，但为什么返回的内容里还是登录失败？
答：需从 HTTP状态码 和 业务响应内容 两个维度分析：HTTP状态码（图中 statusCode: 200）：HTTP 状态码 200表示 客户端（发起请求的一方，如浏览器、程序）与服务器之间的“网络层面通信成功”——服务器收到了请求、完成了响应处理，并将响应返回给客户端。它只代表“请求-响应的传输流程没出问题”，不直接反映业务操作是否成功。业务响应内容（图中 responseContent）：接口返回的 JSON 数据里，success: false、code: 500、message: "失败"、data: "登录失败"是 业务逻辑层面的结果。这说明：虽然服务器正常响应了（HTTP 200），但业务操作本身出错了，需联系第三方接口开发人员排查。当然有些错误在后端也直接提示较明显就是用户名或密码错误，就按提示检查用户名和密码即可。
场景二：节点执行成功，但statusCode结果是非200
答：API节点支持设置接收异常结果，让节点即使执行失败也能继续往下执行，确认是否有开启该配置。至于请求执行失败400的状态码则如上方http状态码介绍部分，一般表示“客户端错误请求”（Bad Request），可检查通常表示服务器因为请求中存在语法错误或格式问题，无法理解或处理客户端的请求。需检查请求头、请求体及参数是否配置有误，或联系SmartBI官方或第三方接口开发人员分析。
（2）为什么接口测试工具中可以测试通过但API节点上运行失败？
答：接口测试工具中为方便测试其实是默认是有配置一些请求头参数，细心的小伙伴也发现在截图中接口测试工具显示的Headers配置上有“已隐藏7个”的字样：
显示隐藏的参数发现实际是有这些参数的：
注意到上方参数中其实有配置Cookie，如果将Cookie取消勾选也一样报错了：
此时检查cookie的中内容发现配置：token=51198da1-3f0e-4f7a-a31a-9d97aada4622，将其配置到API节点上一样可运行成功：
则以实际规则配置Cookie头即可，当然此时也说明现场的令牌位置并非在Authorization头上或是不支持从请求头中获取，若依然还是想以请求头的方式获取则需以认证方接口实际为准。
都看到这了，那来做个题吧，答题可领取麦豆——>点击领取任务
| 
