2010-01-19 44 views
2

当某些日期发生或满足某些业务条件时,我们需要能够发送自动电子邮件。我们正在建立这个系统来处理现有的ASP.NET网站。我和其中一位开发者聊了一下,并讨论了一些问题。在ASP.NET中执行批量处理页面

注意事项:

  • 所有我们需要的信息在ASP.NET网站已经建模
  • 有所需的邮件生成这也是该网站的一些业务逻辑已经

我们认为理想的解决方案是安排一个单独的可执行文件,该文件计划在夜间运行并执行处理和电子邮件。该解决方案有两个主要问题:

  • 如果网站被更新(业务逻辑或模式),但可执行文件意外丢失,则可执行文件可以停止发送电子邮件,或者更糟的是,基于过时的逻辑将送给他们。
  • 我们希望使用类似this使用用户控件到模板中的电子邮件,我不相信这是可能的ASP.NET网站

的第一个问题之外本来可以避免与构建和部署脚本(我们现在正在研究),但我认为我们不能解决第二个问题。

因此,我们决定的解决方案是有一个由SSIS定期调用的ASP.NET页面,并执行一定数量的处理(例如30秒)然后返回。我知道ASP.NET页面并不是进行这种处理的理想场所,但这似乎最符合我们的要求。我们考虑产生一个新的线程(不是来自工作者池)进行处理,但决定如果我们这样做了,我们就不能使用返回的页面来表示成功或失败。通过在页面的生命周期内处理,我们可以使用页面内容来指示处理过程如何进行。

所以问题是: 这个设置有什么技术问题吗?

很显然,如果您尝试过这样的事情,任何成功/失败的报告将不胜感激。同样可以提出其他建议。

干杯,

回答

3

不要使用asp.net线程来做到这一点。如果网站正在生成您需要的一些信息以创建或触发电子邮件发送,那么网站会将一些信息写入文件或数据库。

创建一个Windows服务或计划进程,它从该文件或数据库收集所需信息,并在完全独立的进程/线程上运行电子邮件发送进程。

您想避免的是由于流程处理程序中的限制导致您的站点崩溃或电子邮件崩溃。根据您在问题标题中使用“bulk”这个词,两者需要彼此独立。

0

听起来像你应该创建一个工作线程来完成这项工作。

+0

为什么您认为在单独的线程中处理会比在页面生命周期中处理更好?从我的阅读中,只要应用程序在IIS应用程序池中循环使用,您创建的任何线程都会死亡。所以通过将它保持在页面生命周期中,我们希望避免这种情况发生。 – David

0
+0

我相信,如果AppPool被回收(处于非活动状态,或者服务器重新启动),这种类型的系统将停止工作。所以如果你想确保它始终在运行,你需要有一个外部定时系统从你的网站请求一个页面。在这种情况下,你可能会有外部计时器直接触发动作(少一件事就会出错)。 (http://www.codeproject.com/KB/aspnet/ASPNETService.aspx)建议您在第三方可用性检查器上注册您的站点以确保频繁的请求。但我认为这是一个可怕的解决方案。 – David

2

我认为你应该没问题。我们在公司使用类似的方法好几年,并没有遇到很多问题。有时需要一个多小时才能完成该过程。最近我们将第二个线程(如你所说)移动到一个单独的服务器上。

1

把电子邮件和网站耦合在一起可以工作,但它不是一个很好的设计,并且从长远来看将会为您提供更多的维护。你可以通过做一些事情来解决你所说的问题。

  1. 将通用业务逻辑移至Web服务或通用库。您的网站和可执行文件/ WCF服务都可以使用它,并集中了逻辑。如果您正在复制和粘贴代码,则知道存在问题;)

  2. 如果您需要模板邮件程序,可以调用ASP.Net类为您动态创建页面(请参阅BuildManager类,以及blog posts like this one。如果邮件程序不依赖于页面事件(它似乎没有),那么你的可执行文件不应该有任何问题从你的网站程序集加载一个Page类,动态构建它,并填写内容

这显然代表工作显著量,但会导致一个更灵活的解决方案适合你。

0

当某些业务条件满足时,您可以并且应该在域逻辑(它意味着您的asp.net应用程序)中构建消息正文(模板化消息正文),并将其发送给只应发送消息的外部服务。所有消息都会有适当的信息。

对于“当某些日期出现”情况下,你可以使用后台任务简单的解决方案(看克雷格答案),做与上面相同:解析模板,建立信息和快速发送到指定的服务。

当然,你应该这样做安全,然后应用程序池重新启动不会破坏你的任务。