Описание интеграционного протокола Oktell web-soсket protocol — различия между версиями

Материал из Oktell
Страница-перенаправление
Перейти к: навигация, поиск
 
(не показаны 33 промежуточные версии 2 участников)
Строка 1: Строка 1:
ИСХОДНЫЕ ДАННЫЕ: 
+
#REDIRECT [[Oktell Web-Socket Protocol]]
 
+
1. Есть web-система, которыая на рабочем месте сотрудника используется через браузер.
+
2. Есть телефонная система, к которой подключен телефон, находящийся на рабочем месте сотрудника.
+
 
+
ЗАДАЧА
+
 
+
Объединить две системы функционально.
+
 
+
 
+
КРАТКОЕ ОПИСАНИЕ ВОЗМОЖНОСТЕЙ ТЕЛЕФОНИИ ОКТЕЛ
+
 
+
Стандартный функционал октелла предоставляет пользователям
+
доступ к управлению телефонами (позвонить, переключить, отклонить звонок, организовать конференцию, пригласить других участников в конференцию, подключиться к разговору в режиме прослушивания, помощи и т.д.).
+
доступ к управлению состояниями пользователей (перерыв - чтобы поток входящих звонков не поступал, занят - чтобы отметить факт обработки звонка, переадресация - чтобы все звонки на пользователя перенаправлялись в соответствии с настроенными правилами, готов - чтобы вернуться к обычному режиму).
+
информацию о текущем состоянии телефонов, внутренних номеров, пользователей с т.з. занятости в операциях телефонии.
+
информацию о поступающем звонке, абоненте
+
доступ к статистике разговоров (по правам).
+
доступ к записям разговоров (по правам).
+
доступ к информации об ожидающей очереди абонентов в реальном времени.
+
доступ к управлению режимом переадресации.
+
и т.д.
+
 
+
Помимо этого в рамках настройки сценариев октелла появляется возможность
+
отправлять синхронные и асинхронные запросы в веб-систему (фактически исполнять методы по событиям в октелле)и получать ответы и применять их в рамках проведения маршрутизации или любых других действий, реализуемых в сценариях.
+
 
+
Например, выяснить, какому клиенту/контакту принадлежит определившийся номер телефона или введенный им вручную с помощью DTMF-набора номер договора, отфильтровать по черному списку, переключить вызов на ответственного за работу с этим контактом пользователя, если пользователя нет в системе - переключить на секретаря, а если контакт новый - соединить с отделом продаж. Если ответственный пользователь занят, предложить оставить голосовое сообщение для VIP клиентов.
+
В момент поступления звонка открыть карточку у пользователя, которому звонок поступает. Закрыть ее автоматически, если пользователь так и не снял трубку (а снял кто-то другой, или звонок потерялся). Или выполнить какое-то важное с т.з. веб-системы действие в случае, если пользователь оставил заказ на встречный звонок, например.
+
 
+
Именно сценарии придают жизнь и востребованность октеллу и его сервисов
+
 
+
Среди событий октелла, отрабатываемых в сценариях
+
поступление внешнего звонка.
+
завершение звонка.
+
переключение абонента на пользователя, группу пользователей, задачу коллцентра.
+
любое из интересующих явлений в ходе обработки звонка (от преобразования номера абонента в нужный формат и сверки времени поступления звонка до обработки контента звонка после завершения и выявления там факта состоявшейся конференции).
+
наступление определенного времени.
+
периодический запуск по таймеру.
+
поступление/отправка e-mail.
+
поступление/отправка sms/icq/jabber.
+
контрольные события коллцентра (оператор первым положил трубку, оператор слишком долго находится в перерыве или поствызывной обработке, число операторов в задаче меньше минимально допустимого, число абонентов в очереди задачи больше допустимого и т.д.)
+
ручной запуск сценария по инициативе пользователя или веб-системы.
+
исходящий звонок от пользователя
+
поступление голосовой почты
+
появление где-то в базе данных интересующего события (например появление новой записи в таблице абонентов)
+
появление где-то на веб-ресурсе интересующего события (например температура на улице опустилась ниже нуля)
+
и т.д.
+
 
+
 
+
'''ПРЕДЛАГАЕМАЯ СХЕМА ИНТЕГРАЦИИ'''
+
 
+
 
+
 
+
рис.1
+
 
+
 
+
Сервер октелл взаимодействует с телефонами и с веб-сервером CRM.
+
Веб-сервер CRM взаимодействует ответно с сервером Октелл и с браузерами.
+
 
+
Первая проблема, предшествующая проведению обмену функционалом - сопоставление конкретных пользователей с конкретными телефонными устройствами. Почему это проблема: элементы управления устройством находятся в браузере, а влияют они на поведение конкретного телефона. Например, простейшая задача перевода звонка из браузера на врача Михайлова. Звонок должен поступить на телефон, находящийся в кабинете 103, за компьютером в котором сейчас сидит Михайлов (в браузере открыта веб-система и авторизован Михайлов)
+
 
+
Пользователи могут работать
+
- стационарно каждый за своим компьютером.
+
- перемещаться с одного рабочего место за другое.
+
- работать посменно за одним рабочим местом.
+
(Рабочее место = компьютер + телефон)
+
 
+
Необходимо в каждый момент времени знать, около какого телефона какой пользователь сидит.
+
 
+
'''Существуют два подхода к решению.'''
+
 
+
1. Жесткая привязка пользователя к телефонной учетной записи.
+
 
+
+: При взаимодействии октелла и веб-системы используются одни и те же идентификаторы (например логины пользователей), соответственно отсутствует проблема привязки как таковая.
+
-: Пользователь вынужден перемещаться с одного компьютера на другой вместе со своим телефоном, или переназначая учетную запись в телефонном аппарате.
+
 
