отправив письмо, но не сейчас

Question

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

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

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

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

Answer 1

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

Answer 2

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

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

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

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

Наконечник шляпы Робу.

Answer 3

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

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

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

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

Пока вы занимаетесь этим, вам следует подумать об использовании шаблона проектирования команд и реализовать этот сервис в качестве многоразового исполнителя команд. Недавно я сделал это с помощью веб-приложения, которое должно синхронизировать данные о листинге недвижимости (MLS) со сторонним поставщиком.

Answer 4

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

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

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

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

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

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

Answer 5

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

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

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

Answer 6

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

Answer 7

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

Answer 8

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

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