Описание интеграционного протокола Oktell web-soсket protocol — различия между версиями
Zilant (обсуждение | вклад) |
Zilant (обсуждение | вклад) |
||
Строка 73: | Строка 73: | ||
+: При взаимодействии октелла и веб-системы используются одни и те же идентификаторы (например логины пользователей), соответственно отсутствует проблема привязки как таковая. | +: При взаимодействии октелла и веб-системы используются одни и те же идентификаторы (например логины пользователей), соответственно отсутствует проблема привязки как таковая. | ||
+ | |||
-: Пользователь вынужден перемещаться с одного компьютера на другой вместе со своим телефоном, или переназначая учетную запись в телефонном аппарате. | -: Пользователь вынужден перемещаться с одного компьютера на другой вместе со своим телефоном, или переназначая учетную запись в телефонном аппарате. | ||
Строка 79: | Строка 80: | ||
+: Кто бы ни залогинился с этого компьютера, приобретает управление телефоном, все звонки пользователю попадают на этот телефон. | +: Кто бы ни залогинился с этого компьютера, приобретает управление телефоном, все звонки пользователю попадают на этот телефон. | ||
+ | |||
-: Требует указания одного из постоянных идентификаторов компьютера в октелле, а также передачи его из веб-системы в момент логина для привязки. Это может быть айпи адрес, хостнейм или любой другой постоянный идентификатор. | -: Требует указания одного из постоянных идентификаторов компьютера в октелле, а также передачи его из веб-системы в момент логина для привязки. Это может быть айпи адрес, хостнейм или любой другой постоянный идентификатор. | ||
Логин в октелл нужен для приведения состояния пользователя в готовность. Без этого звонки на пользователя не поступают, а обрабатываются как и в случае, когда он недоступен. Логофф - обратная операция. В ходе взаимодействия пользователю доступны команды управления своим состоянием. Он может отлучиться, выставить перерыв, переадресацию, занятость и т.д. Все это нужно для того, чтобы изменить направление маршрутизации звонков и режим работы коллцентра. | Логин в октелл нужен для приведения состояния пользователя в готовность. Без этого звонки на пользователя не поступают, а обрабатываются как и в случае, когда он недоступен. Логофф - обратная операция. В ходе взаимодействия пользователю доступны команды управления своим состоянием. Он может отлучиться, выставить перерыв, переадресацию, занятость и т.д. Все это нужно для того, чтобы изменить направление маршрутизации звонков и режим работы коллцентра. | ||
− | Ограничение: Октелл не позволяет пользователям логиниться с разных рабочих мест одновременно. Делается это для того, чтобы каждому пользователю соответствовало не более одного телефона. | + | ''Ограничение: Октелл не позволяет пользователям логиниться с разных рабочих мест одновременно. Делается это для того, чтобы каждому пользователю соответствовало не более одного телефона.'' |
рис.4 | рис.4 |
Версия 14:19, 6 июня 2011
ИСХОДНЫЕ ДАННЫЕ:
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).
Среди параметров находятся и индивидуальные параметры сообщения. Поддерживается произвольная вложенность объектов: строк, чисел, дат, словарей, списков.
СПИСОК МЕТОДОВ ИНТЕРФЕЙСА