是否通过电子邮件(作为附件)发送要由SQL Server 2005分析的InfoPath表单?

更高版本的SQL Server能够在其中运行.NET代码,因此,您可以从SQL Server中轮询邮箱并处理一个InfoPath表单。但是,我不确定我会这样做。

最好考虑编写一个能完成这项工作的Windows服务。Windows服务将启动,检查“服务帐户”的邮箱,读取邮件,提取附件,处理XML,最后将数据写入SQL。如果出现业务规则或验证错误,它可能也会对该邮件作出确认或错误的响应。

我不确定是否会将上述所有逻辑都放到SQL中——首先,我怀疑您的帐户有问题(必须让运行SQL的帐户能够访问Exchange邮箱帐户)。

您的里程可能会有所不同,您应该对此进行原型设计,以确定什么最适合您,但我会尝试将使用Exchange作为“工作队列”的代码与SQL分开,并且只将处理将数据写入SQL表的代码放在SQL中。

我不会使用你上面概述的方法。在我看来,有几种方法比让SQL Server查看Exchange邮箱更可取。您提出的一个重要要求是允许InfoPath表单在脱机模式下工作。我认为项目的“脱机模式”和“数据传输”部分是两个截然不同的独立部分:1)表单和数据应存储在客户端,直到可以连接到Internet;2)一旦连接可用,表单和数据应传输到服务器。

您可以将您的InfoPath表单设置为直接提交到SQL Server,并完全绕过Exchange“中间人”。在设计表单时,InfoPath中的设置非常直接:1)为连接启用“提交数据”,2)配置提交选项。这个 article 有关于如何做的细节。此外,您与SQL Server的连接可能设置为脱机使用,正如本文所讨论的那样。 article .这种方法唯一需要注意的是,您可能需要更改数据库模式来支持它。

另一种方法是让您的InfoPath表单提交到SQL Server 2005 HTTP端点。InfoPath客户端只是一个美化的XML编辑器,HTTP端点基本上是Web服务的不同名称。您将在HTTP端点处的表单数据接收到一个临时表中,在该表中,数据存储为XML,然后可以从该临时区域对该数据进行解析。但是,您仍然需要设置供脱机使用的InfoPath连接。这种方法的主要注意事项是,微软将放弃SQL Server 2008中的HTTP端点,转而支持WCF。

我建议的另一种方法是使用WCF本身来从InfoPath客户端接收XML表单数据。这种方法要求您在设计时将表单的数据源连接到WCF Web服务,然后设置表单以供脱机使用。

我希望这对你有用,至少能为你指明正确的方向。

我见过类似的项目,它们在客户端使用了一个Express版本,在Express中保存了InfoPath(或应用程序数据),并使用Service Broker将其传递到Center,因为SSB与邮件的传递语义是有保证的。这使您可以更容易地向它销售全SQL解决方案,并且不需要在服务器上进行轮询。另外,您将不必处理MIME解析,而是直接进行XML处理。不过,这并不是为了让心脏衰弱的人,让SSB启动和运行是一个挑战。 如果您决定使用邮件传递,那么可以说外部服务更容易构建、调试和故障排除。对于以下问题,您应该有一个更好的答案: -如何保持邮件出列操作和表写入操作的一致性?您的组件必须将Exchange读/删除和SQL插入结合到一个分布式事务中。 -您的逻辑是否准备好处理出现故障的InfoPath文档?邮件传输绝对不能保证交货顺序,因此您可能会在“订单创建”文档之前看到“订单删除”文档。 -如何检测丢失的文档(不是通过邮件发送)?你打算实现一个发送者序列号并最终在邮件上重新设计TCP吗? -您的处理是否允许并行处理相关文档?如果线程1从同一发送方获取文档1,线程2从同一发送方获取文档2,并且文档2与文档1相关(即引用相同的业务事务),那么在数据库写入时会发生什么?它会死锁吗?会释放一个更新吗?会回滚一个更新吗?

前面的桥下有很多龙…