C#中高效的电子数据交换数据库解析
几年前，我们被要求作为紧急事项为客户开发3+解决方案。
他们想要解决方案的完整IP/控制等，而不想使用免费的开源解决方案，不想为BizTalk等支付大笔资金，也不想向面包车支付经常性费用。
我们当时做了一些研究，实际上没有找到很多关于EDI格式，解析等的信息，所以我们的两个人的开发团队直接跳起来，用C#/ASP.Net开发了一个解决方案。由于发生的EDI消息事务数量很少(每天100个左右)，我们采用了RegEx过程进行解析、验证和插入数据库。这是通过一个单独的C#应用程序完成的，该应用程序计划每隔几分钟运行一次，并连接到客户端不同提供商的FTP、AS2、EBMX通信和下载数据，以及上传任何出站电子数据交换消息。
然后我们开发了一个web前端，允许客户员工完全访问各种收入报告的数据，能够控制数据，并允许一些客户代理登录，还可以与数据交互并启动发票交易。
客户现在希望为他们的业务的另一条途径做更多的电子数据交换工作，然而，这一次电子数据交换消息事务将跃升到1000。我们的开发团队关心的是RegEx的使用。我最近读到使用RegEx进行EDI解析有很大的开销，应该避免。
我们最初采用它的唯一原因是缺乏经验，不知道什么是最好的。也就是说，RegEx使管理电子数据交换消息模板变得轻而易举，包括在模板中进行验证。客户已经向他们的账簿中添加了更多的提供者，我们能够在几分钟内添加新的消息模板(具有自定义更改)。
经过最近更多的研究，我们发现大多数解决方案都将EDI文件解析为XML。这是有原因的吗？这仅仅是为了采用更通用的格式和/或避免访问数据库吗？在平面文件EDI消息上解析XML是不是更快？
我们希望EDI文件中的数据元素位于数据库中？我们是否可以直接解析XML文件呢？这不是可以避免的另一个处理步骤吗？
我为我的问题的一般性道歉，但我很难找到答案。
非常感谢您的宝贵时间。
注意:我们的开发团队只使用微软的产品，所以在反馈时请考虑到这一点。
回答 2
Stack Overflow用户
发布于 2013-03-08 23:19:21
我怀疑大多数选择编写自己的解决方案的开发人员都编写了自己的类来进行EDI到XML的转换，因为他们的端点集成支持XML (或者他们不能直接写入数据库，或者希望使用XSLT很好地向最终用户显示数据)。我已经编写了解析器，可以“转换”成CSV和平面文件格式，因为这是我们需要导入的格式。我还编写了解析器来直接转储到数据库中。对于某些人来说，解析成XML通常是一个必要的步骤，因为它是一种“中间件”方法。如果你不需要做中间步骤，那你为什么要做呢？如果你可以把它写到数据库中，那么一定要这样做。您也没有提到您正在做什么文档，我假设您已经在您的应用程序中构建了FA流程。RegEx应该继续为您工作，并且有很多方法可以帮助您脱皮。
话虽如此，我通常的免责声明也适用。你在这里重新发明轮子。以英里为单位。我理解你的客户的意愿，很高兴你能满足我们的需要。坦率地说，我可能会解雇客户:)因为你只使用微软的产品，你有点束缚了自己。环顾四周，BizTalk比其他包更受关注。这可能是有原因的，正如你所发现的，它也是非常昂贵的。我是cost的铁杆粉丝-在Windows上运行，核心使用Microsoft Foundation类，允许您以BizTalk的一小部分成本将any- to -any转换为any-to-any。在我看来，维护拖放“地图”比维护数千行代码更容易，但嘿，策略就是策略:)希望这能有所帮助。
Stack Overflow用户
发布于 2013-03-19 10:19:02
大约3年前，我还创建了一个XML解析器，它将x12电子数据交换解析成x12。它目前在http://x12parser.codeplex.com上是开源的。我这样做的原因是，我希望解析部分不关心目标，无论它是数据库还是平面文件。事实证明，这是有价值的，因为一些用户使用Oracle而不是Sql Server，许多用户将其展平为平面文件，以便加载到他们的数据库中或发送到某个下游进程。我认为这使得解析器本身对于许多环境都非常灵活。我喜欢XML的另一个原因是，我能够添加其他批注，这些批注对于那些没有记住所有EDI代码的人(基本上是每个人)都很有价值，并且我能够使用这些批注将其转换为HTML (参见网站的示例)。我还内置了将对象拆分到单个消息中的功能，以便您的后处理可以一次使用一个对象。很多用户帮助我优化了它，让它可以处理大文件，所以它变得相当稳定。我现在正在对它进行一些维护，以便它可以支持所有4010个事务。关于解析到数据库的部分我留给了用户，因为每个人似乎都对如何设计数据表非常挑剔(例如，我不能同意同事关于是使用into还是GUID来确定表标识，倾向于DBA思维的人更喜欢into，那些使用大量ORM的人更喜欢GUID)。
在我发布这篇文章后不久，我确实添加了数据库支持，因此您可以跳过XML，将其直接转到SqL服务器数据库。你可以决定有多少段类型将被解析成单独的表，这样你就不会因为300个表而膨胀你的数据库，其中你可能只使用10或20个。这里SQL Server as Staging Environment讨论了使用xml或sql server作为你的最终系统的中介的利弊。
https://stackoverflow.com/questions/15291332
复制相似问题
腾讯云开发者
