黎平网站建设,关闭wordpress注册邮件,手机app开发上市公司,梧州网站建设公司经常有客户问起#xff0c;为什么在处理EDI文件时不一次到位#xff0c;而需要使用多个端口来分次进行处理呢#xff0c;是不是想要多占用几个端口好多卖钱呀#xff1f;
实际上#xff0c;在一开始的知行EDI产品中#xff0c;功能还没有这么完善#xff0c;当时只支持…经常有客户问起为什么在处理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
...
BEG typeSegment!--Transaction Set Purpose Code--BEG01
!--Original--00/BEG01
!--Purchase Order Type Code--BEG02
!--Dropship--DS/BEG02
!--Purchase Order Number--BEG030476696888/BEG03
!--Release Number--BEG04 xsi:niltrue/
!--Date--BEG0520150708/BEG05
/BEG
REF typeSegment
!--Reference Identification Qualifier--REF01!--Sales Region Number--SB/REF01
!--Reference Identification--REF02ZZ11/REF02
/REF
...
我们可以看出标准XML包含解释每个节点含义的注释。最重要的是对于标准XML文件可以直接将其映射到目标格式而不必查找EDI文档中每个节点的含义只需参考标准XML文档中提供的说明和贸易伙伴提供的规范即可。
显而易见在处理EDI报文时并不是直接对EDI报文进行处理一步到位就更好。先将EDI报文转换为标准XML再对标准XML进行后续处理存在以下优点 代码逻辑简单工作量较小 可以自动检查贸易合作伙伴传来的EDI报文是否符合国际标准 易于调试进行业务测试 易于后期维护 易于和其他目标格式文档做转换比如自定义XMLCSVPSVExcel等 增加功能模块的独立性降低耦合性
阅读原文
