|
|
| (не показано 36 промежуточных версии 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).
| + | |
| − | | + | |
| − | | + | |
| − | Среди параметров находятся и индивидуальные параметры сообщения. Поддерживается произвольная вложенность объектов: строк, чисел, дат, словарей, списков.
| + | |
| − | | + | |
| − | | + | |
| − | СПИСОК МЕТОДОВ ИНТЕРФЕЙСА
| + | |
