Схема работы каналов коммуникации

Общая структура

При запуске кампании запускается бинарный файл campaign, который:

• обрабатывает шаблон и бизнес-логику (стоп-списки, лимиты, подписки, фильтры и т.д.);
• формирует структуру сообщений для отправки;
• направляет готовые сообщения в очереди RabbitMQ;
• фиксирует ошибки в журнале кампании.

Далее каждое сообщение попадает в соответствующий сервис обработки в зависимости от канала.

---

Email

Для email-канала поддерживается несколько видов сендеров (отправщиков): AKMTA (сендер Altcraft) и внешние сендеры. В зависимости от используемого сендера, схема работы может отличаться.

Процесс отправки

AKMTA

Кампания отправляет сообщения в очереди:

• akmta_<sender_id> — обычная очередь;
• akmta_prior_<sender_id> — приоритетная очередь;
• geo_akmta_<sender_id> — очередь рассылки по часовому поясу. Она приоритетнее обычной очереди, но менее приоритетна akmta_prior. Используется для того, чтобы даже при высокой нагрузке на платформу клиент получал коммуникации в пределах выбранного часа в его часовом поясе.

Из очередей сообщения обрабатывает сервис akmtad. Дальнейшее поведение процесса akmtad зависит от приоритетности сообщения:

• Для неприоритетных сообщений — сохраняет сообщения на диск, периодически читает и отправляет их по стратегии отправки, заданной для конкретного sender_id;
• Для приоритетных — производит попытку немедленной отправки. Если установлены правила повторной отправки, то при неудаче сообщение будет сохранено на диск.

На диске сообщения попадают в очередь spool. Отправка оттуда происходит в соответствии с правилами сендера, платформа "читает" spool с периодичностью равной MTA_EXCHANGE_SCAN_PERIOD. Обратите внимание, что эти сообщения больше не хранятся в RabbitMQ.

Схема отправки выглядит следующим образом:

campaign —> Очередь RMQ (akmta / akmta_prior) —> akmtad —> (при неудаче — запись в очередь spool на диске ) —> SMTP

Остальные сендеры

Отправка происходит от бинарного файла campaign через внешний HTTP-запрос. Если платформа не может отправить сообщение, то регистрируется ошибка кампании. Обратите внимание, что подобная ошибка не засчитывается как "Недоставка" и в отчет по недоставкам не вносится.

Регистрация статусов

AKMTA

Статусы доставки регистрируются сразу по:

• коду ответа SMTP-сервера;
• bounce-паттернам (анализ шаблонов возвратов).

