为什么工作流中围绕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等

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

了解更多EDI信息,请您电话 177-8250-8152 或邮件 sales@kasoftware.cn 联系我们。点击下方蓝色按钮,即可免费试用EDI软件。

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

标签: , , , , ,
文章分类 帮助文档, 知识库

发表评论