Как настроить приём входящих SMS через SMPP без потерь

Чтобы принимать входящие SMS через SMPP, приложение подключается к шлюзу с подходящим типом bind, обрабатывает команду deliver_sm и возвращает deliver_sm_resp с тем же sequence number. Надёжная схема сначала сохраняет сообщение в устойчивую очередь, а затем подтверждает его приём. Так сбой приложения не стирает уже полученный текст, а повторная доставка не создаёт лишние действия в вашей системе. Ниже — порядок настройки, проверка ответов и способы защититься от потерь и дублей.

Какое подключение нужно для входящих SMS?

Сначала уточните у SMPP-провайдера параметры подключения и режим сессии. Для приёма сообщений обычно используют bind_receiver или bind_transceiver: первый предназначен для входящего потока, второй позволяет принимать и отправлять SMS в одной сессии. Конкретный режим зависит от настроек шлюза.

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

Перед подключением к рабочему потоку проверьте настройку на тестовой сессии. В руководстве по приёму SMS через SMPP разобраны параметры такой интеграции.

Как обработать deliver_sm и вернуть ответ?

Обработчик принимает deliver_sm, проверяет тип сообщения и записывает его в надёжное хранилище. После успешной записи приложение отправляет deliver_sm_resp, указывая sequence number из исходной команды и подходящий статус. Пустое тело ответа допустимо, если этого требует реализация протокола и настройка шлюза.

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

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

Как защититься от потерь и повторов?

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

• Сохраните исходные поля deliver_sm и тело сообщения до успешного ответа.
• Запишите sequence number для связи команды с ответом в рамках сессии.
• Создайте устойчивый идентификатор записи из доступных полей сообщения и данных провайдера.
• Повторяйте обработку незавершённых записей из очереди, не повторяя уже выполненное действие.
• Разделяйте входящие SMS и отчёты о доставке: проверяйте признаки типа сообщения, включая esm_class.

Sequence number связывает запрос с ответом, но сам по себе не служит постоянным идентификатором SMS: после переподключения значения могут использоваться снова. Для защиты от дублей сохраняйте идентификаторы и содержимое сообщения в контексте конкретной сессии и провайдера.

Что проверить перед запуском?

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

Типичные ошибки:

• Приложение принимает соединение, но не обрабатывает входящие deliver_sm.
• Ответ отправляется с sequence number, который не совпадает с номером команды.
• Успешный ответ уходит до сохранения сообщения.
• После переподключения программа повторяет бизнес-действие для уже обработанной SMS.
• Отчёт о доставке принимают за текстовое сообщение от абонента.

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