为什么EDI工作流中围绕XML做EDI报文数据解析/生成？
经常有客户问起，为什么在处理EDI文件时不一次到位，而需要使用多个端口来分次进行处理呢，是不是想要多占用几个端口好多卖钱呀？
实际上，在一开始的知行EDI产品中，功能还没有这么完善，当时只支持EDI常见的传输协议，那个时候我们在做报文翻译时，还不能仅通过简单的配置来实现，需要手写代码，去读取报文，然后获取每一行的数据，再逐一去读对应的业务值。参考之前的实施经验，觉得实施过程漫长、前期开发代码量大、后期维护成本也高，经过产品部门多次考量，在一次次的产品升级过程中，不停的进行功能新增、完善，才形成了现在这样的一套报文处理模式。
那么，到底是不是直接对报文进行处理更简单呢？
假设我们现在通过AS2传输，接收850采购订单EDI报文，采用自定义XML方案。
直接处理EDI报文
我们来回顾一下直接处理业务报文的步骤：
首先，通过AS2收到850采购订单后，要直接进行处理，完成报文翻译，我们的代码逻辑大约如下：
- 先读取当前850采购订单报文的内容
- 对内容进行分割，将850采购订单的内容按照节点分割，例如：ST节点，BEG节点等等，每个节点代表不同的信息
- 开始逐一读取节点，匹配节点所属的业务含义，并将每个节点中的详细业务数据读取出来
- 一边读取数据，一边输出自定义XML
- 调试程序，确认业务逻辑和取值正确
以上步骤中我们可以看出，所有的处理都要使用代码来实现，那么代码量一定是非常大的。同时，因为EDI报文中数据比较多，而且结构复杂，所以代码逻辑也会非常复杂。在初步完成代码之后，后续的业务测试过程中，若是因为对EDI报文理解不到位，想要修改某一部分的处理逻辑或是取值方式，将会造成很大的工作量，而且往往都是牵一发而动全身，修改可能会造成其他本来正确的数据出错。同时，在切换生产环境之后，如果贸易合作伙伴对EDI规范做了某些升级或者调整，后来的维护人员需要将整个的代码整体通读一遍，完全理解之后，才能进行修改。
分步处理EDI报文
如果在目前的知行EDI产品中，我们分多个端口去完成报文翻译，每个端口都只负责各自的功能部分，那么整体步骤如下：
- AS2端口收到850采购订单后，直接转发到X12端口（直接配置实现）
- X12端口将EDI报文转换为标准XML，并转发到XMLMap端口（直接配置实现）
- XMLMap端口通过界面拖拽，并辅以少许简单code，实现转换为自定义XML文件（简单coding）
以上步骤中我们可以看出，通过这种方式，一方面，代码量非常少，大家知道，写的越多，容易出错的地方越多，代码量少了，大部分功能依赖于产品，所以出错概率会降低。如果有EDI报文结构更改或是升级的情况，前两步我们不用做任何修改，只要在最后一步，仅修改需要调整的部分即可。
标准XML文件
在知行EDI系统中，几乎所有的EDI报文处理都是以标准XML文件为媒介的。
XML（可扩展标记语言）是一种标记语言，提供了一种简单，灵活的文本格式。XML描述文档的数据结构，并为所有其他规范提供通用语法。XML的主要应用程序之一就是处理B2B和B2C数据交换。
这是部分EDI报文采购订单和标准XML采购订单:
850 原始EDI文件:
.. BEG*00*DS*0476696888**20150708~ REF*SB*ZZ11~ REF*6P*ZZ~ ...
经X12端口标准XML：
<pre>...
<BEG type="Segment">
<!--Transaction Set Purpose Code-->
<BEG01>
<!--Original-->00</BEG01>
<!--Purchase Order Type Code-->
<BEG02>
<!--Dropship-->DS</BEG02>
<!--Purchase Order Number-->
<BEG03>0476696888</BEG03>
<!--Release Number-->
<BEG04 xsi:nil="true"/>
<!--Date-->
<BEG05>20150708</BEG05>
</BEG>
<REF type="Segment">
<!--Reference Identification Qualifier-->
<REF01><!--Sales Region Number-->SB</REF01>
<!--Reference Identification-->
<REF02>ZZ11</REF02>
</REF>
...
</pre>
我们可以看出，标准XML包含解释每个节点含义的注释。最重要的是，对于标准XML文件，可以直接将其映射到目标格式，而不必查找EDI文档中每个节点的含义，只需参考标准XML文档中提供的说明和贸易伙伴提供的规范即可。
显而易见，在处理EDI报文时，并不是直接对EDI报文进行处理一步到位就更好。先将EDI报文转换为标准XML，再对标准XML进行后续处理存在以下优点：
-
代码逻辑简单，工作量较小
-
可以自动检查贸易合作伙伴传来的EDI报文是否符合国际标准
-
易于调试，进行业务测试
-
易于后期维护
-
易于和其他目标格式文档做转换，比如自定义XML，CSV，PSV，Excel等
-
增加功能模块的独立性，降低耦合性
