各位商家、各位合作伙伴：
感谢大家一路相伴！
有赞开放平台自2014年初开放了API接口，帮助商家通过接口的形式与ERP进销存等系统完成无缝对接。目前，由于商家交易量持续增长，每日接口调用量持续走高，已发生多起调用超出系统承受能力的事件。
为让大家能更高效调用接口资源，保障系统稳定运行，我们决定将在2016年8月18日-9月18日期间，推动自行开发系统的商家和第三方ERP合作伙伴从原有的轮询拉取方式升级到Push数据推送方式。
Push数据推送方式，开发者和商家无需再定时不断抓取订单。当有订单产生，状态变更，商品更新等变化后，有赞会主动推送变更信息到外部开发者系统，如此可有效提高了外部调用的效率，减少外部系统和有赞的服务器资源消耗，提升数据开放服务能力。
由于目前接口调用的服务压力越来越大，我们将在9月18日后针对API接口调用发布限流策略、设定阈值（但不影响Push数据推送服务），以确保整个有赞交易系统、买家购物体验不因接口调用超限发生大面积使用故障。由此带来不便，请大家谅解。
同时，为了保障订单数据、商品数据、库存数据的正常对接，请自行开发进销存系统商家和正在服务大量商家的第三方ERP合作伙伴，在9月18日前尽快完成有赞Push数据推送服务的接入、切换。
数据推送服务接入过程中，有赞开放平台团队将与大家紧密配合，给予及时、必要、到位的技术支持。联系人：有赞墨迹；工作微信：yemoji
感谢您对有赞开放平台的支持！
8月18日 有赞开放平台 有赞开放平台Push数据推送服务接入指南 背景： 目前有赞接口授权方式分为两种：免签名（第三方开发者）和签名通讯协议（适用于商家） 授权过程中，获取消息的方式必须是由商家或第三方主动向有赞发起申请，开放平台接到具体参数的请求后，如果请求正确则返回具体参数对应的正确消息，如请求错误则返回错误报告。
为什么要用数据推送功能？ 举个案例：某餐饮外卖的门店商家在有赞开店，利用有赞周边的小票打印机来实现自动接单打印订单，因外卖的订单及时性非常高，需要自动接单打印后快速备货配送。所以，我们的打印机合作伙伴只能不间断的轮询我们的接口，频繁到一分钟抓取一次订单甚至更短。直接增加了第三方和商家的调用成本。同时，对有赞的服务器也带来了超大的压力。
Push 功能上线后，外部开发者和商家无需再定时不断抓取我们的接口消息，当有订单产生，状态变更，商品更新等变化后，有赞会主动推送变更信息到外部开发者，如此，有效提高了外部调用的效率，也减轻了有赞服务器的压力。
备注：现在只开放推送交易接口信息，更多信息推送将陆续开放。
Push推送接入——
消息推送模式 ： 1. 商家自有消息推送 （适用于有自主开发能力的商家） 2. 服务商消息推送 （适用于服务商，需要商家授权）
商家自有消息接入：
一 . 商家后台配置管理 “推送服务” a. 登陆商家后台 选择“营销”—> “有赞API” 页面 ，启用 “开关 ” b. “API数据主动推送服务 ” 填写 “推送网址” ，勾选 需要推送的内容
二 . 消息推送&解析 a. 消息结构体定义 属性 | 类型 | 释义 | mode | number | 0-商家自有消息推送
1-服务商消息推送
| id | String | 业务消息的标识: 如 订单消息为订单编号
| appid | String | 对应商户后台的appid
| type | enum | 消息业务类型：TRADE-交易
| msg | String | 经过unicode（UTF-8）编码的消息对象 ：交易对象参考 TradeDetail
| kdt_id | number | 店铺ID
| sign | String | 防伪签名 ：MD5(appid+msg+appSecrect)
| version | long | 消息版本号 为了解决顺序性的问题 ，高版本覆盖低版本
| test | boolean | false-非测试消息 true- 测试消息 ，PUSH 服务会定期通过发送测试消息检查 商家服务是否正常
| send_count | number | 重发的次数
| status | String | 订单状态
|
b. 推送服务消息推送: （重要） 1. 消息推送服务通过 POST 、参数编码为APPLICATION/JSON 的方式向商家提供的地址推送消息 2. 当推送没有成功返回 （超时时间为5秒），会进入重发 。最多重发三次， 分别间隔 10S 、 30S 、 60S 。三次重发后如果还是失败 ，该消息丢弃。 3. 当推送某个商家服务连续失败时 ，商家服务会被添加到 亚健康列表中。在亚健康列表的商家服务将无法接收到消息，并且期间产生的消息 会被丢弃 4. 推送服务会定期检查亚健康列表中的商家服务是否恢复正常，正常的服务会被从该列表中移除
c. 消息接收以及返回：（重要）
1.消息接收协议参考推送服务的约定 2. 接收服务返回 {"code":0,"msg":"success"} 通知推送服务成功接收. 由于服务端设置5秒的超时时间，建议接收到消息后异步处理自有的业务。注意接收测试消息也请返回 {"code":0,"msg":"success"} 3. 消息解析 ： 1）判断消息是否测试 —> 解析test 2）判断消息推送的模式—> 解析mode 3）判断消息是否伪造 —> 解析sign 4) 判断消息版本 —> 解析version 5) 判断消息的业务类型 —> 解析type 6) 处理消息体 —> 解码msg ,反序列化消息结构体 7) 返回成功标识
--------------------------------------------
服务商消息推送接入：
一 . 开发者后台&商户后台 配置推送服务 a. 开发者后台开启推送服务 b. 商家需要到商家后台将推送权限授权给服务商
二 . 消息推送&解析
a. 消息结构体定义 属性 | 类型 | 释义 | mode | number | 0-商家自由消息推送
1-服务商消息推送
| id | String | 业务消息的标识: 如 订单消息为订单编号
| client_id | String | 对应开发者后台的client_id
| type | enum | 消息业务类型：TRADE-交易
| msg | String | 经过unicode（UTF-8）编码的消息对象 ：交易对象参考 TradeDetail
| kdt_id | number | 店铺ID
| sign | String | 防伪签名 ：MD5(client_id+msg+client_secrect)
| version | long | 消息版本号 为了解决顺序性的问题 ，高版本覆盖低版本
| test | boolean | false-非测试消息 true- 测试消息 ，PUSH 服务会定期通过发送测试消息检查 商家服务是否正常
| send_count | number | 重发的次数
| status | String | 订单状态
|
b. 推送服务消息推送: （重要）
1. 消息推送服务通过 POST 、参数编码为APPLICATION/JSON 的方式向开发者提供的地址推送消息 2. 当推送没有成功返回 （超时时间为5秒），会进入重发 。最多重发三次， 分别间隔 10S 、 30S 、 60S 。三次重发后如果还是失败 ，该消息丢弃。 3. 当推送某个服务连续失败时 ，该服务地址会被添加到 亚健康列表中。在亚健康列表的服务将无法接收到消息，并且期间产生的消息会被丢弃 4. 推送服务会定期检查亚健康列表中的商家服务是否恢复正常，正常的服务会被从该列表中移除 c. 消息接收以及返回：（重要）
1. 消息接收协议参考推送服务的约定 2. 接收服务收到消息请返回 {"code":0,"msg":"success"} 通知推送服务成功接收. 由于服务端设置5秒的超时时间，建议接收到消息后异步处理自有的业务。注意接收测试消息也请返回 {"code":0,"msg":"success"} 。
3. 消息解析 ： 1）判断消息是否测试 —> 解析test 2）判断消息推送的模式—> 解析mode 3）判断消息是否伪造 —> 解析sign 4) 判断消息版本 —> 解析version 5) 判断消息的业务 —> 解析type 6) 处理消息体 —> 解码msg ,反序列化消息结构体 7) 返回成功标识
Demo 下载：
java-demo php-demo
PS：
1. 关于交易消息 有可能会出现同版本号的消息 这里需要判断交易状态。
本帖最后由 有赞-墨迹 于 2017-6-20 18:08 编辑 |
用手机打开
收藏
赞 1
···
回复
复制链接
新浪微博
QQ空间
微信扫码
赞 
回复
