Для уведомлений о ремонте техники удобно связать учётную систему мастерской с SMPP-шлюзом и отправлять SMS после каждого изменения статуса заказа. В статье разберём схему интеграции, параметры подключения, формат сообщения, обработку DLR и повторную отправку. В результате разработчик сможет собрать понятный процесс: система фиксирует событие, шлюз принимает SMS, оператор возвращает статус доставки, а программа сохраняет результат рядом с заказом.
Какие статусы ремонта стоит передавать клиенту?
Сначала определите события, которые действительно требуют сообщения. Для небольшой мастерской обычно достаточно статусов «заказ принят», «диагностика завершена», «согласование стоимости», «ремонт завершён» и «техника готова к выдаче». Названия зависят от вашей учётной системы, но каждое событие должно иметь отдельный код или понятное условие запуска.
Например, после смены статуса на «готово к выдаче» система формирует сообщение: «Заказ №482 готов. Заберите технику в рабочее время». Номер заказа помогает клиенту быстро объяснить ситуацию сотруднику, а короткий текст уменьшает риск обрезания сообщения на телефоне.
Для каждого SMS сохраните минимум четыре значения:
- идентификатор заказа;
- номер телефона в международном формате;
- код события, например repair_ready или repair_approved;
- внутренний идентификатор сообщения.
Внутренний идентификатор особенно нужен для DLR. По нему система связывает технический ответ шлюза с конкретным SMS и заказом клиента. Практический разбор автоматизации уведомлений о ремонте можно посмотреть в материале об автоматизации SMS о статусе ремонта техники.
Как выглядит схема интеграции SMPP?
В простом варианте участвуют три компонента: программа, где хранятся заказы, SMPP-клиент и SMS-шлюз. Система ремонта не обращается к шлюзу напрямую из каждого экрана. Она создаёт событие и передаёт задачу отдельному модулю отправки. Такой подход позволяет повторить отправку после временного сбоя и не задерживать работу оператора.
- Сотрудник меняет статус заказа.
- Система создаёт запись в очереди SMS.
- SMPP-клиент устанавливает соединение со шлюзом.
- Клиент отправляет сообщение командой submit_sm.
- Шлюз возвращает идентификатор принятого сообщения.
- После попытки доставки шлюз передаёт DLR через deliver_sm.
- Программа обновляет результат в журнале заказа.
Отдельная очередь нужна даже при небольшом объёме. Если шлюз временно недоступен, заказ не потеряется: запись останется в базе со статусом pending или retry. После восстановления соединения отправитель продолжит обработку с последней незавершённой записи.
При подключении провайдер обычно передаёт адрес SMPP-сервера, порт, логин, пароль, разрешённый источник SMS и параметры скорости отправки. Эти значения нельзя зашивать в код. Храните их в конфигурации, а пароль ограничьте доступом для процесса отправки.
Какие параметры нужно настроить в SMPP-клиенте?
Соединение начинают с команды bind_transceiver, если один канал должен и отправлять SMS, и принимать DLR. В настройках указывают system_id, пароль, тип bind и тайм-ауты. После подключения клиент должен отправить enquire_link. Эта служебная команда проверяет, что соединение ещё отвечает.
Для каждого сообщения проверьте следующие поля:
- source_addr, то есть имя отправителя, согласованное со шлюзом;
- destination_addr, номер получателя;
- data_coding, кодировка текста;
- registered_delivery, запрос отчёта о доставке;
- short_message или message_payload, поле с текстом SMS;
- service_type и esm_class, если их требует конкретная конфигурация шлюза.
Поле registered_delivery должно быть включено для сообщений, по которым нужен отчёт. Если его не передать или задать неверно, SMS может уйти клиенту, но приложение не получит ожидаемый DLR. Точные значения полей проверяют по документации выбранного SMPP-шлюза и тестируют на отдельном номере.
Длина текста влияет на кодировку и количество частей. Кириллица часто переводит сообщение в Unicode, поэтому в одном SMS помещается меньше символов, чем при использовании GSM-алфавита. Перед отправкой полезно посчитать число сегментов и записать его в журнал: тогда бухгалтерия и технический специалист увидят, почему одна операция создала несколько SMS.
Как обработать DLR и повторные попытки?
DLR содержит технический результат доставки. В зависимости от шлюза и оператора в нём встречаются статусы DELIVERED, EXPIRED, UNDELIVERABLE, REJECTED или UNKNOWN. Программа должна сохранять исходную строку DLR, распознанный статус, время получения и идентификатор сообщения.
| Результат | Что записать в системе | Действие |
|---|---|---|
| DELIVERED | SMS доставлено | Завершить обработку сообщения |
| EXPIRED | Истёк срок ожидания доставки | Проверить срок действия заказа и канал связи |
| UNDELIVERABLE | Шлюз не доставил SMS | Зафиксировать ошибку, повтор не запускать без правила |
| REJECTED | Сообщение отклонено | Проверить номер, отправителя и параметры запроса |
| UNKNOWN | Результат не распознан | Сохранить DLR и передать запись на разбор |
Повторная отправка нужна только для временных ошибок. Например, приложение может повторить попытку после разрыва SMPP-соединения или временной недоступности шлюза. Повторять SMS после любого неуспешного DLR рискованно: клиент получит дубликат, если первый отчёт пришёл с задержкой.
Для защиты от дублей добавьте ключ идемпотентности: order_id плюс event_code. Если статус «готово» уже породил отправленное сообщение, повторный запуск обработчика не должен создавать вторую запись. Для каждой попытки храните номер попытки и причину повторной отправки.
Если DLR не приходит, это не всегда означает, что SMS не доставлено. Сначала проверьте флаг registered_delivery, обработчик deliver_sm, фильтр по message_id и журнал сетевого соединения. Отдельный разбор причин недоставки есть в материале почему SMS не доходит до клиента и как читать DLR в SMPP.
Как проверить шлюз до запуска в рабочем режиме?
Тестирование лучше разделить на несколько сценариев. Сначала отправьте короткое SMS на тестовый номер и проверьте submit_sm_resp. Затем убедитесь, что приложение принимает deliver_sm и связывает его с правильным message_id. После этого проверьте кириллицу, длинное сообщение, неверный номер и разрыв соединения во время отправки.
В журнале должны быть видны время события, номер заказа, номер получателя в маскированном виде, результат submit_sm, message_id, текст DLR и итоговый статус. Логи помогают найти ошибку без ручного просмотра базы. Полный переход от отправки до отчёта лучше проверять на копии рабочего контура, чтобы тестовый SMS не изменил реальный статус ремонта.
Типичные ошибки при настройке SMPP и DLR
- Система отправляет SMS прямо из интерфейса оператора и зависает при проблемах со шлюзом.
- Программа не сохраняет message_id, поэтому DLR нельзя связать с заказом.
- Флаг запроса доставки не включён в submit_sm.
- Обработчик принимает только один формат статуса и теряет неизвестные значения.
- Повторная отправка запускается без проверки предыдущей попытки.
- Текст статуса содержит слишком много деталей, из-за чего сообщение разбивается на несколько частей.
3 шага, которые можно сделать на этой неделе:
- Составить список событий ремонта и связать каждое событие с шаблоном SMS.
- Добавить очередь отправки, message_id и журнал DLR в техническое задание.
- Проверить submit_sm, deliver_sm, разрыв соединения и повторную попытку на тестовом заказе.
Когда сценариев становится больше, мастерской нужен отдельный SMPP-модуль с очередью, контролем соединения и обработкой DLR. Такой контур можно подключить к существующей системе учёта, не меняя рабочий процесс сотрудников: оператор меняет статус заказа, а техническая часть сама отправляет SMS и сохраняет результат доставки.
