Интеграция с SMS-сервисами

«Mobi Service»

Техническое описание

Редакция 1

Сервис»

2010

Содержание

Обзор решения......................................................................................................................................... 3

Методы интеграции................................................................................................................................. 6

SMPP метод........................................................................................................................................... 6

XML-интеграция.................................................................................................................................... 6

DB-Gate метод....................................................................................................................................... 7

Сравнительный анализ и рекомендации по выбору метода................................................... 7

Интерфейсы и протоколы обмена....................................................................................................... 8

SMPP метод.......................................................................................................................................... 8

Свойства SMPP протокола............................................................................................................ 8

Пример подключения по SMPP.................................................................................................... 8

НЕ нашли? Не то? Что вы ищете?

XML-интеграция.................................................................................................................................... 9

Адрес для отправки XML-запросов.............................................................................................. 9

XML-запрос для отправки SMS..................................................................................................... 9

XML-запрос для получения статуса ранее переданных сообщений.............................. 10

XML-запрос на получение SMS................................................................................................. 11

Ограничение на передачу специальных символов в тексте SMS................................... 12

DB-Gate метод (версия для Oracle)............................................................................................... 12

Структура таблиц........................................................................................................................... 12

Отправка сообщений.................................................................................................................... 13

Статусы сообщений..................................................................................................................... 13

Возможные статусы сообщений:............................................................................................... 13

Технические характеристики решения............................................................................................ 15

Зона покрытия.................................................................................................................................... 15

Доставка сообщений......................................................................................................................... 15

Отчеты................................................................................................................................................... 15

Надежность и безопасность............................................................................................................ 15

Режим работы сервиса................................................................................................................ 15

Меры по обеспечению надежности и безопасности............................................................ 15

Резервное копирование данных................................................................................................ 16

Администрирование.................................................................................................................... 16

Порядок подключения........................................................................................................................... 17

SMPP метод......................................................................................................................................... 17

XML-интеграция................................................................................................................................. 17

DB-Gate метод..................................................................................................................................... 17

Перечень документации....................................................................................................................... 17

Обзор решения

Интеграция информационной системы Заказчика и системы Mobi Service означает доставку исходящих SMS из Информационной системы (ИС) Заказчика до мобильного телефона клиента и доставку входящих SMS от мобильного телефона клиента до ИС Заказчика.

При этом система Mobi Service обеспечивает:

·  Передачу как одиночных сообщений в реальном времени, так и пакета сообщений;

·  Временное хранение сообщений, ведение журналов обмена, архивов и резервное копирование;

·  Формирование статистики и предоставление отчетов о потребленном трафике;

·  Резервирование каналов связи и переключение на альтернативные каналы связи при сбое основного канала;

·  Кодирование информации, передаваемой по каналам связи.

В самом общем виде передача сообщений происходит следующим образом:

1.  Информационная система Заказчика формирует запрос, содержащий: текст сообщения, номер получателя, номер отправителя.

2.  Информационная система Заказчика отправляет запрос в систему Mobi Service.

3.  Система Mobi Service обеспечивает отправку сообщения на мобильный телефон клиента и получение статуса доставки.

4.  Система Mobi Service формирует ответ на запрос, содержащий статус доставки или описание ошибки.

5.  Система Mobi Service отправляет ответ в информационную систему Заказчика.

6.  Информационная система Заказчика обрабатывает ответ от системы Mobi Service

Процесс обмена запросами показан на рисунке 1.

Рисунок 1. Обмен запросами/ответами.

Система Mobi Service состоит из сервера баз данных, сервера биллинга, web-сервера и сервера резервного копирования данных.

Все оборудование системы Mobi Service расположено в защищенном помещении дата-центра, обеспечивающем защиту от несанкционированного доступа.

Передача запросов между информационной системой Заказчика и системой Mobi Service происходит через Интернет по защищенным каналам.

Передача данных между системой Mobi Service и операторами мобильной связи происходит через Интернет по защищенным каналам.

В общем виде архитектура решения показана на рисунке 2.

Рисунок 2. Архитектура интеграционного решения.