Остальные сендеры (#other-status)

Cтатус события обрабатывают трекинг-сервисы платформы.

Повторная отправка

AKMTA

• Правила повторов задаются отдельно через Панель администратора. О том, как это сделать, можно прочесть в документации администратора;
• В зависимости от SMTP-кода регистрируются статусы hard bounce или soft bounce;
• Для soft и hard bounce правила повторной отправки могут отличаться.

Остальные сендеры

Для остальных сендеров повторные попытки отправки не предусмотрены. В случае ошибки при отправке http-запроса, платформа не производит никаких действий.

---

SMS

Процесс отправки

Кампания отправляет сообщения в одну единую очередь — sms_sender. Затем сервис procintegras рассылает сообщения из очереди. Некоторые шлюзы поддерживают отправку батчем.

Регистрация статусов

Регистрация статуса работает одним из следующих способов:

• Шлюз присылает статус сообщения через вебхук. Статус обрабатывается сервисом procsmslisten;
• Платформа "опрашивает" шлюз. Статус обрабатывается сервисом procsmsev.

Время жизни SMS-сообщения указывается в параметре конфигурации SMS_DEFAULT_TTL (по умолчанию ― 1 сутки). Платформа регистрирует недоставку, если статус не получен в течение этого времени.

Повторная отправка

Повторные отправки SMS-сообщений происходят через 60, 120, 180, 300 и 600 секунд с момента последней неудачной попытки. Максимальное количество попыток — 5.

---

Push

Процесс отправки

Кампания отправляет сообщения в очередь. Очередь зависит от провайдера:

• APNs — apns_push_sender
• Firebase — firebase_push_sender
• Huawei — huawei_push_sender
• RuStore — rustore_push_sender
• Браузерные push Firefox и Safari — web_push_sender
• Прочие push-провайдеры — custom_push_sender

Затем сервис procintegras рассылает сообщения из очереди. Некоторые шлюзы поддерживают отправку батчем.

Регистрация статусов

За обработку статуса браузерных веб-пушей отвечает сервис cookie_saver, который отправляет событие в push_events. Дальнейшая обработка происходит в procpush.

Регистрация статусов для мобильных push происходит схожим образом, главное отличие в том, что обработка асинхронных отправок происходит в очереди push_events, а синхронные сразу обрабатываются сервисом procrpc.

Время жизни push-сообщения указывается в параметре конфигурации MTA_DEFAULT_TTL (по умолчанию — 3 суток). Недоставка регистрируется, если не получен статус в течение этого времени.

Синхронные и асинхронные запросы

Синхронные запросы — те запросы, при которых платформа регистрирует ответ по результату отправки, т.е. платформа ждет ответа на свой запрос.
Асинхронные запросы — те запросы, при которых платформа регистрирует ответ по постановке отправки в очередь, т.е. платформа не ждет ответа на свой запрос.

Повторная отправка

Сендер смотрит на ответ шлюза и на возвращаемые заголовки и, в зависимости от ответа, устанавливает правило повтора. Если в ответе шлюза содержатся конкретные указания (например, шлюз "просит" попробовать заново через 5 минут), то повторная отправка будет выполнена в соответствии с ними. Если ответа нет, или в нем не содержатся точные указания, то срабатывают правила, установленные в конфигурации платформы:

• PUSH_SENDER_RETRY_MAX_AMOUNT — максимальное количество попыток повторной отправки push-сообщений. По умолчанию — 3;
• PUSH_SENDER_RETRY_INTERVAL — время между попытками повторной отправки (в секундах). По умолчанию — 1800;
• PUSH_SENDER_RETRY_SCAN_INTERVAL — периодичность сканирования базы повторных отправок на наличие новых записей (в секундах). По умолчанию — 60.

Подробнее об этих параметрах можно прочесть в документации администратора.

---

Каналы мессенджеров

Процесс отправки

Кампания отправляет сообщения в очередь. Далее сообщения в очереди RabbitMQ обрабатываются в зависимости от канала:

• Telegram Group, Telegram Bot — очередь piper_messages, обрабатывается в procpiper;
• Viber, WhatsApp, Notify — обрабатывается в procintegras.

Регистрация статусов

• Telegram — регистрируется в зависимости от http-ответа Telegram. Доставка регистрируется, если нет ошибок во время отправки в API Telegram. Соответственно, недоставка регистрируется, если платформа получила в ответ ошибку при отправке;
• Viber, WhatsApp, Notify — статусы попадают в платформу через вебхуки. Если во время отправки сообщения получена ошибка, то регистрируется событие недоставки. Статусы "прослушиваются" сервисом trklisten.

Повторная отправка

В данный момент повторные отправки для сообщений в мессенджерах не предусмотрены.

Ограничения по отправкам

Для Telegram действует ограничение в 28 запросов в секунду на один токен. Для Notify по умолчанию установлено ограничение 20 запросов в секунду, значение можно изменить в параметре конфигурации VKNOTIFY_SEND_LIMIT_PER_SECOND, максимально — 50 запросов в секунду.
Для Viber по умолчанию установлен максимум в 50 запросов в секунду, изменяется в параметре VIBER_DEVINO_SEND_LIMIT_PER_SECOND. Для WhatsApp по умолчанию установлено ограничение в 20 запросов в секунду (WHATSAPP_SEND_LIMIT_PER_SECOND); у различных провайдеров могут быть установлены свои ограничения по запросам.