+
 
+
2. Телефон привязывается к компьютеру, а в момент логина пользователя сопоставление производится через этот компьютер.
+
 
+
+: Кто бы ни залогинился с этого компьютера, приобретает управление телефоном, все звонки пользователю попадают на этот телефон.
+
-: Требует указания одного из постоянных идентификаторов компьютера в октелле, а также передачи его из веб-системы в момент логина для привязки. Это может быть айпи адрес, хостнейм или любой другой постоянный идентификатор.
+
 
+
Логин в октелл нужен для приведения состояния пользователя в готовность. Без этого звонки на пользователя не поступают, а обрабатываются как и в случае, когда он недоступен. Логофф - обратная операция. В ходе взаимодействия пользователю доступны команды управления своим состоянием. Он может отлучиться, выставить перерыв, переадресацию, занятость и т.д. Все это нужно для того, чтобы изменить направление маршрутизации звонков и режим работы коллцентра.
+
 
+
Ограничение: Октелл не позволяет пользователям логиниться с разных рабочих мест одновременно. Делается это для того, чтобы каждому пользователю соответствовало не более одного телефона.
+
 
+
рис.4
+
 
+
Все взаимодействие между октеллом и веб системой идет по общему каналу путем обмена сообщениями.
+
В каждом из сообщений должен присутствовать идентификатор, позволяющий различать одинаковые, но направляемые от разных пользователей команды из веб-системы в октелл и наоборот соответственно.
+
В качестве идентификатора в зависимости от реализуемой схемы привязки могут выступать пользователь (например его логин) или рабочее место (его постоянный идентификатор).
+
 
+
Октелл генерирует события.
+
Октелл производит запросы к веб-системе.
+
Веб-система отправляет ответы на получаемые запросы.
+
 
+
Веб-система производит запросы к октеллу. В том числе и команды.
+
Октелл отправляет ответы на запросы.
+
 
+
Взаимодействие на транспортном уровне может происходить по websocket, http, udp.
+
Формат представления сообщений json или xml.
+
Формат самих сообщений определяется непосредственно протоколом интеграции. Например вот так выглядит сообщение из октелла в веб-систему о факте входящего вызова в формате json:
+
 
+
рис.5
+
 
+
Для исполнения динамических методов в веб-срм по событиям в октелле существует запрос, в ответ на который веб-система перечисляет список действий, инициативу исполнения которых она готова отдать наружу в октелл. При описании метода упоминаются
+
человеческое название,
+
краткий код метода,
+
описание для администратора, настраивающего октелл,
+
список входных параметров с упоминанием типов (и возможных значений для перечислений),
+
список выходных параметров, если метод возвращает данные и призван влиять на алгоритм сценария в октелле,
+
признак того, нужно ли исполнять метод с привязкой к конкретному пользователю, или это обращение к серверу вообще,
+
разрешено ли отменять исполнение (например для метода «открыть карточку такую-то» возможна отмена, означающая «закрыть карточку такую-то»),
+
куда октеллу гнать запрос - через сокет (стандартный для взаимодействия канал) или по http на альтернативный url веб-сервера.
+
 
+
 
+
Соответственно, когда настраивается сценарий в октелле, администратором определяется одно или несколько из доступных действий, определяется момент исполнения, определяются входные параметры или способ их вычисления, а также режим ожидания или асинхронного выполнения.
+
В рантайм октеллом отправляется команда на исполнение в соответствии с определенными админом настройками. Если метод призван исполняться синхронно и возвращать некие значения, то сценарий приостанавливается, а после получения ответа сохраняет результаты в переменных сценария и продолжает выполнение.
+
 
+
 
+
'''WEB-SOCKET'''
+
 
+
Между октеллом и веб-сервером CRM-системы существует один канал для обмена сообщениями. Все сообщения имеют идентификаторы для организации серий типа “запрос-ответ”.
+
Сообщения могут адресоваться конкретному пользователю или относиться к общим. В первом случае указывается идентификатор/логин пользователя. Касается обоих направлений пересылки.
+
 
+
Установка соединения может производиться как октеллом, так и веб-сервером CRM-системы. В случае разрыва соединения сторона-инициатор вновь организует подключение.
+
Рукопожатие на установление web-socket соединения предлагается также стороной-инициатором. Подробнее http://ru.wikipedia.org/wiki/WebSocket.
+
 
+
Каждое сообщение представляет из себя строку XML или JSON в кодировке UTF8. Сообщения в общем потоке данных в канале отделяются друг от друга байтами 0 и 255. 0 - в начале сообщений, 255 в конце. Форматы XML и JSON представления данных в текстовом виде гарантируют отсутствие байтов 0 и 255 в теле сообщений.
+
 
+
Сообщения длиной более 64К упаковываются в Base64 и разбиваются на несколько сообщений длиной до 64К. Формат multipart сообщения определен отдельно.
+
 
+
После установки соединения системы обмениваются данными друг о друге, об авторизованных пользователях, о динамических методах.
+
 
+
Общий формат сообщения
+
 
+
Структура каждого сообщения - это список из двух объектов, первый из которых - тип сообщения, второй - словарь параметров. В словаре обязательно присутствует идентификатор запроса (любое текстовое уникальное значение). В случае, когда сообщение производится от имени пользователя, присутствуют его идентификаторы (userid, userlogin).
+
 
+
 
+
Среди параметров находятся и индивидуальные параметры сообщения. Поддерживается произвольная вложенность объектов: строк, чисел, дат, словарей, списков.
+
 
+
 
+
СПИСОК МЕТОДОВ ИНТЕРФЕЙСА
+

Текущая версия на 12:51, 17 сентября 2012