Dynamics ERP 接口设计思路

ERP系统并不是一个完全独立的系统，经常要和周边系统进行对接。小到公司内部，大到公司外部系统， 总会有各种通信需求。比如和CRM系统，HR系统，外部第三方供应商和客户对接。
无论怎么接，通常分为手工对接和自动对接两类。
手工对接，最常用的方法就是点击某个按钮导入文件， 文件的格式最常见的有Excel, Txt, CSV, 如有观众需求, 后续单独篇幅进行介绍。本文主要介绍自动对接的思路. 自动对接通常是批处理异步执行或实时导入，对接方法通常会有文件对接，Webservie, EDI 等方式。
具体的接口技术细节这里不作详细介绍，本文主要想从甲方运维角度看，健壮的接口应该是什么样子的。
本人经历过很多接口，上面提到的各种对接都遇到过。以下主要介绍自动接口的常见问题及设计思路。常见问题有：
1. Log日志描述不清晰，不能够准确定位错误原因
2. 接口数据导入错误用户并不知晓，只有后期使用过程中出错才知道接口错误导致
3. 发现错误后，很难排查问题原因， 因为接口不断更新，也不知道是什么什么原因导致的错误
4. 接口恢复后，不能正确工作，导致数据重复，数据丢失等。

大家是不是也遇到过类似的问题呢？ 我的改造思路是从甲方运维的角度为出发点进行设计。基于上述几点的分析，问题可以归结为两大类，第一，问题定位及查询不清晰，第二，接口自身问题。
针对接口自身问题，我的思路是，首先要增加接口调用日志，区分出系统责任。增加一个日志表，对所有调入调出的命令进行记录。这一动作主要是为了划分责任，到底是对方系统问题还是ERP系统的问题，避免出了问题都说跟自己没关系。如果ERP是入站口，这一日志表没有记录的，就代表ERP没有接收成功，如果是出站口，不仅仅要记录该日志，还要记录该日志的返回状态，如果目标系统返回正确接收命令，后续不再发送，如果没有收到正确接收状态，后续还应根据业务需求，定时重发，重发一定次数还是失败的，要发邮件提醒运维人员。这种机制也保证了接口恢复后的数据重传。根据不同的业务场景，可以和上游系统规定版本号，每次数据都以最新版本号为准。出现问题后，检查这张日志表是正确的，那问题就出在ERP内部。
内部问题定位及查询不清晰的处理相对简单，只要是接口，无非就是对接主数据，交易记录，最多再增加过账逻辑。导入记录的验证相对较多一些，我们以文件对接为例，说明一下定位思路。由于文件有文件名，有清晰的行，列信息，所以，Log日志要详细记录文件名，导入时间。验证的时候要逐行验证，清晰的记录文件出错的行，列信息，把错误信息统一收集起来，在接口执行结束后，判定有没有错误，如果有错误统一发邮件给相关人员，不能仅仅依靠批处理信息。涉及到标准功能报错的要用自己的话重新整理报错，然后按照统一的格式发邮件给运维人员。有时导入的信息量比较大，所以邮件信息最好做一下归类，让用户一看就知道如何去处理。 邮件内不仅仅要提供出错问题，更要提供如何处理的建议。可以把想到的问题进行归类，不同类型的问题处理办法也不同，清晰的反馈给用户。邮件内容要足够详细，让用户一看就知道是哪里的问题。

导出数据相对简单，根据对方系统要求进行数据把关即可。

实际应用中，ERP内部出现问题的概率还是比较小的，一旦调试完毕，出了问题基本按照邮件指示进行处理就好了。这种设计最大的好处就是对甲方运维人员后期对接口的运维比较省心。 缺点就是接口开发比改造之前的方案要多花不少时间。但是总的来说我个人认为是值得投入的。因为做为ERP，我们可以保证自己的系统数据是正确的，但是完全不能保证上游系统数据的正确性。