项目涉及业务系统交互，需要用到回传，饱受折磨后，决定整理一下。
简述
回传不是一个方法，或一个功能。虽然说是功能也没错，但是个复杂的功能或是一套机制更合适。
首先，不只是落库的数据需要回传，有些中间状态的数据也需要回传。这两种情况抓数据的方式不一样。
1、落库的数据。扫表抓数据。
2、中间数据。删除掉就没了，所以需要埋点。
按业务系统、类型来回传。不同业务系统回传的类型不一样，有的不用回传，有的回传这几个，有的回传那几个。
定时任务回传。
建议分开写，因为不同的类型，回传逻辑不一样。
落库的数据不要放到备份表
现有方案：
将需要回传的数据放到备份表中，然后定时扫描备份表进行回传。
这里当初涉及的比较粗糙，落库的数据也放到备份表了，这样有个问题，抓数据的时候容易冗余，两个表关联查询吧，又是没有业务关系的两个表，而且关联太多表sql慢(因为标准逻辑已经有几张关联表了)。
优化方案：
落库的数据干嘛还要放备份表呢? 多此一举。直接用扩展字段标记，然后根据状态回传，避免了冗余数据，省了很多性能。
指定功能固定筛选条件
对于指定功能的方法，条件可以内置固定。
例如：回传已开未回传单据。
条件是固定的，那就在方法里面把这两个条件写死。当然，分页和创建日期可以灵活掌握，接收传参。
这样有个好处，通过方法就可以完全区分功能，甚至在定时任务中也不用控制条件了，直接拿过来方法就行。
之前有个误区，方法写的灵活性太强，筛选条件都在定时任务中设定，那么其实很麻烦，测试也不好测试，例如拿controller来测试，那么多条件，很容易设置错。
回传字段的设计
以下几个字段是可以的。
flag 回传标志 0未回传 1已回传
times 次数(可以设置个域值，例如5次或6次)
message 反馈信息(存放业务系统的反馈，成功或失败原因，也可以存放本地不回传的原因)
txt 回传报文(拼接好的报文，主要便于查看问题)
关于flag是否要多加几个状态
例如：
0 未回传
1 已回传
2 回传失败
3 无需回传
个人感觉没必要，当然状态多筛选的时候条件可以少点，但是之前的处理逻辑就复杂很多，不如直接用flag+times来判断，完全够用了。
这两个条件就够：
and flag !=‘1’
and times<6
筛选条件的定制
这里的筛选条件和常规的不太一样。
例如：常规字段都会判断，test="documentNumber != null and documentNumber != ''
如果想要实现is null的需求，很明显不好用了，所以需要定制标志。
常规sql：
<if test="documentNumber != null and documentNumber != ''">AND t.DOCUMENT_NUMBER = #{documentNumber}
</if>
定制的sql是这样：
<if test="flagNot1Flag != null and flagNot1Flag != '' and flagNot1Flag==true ">AND t2.FLAG !='1'
</if>
根据实际来吧，需要多少sql就定制多少sql。
但是有一点要注意，同字段sql，无论是定制非定制，只能有一条同时生效。
回传结果兜底落库(后处理)
回传和其他不一样，需要有个feedback对象(反馈对象)贯穿始终，这样好处多多。
为什么这么说呢?
不同于其他功能，例如新增单据，失败了业务终止，返回就行了。
回传如果失败了，不能简单的终止，次数要加1(或做其他标记)，否则下次还会查到它。 因此，反馈对象及后处理非常必要。
反馈对象还可以作用到接口调用时反馈结果，因为整个链路太长了。
包括：
单据信息
拼接后的报文
发送后的反馈
后处理等。
如果不加个反馈类，不好排查问题。
回传字段的初始化
如果在同一个表里，那么比较好弄，字段设置默认值为0就行。
如果是在扩展表里，就比较麻烦，因为是通用表，不好给设置默认值。
这时可以通过定时任务实现，
如果flag为空，flag和times都设置为0。
update T_TABLE
set
FLAG= '0',
TIME= '0'
where
FLAG is null
历史数据的初始化
当然还有历史数据的初始化，例如1年前的数据，肯定早回传了。再循环白白浪费资源。
方案：
单表的话，根据单据时间设置状态为1即可。
扩展表的话，先根据单据时间关联查询，拿到id列表，批量更新。
)