Для отправки SMS компания Mobi Service регистрирует выбранный Заказчиком номер отправителя – любую комбинацию латинских букв, цифр, специальных символов, длиной не более 11 символов. SMS будут отправляться от номера отправителя, именно этот номер получатель сообщения увидит в поле "От кого".

Для получения SMS компания Mobi Service предоставляет для выбора несколько цифровых номеров в федеральном формате вида +7XXXNNNNNNN. Также имеется возможность получения SMS на короткие четырехзначные сервисные номера.

Методы интеграции

Mobi Service предлагает 3 метода интеграции, обеспечивающих как отправку, так и получение SMS:

·  Метод SMPP-интеграции базируется на использовании протокола SMPP.

·  XML-интеграция основана на обмене запросами/ответами на языке XML.

·  Интеграция методом DB-Gate осуществляется с помощью "шлюза" – базы данных, встраиваемой в контур ИС Заказчика. В настоящее время существуют версия шлюза, работающая под управлением СУБД Oracle.

SMPP метод

Система Mobi Service в полной мере реализует обмен данными по протоколу SMPP. Поддерживается версия 3.4 протокола SMPP. Протокол реализован согласно "Short Message Peer to Peer Protocol Specification v3.4. Document Version:- 12-Oct-1999 Issue 1.2".

При необходимости соблюдения особенно высоких требований к защите информации возможна организация SSH-туннеля.

Схема обмена данными показана на рисунке 3.

Рисунок 3. Схема обмена данными при SMPP-интеграции

XML-интеграция

Этот способ предполагает, что между информационной системой Банка и системой Mobi Service происходит обмен запросами на языке XML. Обмен происходит через TCP/IP соединение по протоколу HTTPS методом POST, используется двухсторонняя аутентификация с использованием сертификатов.

Схема обмена данными показана на рисунке 4.

Рисунок 4. Схема обмена данными при XML-интеграции

DB-Gate метод

Непосредственно в контуре информационной системы Банка располагается база данных шлюза и служба, полностью реализующая обмен данными с системой Mobi Service. Способ взаимодействия информационной системы Банка с базой данных шлюза остается на усмотрение Банка. В настоящее время реализована версия Mobi Service DB-Gate, работающая под управлением Oracle. Служба обмена реализована на языке Java.

Схема обмена данными показана на рисунке 5.

Рисунок 5. Схема обмена данными при интеграции методом DB-Gate

Сравнительный анализ и рекомендации по выбору метода

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

Протокол SMPP является общепринятым для отправки сообщений в сетях операторов связи. Все крупные операторы, и Mobi Service в том числе, поддерживают этот протокол для подключения внешних систем. Реализация этого протокола на стороне Заказчика ребует квалифицированного программирования. Однако, ряд информационных систем, в частности процессинговые системы банков, поддерживают протокол SMPP. Этот метод можно порекомендовать тем Заказчикам, которые либо имеют ИС с поддержкой SMPP, либо способны самостоятельно реализовать поддержку протокола SMPP в своей ИС.

Передача документов на языке XML является одним из самых распространенных и универсальных методов передачи данных через Интернет. Реализация такого обмена на стороне Заказчика обычно не представляет больших трудностей. Этот метод достаточно универсален и может использоваться заказчиками с любым типом информационных систем.

В случае, когда Заказчик обладает ИС, построенной на базе Oracle, метод интеграции DB-Gate будет наиболее эффективен. База данных шлюза является однотипной с ИС Заказчика, она полностью открыта, Заказчик самостоятельно реализует обмен данными с ней и администрирует базу данных шлюза.

Компания Mobi Service постоянно совершенствует методы интеграции. Кроме того, возможна адаптация одного из методов под специфические требования Заказчика.

Интерфейсы и протоколы обмена

SMPP метод

Свойства SMPP протокола

    Поддержка версия 3.4 протокола SMPP Асинхронный режим Тип сессии: SMPP Transceiver Source Address Ton =[0,1,5], Source Address Npi =[0,1] Работа с пакетами enquire_link Возможность организации защищенного ssh соединения

