他们想要解决方案的完整IP /控制等，并且不想使用免费的开源解决方案，为BizTalk等支付大笔款项或者向VAN支付经常性费用。
我们当时做了一些研究，实际上没有找到很多关于EDI格式，解析等的信息，所以我们的2人开发团队直接跳进去开发了C＃/ ASP.Net的解决方案。由于将要发生的EDI消息事务数量很少（每天100个左右），我们采用了RegEx过程来解析，验证和插入数据库。这是通过一个单独的C＃应用程序完成的，计划每隔几分钟运行一次，并连接到客户端各种提供商FTP，AS2，EBMX通信和下载数据，以及上传任何出站EDI消息。
然后，我们开发了一个Web前端，允许客户员工使用各种收入报告完全访问数据，控制数据的能力以及允许一些客户端代理登录并与数据交互也启动发票交易。
客户现在想要为其业务的另一条途径完成更多EDI工作，但是，这次edi消息交易将跃入1000年代。我们的开发团队关注的是RegEx的使用。我最近读到，使用RegEx进行EDI解析会产生巨大的开销，应该避免使用。
我们首先采用它的唯一原因是缺乏经验，不知道什么是最好用的。也就是说，RegEx使管理edi消息模板变得轻而易举，包括模板内的验证。客户已在其图书中添加了多个提供商，我们可以在几分钟内添加新的消息模板（包含自定义更改）。
经过最近的研究，我们发现大多数解决方案都将EDI文件解析为XML。是否有一个原因？这只是采用更常见的格式和/或避免数据库访问吗？在平面文件EDI消息上解析XML是否更快？
我们希望EDI文件中的数据元素在数据库中吗？我们只是解析XML文件吗？这不仅仅是可以避免的另一个处理步骤吗？
我为我的问题的一般性质道歉，但我很难找到答案。
非常感谢你的时间。
注意：我们的开发团队仅使用Microsoft产品，因此在提供反馈时请将此考虑在内。
答案 0 :(得分：10)
大约3年前，我还创建了一个x12解析器，它将x12 edi解析为xml。它目前在http://x12parser.codeplex.com以开放源代码的形式提供。我这样做的原因是我希望解析部分不关心目标，无论是数据库还是平面文件。事实证明这是有价值的，因为一些用户使用Oracle而不是Sql Server，并且许多用户将其扁平化为平面文件以加载到他们的数据库或发送到某个下游进程。我认为这使得解析器本身在许多环境中都非常灵活。 我喜欢XML的另一个原因是因为我能够添加其他注释，这些注释对于没有记住所有EDI代码的人（基本上每个人）都很有价值，并且我能够将其转换为HTML（请参阅网站）例如）带有那些注释。 我还建立了将对象解包为单个消息的能力，以便您的后期处理可以一次消耗一个对象。 很多用户帮助我优化它以便它可以处理大量文件，因此它非常稳定。我现在正在对它进行一些维护，以便它将支持所有4010个交易。 关于解析到数据库的部分我留给用户，因为每个人似乎都非常关注他们如何设计数据表（例如，我不同意同事是否使用int或GUID表格身份，那些倾向于DBA心态的人更喜欢整体，那些使用大量ORM的人更喜欢GUID。）
发布此消息后不久，我确实添加了数据库支持，因此您可以跳过XML并将其直接转到SqL Server数据库。您可以决定将多少段类型解析为单个表，这样您就不会在300个表中膨胀您的数据库，其中您可能只使用10或20.这里有一个讨论SQL Server as Staging Environment使用xml或sql server作为最终系统的中介的优点和缺点。
答案 1 :(得分：4)
我怀疑大多数选择编写自己的解决方案的开发人员都编写了自己的EDI到XML转换类，因为他们的端点集成支持XML（或者他们不能直接写入db，或者想使用XSLT来显示最终用户数据很好）。我已经编写了“翻译”成CSV和平面文件格式的解析器，因为这是我们需要导入的。我还编写了解析器直接转储到数据库中。解析为XML通常代表了某些人作为“中间件”方法的必要步骤。如果你不需要做中介步骤，那你为什么要这样做？如果您可以将其写入数据库，请务必这样做。你也没有提到你正在做什么文件，我假设你已经在你的应用程序中建立了FA过程。 RegEx应该继续为你工作，并且有很多方法可以让猫皮肤美化。
据说，我通常的免责声明适用。你在这里重新发明轮子。英里。我理解客户的意愿，很高兴您能满足需求。坦率地说，我可能会解雇客户端:)因为你只使用微软的产品，所以你自己也有点麻烦。环顾四周，BizTalk比其他软件包更受欢迎。这可能是有原因的，正如你所发现的那样，它也非常昂贵。我是Liaison Delta的忠实粉丝 - 在Windows上运行，使用Microsoft基础类作为核心，允许您以BizTalk的一小部分成本翻译任意对任意。在我看来，保持拖放“地图”比维护数千行代码更容易，但是嘿，策略是政策:)希望这会有所帮助。