Переход с HTTP API на SMPP требует поэтапной настройки: сначала сравните форматы сообщений, затем поднимите отдельное SMPP-подключение, проведите тестовые отправки и только после этого переключайте трафик. В статье разберём миграцию для малого бизнеса в Беларуси: какие параметры проверить, как обработать подтверждения доставки DLR, где оставить HTTP API на время перехода и как откатиться при ошибке.
Когда бизнесу нужен переход с HTTP API на SMPP?
HTTP API удобно подключить к сайту или внутренней программе: приложение отправляет HTTP-запрос, получает ответ сервера и продолжает работу. Такой вариант подходит для небольшого объёма сообщений и простого сценария уведомлений. Когда трафик растёт, появляется потребность в постоянном соединении, контроле очереди и более подробной работе со статусами, SMPP становится отдельным вариантом для интеграции.
SMPP особенно уместен, если приложение отправляет большой поток транзакционных SMS: коды подтверждения, уведомления о заказе, напоминания о записи или сообщения о платеже. Протокол поддерживает двусторонний обмен с SMS-платформой. Через него можно отправлять сообщения и принимать отчёты о доставке, а при подходящей настройке также получать входящие SMS.
Решение о миграции лучше принимать после проверки текущего HTTP API. Зафиксируйте, какие поля использует приложение: номер получателя, текст, имя отправителя, внутренний идентификатор сообщения, время отправки и статус. Если система сейчас считает успешным сам факт принятия HTTP-запроса, это ещё не подтверждает доставку SMS абоненту. Для понимания DLR полезен отдельный разбор статусов доставки SMS в SMPP.
| Критерий | HTTP API | SMPP |
|---|---|---|
| Подключение | Отдельный запрос на каждую операцию или группу операций | Постоянная сессия между приложением и SMS-платформой |
| Контроль обмена | Результат приходит в HTTP-ответе | Приложение получает ответы протокола и отдельные DLR |
| Очередь сообщений | Часто реализуется внутри приложения или API-поставщика | Можно управлять отправкой через последовательность SMPP-операций |
| Миграция | Исходная схема уже работает | Нужно настроить bind, кодировку, идентификаторы и обработчики статусов |
Как подготовить HTTP-интеграцию к миграции?
Начните с карты текущего процесса. Для каждого типа SMS запишите, какое событие запускает отправку, откуда берётся номер, какой текст формируется и где система сохраняет результат. Отдельно отметьте повторные попытки. Без такой схемы после переключения трудно понять, потерялось ли сообщение в приложении, очереди или на этапе передачи провайдеру.
Сохраните исходный идентификатор сообщения. В SMPP для сопоставления отправки и DLR используется message_id, который возвращает SMS-платформа. В базе данных удобно хранить его рядом с внутренним ID заказа или операции. Тогда обработчик отчёта сможет найти нужную запись даже при задержке доставки.
Подготовьте единый внутренний статус. Например, приложение может различать «создано», «передано в SMPP», «доставлено», «не доставлено» и «истёк срок ожидания». Названия не принципиальны. Важно, чтобы временный ответ submit_sm не смешивался с финальным результатом доставки.
До запуска запросите у SMPP-поставщика параметры подключения: адрес и порт, логин, пароль, тип bind, допустимое количество одновременных соединений, правила отправки имени отправителя, формат DLR и ограничения скорости. Эти данные нельзя угадывать по документации другого сервиса. От них зависит код подключения и обработка ошибок.
Как настроить SMPP-подключение и кодировку?
Для исходящей отправки приложение обычно открывает TCP-соединение и выполняет bind_transmitter либо bind_transceiver. В режиме transmitter система отправляет SMS, а в режиме transceiver может также принимать DLR и MO-сообщения через ту же сессию. Подходящий режим зависит от параметров поставщика и архитектуры приложения.
После bind приложение должно поддерживать соединение. SMPP использует enquire_link для проверки доступности сессии, а на ответ сервера нужно реагировать в пределах настроенного тайм-аута. При разрыве соединение открывают заново с ограниченной задержкой между попытками. Бесконечный цикл мгновенных переподключений создаёт лишнюю нагрузку и затрудняет диагностику.
Проверьте кодировку до отправки первой рабочей партии. Для латиницы и кириллицы применяются разные значения DCS: в документации МТС для интеграции по SMPP указаны DCS 0x03 для латинского текста и DCS 0x08 для кириллицы (МТС Поддержка для бизнеса). Если сообщение не помещается в один сегмент, приложению нужно корректно формировать составное SMS и учитывать длину текста в выбранной кодировке.
Имя отправителя, номер назначения и текст передавайте в формате, который согласован с поставщиком. Ошибка в source_addr, неверный TON/NPI или неподдерживаемый формат номера приводит к отказу ещё до передачи SMS оператору. В журнале сохраняйте команду и код результата без паролей и других секретов подключения.
Как провести тестовую отправку?
Сначала отправьте тестовое сообщение на один разрешённый номер. Проверьте четыре результата: bind прошёл, submit_sm вернул успешный ответ, DLR пришёл в обработчик, а внутренний статус изменился. Затем повторите тест с кириллицей, длинным текстом и несколькими параллельными сообщениями.
Тестируйте также отрицательные сценарии. Укажите некорректный номер, временно остановите обработчик DLR, разорвите соединение и проверьте повторную отправку. Система не должна создавать дубликат, если ответ на submit_sm потерялся, но сообщение уже принято платформой. Для этого нужен устойчивый идентификатор операции и понятное правило повторов.
Как перенести трафик без потери сообщений?
Безопаснее запускать SMPP параллельно с HTTP API. Сначала приложение формирует сообщение в общей очереди, затем отдельный отправитель выбирает канал. На тестовом этапе через SMPP проходит ограниченная доля очереди, а HTTP API остаётся резервом. Процент распределения выбирайте по объёму, который можно проверить вручную, без резкого переключения всего трафика.
Во время параллельной работы сравнивайте не только количество принятых запросов. Сопоставляйте внутренние ID, ответы submit_sm, коды ошибок, время получения DLR и финальные статусы. Если HTTP API сообщает об успехе, а SMPP возвращает ошибку кодировки или адреса, причину нужно устранить до расширения доли SMPP-трафика.
Для каждого сообщения определите владельца отправки. Если после тайм-аута приложение автоматически повторяет операцию через другой канал, оно рискует отправить SMS дважды. Надёжнее сначала проверить, сохранился ли message_id и был ли получен результат от платформы. При отсутствии такой возможности задайте отдельный флаг «результат неизвестен» и разберите его в журнале.
После успешного теста переключите один сценарий, например уведомления о статусе заказа. Несколько рабочих дней собирайте технические логи и проверяйте обращения клиентов. Затем переносите остальные сценарии. HTTP API удаляйте только после того, как очередь, DLR и откат проверены на реальном потоке.
Какие ошибки чаще всего мешают миграции?
- Считать ответ submit_sm доказательством доставки. Он подтверждает приём операции, а итоговый результат приходит через DLR.
- Перенести текст без проверки DCS. Кириллица и латиница могут использовать разные значения кодировки.
- Не сохранять message_id. Без него сложно связать отчёт доставки с заказом или другой операцией.
- Настроить повторную отправку после любого тайм-аута. При потерянном ответе сообщение могло уже попасть в очередь поставщика.
- Проверить только один короткий текст. Отдельно нужны тесты кириллицы, длинного сообщения, неверного номера и разрыва соединения.
- Сразу отключить HTTP API. Резервный канал нужен до завершения сверки статусов и проверки отката.
Если приложение должно принимать ответы абонентов, заранее продумайте обработчик MO-сообщений: в SMPP входящие SMS приходят отдельно от DLR, поэтому их нельзя смешивать в одном статусе. Практическая схема такого обмена описана в материале «Как принимать ответы на SMS через SMPP».
3 шага, которые можно сделать на этой неделе:
- Составьте таблицу текущих HTTP-полей, внутренних ID, повторов и статусов.
- Поднимите тестовую SMPP-сессию, проверьте bind, DCS, submit_sm и получение DLR.
- Переведите один сценарий на общую очередь с резервом HTTP API и сравните результаты по каждому message_id.
