Приложение ASP.NET MVC + SQL Server: лучший способ отправки уведомлений по электронной почте, связанных с событиями

Question

У меня есть приложение ASP.NET MVC, использующее NHiberante и SQL Server 2008 на сервере. Существуют требования для отправки и событийных сообщений на ежедневной/еженедельной основе И общее уведомлений еженедельно.

Вот пример того, как рабочий процесс событийного должен работать:

1. Сотрудник (ы) создать несколько заказов на поставку.
2. Уведомление по электронной почте ежедневно отправляется любому руководителю с подчиненным сотрудником, который сделал заказ на поставку со списком всех заказов на покупку, созданных подчиненными, которые требуют его одобрения. Надзорный орган должен получить это только один раз (например, если сотрудник А создает ПО, его руководитель не должен получать электронное письмо КАЖДЫЙ ДЕНЬ, пока он не одобрит его). Кроме того, список заказов на поставку должен ТОЛЬКО включать те, которые надзорный орган НЕ предпринял. Если заказы на покупку не требуют одобрения данного руководителя ... они не должны получать электронное письмо.
3. Уведомление по электронной почте отправляется ежедневно в Департамент. Менеджеры со списком всех заказов на закупку УТВЕРЖДЕНО подчиненными супервизорами аналогично # 2 выше.
4. Каждый раз, когда принимаются какие-либо меры в отношении одобрения ПО руководителем или отделом. менеджер, сотрудник должен ежедневно получать уведомление по электронной почте, содержащее ВСЕ такие изменения. Если для данного сотрудника нет никого, они не должны получать электронное письмо вообще.

Поэтому, учитывая такую ​​последовательность действий:

• Что это лучший способ планировать такие уведомления происходят ежедневно, еженедельно или даже сразу после возникновения события?
• Как бы вы гарантировали, что такие уведомления, связанные с событиями, будут доставлены только один раз?
• Как бы вы обрабатывали исключения, чтобы гарантировать, что неудачные попытки отправить электронную почту регистрируются и чтобы можно было попытаться отправить следующий день?

Спасибо!

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 или использовать триггеры в базе данных. Но такая функциональность действительно не должна нести ответственность за ваше веб-приложение переднего конца. Если нажатие нажимает, вы можете запустить другой поток в приложении asp.net для обработки этой очереди.

Answer 3

Это может быть сделано с помощью агента SQL Server прочитать об этом здесь:

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

Answer 4

Похоже, работа для службы или запланированного задания.

Вы не хотите делать это в ASP.NET, потому что вам нужно настроить IIS, чтобы поддерживать ваше приложение в течение всего времени, что может и не быть лучшей идеей.

Запланированная задача в порядке, но вам придется запрограммировать ее со всей логикой для разбора ваших данных. Не лучшее для разделения проблем. Также вам придется обновить две базы кода, если что-то изменится.

Служба не идеальна, так как она действительно будет делать что-то один раз в день. Но вы можете настроить службу wcf и настроить электронную почту на веб-узле с помощью службы.

Answer 5

Я бы все ваши электронные письма, уведомления, и т.д., сохраненные в БД/таблице первого, а затем иметь услугу, опросы новых записей в эта база данных или таблица, которая обрабатывает фактическую отправку электронной почты/уведомление.

Для решения конкретных ситуаций вы можете иметь контроллеры для записи в БД, когда требуется уведомление по электронной почте/уведомлению, а также служба, которая выполняет проверку интервалов/событий, также записывает в БД для создания нового сообщения электронной почты. Таким образом, ваше приложение и сервис действительно не заботятся о том, как и что происходит с этими уведомлениями, они просто говорят: «Эй что-то делай». и служба электронной почты/уведомления фактически выполняет эту реализацию.

Преимущество этого в том, что если ваш провайдер электронной почты не работает, вы не потеряете никаких писем, и у вас есть история всех электронных писем, отправленных с их подробностями о том, когда, кто и т. Д. Вы также можете вырвать или измените почтовый клиент, чтобы сделать больше, например, отправить в Twitter или текстовое сообщение телефона и т. д. Это эффективно отделяет ваши уведомления от вашего приложения.

Все приложения, которые я недавно использовал, используют этот тип модели, и он потерял электронные письма от потери из-за сбоев службы и других причин. Он также позволил найти все электронные письма, которые прошли через систему, и получить показатели, которые позволяют мне оптимизировать необходимость отправки электронных писем, сохраняя дополнительную информацию в записи электронной почты, например, отправленную причину, если она сообщает об ошибке и т. Д. .. Добавление дополнительных дополнений, таких как уведомления о маршрутизации (например, переход на текстовое сообщение вместо этого, если электронная почта) в зависимости от времени суток или пользователя, возможно без изменений основного приложения.

Ваш клиент может подумать, что все, что им нужно, это электронная почта сегодня, но вы должны убедиться, что ваше решение достаточно гибкое, чтобы в будущем было больше, чем просто электронная почта, с небольшими твиками.