Пример подключения по SMPP

PDU-запрос:

00A0001 6D 6F7633 63 6E00

Детали запроса:

@command_length: 42

@command_id: 9

@command_status: 0

@sequence_number: 1

@system_id: mobiservice

@password: g3cna5#d

@system_type:

@interface_version: 52

@addr_ton: 1

@addr_npi: 1

PDU-ответ:

000000

Детали ответа:

command_id: bind_transceiver_resp

command_status: 0

sequence_number: 1

XML-интеграция

Общение с сервисом осуществляется при помощи отправки XML запросов в кодировке UTF-8 на заданный адрес сервиса по протоколу HTTP/HTTPS методом POST.

Каждый запрос может состоять из отправляемых сообщений и (или) запросов для получения статусов и (или) запросов для получения входящих сообщений.

Адрес для отправки XML-запросов

http://service. *****

XML-запрос для отправки SMS

Запрос

<?xml version="1.0" encoding="utf-8" ?>

<package login="login" password="123456">

<message>

<default sender="SMSINFO"/>

<msg id="1234" recipient="+" sender="SMSINFO" date_beg="T15:55" date_end="T15:55" url="url" type="0">text</msg>

<msg recipient="+">text</msg>

</message>

</package>

Default – тег, в котором определяются общие атрибуты, указываемые для всех отправляемых сообщений. Если какой-либо атрибут указан в сообщении, то атрибут данного тега игнорируется.

msg – тег сообщения, в качестве параметра указывается текст отправляемого сообщения, может содержать следующие атрибуты:

id – (integer) пользовательский числовой идентификатор сообщения, необязательный атрибут, при использовании пользователь должен гарантировать уникальность данного идентификатора в пределах своей учетной записи.

recipient – (varchar(21)) получатель сообщения (номер телефона), может использоваться в формате с «+» или без него.

sender – (varchar(11)) отправитель сообщения (подпись сообщения), необязательный атрибут.

date_beg – (datetime, ISO8601) дата отправки сообщения, необязательный атрибут, указывается для отложенной отправки сообщений.

date_end – (datetime, ISO8601) дата после которой сообщение теряет актуальность и если оно еще не было отправлено абоненту, отправляться не будет, необязательный атрибут.

url – (varchar(100)) ссылка для создания wap-push сообщения.

type – (integer) тип сообщения: 0-обычное сообщение, 1-флеш сообщение, 2-wap-push сообщение.

Ответ в случае успешной обработки запроса

<?xml version="1.0" encoding="utf-8" ?>

<package>

<message>

<msg id="1234" sms_id="0" sms_count="1">201</msg>

<msg sms_id="1234568" sms_count="1">1</msg>

</message>

</package>

msg – тег сообщения, в качестве параметра возвращается код статуса, может содержать следующие атрибуты:

◦  id – (integer) пользовательский числовой идентификатор сообщения, необязательный атрибут, возвращается при указании данного атрибута в запросе.

◦  sms_id – (integer) числовой идентификатор сообщения присвоенный шлюзом.

◦  sms_count – (integer) реальное количество SMS к отправке.

Ответ в случае ошибки обработки запроса

<?xml version="1.0" encoding="utf-8" ?>

<package>

<error>201</error>

</package>

ERR_UNKNOWN = 200, // Неизвестная ошибка

ERR_FORMAT = 201, // Неправильный формат документа

ERR_AUTHORIZATION = 202 // Ошибка авторизации

XML-запрос для получения статуса ранее переданных сообщений

Запрос

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

<?xml version="1.0" encoding="utf-8" ?>

<package login="login" password="123456">

<status>

<msg id="1234"/>

<msg sms_id="1234568"/>

</status>

</package>

msg – тег сообщения для которого происходит запрос статуса, может содержать следующие атрибуты:

id – (integer) пользовательский числовой идентификатор сообщения, необязательный атрибут.

sms_id – (integer) числовой идентификатор сообщения присвоенный шлюзом.

В ответ на запрос возвращается XML документ содержащий статусы для запрошенных сообщений, либо соответствующие коды ошибок.

