接口逻辑实现的总结

最近在开发一个KA系统的接口逻辑。

1、接口涉及到的业务背景问题：

（1）客户BI系统按照 经销商编码+业务日期 作为文件名来覆盖历史数据，所以一旦历史中某个经销商的某一天数据被更新了，那么需要回传这个经销商某天的所有数据，如果直传更新过的数据，就会导致覆盖时少了无变化的数据。

（2）匹配关系表是事先维护好的对应关系表，是一个 实时变化的业务表，一旦数据变化，就会导致接口数据变化，所以为了稳定接口数据，使得接口数据不会随着匹配关系不断变化，所以需要对匹配关系做结存。具体实现方式是 客户在每月的月结日第二天凌晨，回传一次定版的匹配关系作为当月的结存版匹配关系。

（3）客户端维护表中记录了 每个抽取数据的客户端的开始日期、结束日期，表示这个客户端的有效期，只有在有效期内的数据，才是有效的。

（4）接口实现逻辑包含了，结存逻辑 和 回传数据逻辑。

          结存逻辑是什么样的数据要放到接口（在月结日之前，每次刷新最近2个月的数据，在月结日后每次只刷新当月数据）；如果数据所在的描述环境发生什么变化时（客户端周期变化），数据要相应的做什么变化再放入接口表。

          回传数据是 每次回传最近2个月的接口数据，但如果数据的状态从有效变为了无效，那么需要把之前有效的数据和 无效的数据一起回传，否则覆盖文件后，会导致数据缺失。

2、接口功能

就是把抓取到的业务数据，按照匹配关系，生成匹配后的数据，放到csv文件，文件命名规则是 经销商编码+业务日期，再把相同业务日期的csv文件 生成压缩包，最后把压缩包回传到客户的sftp文件夹中。

其中最主要的就是把原始抓取的数据，按照结存版或者最新的匹配关系，找到匹配后的标准产品和门店。

正常情况下，除了最近1个月会重新刷新外，已结存数据是不会变化的，但实际上还有下面几个情况会导致数据变化：

（1）新验收客户端

对于新验收客户端，需要判断验收日期是否为昨天，如果是，就说明客户端是新验收的，需要结存、回传历史所有数据，之后只要回传最近2个月的数据。

（2）特殊匹配关系变化

一般情况下结存逻辑只会用到 结存版的匹配关系，匹配关系一旦结存就不会在变化，但如果历史的匹配关系有问题，怎么办？

为了解决这个问题，做了2个导入表单，分配导入要变更的产品匹配和门店匹配关系。

在结存时，会判断如果表单中更新时间为昨天的，就要用这些匹配关系，刷新历史数据，在回传。

但是考虑到客户BI系统是 按照 经销商编码+业务日期 作为文件名来覆盖历史数据的，而刷新的历史数据，其实里面并没有包含其他匹配关系没有变化的数据，如果直接回传这些文件，就会把历史文件覆盖了，所以 除了刷新历史数据，还需要把 和刷新数据相同经销商编码、相同业务日期的数据 也一并放入回传文件，这样数据就不会丢失。

（3）客户端周期变化

数据都是通过客户端抓取上来的，每个客户端都会有 开始日期、结束日期，指定了这个客户端中数据的有效期。一旦开始日期 或者 结束日期变化了，比如：开始日期前移（情况1）、开始日期后移（情况2），结束日期前移（情况3）、结束日期后移（情况4）。

一般的业务场景只会修改其中1个日期，但也不排除同时修改开始日期和结束日期的情况，在处理时不考虑修改的组合情况，而把作为独立的4种情况来处理。比如：开始日期前移 同时 结束日期前移，就分别化简为2种情况：开始日期前移的处理 和 结束日期前移，先处理情况1，再处理情况2。