SMPP-песочница: как проверить SMS, DLR и конкатенацию

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

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

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

SMPP работает через команды протокола. Клиент открывает соединение, выполняет bind, передаёт сообщение командой submit_sm, а сервер возвращает ответ с идентификатором сообщения. Статус доставки приходит отдельным событием deliver_sm, если маршрут передаёт DLR. Поэтому тест нужно строить вокруг всей цепочки, а не только вокруг факта подключения.

Перед началом зафиксируйте параметры тестовой среды: адрес и порт, логин, пароль, тип bind, TON/NPI, кодировку, формат идентификатора сообщения и правила DLR. Если один параметр отличается от рабочего подключения, результат нельзя переносить на production. Для SMS в Беларуси отдельно проверьте настройки TON/NPI: разбор этих полей вынесен в материал о настройке TON/NPI в SMPP для SMS в Беларуси.

Какой сценарий отправки SMS проверить первым?

Начните с короткого сообщения в однократной сессии. Клиент должен последовательно выполнить такие действия:

1. Открыть TCP-соединение с тестовым SMPP-сервером.
2. Отправить bind_transceiver и дождаться положительного ответа.
3. Передать короткий текст через submit_sm.
4. Сохранить message_id, который вернул сервер.
5. Ожидать DLR и сопоставить его с сохранённым идентификатором.
6. Корректно закрыть сессию через unbind.

В журнале должны остаться время подключения, результат bind, команда отправки, код ответа, идентификатор сообщения и содержание DLR. Текст SMS лучше сделать узнаваемым, например «SMPP TEST 001», чтобы его не перепутать с рабочим уведомлением. Номер получателя используйте только тот, который разрешён условиями песочницы.

На этом этапе проверяют транспорт и базовый обмен. Если сервер принял submit_sm, это ещё не означает доставку: сервер мог принять запрос на обработку, а итоговый статус придёт позже. Клиенту нужно хранить связь между внутренним идентификатором события и SMPP message_id.

Как проверить DLR и правильно прочитать его статус?

DLR, или delivery receipt, сообщает результат обработки сообщения. В нём могут присутствовать идентификатор исходной SMS, статус, код ошибки и текстовое описание. Формат зависит от шлюза, поэтому обработчик нельзя жёстко привязывать к одной строке: сначала выделяйте поля, затем нормализуйте статус во внутренний справочник.

Что проверяется	Что записать в журнал	Какой результат нужен
Приём DLR	Время события и тип PDU	Клиент принимает deliver_sm и отвечает серверу
Связь с исходной SMS	Полученный и внутренний идентификаторы	DLR относится к правильной отправке
Статус доставки	Исходный статус и нормализованное значение	Статус сохраняется без потери деталей
Ошибка маршрута	Код ошибки и описание	Ошибка доступна для повторной обработки или отчёта

Обработчик входящего DLR должен вернуть подтверждение получения. Если клиент принимает событие, но не отвечает на него, сервер может повторять доставку одного и того же отчёта. Это создаёт дубликаты в журнале и мешает считать фактические результаты.

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

Когда SMS используется для кода входа, логика повторов особенно чувствительна к статусу. Практическая схема разбора OTP, DLR и повторных отправок описана в материале как отправить OTP-код через SMPP: DLR и повторы.

Как протестировать конкатенацию длинного сообщения?

Длинная SMS передаётся несколькими частями. Чтобы телефон собрал их в одно сообщение, клиент добавляет служебные параметры конкатенации, обычно через User Data Header. В тесте нужно проверить не только число отправленных частей, но и их порядок, общий идентификатор и корректность кодировки.

1. Создайте текст, который превышает лимит одной части в выбранной кодировке.
2. Передайте его через тот же путь, который будет использовать рабочее приложение.
3. Проверьте, сколько частей сформировал клиент.
4. Убедитесь, что каждая часть получила ответ на submit_sm.
5. Сопоставьте DLR отдельных частей с исходным сообщением.
6. Проверьте сборку на тестовом устройстве или в предусмотренном эмуляторе.

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

В рабочем журнале храните общий идентификатор логического сообщения и идентификаторы его частей. Тогда ошибка одной части не потеряется среди успешных ответов остальных. Для алерта о сбое сервера это также помогает понять, дошло ли уведомление целиком.

Какие типичные ошибки возникают в SMPP-песочнице?

• Клиент считает принятие submit_sm доставкой. Ответ на команду показывает приём запроса сервером, а итог нужно брать из DLR.
• DLR не связывается с отправкой. Причина часто в разном формате идентификатора: ведущие нули, регистр букв или дополнительные символы нужно нормализовать.
• Клиент не подтверждает deliver_sm. Входящий PDU следует обработать и подтвердить, иначе сервер может повторить событие.
• Длинный текст приходит с повреждёнными символами. Проверьте data_coding, кодировку строки и параметры UDH на каждой части.
• Повтор запускается для неверного номера. Постоянную ошибку адреса нельзя обрабатывать так же, как временный сбой маршрута.
• Тестовый конфиг отличается от рабочего. Сравните bind, TON/NPI, формат DLR и правила поддержания сессии перед переносом настроек.

Для рабочего подключения полезно разделить тесты на три уровня: соединение и bind, передача SMS, обработка DLR и конкатенации. Такой набор можно запускать после изменения библиотеки, конфигурации или SMPP-шлюза. Описание интеграции по SMPP 3.4 также включает обмен сообщениями и поддержание сессии (SevenTech docs).