ASP.NET MVC + SQL Server应用程序：发送事件驱动的电子邮件通知的最佳方式

Question

我有一个ASP.NET MVC应用程序，它在后端使用NHiberante和SQL Server 2008。需要每周/每周发送事件驱动的通知和通用通知。

这里是事件驱动的工作流程需要如何工作的一个例子：

1. 员工（S）创造了多项采购订单。
2. 电子邮件通知每天发送给任何一位主管，其下属员工已经下达了采购订单，并列出了需要他批准的下属创建的所有采购订单。主管只应该得到这一次（例如，如果员工A创建了一份采购订单，他的主管每天都不会收到电子邮件，直到他批准为止）。此外，采购订单清单应仅包括主管未采取行动的清单。如果没有采购订单需要特定主管的批准......他们不应该收到电子邮件。
3. 每天向部门经理发送一封电子邮件通知，其中列出所有采购订单，由下级主管以与上述＃2相似的方式批准。
4. 任何时候对主管或部门批准PO采取任何行动。经理，员工应每天收到一封电子邮件通知，列出所有此类更改。如果没有特定员工，他们根本不应该收到电子邮件。

所以给出了这样一个工作流程：

• 什么是安排这样的通知，每天发生的最好办法，每周甚至在事件发生后立即？
• 你如何确保这种事件驱动的通知只能交付一次？
• 您将如何处理例外情况，以确保发送失败的电子邮件尝试被记录下来，并且可以尝试在第二天发送？

谢谢！

Answer 1

您可以在控制器

Function SendEmails() As ActionResult 
    Dim result As String = "" 
    ''//big timeout to handle the load 
    HttpContext.Server.ScriptTimeout = 60 * 10 ''//ten minutes 

    result = DoTheActualWork() 

    ''//returns text/plain 
    Return Content(result) 

End Function 

添加一个正常的操作，然后从计划的任务调用页面。可以是服务器或任何机器上的计划任务。使用此为.vbs：

SendEmails.vbs：

''//Force the script to finish on an error. 
On Error Resume Next 

''//Declare variables 
Dim objRequest 
Dim URL 

Set objRequest = CreateObject("Microsoft.XMLHTTP") 

''//Put together the URL link appending the Variables. 
URL = "http://www.mysite.com/system/sendemails" 

''//Open the HTTP request and pass the URL to the objRequest object 
objRequest.open "POST", URL , false 

''//Send the HTML Request 
objRequest.Send 

''//Set the object to nothing 
Set objRequest = Nothing 

Answer 2

您可以托管Windows工作流程或Windows服务。并设置一个消息队列来处理这些事件。您可能只是将数据库用于消息队列，或者可以使用ms消息队列或在数据库中使用触发器。但这种功能实际上不应该是您的前端Web应用程序的责任。如果push来推，你可以从你的asp.net应用程序中产生另一个线程来处理这个队列。

Answer 3

这可以通过使用SQL Server代理来完成阅读更多关于它在这里：

http://msdn.microsoft.com/en-us/library/ms189237.aspx

Answer 4

听起来像是一个服务或计划任务的任务。

你不想在ASP.NET中这样做，因为你必须配置IIS以保持你的应用程序始终活着，这可能不是最好的主意。

计划任务没问题，但您必须使用解析数据的所有逻辑对其进行编程。不是分离问题的最佳选择。如果有变化，你也必须更新两个代码库。

服务是不理想的，因为它会唯一真正的一次做的事情了一天。但是你可以设置一个wcf服务并让该网站使用该服务排队发送电子邮件。

Answer 5

我会对所有的电子邮件，通知等保存到数据库/表，然后再有一个服务，轮询新条目此数据库或表处理电子邮件/通知的实际发送。

为了满足您的特定情况下，你可以有需要电子邮件/通知时，控制器写入数据库，并已经做了你的时间间隔/事件专项检查也写DB创建新的电子邮件服务。这样，您的应用程序和服务并不真正关心这些通知如何或发生什么，他们只是说，“嘿，做点什么。”而电子邮件/通知服务实际上正在执行。

这样做的好处是，如果您的电子邮件提供商发生故障，您不会丢失任何电子邮件，并且您有发送的所有电子邮件的历史记录，包括何时，谁等的详细信息......您也可以撷取或更改电子邮件发送者做更多事情，如发送到Twitter或电话短信等。这有效地将您的通知从应用程序中分离出来。

我所做的一切应用程序最近使用这种类型的模型，它已停止从邮件丢失，由于服务故障等原因。它还可以查找所有通过系统的电子邮件，并获取指标，使我可以通过在电子邮件记录中存储额外信息（如发送原因，如果报告错误等）来优化发送电子邮件的需求。 ..基于一天中的时间或者用户添加诸如路由通知的添加（例如，转到文本消息而不是电子邮件），但对主要应用程序没有改变。

你的客户可能会觉得今天他们需要的是电子邮件，但你应该确保您的解决方案具有足够的灵活性，允许不仅仅是在未来只有轻微tweeks电子邮件。