отправка электронной почты, но не сейчас

Question

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

Я в ASP.NET (2.0) на MS SQL. Непосредственный адрес электронной почты не проблема, но я не уверен, как лучше всего обратиться к электронному письму с напоминанием. В принципе, я могу думать о трех подходах:

1. Настройте SQL-задание, которое выполняется каждую ночь, начиная с электронных писем SQL для людей, у которых есть встречи в этот день.
2. Как-то отправить электронное письмо с флагом «не доставлять раньше», хотя это похоже на то, что я могу придумать.
3. Напишите еще одно приложение, которое запускается в определенное время каждую ночь.

Я пропустил что-то очевидное? Как я могу это сделать?

Answer 1

Выбор № 1 будет лучшим вариантом, создайте таблицу писем для отправки и обновите таблицу при отправке каждого письма. Также лучше не удалять запись, а отмечать ее как отправленную, вы никогда не знаете, когда у вас будет проблема в будущем, и вы хотите повторно отправить электронные письма, я видел, как это случалось много раз в похожих настройках.

Answer 2

Ваш вариант 2, безусловно, кажется чем-то, что вы изобретаете. Я знаю, что почтовая система моей не будет содержать сообщения для будущей доставки, если вы хотите отправить мне что-то подобное.

Я не думаю, что вам не хватает ничего очевидного. Вам понадобится то, что запускает день назначения для отправки электронных писем. Может ли быть лучше, чем SQL-задание или отдельное приложение, зависит от вашей архитектуры приложения.

Answer 3

Я бы порекомендовал первый вариант, используя SQL или другое приложение для автоматического запуска каждый день для отправки электронной почты. Это просто, и это работает.

Answer 4

У Microsoft Office есть функция задержки доставки, но я думаю, что это вещь Outlook, а не вещь Exchange/Mail Server, поэтому вам придется идти с опцией 1 или 3. Или вариант 4 будет состоять в том, чтобы напишите услугу. Таким образом вам не придется беспокоиться о запланированных задачах, чтобы запустить приложение с параметром 3.

Answer 5

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

Вы можете ввести уровень абстракции через MSMQ как для начального, так и для напоминания по электронной почте - и иметь сервис, подметающий очередь по расписанию. Исходное сообщение может быть помечено атрибутом, который означает «ОТПРАВИТЬ СЕЙЧАС» - сообщение напоминания может быть помечено как «РАСПИСАНИЕ» - и подметальная машина просто должна отправить любые сообщения, которые он находит, которые относятся к «ОТПРАВИТЬ СЕЙЧАС» или которые «SCHEDULED» и иметь toBeSentDate> = текущую дату. Как только сообщение будет успешно отправлено - блок работы можно завершить, удалив сообщение из очереди.

Этот подход гарантирует, что сообщения не будут потеряны, и позволяет распределять нагрузку в нерабочие часы, настраивая интервал опроса службы.

Как отмечает Роб Уильямс, мое предложение о MSMQ немного переборщило по этому конкретному вопросу ...но это жизнеспособный подход, чтобы иметь в виду, когда вы начинаете рассматривать проблемы масштаба - и вы хотите (или необходимо) минимизировать/уменьшать активность чтения/записи базы данных (особенно в периоды пиковой обработки).

Hat наконечник для Роб.

Answer 6

Для каждого крупного проекта я обычно создаю службу, которая выполняет регулярные или периодические задачи.

Служба обновляет свой статус и время последнего выполнения где-то в базе данных, чтобы информация была доступна для приложений.

Например, приложение заносит команды в очередь команд, а служба обрабатывает их по расписанию.

Я считаю, что это решение проще в обращении, чем задачи или задания SQL Server, поскольку это всего лишь одна служба, которую требуется установить, вместо того, чтобы гарантировать, что все необходимые задания настроены правильно.

Кроме того, поскольку служба написана на C#, у меня есть более мощный язык программирования (плюс библиотеки) под рукой, чем T-SQL.

Если это действительно чистый материал T-SQL, который необходимо обработать, будет храниться хранимая процедура Execute_Daily, которую служба будет вызывать при изменении даты.

Answer 7

Создайте отдельное пакетное обслуживание, как предложили другие, но используйте его для отправки ВСЕХ писем.

Веб-приложение должно записать необходимость отправки уведомлений в таблицу базы данных, как для немедленного уведомления, так и для напоминания, с обоими записями, аннотированными желаемой датой отправки/временем.

Использование MSMQ - излишний - у вас уже есть база данных и простое приложение. По мере роста сложности MSMQ или что-то подобное может помочь в этой сложности и масштабируемости.

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

В то время как вы находитесь на нем, вам следует рассмотреть возможность использования Command design pattern и реализовать эту службу в качестве исполняемого исполнителя многократного использования. Я сделал это недавно с веб-приложением, которое должно поддерживать данные о листинге на рынке недвижимости (MLS), синхронизированные с сторонним поставщиком.

Answer 8

Если вы планируете разместить это приложение в недорогом хостинговом сервисе (например, GoDaddy), то то, что я рекомендую, - это открутить рабочий поток в Global.asax на Application_Start и заснуть, проснуться , отправлять письма, спать ...

Поскольку вы не сможете что-то запустить на машине SQL Server, и вы не сможете установить свою собственную услугу.

Я делаю это, и он отлично работает.