<?xml version="1.0" encoding="utf-8" ?>

<package>

<status>

<msg id="1234" sms_id="0" sms_count="1" date_completed="T15:27:03">102</msg>

<msg sms_id="1234568" sms_count="1">1</msg>

</status>

</package>

msg – тег сообщения для которого происходит запрос статуса, в качестве параметра возвращается код статуса, может содержать следующие атрибуты:

id – (integer) пользовательский числовой идентификатор сообщения, необязательный атрибут, возвращается при указании данного атрибута в запросе.

sms_id – (integer) числовой идентификатор сообщения присвоенный шлюзом.

sms_count – (integer) реальное количество SMS к отправке.

date_completed – (datetime, ISO8601) дата присвоения финального статуса.

XML-запрос на получение SMS

Запрос

Входящие сообщения хранятся на сервере и могут быть запрошены пользователем в любой момент. При запросе пользователь получает очередные сообщения неполученные им ранее. Каждому сообщению на сервере присваивается идентификатор ID, который гарантируют уникальный порядок, и если по каким-либо причинам, часть сообщений будет утрачена клиентом, по недостающим ID можно будет запросить эти сообщения в любое время. За один запрос может быть возвращено максимум 100 сообщений.

<?xml version="1.0" encoding="utf-8"?>

<package login="login" password="123456">

<incoming>

<get_msg/>

<msg sms_id="123"/>

</incoming>

</package>

get_msg – тег запрашивающий очередные сообщения, не содержит атрибутов и параметров

msg – тег запрашивающий сообщения по определенному ID:

    sms_id – (integer) числовой идентификатор сообщения.

Ответ в случае успешной обработки запроса

<?xml version="1.0" encoding="utf-8" ?>

<package>

<incoming>

<msg sms_id="123" sender="+" destination="2222" date_received="T15:27:03">Текст сообщения</msg>

</incoming>

</package>

msg – тег сообщения, в качестве параметра возвращается текст сообщения, может содержать следующие атрибуты:

·  sms_id – (integer) числовой идентификатор сообщения (уникальный для пользователя).

·  sender – (varchar(21)) отправитель сообщения.

·  destination – (varchar(11)) номер на который абонент отправляет сообщение.

·  date_received – (datetime, ISO8601) дата получения сообщения.

Если нет невыбранных сообщений, то запрос вернет XML документ:

<?xml version="1.0" encoding="utf-8" ?>

<package/>

Ограничение на передачу специальных символов в тексте SMS

При формировании XML запроса во всех данных следует выполнять замену символов согласно таблице 1. В ответах выполняется соответствующая обратная замена.

Таблица 1. Замена специальных символов в XML запросах.

Специальный символ

Замена

&lt;

&gt;

"

&quot;

'

&apos;

&

&amp;

DB-Gate метод (версия для Oracle)

Обмен данными производится с помощью базы данных шлюза. Она имеет название " Mobi Service DB-Gate".

Структура таблиц

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

ID — PRIMARY KEY
CREATED -- дата добавления сообщения в очередь
MESSAGE -- ID пользовательского сообщения
SOURCE -- исходящий номер
DESTINATION -- номер получателя
REFERENCE -- ID последовательности конкатенированных сообщений
MAXIMUM -- длина последовательности конкатенированных сообщений
SEQUENCE -- номер текущего фрагмента конкатенированного сообщения
VALIDITY -- время жизни сообщения (секунды)
OPERATOR -- ID оператора, на который должно быть отправлено сообщение
TYPE -- Тип. 0 - текстовое смс, 1 - текстовое flash-sms, 2 - wap push
CODING -- кодировка. 0 - GSM Default, 1 — UCS2
ATTEMPTS -- число сделанных попыток отправки сообщения
SUBMITTED -- дата последний попытки отправки
CODE -- ответный command_status на отправку сообщения
MID -- MESSAGE ID сообщения
COMPLETED -- дата получения финального статуса
TID -- ненужный ID сессии от билайна
DONE -- дата получения сообщения абонентом
ERROR, -- код ошибки в случае если абонент сообщение не получил
STATUS -- статус
QUERIED -- дата, когда у оператора был запрошен статус данного сообщения (QUERY_SM)
PRIORITY -- приоритет отправки. у уже отправленных сообщение null
DATA -- текст сообщения
SCHEDULED -- дата запланированной отправки сообщения (не реализовано)
URL -- URL для wap push

