为什么在面对易于使用的技术时仍然使用这种古老的格式？它是否提供了一些我没有看到的好处？似乎大量供应商仍然只提供这种格式的数据,而不是像XML那样更易于管理和更易于使用的东西; 至少我可以提供这两种格式.
此外,除了使用它之外别无选择,有什么好的方法来处理和利用EDI？像BizTalk这样的东西是不可能的,因为它太贵了.是否有任何免费/开源应用程序可以使EDI更易于使用？
一旦您熟悉它使用的分隔符,EDI就不那么难理解了.您可能会问自己为什么还有人会使用CSV或制表符分隔的数据.
答案可能是这些格式是由委员会定义并在某个行业标准化的"领域特定语言",并且已经投入大量资金来支持这些格式.什么是商业案例再次抛出这一切？
一句话,惯性.委员会在各个公司和具有不同议程的组织之间制定EDI格式是一场噩梦(可悲的是我曾经去过那里).
请求他们放弃这些与另一轮委员会同意网络服务API标准将需要更长时间,你如何出售将一种电子格式替换为非技术委员会的想法？它给他们带来了什么可能的公交优势.最初电子交换的好处是明确的,但不能替换另一个.我们在这里谈论真正的大公司.
您可能对以下项目感兴趣:
http://bots.sourceforge.net/en/index.shtml Google代码存档
切换到XML会为您提供什么 - 稍微更容易调试行格式？
通常你设置并离开它,没有太多需要使用原始EDI源,当然不足以放弃标准并重新开始.
有许多标准,比如传真,可以更具可读性,但没有真正迫切需要改变它们.
因为它是一个正式建立的标准(实际上是一套非常庞大和全面的标准).这是标准所声称的好处之一 - 你不需要长时间改变任何东西.
要改变它,需要两个或更多(通常是数千到数千个)贸易伙伴(包括可能所有竞争对手)之间达成一致意见.
EDI格式具有更高的信噪比(因为它们被认为是重要的时候设计的.)知道并理解EDI的人会查看你的XML并说"牛肉(数据)在哪里？"
很少有开发人员编写自己的解析器.有许多优秀的地图制作者(许多遗留和企业应用程序都内置它们).因此,您的痛苦可以得到很多缓解(包括SourceForge上的至少一个开源应用程序).
所有感兴趣的小信息.EDI基本上是委员会数据交换格式的设计,不仅规定了数据格式化规则(如XML),而且还着手定义可能在两家公司之间发送的每个文档.因此,对于可以在公司之间交换的任何数据,他们想出了每个文档中应该包含的内容的确切定义.当然,没有人能预见到2家公司想要交换的每一条数据.因此,您最终会使用为一件事定义的字段的公司,用于其他一些信息.
你最终得到的是一种极其复杂的数据格式,许多使用它的人不遵守标准,因为他们需要发送标准没有考虑的自定义信息.因此,最后,您仍然需要与您想要处理的每个公司进行对话,并找出其实现的所有小特性,就像您去找具有自定义XML接口的人一样.除了在EDI的情况下,格式很难解析,甚至更难写,所以你最后做一大堆工作只是为了发送文档,当做同样的想法与自定义XML解决方案会导致问题少很多次.
"如果没有破产,请不要修理它."
这些组织中的大多数都在使用EDI处理大量数据,并且在没有令人信服的理由的情况下不会更改为更现代的数据.令人遗憾的是,让第三方开发人员轻松搞定通常不符合条件.
恕我直言,EDIFACT有几个问题.
从中解析或生成对象模型并不容易.这可能不再是一个大问题,因为现在有很好的系统为你做这件事,例如smooks.org
这不容易阅读.您已经习惯了,但XML更容易阅读
验证并不那么容易(将其与验证XML进行比较)
有太多不同的版本和口味,D95B,D96B,D00A,D00B等.
但我认为最大的问题是每个人都使用不同的标准.它们使用相同的"格式",但字段的定义不同.我们使用EDIFACT发送和接收来自Container Terminals的消息,它们都有细微的差别.例如,它们都使用D95B CODECO,但对于某些终端,某个段是强制性的,而对于另一个终端,它是可选的,甚至不允许存在.然后,您使用相同的段,但其中的内容是不同的.
总而言之:颈部疼痛.
京公网安备 11010802040832号 | 京ICP备19059560号-6 