Если push-уведомления Ozon не приходят, продавец может добавить SMS-канал к своей системе заказов. Для этого интернет-магазин или внутренний сервис передаёт событие о заказе в приложение, приложение формирует текст и отправляет его через SMPP-шлюз. В статье разобраны схема интеграции, обязательные параметры сообщения, обработка статусов доставки и проверка соединения. Такой подход подходит бизнесу, которому нужно контролировать большой объём транзакционных SMS.
Почему push-уведомления не стоит оставлять единственным каналом?
Push зависит от установленного приложения, разрешений на уведомления, авторизации пользователя и доступа устройства к интернету. Если приложение удалено, отключено или работает нестабильно, клиент может не увидеть изменение статуса заказа. SMS приходит на номер телефона, который уже используется в заказе, поэтому его удобно применять как резервный канал для важных событий.
Для продавца Ozon речь обычно идёт о коротких сообщениях: заказ принят, товар передан в доставку, заказ готов к выдаче, срок получения изменился. Внутренняя система продавца получает информацию о событии из доступного ему источника, после чего передаёт SMS-компоненту номер телефона, шаблон и идентификатор заказа. SMPP отвечает за связь этого компонента с SMS-шлюзом.
Сначала полезно определить границы задачи. Если продавцу нужно уведомлять только о собственных действиях, достаточно связать учётную систему с сервисом отправки. Если требуется получать точные статусы площадки, понадобится источник данных, который эти статусы предоставляет. Сам SMPP не получает сведения о заказах: протокол доставляет уже подготовленное сообщение.
Как выглядит схема SMS-уведомления через SMPP?
Рабочая схема состоит из нескольких этапов. Событие о заказе поступает в приложение, приложение выбирает шаблон, подставляет номер заказа и отправляет сообщение через SMPP. Шлюз возвращает идентификатор сообщения, а затем присылает отчёт о доставке. По этому отчёту система меняет статус уведомления и фиксирует результат.
- Система продавца получает событие: заказ создан, изменён, передан в доставку или готов к выдаче.
- Модуль уведомлений проверяет, что для этого события ещё не отправлялось SMS.
- Программа собирает текст из шаблона и ограничивает его допустимой длиной.
- SMPP-клиент открывает bind-соединение и передаёт сообщение шлюзу.
- Система сохраняет message ID и связывает его с конкретным заказом.
- После delivery receipt приложение обновляет статус: доставлено, отклонено или неизвестно.
Для транзакционных уведомлений лучше использовать отдельные шаблоны и коды событий. Например, «Заказ №12345 передан в доставку» и «Заказ №12345 готов к получению» должны считаться разными уведомлениями. Это упрощает повторную отправку и помогает оператору понять, на каком шаге возникла проблема.
Если клиенту нужно отвечать на SMS, одной исходящей отправки мало. В этом случае проектируют обработку MO-сообщений, то есть входящих ответов абонента. Техническая схема описана в материале как принимать ответы на SMS через SMPP.
Какие параметры нужны для подключения к SMPP?
Провайдер SMS-шлюза выдаёт параметры подключения. Обычно приложению нужны адрес и порт шлюза, логин, пароль, тип bind, допустимый sender ID и правила кодировки. Эти данные хранят отдельно от исходного кода. Доступ к ним получают только сервисы, которым действительно нужно отправлять сообщения.
| Параметр | Что проверить | Практический результат |
|---|---|---|
| Тип соединения | Подходит ли transmitter, receiver или transceiver для вашей схемы | Приложение отправляет SMS и получает нужные отчёты |
| Кодировка | Корректно ли передаются кириллические символы | Текст не превращается в нечитаемый набор знаков |
| Sender ID | Какое имя отправителя разрешено шлюзом | Клиент видит ожидаемое обозначение отправителя |
| Delivery receipt | Включена ли передача статусов доставки | Система отличает принятую шлюзом SMS от доставленной |
| Reconnect | Что происходит после разрыва TCP-соединения | Клиент восстанавливает bind без ручного запуска |
| Ограничения скорости | Сколько сообщений в секунду принимает шлюз | Очередь не перегружает соединение |
Кириллица влияет на размер SMS и число частей сообщения, поэтому текст лучше держать коротким. В уведомлении достаточно назвать событие, номер заказа и следующий шаг. Ссылки, длинные описания товара и рекламные фразы увеличивают объём и усложняют контроль отправки.
При подключении через SMPP проверяют не только факт авторизации. Тестовая отправка должна пройти полный путь: submit, получение message ID, delivery receipt и запись результата в журнале. Для отдельной проверки канала пригодится инструкция о том, как проверить скорость и стабильность SMPP-шлюза.
Как настроить очередь, повторы и статусы доставки?
Магазин не должен отправлять SMS прямо из обработчика заказа без очереди. Если шлюз временно занят или соединение оборвалось, пользовательский запрос зависнет вместе с отправкой. Очередь отделяет бизнес-логику от SMPP-клиента: приложение добавляет задачу, а отдельный обработчик отправляет её и повторяет попытку по понятному правилу.
У каждой задачи стоит хранить внутренний идентификатор заказа, тип события, номер телефона, текст после подстановки, время постановки в очередь, message ID и итоговый статус. Повторная отправка должна зависеть от причины сбоя. Временная ошибка соединения допускает повтор, а постоянная ошибка адресата требует отметки о невозможности доставки.
| Ситуация | Действие приложения |
|---|---|
| Шлюз принял submit_sm | Сохранить message ID и ждать отчёт |
| Соединение разорвано до ответа | Проверить результат по журналу и не создавать дубликат без идемпотентного ключа |
| Пришёл статус доставки | Связать его с заказом и закрыть задачу |
| Шлюз временно отклонил запрос | Поставить задачу в повторную очередь с ограничением попыток |
| Текст превышает лимит | Сократить шаблон или явно разделить сообщение на части |
Идемпотентность особенно важна при повторной обработке событий. Если система дважды получила один и тот же статус Ozon, клиент не должен получить два одинаковых SMS. Для этого в базе создают уникальный ключ, например «номер заказа плюс тип события», и проверяют его до постановки задачи.
Мониторинг нужен на уровне соединения и сообщений. В журнале фиксируют bind, reconnect, submit_sm, ответы шлюза, delivery receipt и ошибки кодировки. Отдельно считают сообщения в очереди: резкий рост покажет проблему раньше, чем её заметит клиент.
Какие ошибки чаще всего ломают SMS-уведомления?
- Система считает сообщение доставленным после submit_sm. Принятие шлюзом и доставка на телефон — разные статусы, поэтому нужен delivery receipt.
- Один шаблон используется для всех событий. Из-за этого клиент не понимает, изменился ли статус заказа или повторилась старая отправка.
- Кириллица не проверена на тестовом номере. До запуска нужно проверить отображение текста и число частей SMS.
- После разрыва соединение не восстанавливается. SMPP-клиенту нужен таймер переподключения и корректное закрытие старой сессии.
- Повторы создают дубликаты. Очередь должна хранить ключ события и ограничивать повторные попытки.
- Статусы не связываются с заказом. message ID нужно записывать сразу после ответа шлюза, иначе отчёт доставки будет трудно сопоставить.
Для небольшого бизнеса разумно начать с двух событий: «заказ принят» и «заказ готов к выдаче». После проверки шаблонов, кодировки и статусов можно добавить передачу в доставку или изменение срока. Если нужна отдельная схема уведомлений при выдаче заказа, полезно сравнить её с материалом о SMS-подтверждении выдачи заказа в пункте выдачи.
3 шага, которые можно сделать на этой неделе:
- Описать события заказа и для каждого подготовить короткий шаблон SMS.
- Подключить тестовый SMPP-bind, проверить кириллицу, message ID и delivery receipt.
- Добавить очередь с защитой от дублей, повторным подключением и журналом ошибок.
Так продавец получает независимый технический канал для уведомлений, когда push в приложении Ozon недоступен. На сайте smpp.by можно подобрать архитектуру SMPP-подключения под объём сообщений, требования к статусам и способ интеграции с системой заказов.
