为什么工作流中围绕XML做EDI报文数据解析/生成？

经常有客户问起，为什么在处理EDI文件时不一次到位，而需要使用多个端口来分次进行处理呢，是不是想要多占用几个端口好多卖钱呀？

实际上，在一开始的知行EDI产品中，功能还没有这么完善，当时只支持EDI常见的传输协议，那个时候我们在做报文翻译时，还不能仅通过简单的配置来实现，需要手写代码，去读取报文，然后获取每一行的数据，再逐一去读对应的业务值。参考之前的实施经验，觉得实施过程漫长、前期开发代码量大、后期维护成本也高，经过产品部门多次考量，在一次次的产品升级过程中，不停的进行功能新增、完善，才形成了现在这样的一套报文处理模式。

那么，到底是不是直接对报文进行处理更简单呢？

假设我们现在通过AS2传输，接收850采购订单EDI报文，采用自定义XML方案。

直接处理EDI报文

我们来回顾一下直接处理业务报文的步骤：

首先，通过AS2收到850采购订单后，要直接进行处理，完成报文翻译，我们的代码逻辑大约如下：

1. 先读取当前850采购订单报文的内容
2. 对内容进行分割，将850采购订单的内容按照节点分割，例如：ST节点，BEG节点等等，每个节点代表不同的信息
3. 开始逐一读取节点，匹配节点所属的业务含义，并将每个节点中的详细业务数据读取出来
4. 一边读取数据，一边输出自定义XML
5. 调试程序，确认业务逻辑和取值正确

以上步骤中我们可以看出，所有的处理都要使用代码来实现，那么代码量一定是非常大的。同时，因为EDI报文中数据比较多，而且结构复杂，所以代码逻辑也会非常复杂。在初步完成代码之后，后续的业务测试过程中，若是因为对EDI报文理解不到位，想要修改某一部分的处理逻辑或是取值方式，将会造成很大的工作量，而且往往都是牵一发而动全身，修改可能会造成其他本来正确的数据出错。同时，在切换生产环境之后，如果贸易合作伙伴对EDI规范做了某些升级或者调整，后来的维护人员需要将整个的代码整体通读一遍，完全理解之后，才能进行修改。

分步处理EDI报文

如果在目前的知行EDI产品中，我们分多个端口去完成报文翻译，每个端口都只负责各自的功能部分，那么整体步骤如下：

1. AS2端口收到850采购订单后，直接转发到X12端口（直接配置实现）
2. X12端口将EDI报文转换为标准XML，并转发到XMLMap端口（直接配置实现）
3. XMLMap端口通过界面拖拽，并辅以少许简单code，实现转换为自定义XML文件（简单coding）

以上步骤中我们可以看出，通过这种方式，一方面，代码量非常少，大家知道，写的越多，容易出错的地方越多，代码量少了，大部分功能依赖于产品，所以出错概率会降低。如果有EDI报文结构更改或是升级的情况，前两步我们不用做任何修改，只要在最后一步，仅修改需要调整的部分即可。

标准XML文件

在知行EDI系统中，几乎所有的EDI报文处理都是以标准XML文件为媒介的。

XML（可扩展标记语言）是一种标记语言，提供了一种简单，灵活的文本格式。XML描述文档的数据结构，并为所有其他规范提供通用语法。XML的主要应用程序之一就是处理B2B和B2C数据交换。

这是部分EDI报文采购订单和标准XML采购订单:

850 原始EDI文件:

经X12端口标准XML：

我们可以看出，标准XML包含解释每个节点含义的注释。最重要的是，对于标准XML文件，可以直接将其映射到目标格式，而不必查找EDI文档中每个节点的含义，只需参考标准XML文档中提供的说明和贸易伙伴提供的规范即可。

显而易见，在处理EDI报文时，并不是直接对EDI报文进行处理一步到位就更好。先将EDI报文转换为标准XML，再对标准XML进行后续处理存在以下优点：

• 代码逻辑简单，工作量较小

• 可以自动检查贸易合作伙伴传来的EDI报文是否符合国际标准

• 易于调试，进行业务测试

• 易于后期维护

• 易于和其他目标格式文档做转换，比如自定义XML，CSV，PSV，Excel等

• 增加功能模块的独立性，降低耦合性

注：文案部分图片及内容来源于网络，版权归原创作者所有，如有侵犯到您的权益，请您联系我们进行删除，给您带来困扰，我们深感抱歉。