Миграция с HTTP API на SMPP без потери SMS

Переход с HTTP API на SMPP нужен, когда SMS-трафик вырос, а приложению стало важно управлять соединением, скоростью отправки и статусами доставки. В статье разобран пошаговый план миграции для малого бизнеса: как сравнить текущую интеграцию, подготовить SMPP-подключение, провести тесты, перенести отправку и проверить DLR-отчёты. Такой порядок помогает сохранить контроль над очередью сообщений и не переключать рабочую систему вслепую.

Когда бизнесу пора переходить с HTTP API на SMPP?

HTTP API удобно подключить к сайту, интернет-магазину или внутренней программе: приложение отправляет HTTP-запрос, получает ответ и продолжает работу. Для умеренного потока этого обычно достаточно. Сложности появляются, когда отправка становится постоянной частью операционного процесса, а системе приходится учитывать очереди, ограничения скорости и повторные попытки.

О переходе на SMPP говорят несколько технических признаков:

• приложение регулярно отправляет большой поток SMS и упирается в лимиты HTTP-запросов;
• очередь сообщений живёт отдельно от отправляющего кода, из-за чего сложно понять, что уже принято шлюзом;
• бизнесу нужны детальные статусы доставки, а не только ответ API о принятии запроса;
• система должна поддерживать постоянное соединение с SMS-шлюзом;
• разработчику нужно управлять скоростью отправки и реакцией на ответы шлюза.

SMPP не решает проблему автоматически. Он переносит больше ответственности в вашу систему: нужно поддерживать соединение, обрабатывать ответы на команды, отслеживать тайм-ауты и корректно закрывать зависшие сессии. Поэтому решение принимают по нагрузке и требованиям к контролю, а не по самому названию протокола.

Чем SMPP отличается от HTTP API при большом потоке SMS?

HTTP API работает по модели «запрос — ответ». SMPP использует команды протокола и постоянную сессию между приложением и SMS-шлюзом. В распространённой реализации применяют SMPP версии 3.4. Каждая команда получает подтверждение с command_status, а результат доставки приходит отдельным отчётом DLR через deliver_sm PDU.

Для DLR провайдер может передавать идентификатор сообщения, даты отправки и завершения, число доставленных сообщений, итоговый статус и код ошибки. Формат нужно согласовать с конкретным шлюзом, потому что названия полей и набор статусов могут отличаться. В документации Infobip, например, DLR описывается через поля id, sub, dlvrd, submit date, done date, stat и err (Infobip Docs).

Если в системе уже есть отдельная логика статусов, заранее определите соответствие между HTTP-ответами и SMPP-событиями. Для этого полезно изучить практику выгрузки статусов SMPP в 1С и отдельно решить, какие статусы считать промежуточными, а какие финальными.

Как подготовить миграцию до изменения рабочего кода?

Сначала опишите текущий путь сообщения: где приложение создаёт SMS, где формируется очередь, где хранится идентификатор и что происходит после ответа API. Не начинайте с замены библиотеки. Сначала составьте таблицу соответствий: поле HTTP-запроса, поле SMPP-команды, значение в вашей базе и обработчик ошибки.

У провайдера SMPP запросите параметры подключения. Обычно для теста нужны сервер, порт, логин, пароль, режим transceiver, TON/NPI и лимиты отправки. Эти значения нельзя подбирать случайно: TON и NPI влияют на интерпретацию адресов, а лимит определяет допустимую скорость submit_sm. Практическую последовательность получения доступа, тестовой отправки и проверки DLR описывает инструкция как определить нужный SMPP-throughput.

В приложении подготовьте отдельный SMPP-адаптер. Бизнес-логика должна передавать ему номер, текст, имя отправителя и внутренний идентификатор, но не зависеть от конкретного протокола. Тогда HTTP API и SMPP можно временно держать параллельно, направляя тестовую группу сообщений через новый канал.

Очередь лучше разделить на несколько состояний: «создано», «передано в SMPP», «принято шлюзом», «доставляется», «доставлено» и «ошибка». Идентификатор сообщения из submit_sm сохраняйте рядом с внутренним ID. Без этой связи DLR придёт, но система не поймёт, к какой операции его отнести.

Как провести технический тест SMPP-подключения?

Тест начинайте с установки TCP-соединения и команды bind_transceiver. После подтверждения проверьте, что приложение принимает ответы шлюза и поддерживает сессию. Затем отправьте короткое тестовое SMS на разрешённый номер, получите message_id и дождитесь DLR. Во время проверки записывайте в журнал время команды, sequence_number, command_status и текст ошибки.

1. Проверьте доступность сервера и порта с тестового окружения.
2. Установите bind_transceiver с выданными логином и паролем.
3. Отправьте сообщение с простым текстом и сохраните ответ submit_sm.
4. Проверьте, что DLR поступил через deliver_sm и связался с исходным message_id.
5. Проверьте отправку кириллического текста и длинного сообщения.
6. Отключите соединение во время теста и убедитесь, что очередь не теряет сообщение.

Кириллица требует отдельной проверки кодировки. Если текст не помещается в один SMS, приложение должно корректно разбивать его на части и передавать параметры, по которым телефон соберёт сообщение. Для такого сценария пригодится разбор конкатенированных SMS через SMPP.

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

Как переключить отправку на SMPP без потери сообщений?

Безопаснее использовать поэтапное переключение. Сначала включите SMPP только в тестовой среде, затем направьте через него ограниченную долю рабочих сообщений и сравните результаты с HTTP API. Смотрите не только на факт принятия команды, но и на сопоставление message_id, DLR, ошибки и время обработки очереди.

Перед переключением зафиксируйте момент смены канала и правило маршрутизации. У каждого сообщения должен быть один владелец отправки. Если после тайм-аута приложение не знает, принял ли шлюз SMS, повторная отправка может создать дубль. Поэтому повторять нужно по понятному правилу: например, только для сообщений, которые точно не получили подтверждение, либо после проверки состояния по доступному идентификатору.

На время миграции оставьте HTTP API как резервный путь, но не включайте автоматический повтор через оба канала одновременно. Резервный SMPP-канал и правила переключения лучше проектировать отдельно; полезный ориентир даёт материал о резервном SMPP-канале при сбое провайдера.

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

Какие ошибки чаще всего ломают миграцию?

• Смешение принятия и доставки. Ответ submit_sm означает обработку команды шлюзом, а не доставку SMS получателю. Финальный результат нужно брать из DLR.
• Потеря связи между ID. В базе сохраняют внутренний номер заказа, но не message_id SMPP. Тогда отчёт доставки невозможно корректно обработать.
• Неверные TON/NPI. Эти параметры копируют из чужого примера, хотя провайдер выдал другие значения для конкретного сценария.
• Отсутствие heartbeat. Сессия выглядит открытой, но фактически соединение уже не работает. Нужны регулярные проверки и повторное подключение.
• Повтор после любого тайм-аута. Тайм-аут не всегда означает, что шлюз не принял сообщение. Перед повтором проверьте логику идемпотентности и правила провайдера.
• Тест только короткого текста. Кириллица и длинные SMS проходят другой путь кодирования, поэтому их проверяют до запуска.