Отправка сообщений

Для добавления сообщения в очередь на отправку необходимо произвести insert записи во view SMS_QUEUE_REMOTE2 с полями queue_id, contact_id, message_text, msisdn, operator_id, source_name, type, url(опционально),

где:

·  queue_id — уникальный ID сообщения в очереди (может быть равен contact_id)

·  contact_id — уникальный ID сообщения

·  message_text — текст сообщения

·  msisdn — номер получателя

·  operator_id — ID оператора, через которого должно быть отправлено сообщение

·  source_name — отправитель

·  type — Тип. 0 - текстовое смс, 1 - текстовое flash-sms, 2 — wap-push

·  url — URL-адрес для wap-push сообщения

Триггер автоматически разобьет текст сообщения на нужное кол-во частей и создаст записи в таблице MDS_OUTPUTS

Статусы сообщений

В любой момент может запрошен статус отправленного сообщения. Для этого нужно вызвать процедуру GET_STATUS3

Входные параметры: contact_id — ID отправлненного сообщения

Выходные параметры:

·  STATUS — текущий статус сообщения

·  DELIVERED_PARTS — кол-во доставленных частей

·  FINAL_DATE — дата получения финального статуса

·  error_code — код ошибки

Возвращаемый статус сообщения рассчитывается как наихудший статус из всех частей сообщения.

FINAL_DATE равно null если окончательный статус для всего сообщения еще не получен.

Возможные статусы сообщений:

·  0 - PENDING — ожидает отправки

·  1 - ENROUTE — отправлено в SMSC, но статус еще не получен

·  2 - DELIVERED — доставлено до абонента

·  3 - EXPIRED — истек срок жизни смс

·  4 - DELETED — сообщение удалено из смс-центра

·  5 - UNDELIVERABLE — невозможно доставить сообщение абоненту

·  6 - ACCEPTED — прочитано абонентом

·  7 - UNKNOWN — невозможно определить статус сообщения

·  8 - REJECTED — отвергнуто смс-центром

·  9 - DISCARDED — ошибка при отправке сообщения

·  10 - INDEFINITE — не получен ответ от смс-центра о приеме сообщения

·  11 — из заданных параметров невозможно сформировать корректное сообщение.

Технические характеристики решения

Зона покрытия

Компания Mobi Service обеспечивает доставку сообщений до всех операторов сотовой связи стандарта GSM на территории РФ.

Доставка сообщений

Компания Mobi Service предлагает 2 типа трафика:

·  рекламно-информационные сообщения – доставка большого объема сообщений, отправляемых пакетами.

·  трафик реального времени – доставка одиночных сообщений в течение короткого времени.

Обеспечиваются требования к доставке сообщений, перечисленные в таблице 5.

Таблица 5. Параметры доставки сообщений

Feature

Value

Среднее время доставки сообщений

рекламно-информационный трафик – 5-60 с.

трафик реального времени – 5-20 с.

Гарантированное время доставки

рекламно-информационный трафик – 30 мин.

трафик реального времени – 2 мин.

Возможность переотправки недоставленных сообщений

Присутствует

Отчет о доставке

Присутствует

Отчеты

Каждое сообщение получает статус доставлено / не доставлено. В случае, если сообщение не доставлено, дополнительно сообщается причина ошибки. По запросу ИС Заказчика может получить текущий статус каждого отправленного сообщения.

Web-интерфейс пользователя системы Mobi Service позволяет получить сводную статистику по отправленным/доставленным/полученным сообщениям за указанный период времени.

Отчеты об отправленных/доставленных/полученных сообщениях могут отправляться по электронной почте с указанной периодичностью в автоматическом режиме. Формат отчетов может быть согласован с Заказчиком.

