提现功能流程图
2017-03-01 20:56:35 0 举报
用户在需要提现时,首先需要登录自己的账户。登录后,用户可以选择提现的金额和提现的方式,如银行卡、支付宝等。然后,系统会检查用户的账户余额是否足够提现。如果足够,系统会进一步验证用户的提现信息,如银行卡号、姓名等。验证通过后,系统会将提现请求提交给财务部门进行审核。财务部门审核通过后,系统会从用户的账户中扣除相应的金额,并将提现金额发送到用户选择的提现方式中。整个过程结束后,系统会向用户发送一条提现成功的提示信息。
作者其他创作
大纲/内容
不是
返回请求参数为空,结束
是
往 result 里面 put 失败状态和 “NO_DATE”
通过 WithdrawOrderFacade 调用 Biz 层的同名方法
遍历完成
返回 result.toString 结束
通过entity获得提现状态oldStatus(枚举类型)
设置 entity 的Code和Msg
设置 entity 的状态为 PROCESS
判断 getDefineCode 的值是否为 default_router_timeout_exception_code 或者与 ROUTER_UNKNOW_EXCEPTION.getDefineCode() 的值相同
不为空
判断 entity 的状态是否为INIT 或者 PROCESS
判断 entity 状态值与 FAILURE 是否相同
为假
在 Service 中的方法还调用了 Dao 中的方法,而这些方法都是简单的调用,因此给予省略
获取参数,补单号和商编
设置 entity 的状态为 FAILURE
为空
创建提现响应 dto,把从entity得到的参数都设置到该dto中
创建 JSONObject 对象 result
进入主动通知action
不需要
判断 isUpdate 是否为真且 entity的状态为SUCCESS或者FAILURE
entity 为 null
返回提现补单异常,结束
批量补单
主动通知成功,结束
通过dto获取提现请求号
为真
通过远程服务获取提现查询响应dto
以 request 为参数,调用 buildBatchQueryParam 方法,返回提现查询请求 DTO 列表 requestList
是否遍历完成
提现响应DTO是否为null
声明一个 success 变量,初始化为 0
抛出提现商编不能为空的异常
判断执行如下代码是否发生异常
未发生异常
判断 entity.getPpUserNo 是否为空
有
判断 Entity 是否为null
返回补单异常,结束
判断是否是订单异常
在 BizImpl 中实现方法,通过dto获取用户商编
创建提现请求DTO,将补单号和商编设置到dto中
设置 isNeedCache 为 TRUE
不主动通知
将 entity 作为参数,调用updateWithdrawAndRecordAccounting 更新 isUpdate 的值
结束
不是/不同
设置entity 的码、错误信息和失败状态
判断提现响应dto是否为null
是否发生异常
进入批量通知action
发生异常
需要
以 entity 的 Code 和 Msg 为参数,判断 isRouterWithdrawUnknowCodeOrMsg 是否为真
未遍历完
获取wdExternalNo
大于
判断 oldStatus 是否与 entity 的状态值相同
抛出 PPOrderException 异常
判断提现响应dto的状态是否为REMIT_SUCCESS
返回提现响应DTO
抛出提现请求号不能为空的异常
判断 requestList 的长度是否大于最大批量补单数量(1000)
进入补单action
不补单
商编是否为空
没有
提现请求号是否为空
判断是否需要缓存
未发出异常
wdExternalNo是否为空或者为null
往 result 里面 put 成功状态和 msg
是否有符合条件的记录
无论是这里的 Biz 层方法,还是接下来的 Service 层方法,都是在先在接口中定义, 然后在 Impl 中实现该方法,最后在 ServiceImpl 中调用 Dao 层的方法,而 Dao 层方法则是和 Mapper 文件中的对应的 SQL 语句的 id 同名
判断 requestList 是否为空
相同
获取 entity 的 Code 和 Msg 的值,并带入isRouterWithdrawUnknowCodeOrMsg,看其值是否为真
不相同
此远程调用的内部实现,与前面“补单”完全相同,因此省略
以提现请求dto为参数,通过routerWithdrawService.queryWithdrawOrder获得提现响应dto
调用RemoteCacheUtils.put加入缓存
不批量通知
设置 isUpdate 为 FALSE
创建 MerchantNotifyParam 对象 parm,并设置 BizNo
是否主动通知
判断 AsyncEventSender.send 是否发生异常
不批量补单
在 WithdrawFacadeImpl 中调用MQSendService .sendMerchantWithdrawResultNotify发生(参数为wdExternalNo)
补单
是否批量补单
success自增
打印错误日志,continue
是/相同
发送通知消息
小于
判断提现响应dto的状态是否为REMIT_FAILURE
以 entity 为参数,通过 buildRouterWithdrawQueryParam,获取查询提现请求dto
判断 entity 的状态是否为SUCCESS 或者 FAILUER
判断 requestList 的长度是否大于最大批量通知数量(1000)
进入远程服务调用 queryWithdrawOrderBySerialNo 方法(参数为提现查询请求dto)
抛出提现查询异常
补单号和商编是否为空或者为null
输入查询条件
创建提现查询响应DTO,并将通过entity获得参数设置到该DTO中
批量通知
判断 (entity 的状态是否为INIT 或者 PROCESS)是否发生异常
获取提现响应DTO是否发生异常
是否补单
以wdExternalNo为参数,通过远程服务调用withdrawMerchantNotify函数
进入批量补单action
往JSONObject对象里put成功状态和信息
往 result 里面 put 失败状态和 msg“EXCEED_LIMIT_MSG”
进入查询action
获取提现订单Entity,并声明 isNeedCache 为FALSE
设置entity 的码、成功信息和成功状态,银行码
调用 withdrawOrderService 中的 queryWithdrawOrderBySerialNo 方法获得entity
遍历 requestList 列表
打印日志,内容为“发送商户提现主动通知失败”
判断调用远程服务是否发生异常
返回主动通知异常,结束
返回查询结果列表
主动通知
创建 AsyncMQEventEntity 对象,并设置请求号、事件唯一ID、业务类型等值
此远程调用的内部实现,与前面“主动通知”完全相同,因此省略
设置entity 的码、信息和状态,抛出异常
通过 RemoteCacheUtils.put 设置缓存
抛出更新提现状态异常信息
通过远程服务获取提现查询响应DTO
通过缓存工具创建cacheKey
是否批量通知
返回提现补单成功,结束
判断 getDefineCode 值是否为 YOP_WITHDRAW_ING
0 条评论
下一页