Не так давно пришлось дорабатывать одну самописную конфигурацию, созданную на базе платформы «1С:Предприятие 8». Конфигурация достаточно простая и одна из самых ее «тяжелых» функций – отправка писем клиентам. Клиентов достаточно много, и в день нужно отправлять по 50-100 писем в автоматическом режиме. Например, в базе произошло какое-то важное событие по клиентскому договору и нужно оперативно известить об этом клиента на email.
Разработчик, создавший эту конфигурацию, сделал все максимально просто – написал отдельную обработку и экспортную функцию, которая формировала письма и сразу же их отправляла. Все бы хорошо, но у клиента стали происходить внештатные ситуации вроде отключения интернета и периодической недоступности почтового сервера. Автор обработки об этом явно не думал, поэтому если возникла какая-нибудь проблема, то важное для клиента письмо не отправлялось.
Владелец этой разработки долго с этим мирился, но когда потребители услуг подняли бунт, спохватился и решил в срочном порядке найти разработчика, способного решить зоопарк накопившихся проблем.
Сначала он обратился в местный “Франчайзи” (вроде как солидно), но там поставили неутешительный диагноз и запросили кругленькую сумму за исправления. Вторым вариантом было предложение внедрить новую готовую конфигурацию с необходимой адаптацией. Не знаю, чем они думали, но этот способ потребует значительно больше затрат (как временных, так и финансовых). К тому же имеющееся приложение вполне хорошо решает задачи заказчика, поэтому внедрение нового продукта, на мой взгляд, совершенно неоправданно.
Мое решение
Детально изучив работу ключевых алгоритмов, я пришел к выводу, что решить проблемы клиента можно достаточно просто. Всего-то нужно добавить один регистр сведений для хранения сформированных писем и одно регламентное задание для периодической проверки наличия новых писем. Появились новые письма – соединяемся один раз с сервером и выполняем их последовательную отправку.
В регистре сведений я предусмотрел измерение “Статус”, которое определяет возможные статусы писем: готово к отправке и отправлено. Каждое новое письмо добавляется в регистр, и ему присваивается статус “Готово к отправке”. Регламентное задание выбирает все письма с этим статусом и последовательно выполняет отправку через сервер. Если проблем с отправкой не возникло, то статус письма изменяется на “Отправлено”. Таким образом, это письмо больше не попадет в список на отправку.
Отсутствие интернета или недоступность почтового сервера больше не вызывает проблем, т.к. в случае ошибки ничего страшного не произойдет. Статус письма не изменится, и повтор отправки будет выполнен позже.
Предложенное мной решение хорошо сказалось на производительности. Раньше отправка инициировалась пользователем (в некоторых случаях), из-за чего ему приходилось долго наблюдать на застывшее приложение. Платформе требуется время на установку соединения с сервером и передачу письма.
Пользователю больше не нужно ждать, пока произойдет соединение с сервером. Данные для отправки должны лишь добавиться в регистр сведений, а дальше будет действовать регламентное задание.
Решение достаточно элегантное, и его без проблем можно масштабировать. Например, добавляем дополнительное измерение в регистр сведений (пусть это будет «ВидТранспорта») и дорабатываем механизм передачи данных. Таким образом, добавить поддержку отправки сообщений посредством SMS — дело пары часов (все зависит от степени готовности модуля взаимодействия с SMS-провайдером).
Проблемы заказчика я решил за каких-то 4 часа, соответственно, он отделался минимальным бюджетом. Если сравнивать с предложением от “Франчайзи”, то сумма получилась просто смешной.