Электронная почта представляет собой единственный канал интеграции, который уже есть у любой организации. Поставщики присылают туда счета, формы отправляют заявки, оборудование сообщает об ошибках. Автоматизированный приём данных превращает почту из повседневной обязанности в интерфейс: скрипт подключается к ящику, читает новые сообщения и обрабатывает их.
Это старый и недооценённый подход. Альтернатива, при которой каждому контрагенту предлагают внедрить ваш API, обычно просто недоступна. Разберём подходящие задачи, принципы надёжной реализации и ситуации, когда вебхук действительно лучше.
Для каких задач подходит приём почты по IMAP
Такой подход полезен везде, где отправитель не хочет или не может интегрироваться с вашей системой напрямую.
Документы от контрагентов. Счета, заказы на закупку, накладные и выписки приходят во вложениях от организаций, которые никогда не станут подключаться к вашей системе. Нередко вся интеграция сводится к скрипту, который распределяет документы по отправителю и номеру.
Уведомления от оборудования. Многие устройства умеют отправлять только письма: системы резервного копирования, средства мониторинга и старое промышленное оборудование. Приём по IMAP даёт им единую точку сбора сообщений.
Заявки из форм и ответы. Подходит любое решение, которое присылает структурированное сообщение, в том числе уведомления о недоставке и автоматические ответы об отсутствии, если ваша система должна на них реагировать.
Согласование ответным письмом. Ответ «да» может служить отдельным этапом процесса. Программно прочитать такое письмо часто проще, чем разрабатывать интерфейс, в который никто не захочет входить.
Как настроить надёжную обработку
Сам механизм приёма писем довольно прост. Надёжность обеспечивается несколькими архитектурными решениями.
Выделите отдельный почтовый ящик. Не папку внутри личного ящика и не общий ящик, где те же письма читает человек. С отдельным адресом пользователь не нарушит логику скрипта, случайно наводя порядок. У нас это не требует дополнительных расходов, поскольку плата за каждого пользователя не взимается.
Используйте отдельные учётные данные только для этой задачи. Не подключайтесь под личной учётной записью сотрудника. Если данные скрипта утекут или их понадобится сменить, последствия должны касаться только скрипта.
Перемещайте обработанные сообщения, а не удаляйте их. Папка «Обработанные» сохраняет журнал действий и позволяет повторно запустить обработку после исправления ошибки. При удалении любая ошибка становится необратимой, а ошибки обязательно будут.
Учитывайте повторное поступление одного сообщения. Повторные попытки, переподключения и повторная обработка случаются всегда. Используйте Message-ID как ключ и пропускайте уже встречавшиеся письма. Тогда дубликат не испортит данные, а просто не вызовет никаких действий.
Сразу сообщайте о сбоях. Если скрипт перестал читать ящик, этого никто не заметит, пока не спросит, куда пропали счета. Система должна подавать сигнал не только при ошибке, но и если обработка давно не запускалась.
Почему IMAP хорошо подходит для этой задачи
Автоматическая обработка работает через IMAP, поскольку этот протокол представляет собой полноценный удалённый доступ к структуре почты, а не просто средство загрузки сообщений.
Можно искать на сервере, сначала получать только заголовки и лишь затем решать, загружать ли тело письма, перемещать сообщения между папками и устанавливать флаги. Для этого не нужно скачивать весь ящик. Скрипт обрабатывает только необходимое и не расходует лишние ресурсы, что особенно важно для ящика с многолетней историей.
Главное преимущество IMAP заключается в повсеместной поддержке. Библиотеки есть для любого языка, протокол не меняется так, чтобы ломать существующие решения, а написанный сегодня скрипт будет работать и через десять лет. Большинство API отдельных поставщиков не дают такой гарантии.
Полезно знать: бесплатный тариф включает IMAP, поэтому ящик, предназначенный только для приёма данных, вообще ничего не стоит. Он не может отправлять письма. Если система должна программно отвечать, потребуется платный тариф или отдельный SMTP-профиль.
Стоимость эксплуатации
Расходы обычно оказываются неожиданно низкими.
Для приёма данных используется обычный ящик, а их количество ограничивается уровнем тарифа, а не оплачивается по отдельности. Поэтому добавление двенадцатого адреса не увеличивает стоимость. Именно благодаря этому отдельный ящик для каждого источника становится практичным, а не расточительным решением. Фактическими затратами остаются место в общем хранилище и время на устранение неполадок.
По сравнению с платформами, где оплачивается каждый пользователь, это меняет архитектурный выбор. Там все потоки часто помещают в один перегруженный ящик, поскольку каждый новый адрес стоит денег. Скрипту приходится разделять несколько никак не связанных потоков. Здесь самый дешёвый вариант одновременно оказывается самым понятным.
Когда вебхук лучше
Чёткое понимание этой границы поможет не построить неподходящее решение.
Если контрагент предлагает вебхук, используйте его. Отправка события превосходит периодический опрос по задержке, надёжности и ясности. Вы получаете структурированные данные сразу после события, а не обнаруживаете его при следующей проверке и затем разбираете текст. Приём данных из почты нужен как запасной вариант, когда вебхука нет.
У опроса также есть разумный минимальный интервал. Проверять ящик каждую минуту допустимо, каждую секунду чрезмерно, поэтому сервер ограничит частоту запросов. Если данные действительно нужны в реальном времени, электронная почта не подходит независимо от способа чтения.
Разбирать письма, написанные людьми, тоже бесперспективно. Надёжно извлечь номер заказа на закупку из машинного сообщения можно. Понять намерение человека по свободному тексту нельзя. Процесс, который от этого зависит, будет постоянно порождать немногочисленные, но неизбежные ошибки, которые невозможно полностью устранить.
Масштабирование за пределы одного ящика
Приём данных из почты хорошо масштабируется, а подходящая схема зависит от количества потоков.
Для нескольких источников понятнее всего выделить по ящику на каждый из них. Каждый скрипт читает собственный адрес, и изменение одного потока не влияет на остальные. Поскольку количество ящиков ограничивается тарифом, а не оплачивается отдельно, двадцать адресов для обработки стоят столько же, сколько один.
Для множества однотипных источников лучше подходит один ящик с catch-all, то есть сбором всей почты домена. Адреса invoice-acme@ и invoice-globex@ ведут в один ящик, а сам адрес содержит сведения, необходимые скрипту для маршрутизации. Это тот же приём, что и отдельный псевдоним для каждой регистрации, только применённый к машинам вместо поставщиков.
При действительно большом объёме помните, что хранилище общее. Ящик с постоянно накапливающимися вложениями будет быстро расходовать место. Поэтому квоту и политику хранения нужно заложить в архитектуру заранее, а не обнаружить необходимость позже. Подробнее об этом рассказано в статье про квоты почтовых ящиков.