Надежность и безопасность

Режим работы сервиса

Максимальное время, в течение которого система Mobi Service может быть недоступна, составляет 2 часа в месяц.

Меры по обеспечению надежности и безопасности

·  Серверное оборудование системы Mobi Service размещается в защищенных помещениях дата-центра;

·  Передача данных по HTTPS осуществляется c использованием аутентификации на основе SSL сертификата с длиной ключа 2048 bit;

·  При необходимости возможна организация SSH-туннеля для передачи данных между системой Mobi Service и ИС Заказчика.

Резервное копирование данных

Независимо от метода интеграции в системе Mobi Service сохраняются все отправленные и полученные сообщения, включая текст сообщения, номер отправителя, номер получателя, статус доставки, дату/время отправки/получения. Сохраняется также журнал обмена запросами. Резервное копирование выполняется 5 раз в сутки. Архив хранится в течение 1 года.

Конкретная схема резервного копирования зависит от выбранного метода интеграции.

SMPP, XML

В случае выбора доступа по протоколу SMPP или метода XML-интеграции резервное копирование осуществляется автоматически сервером Mobi Service

DB-Gate

В случае выбора интеграции методом DB-Gate резервное копирование возлагается на информационную систему Заказчика и осуществляется по усмотрению Заказчика.

Администрирование

Возможности администрирования зависят от выбранного метода интеграции.

SMPP, XML

В случае выбора доступа по протоколу SMPP или метода XML-интеграции все задачи по администрированию и управлению доступом к данным решаются сервисной службой компании Mobi Service

DB-Gate

В случае выбора интеграции методом DB Gate администрирование модуля, встроенного в контур ИС Заказчика, возлагается на Заказчика и осуществляется средствами ИС Заказчика. Управление доступом к системе Mobi Service выполняется сервисной службой компании Mobi Service. Обычно, сервисная служба компании Mobi Service не имеет прав доступа ни к ИС Заказчика, ни к базе данных шлюза.

Порядок подключения

SMPP метод

В случае выбора метода интеграции SMPP установка дополнительного программного обеспечения в ИС Заказчика не требуется.

Для подключения необходимо:

1)  Убедиться, что ИС Заказчика поддерживает SMPP протокол;

2)  Сообщить в сервисную службу Mobi Service IP-адрес, с которого будет производиться подключение, и версию протокола SMPP;

3)  Получить IP - адрес и порт шлюза, произвести настройку сети клиента с целью обеспечения обмена между шлюзом и клиентом;

4)  Получить реквизиты SMPP-каналов (наименования пароли);

5)  Получить (заказать) номера отправителя (цифровые или буквенный);

6)  Произвести тестирование подключения.

XML-интеграция

В случае выбора метода XML-интеграции установка дополнительного программного обеспечения в информационной системе Банка не требуется.

Для подключения необходимо:

1)  Убедиться, что ИС заказчика поддерживает передачу XML-запросов оговоренного формата и обработку ответов.

2)  Получить реквизиты доступа (логин и пароль);

3)  Получить (заказать) номера отправителя (цифровые или буквенный);

4)  Произвести тестирование подключения.

DB-Gate метод

Для подключения необходимо:

1)  Получить программное обеспечение базы данных шлюза для установки;

2)  Получить (заказать) номера отправителя (цифровые или буквенный);

3)  Установить программное обеспечение базы данных шлюза следуя руководству пользователя;

4)  Выполнить настройку параметров подключения, следуя руководству пользователя;

5)  Запустить программное обеспечение, следуя руководству пользователя;

6)  Произвести тестирование подключения.

Руководство пользователя входит в комплект программного обеспечения.

Перечень документации

Заказчик обеспечивается следующей документацией:

·  Дистрибутив программного обеспечения (для DB-Gate метода);

·  Параметры доступа, логины пароли;

·  Руководство пользователя;

·  Примеры программного кода для реализации протоколов;

·  Прямые контакты (телефон, адрес электронной почты) специалистов компании Mobi Service, ответственных за выполнение интеграции.