|
Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
|
|
Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
Описание рабочего места оператора.Стр 1 из 6Следующая ⇒
Схема подключения Рис 1. Инфраструктурная схема NCC 6.3
В инфраструктуре СТД Петрович Система Naumen Contact Center располагается на четырёх виртуальных серверах в системе виртуализации VMware 5.5. SIP подаётся по трем Mediant – шлюзам, два из которых являются резервными, а также напрямую через Internet (актуально для шлюзов АКЦ и регионов). Подробное их описание содержится в таблице 1. Таблица 1. Используемые шлюзы
Общая логика работы IVR. Изначально все вызовы поступают на три очереди без операторов: IVR SPB, IVR MSK, IVR SZFO. На этих IVR часть вызовов (те, кто нажал какую – либо кнопку в тоновом наборе) уходят на другие очереди в корпоративный контакт – центр СТД Петрович, а часть переливается в аутсорсинговые контакт – центры (Gran, Newcontact – далее по тексту АКЦ). Фреймворк содержится в client/custom_sm3/. В ivr_sm3.xml этот каталог прописан в качестве BaseProduct. Smart Routing Звонки клиентов, обращающихся в КЦ повторно, маршрутизируются исходя из категории их предыдущих обращений. Категория обращения выбирается оператором на форме анкеты в флекс атрибуте с кодом «cdisp» типа «Элемент справочника». Обычно используется глобальный справочник «Call Disposition», но возможно использование и других справочников. Система анализирует последние x категорий обращения (по коду элемента справочника) для определившегося автоматически номера телефона и в случае совпадения y из x кодов завершения, маршрутизирует звонок в соответствии с таблицей маршрутизации. Таблица 2. Таблица маршрутизации
Таблица маршрутизации настраивается в справочнике «Интеллектуальная маршрутизация». Код элемента соответствует коду категории обращения. Допускается указывать коды в формате <код категории>:<citycall>. Название элемента – либо DNIS, либо uuid очереди. В случае DNIS будет совершено перенаправление на указанный номер, в случае uuid очереди – разблокировка вызова в соответствующей очереди (через CHANGECALLPROJECT). Существует возможность изменения значений размера выборки x и значения совпадений y в конфигурационном файле сервиса Enquiry Data Store (EDS). *ограничение: значения x и y одинаковы для всех пар «код завершения» - «маршрутизация». В IVR в умной маршрутизации участвуют блоки Magic Routing и Smart Routing. Блоки бывают двух типов: простые и комплексные. Простые не содержат внутри других блоков, выполняют код на языке Python. Комплексные блоки, к которым относятся Magic Routing и Smart Routing, содержат внутри другие блоки, как простые, так и комплексные. Блок Magic Routing в качестве параметра принимает номер звонящего (CALLER_ID) и таймаут выполнения HTTP-запроса (TIMEOUT). Выполняет запрос GET /magic_routing к сервису EDS, адрес сервиса блок получает из параметра IVR-скрипта eds_url (/opt/naumen/nauphone/spool/naubuddy/ivr/client/custom_sm3/params.xml). В качестве параметра citycall в GET-запрос подставляется параметр вызова citycall, который установлен на момент выполнения блока. Атрибут data из ответа сервиса сохраняется в self.magic_routing. Блок Smart Routing проверяет параметр вызова smart_routing: если параметр уже установлен, для предотвращения повторного срабатывания срабатывает выход FAIL, при этом параметру присваивается значение loop. Далее анализируется атрибут smart_routing.projectid в JSON, сохраненном в self.magic_routing: если он отсутствует или пуст, срабатывает выход FAIL, параметру smart_routing присваивается значение false, иначе ему присваивается значение true; если smart_routing.projectid содержит uuid проекта (проверяется по наличию префикса corebo), выполняется команда CHANGECALLPROJECT, срабатывает выход QUEUE; иначе совершается попытка трансфера на номер, полученный в параметре smart_routing.projectid, если попытка трансфера не успешна, срабатывает выход FAIL. В IVR существуют блоки, которые обращаются к спискам VIP, VIP2, SList, EList, BlackList для того, чтобы звонок мог правильно маршрутизироваться. Списки VIP, VIP2, SList, EList – включают в себя вип – клиентов, BlackList – чёрный список. Данные списки обновляются вручную через полное удаление клиент – каталога и загрузки нового файла в формате .xls или .xslx с обновлёнными данными. Номер телефона должен быть в следующем формате – 11 цифр, начинающихся с восьмёрки.
3. Описание настройки проектов Общее описание В Системе присутствуют проекты следующих типов: входящие, исходящие, автоинформаторы, по обработке Webchat, E - mail обращений и SMS – обращений (таблица 3). Обращения по Webchat поступают с двух сайтов: http://new.beta.kluatr.ru/ (бета - версия) и http://petrovich.ru/. Сообщения, поступающие с бета – сайта приходят в Naumen Contact Center через шлюз [email protected]. Сообщения, поступающие с главного сайта, приходят в мобильное приложение Webim. Для проекта по обработке входящих SMS – сообщений в Системе используется шлюз smpp.smsc.ru, для отправки SMS с формы анкеты используется шлюз smpp.qtelecom.ru. Все SMS – сообщения поступают в формате 7-ххх-ххх-хх-хх (ограничение SMS провайдера). Для автоматического определения клиента по номеру телефона реализована функция, которая заменяет 7 на 8, и клиент определяется автоматически (так как формат номера клиентов в клиент – каталоге 8-ххх-ххх-хх-хх). Эта функция находится в скрипте petrovich.js, который располагается в /opt/naumen/naucrm/server/webapps/UserFiles/js: self.data.caller =phoneControllerService.caller; if (self.data.caller.match(/^(7|\+7)?[0-9]{10}$/g)) self.data.caller = ('8' + self.data.caller.slice(-10)) Таблица 3. Типы проектов
Анкеты на всех проектах унифицированы, состоят из одной формы и имеют общую функциональность (таблица 4). Таблица 4. Основной функционал анкет
Одновременно оператор может обрабатывать один звонок, одно e-mail обращение, одно sms-обращение и несколько Webchat сессий (количество сессий гибко настраивается). Исключение составляет ситуация, в которой клиент, e-mail которого уже обрабатывается оператором, совершает звонок в контакт - центр. В этом случае звонок принудительно придет оператору в сессию обработки e-mail обращения этого клиента (п. 3.2.1). Операторы могут участвовать одновременно в нескольких проектах по обработке обращений с разных каналов связи. Интеграция с 1С 3.3.1. Функция для создания предзаполненного заказа в 1С Во время обработки обращения у операторов корпоративного контакт – центра СТД Петрович есть возможность перейти в интерфейс 1С из интерфейса Softphone для оформления заказа. Для этого на анкету добавлена кнопка «Создать заказ в 1С» с действием скрипт. По ее нажатию у оператора открывается предзаполненная форма заказа в интерфейсе 1С. При нажатии на кнопку «Создать заказ в 1С» во входящих проектах у оператора открывается интерфейс 1С с перезаполненными полями по клиенту, выбранному в компоненте «Информация о клиенте». При поступлении заказа с сайта (исходящий проект), оператору необходимо связаться с клиентом для подтверждения заказа. При нажатии на кнопку «Создать заказ в 1С» у оператора открывается заказ в интерфейсе 1С, созданный клиентом на сайте. Для входящих и исходящих проектов используется метод petrovich.action_open1c (таблица 5). При каждом нажатии кнопки «Создать заказ в 1С» через WebSoket API устанавливаются следующие параметры: citycall, customerId и useraction. 1С через WebSoket API отслеживает изменение этих параметров. Если он равен OpenNewOrderForm (устанавливается на входящих проектах), то 1С анализирует параметры citycall и customerId, если OpenOrderForm (устанавливается на исходящих проектах), то анализируется параметр citycall и npcp-third-party-external-id, который является идентификатором кейса, из которого достается идентификатор заказа, и по нему 1С открывает нужный заказ. Список заказов формируется следующим образом: клиент создаёт заказ на сайте, заказ формируется в 1С, затем 1С отдает кейс в Naumen Contact Center с нужным идентификатором заказа. Работы с заказами происходит в рамках обработки одной сессии. Кейсы в Системе создаются из мобильного приложения и из 1С (заказы с сайта). Кейсы из мобильного приложения формируются в проект «Звонок с приложения». Задание на исходящий обзвон создаётся в следующем формате: <?xml version="1.0" encoding="UTF-8"?> <callcase> <comment>MSK</comment> // код города, из которого происходит заказ звонка (ниже полный список) <title> Алексей </title> // имя клиента <state> <id>adjourned</id> </state> <scheduledTime>2016-04-15T09:19:48</scheduledTime> // время, на которое клиент заказал звонок <phoneNumbers> <phoneNumber phoneNumberType="HOME">89623699763</phoneNumber> </phoneNumbers> </callcase>
SPb MSK NOVG VBRG LUGA KING PETR TVER SZFO URL:http://172.16.90.27:8080/fx/api/xml/callcases/project=corebolg85k6o0000lj651nuajb6pifc
Получение истории заказов При обработке обращения оператору необходимо иметь возможность просмотреть историю заказов клиента из 1С8 в интерфейсе Softphone. На форме анкеты проекта это выглядит следующим образом: создан блок «история заказов», который представляет из себя таблицу с полями: дата, номер заказа, контрагент, ИНН, ККД, ответственный, статус. «История заказов»» отображает все заказы по выбранному клиенту. Также создан блок «контрагент», который представляет из себя таблицу со следующими полями: контрагент, ИНН, ККД и отображает список существующих контрагентов. Запрос на получение истории заказов выполняется вручную нажатием кнопки «Отобразить заказы из 1С». Для реализации возможности просмотра «Истории заказов» используется интеграционная прослойка между 1С и бизнес – системой PMS.
Рис 8. Диаграмма взаимодействия компонентов
Рис 9. Диаграмма последовательности взаимодействия компонентов посредством clientextid
Рис 10. Диаграмма последовательности взаимодействия компонентов посредством clientid
Реализовано два варианта получения истории заказов из 1С: 1. По параметру clientextid (внешний идентификатор), при котором запрос по данным клиента делается через PMS REST (рис. 9); 2. По параметру clientid (UUID клиента), если по какой – либо причине отсутствует внешний идентификатор (рис. 10). Внешним идентификатором в СТД «Петрович» принято считать мобильный телефон клиента. Получение истории заказов из 1С по параметру clientextid происходит следующим образом: 1. При поступлении звонка клиент определяется в блоке «Информация о клиенте»; 2. Так как внешний сервис на анкете не может обратиться напрямую к 1С и получить оттуда данные, он обращается к интеграционному шлюзу Enquiry Data Store (далее EDS, полное его описание находится в приложении 2) с указанным параметром clientextid; 3. EDS по внешнему идентификатору обращается к PMS REST; 4. Информация о клиенте возвращается из PMS REST в EDS; 5. В неизменном виде эта информация передается из EDS в 1C; 6. 1С возвращает всю историю заказов по номерам, которые были переданы из EDS; 7. EDS возвращает полученные данные в блок «История заказов» на анкете. Разница между первым и вторым вариантом получения истории заказов состоит в следующем: в случае, если внешний идентификатор отсутствует, EDS обращается к отчётной базе PMS SQL по полученному параметру clientid (рис. 10). Остальная логика работы остается неизменной. В общем виде запрос выглядит следующим образом: · GET/rest1_gethistory?clientextid=… - через параметр clientextid; · GET/rest1_gethistory?clientid=… - через параметр clientid. Формат ответа: · {status:200_<статус получения данных клиента>_<статус обращения к 1С>, data:<тело ответа от 1С>}; · {status:500, err:<ошибка>}. Примеры статусов: · 200_200_200 – ОК; · 200_200_500 – ошибка обращения к 1С (1С вернула что-то отличное от 200); · 200_200_504 – не удалось подключиться к 1С; · 200_504_underfined – не удалось подключиться к REST API PMS.
4. Интеграция с Uniteller (оператор платёжного интернет-шлюза) Используется для IVR оплаты банковской картой. Абоненту предлагается ввести PAN, месяц и год истечения карты, CVV. После этого скрипт отправляет специальным образом оформленный HTTP запрос (POST). Модуль интеграции находится в каталоге /opt/naumen/nauphone/spool/naubuddy/ivr/client/integration/uniteller. IVR-скрипт payment_service.xml. Поддержка Uniteller: [email protected] Рис. 11. Схема оплаты заказов
5. Интеграция с Active Directory Приложение 1. Полное описание файла petrovich.js Файл petrovich.js содержит описание синглтона petrovich, синглтон используется в качестве пространства имен. Зависимости
Как внедрить на форму Скрипт необходимо разместить в каталоге /opt/naucrm/server/webapps/fx/UserFiles/js на сервере PMS При редактировании представления формы нажать изменить скрипт, в конец тега <fields-table /> добавить: <fields-holder align="top" autoFitcols="100" height="1px;display:block;overflow:hidden;visibility:hidden" order="custom" rows="1" splitWidth="30%"> <frame-view height="1" uri="javascript:window.parent.jQuery.data(window.parent.document.body,'agent.login','{agent}');window.parent.jQuery.getScript('/fx/UserFiles/js/petrovich.js')"> <item type="expr" value="agent">${user.login}</item> </frame-view> </fields-holder>Конфигурация Файл petrovich_conf.js добавлен в .gitignore, подгружается при выполнении petrovich.main, ожидается, что в этом файле описан объект, оформленный в виде RequireJS модуля. Атрибуты этого объекта переопределяют атрибуты petrovich. Например: define({ eds: { url: 'http://172.16.90.26:8008' }});petrovich petrovich.eds Интеграция с Enquiry Data Store petrovich.eds.url Корневой URL сервиса petrovich.eds.post_enquiry_handling(agent, client) jQuery.ajax POST /enquiry_handling petrovich.eds.delete_enquiry_handling(agent) jQuery.ajax DELETE /enquiry_handling Выполняется синхронно, т.к. предназначено для использования на кнопке "Завершить" (см. petrovich.action_finish) petrovich.ws Интеграция с WS API SoftPhone. Инициализируется в petrovich.main. petrovich.ws.nauphone Объект класса NauPhone. см. petrovich.main petrovich.ws.getcall Текущий вызов. см. petrovich.main petrovich.ws.setCallParam(key, value) Метод для установки параметра вызова с помощью WS API SoftPhone petrovich.init() Метод для инициализации плагина, вызывается по событию jQuery(document).ready Подгружает библиотеку /fx/UserFiles/js/3rdparty/require.js, с помощью нее подгружает остальные необходимые библиотеки После загрузки библиотек выполняет petrovich.main petrovich.main(RequireJS modules ...) Подгружает petrovich_conf.js Сохраняет логин оператора в petrovich.agent (важно правильно внедрить на форму, см. Как внедрить на форму) Подключается к WS API SoftPhone: Создает объект класса NauPhone, присваивает атрибуту petrovich.ws.nauphone После успешного подключения присваивает Promise NauPhone.getCall атрибуту petrovich.ws.getcall Устанавливает обработчик на событие jQuery('#acf_cp1').parent().observe('childlist subtree'), при изменении расширения Информация о клиенте обработчик вызывает petrovich.ui_fix_cp petrovich.action_cp Вызывает petrovich.ui_fix Вызывает petrovich.action_cp Устанавливает обработчик на событие jQuery('#finish').click, при нажатии на кнопку Завершить (до отправки формы) будет вызван petrovich.action_finish, petrovich.action_finish может препятствовать завершению формы. Проигрывает звук для текстовых обращений Если тип обращения xmpp, добавляет callback для atmosphere, чтобы звук проигрывался на каждое новое сообщение. (Потенциально может привести к проблемам с чатами, но маловероятно.) petrovich.agent Атрибут хранит логин оператора. petrovich.debug_refresh() Переход по адресу /fx/npi/callmanager?session_id=fake&caller=89001234567&called=0000&direction=in&seance_id=seanceId&project_id=<uuid проекта>&case_uuid=&service_mode=&citycall=MSK. petrovich.ui_fix() Прячет последний <fields-holder />, который используется для внедрния скрипта на анкету (см. Как внедрить на форму) Вызывает petrovich.ui_fix_cp petrovich.ui_fix_cp() Прячет табы (нам не нужны Юридические лица) Прячет поле Идентификатор (оператор не должен его видеть и изменять) petrovich.action_cp() Вызывается при каждом изменении в расширении Информация о клиенте (см. petrovich.init) Копирует Мобильный телефон в Идентификатор Если обрабатывается почта, вызывает petrovich.eds.post_enquiry_handling(petrovich.agent, <uuid выбранного клиента>) Если выбран пункт Новый клиент для голосовых вызовов копирует phoneControllerService.caller в Мобильный телефон, для почты - в Email petrovich.action_finish() Вызывается при нажатии Завершить (см. petrovich.init) Если обрабатывается почта, вызывает petrovich.eds.delete_enquiry_handling(petrovich.agent) Если в Информации о клиенте выбран пункт Новый клиент, препятствует закрытию анкеты petrovich.action_citycall() deprecated petrovich.action_open1c(useraction = 'openNewOrderForm') С помощтю WS API устанавливает параметры вызова citycall (из флекса citycall) и customerID (из Отображения списков с идентификатором rest1c_customers). Устанавливает параметр вызова useraction. После успешнго установления параметра useraction сбасывает его значение на 'none', что позволяет нажимать кнопку несколько раз. Приложение 2. Описание интеграционного шлюза Enquiry Data Store HTTP-сервис, разработан для проекта СТД Петрович. Назначение Временное хранение данных, связанных с обращением Интеграционный шлюз Окружение (необходимо для работы) Redis (собственный) Отчетная база PMS (PostgreSQL) REST API PMS Настройки Конфигурационные файлы: conf/config.ini, conf/acl.ini, conf/passwd.ini. config.ini [pg] требует перезапуска conString URL отчетной базы PMS формат [pg.options] Опции подключения к PostgreSQL [redis] требует перезапуска conString URL Redis формат [redis.options] Опции подключения к Redis [app] port требует перезапуска TCP-порт, который будет слушать приложение unix_sock требует перезапуска Unix domain socket, потенциально можно увеличить производительность при обращении из IVR mask_status_code_for[] Список логинов, для которых вместо реального кода ответа нужно отправлять 200 (при этом аутентификация может не требоваться) [app.pms_api] PMS RESTful API url username password timeout [app.minify_flex_attributes] Описание того, какие поля mv_flex_attribute необходимо возвращать в зависимости от typecode при получении клиента из БД FlexType.Something = stringcontent - строковое значение FlexType.Something[] = stringcontent - список строк FlexType.Something = [ "stringcontent" ] - список строк FlexType.Something = {"value": "stringcontent", "somethingelse": "stringcontent2"} - сложные типы FlexType.Something[] = {"value": "stringcontent", "somethingelse": "stringcontent2"} FlexType.Something = [ {"value": "stringcontent", "somethingelse": "stringcontent2"} ] [app.client_catalog] catalog_uuid Клиент-каталог, в котором будет производиться поиск клиентов partner_uuid Идентификатор партнера, в котором создан клиент-каталог [app.outsource_comment] expire Время жизни комментария, установленного с помощью POST /outsource_comment [app.smart_routing] catalog_uuid UUID каталога, который устанавливает связь кода категории обращения (код элемента) и UUID проекта (название элемента) flex Флекс-атрибут формы, хранящий категорию обращения X Количество последних обращений клиента, которые нужно учесть при интеллектуальной маршрутизации Y Минимальное количество одинаковых категорий обращения среди последних X для принятия решения по интеллектуальной маршрутизации [app.rest1c_gethistory] 1С RESTful API url timeout acl.ini Содержит описание прав доступа. Формат [<method> <path>] ip[] = <CIDR net> user[] = <login> Например: [GET /something] ip[] = 10.0.0.0/8 ip[] = 172.16.0.0/12 ip[] = 192.168.0.0/16
[POST /something] user[] = user1
[* /something] ip[] = 127.0.0.0/8
[GET *] user[] = user1
[* *] user[] = superuser Типы правил [<method> <path>] [* <path>] [<method> *] [* *] Логика работы правил Если запрос не попадает ни под одно правило, он будет отклонен. Если запрос осуществляется из подсети, указанной в списке ip, он разрешается, успешная аутентификация при этом не требуется. Если запрос осуществляется не из подсети, указанной в списке ip, пользователь обязан успешно пройти аутентификацию (Basic Auth) (см. passwd.ini). passwd.ini Формат [<login>] md5 = <хеш пароля> Логирование В файле conf/logger.js можно описать особый модуль логирования. Установка и запуск git clone https://callcenter.naumen.ru/gerrit/petrovich/enquiry_datastore cd ./enquiry_datastore make redis # если еще нет подготовленного Redis Make install service eds start HTTP запросы Ответ на HTTP-запросы возвращается в формате JSON. POST-запросы в качестве тела принимают параметры формы (application/x-www-form-urlencoded, multipart/form-data). Для удобства использования в контроллере Внешний сервис запрос возможно указывать в GET- или POST-параметре query вместо пути. GET /?query=make_something¶m1=somedata --> GET /make_something?param1=somedata POST /?query=make_something {param1: somedata} --> POST /make_something {param1: somedata} Также при использовании метода GET возможно переопределить метод указанием параметра method. GET /make_something?param1=somedata&method=DELETE --> DELETE /make_something?param1=somedata Поддерживается CORS, сервер отправляет заголоки: Access-Control-Allow-Origin: * Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept Access-Control-Allow-Methods: PUT, GET, POST, DELETE, OPTIONS Access-Control-Max-Age: 86400 Коды ответа
enquiry_handling Назначение Обеспечить возможность докинуть звонок оператору, который сейчас обрабатывает письмо этого же клиента. POST /enquiry_handling {agent: ..., client: ...} POST /enquiry_handling/:agent {client: ...} Назначение Сохранить связь логина оператора (agent) и UUID клиента (client). Формат ответа {status:201, data:['MULTI', <ответы Redis>]} {status:500, err:<ошибка>} Где используется На анкете обработки текстовых обращений (по ТЗ - писем) в момент выбора клиента в расширении Информация о клиенте. см. GET /magic_routing Как работает Redis: get eh:agent:<agent> --> <старый UUID клиента> get eh:client:<client> --> <старый логин оператора> del eh:agent:<старый логин оператора> del eh:client:<старый UUID клиента> set eh:agent:<agent> <client> set eh:client:<client> <agent> DELETE /enquiry_handling?agent=... DELETE /enquiry_handling/:agent Назначение Удалить связь логина оператора (agent) и UUID клиента. Формат ответа {status:200, data:['MULTI', <ответы Redis>]} {status:500, err:<ошибка>} Где используется На анкете обработки текстовых обращений (по ТЗ - писем) в момент нажатия Завершить (фактически - на удачу, при закрытии анкеты может срабатывать не всегда, но проблем это вызывать не должно). Как работает Redis: get eh:agent:<agent> --> <UUID клиента> del eh:agent:<agent> del eh:client:<UUID клиента> GET /enquiry_handlings Назначение Получить все ключи Redis eh:*. Формат ответа {status:200, data:['KEYS', <ответы Redis>]} {status:500, err:<ошибка>} Где используется Тесты, ручная отладка. Как работает Redis: keys eh:* DELETE /enquiry_handlings Назначение Удалить все свзяи (ключи eh:*). Формат ответа {status:200, data:['DEL', <ответы Redis>]} Где используется Тесты, ручная отладка. Как работает Redis: del eh:* outsource_comment Назначение Передать комментарий оператора АКЦ на анкету оператора "домашнего" КЦ. Текущими средствами NCC невозможно связать звонок АКЦ со звонком "домашнего" КЦ (если не обращаться к CallsList'ам). POST /outsource_comment {caller: ..., comment: ...} POST /outsource_comment/:caller {comment: ...} Назначение Сохранить комментарий (comment) для данного CallerID (caller). Формат ответа {status:201, data:['SET', <ответы Redis>]} {status:500, err:<ошибка>} Где используется Анкета АКЦ (Внешний сервис) до совершения трансфера. Как работает Redis: set outc:<caller> <comment> ex <config[app.outsource_comment].expire> GET /outsource_comment?caller=... GET /outsource_comment/:caller Назначение Получить комментарий для данного CallerID (caller). Формат ответа {status:200, data:['GET', <ответы Redis>]} {status:500, err:<ошибка>} Где используется Анкета "домашнего" КЦ (Внешний сервис). Как работает Redis: get outc:<caller> GET /outsource_comments Назначение Получить все ключи Redis outc:*. Формат ответа {status:200, data:['KEYS', <ответы Redis>]} {status:500, err:<ошибка>} Где используется Тесты, ручная отладка. Как работает Redis: keys outc:* DELETE /outsource_comments Назначение Удалить все свзяи (ключи outc:*). Формат ответа {status:200, data:['DEL', <ответы Redis>]} {status:500, err:<ошибка>} Где используется Тесты, ручная отладка. Как работает Redis: del outc:* search_client_by_phone GET /search_client_by_phone?phone=...[&count=...] GET /search_client_by_phone/:phone[?count=...] Назначение Получить UUID и title клиента (Физическое лицо) по номеру телефона (phone). Формат ответа {status:200, data:<строки результата SQL запроса>} {status:200, data:[{client:{uuid:<UUID клиента>, title:<Название клиента>, ...}, flex_attributes:{...}}] {status:500, err:<ошибка>} Где используется Поглощено magic_routing. Как работает см. sql/search_client_by_phone.sql GET /outsource_client_by_phone?phone=... GET /outsource_client_by_phone/:phone Нет автотестов Аналогично GET /search_client_by_phone, зафиксирован параметр count=1, не возвращает флекс-атрибуты. Формат ответа {status:200, data:{client:{uuid:<UUID клиента>, title:<Название клиента>, ...}}] {status:500, err:<ошибка>} Где используется Анкета АКЦ (Внешний сервис) Как работает см. GET /search_client_by_phone smart_routing Нет автотестов GET /smart_routing?clientid=...[&citycall=...] GET /smart_routing/:clientid[?citycall=...] Назначение Проанализировать последние config[app.smart_routing].X обращений клиента (по UUID (clientid)) на предмет наличия минимум config[app.smart_routing].Y одинаковых категорий обращения. Формат ответа {status:200, data:null} {status:200, data:{category:<код категории>, projectid:<UUID проекта>, count:<количество одинаковых категорий>} {status:500, err:<ошибка>} Где используется Поглощено magic_routing. Как работает см. sql/smart_routing.sql magic_routing Нет автотестов GET /magic_routing?phone=...[&citycall=...] GET /magic_routing/:phone[&citycall=...] Назначение Попытка собрать всю магию IVR в один запрос. Формат ответа {status:200, data:null} {status:200, data:{client:{uuid:<UUID клиента>, title:<Название клиента>, ...}, flex_attributes:{...}, eh_agent:['GET', <ответы Redis>], smart_routing:{category:<код категории>, projectid:<UUID проекта или DNIS>, count:<количество одинаковых категорий>}, phone_category:{vip:0, blacklist:1,...}} {status:500, err:<ошибка>} Где используется IVR Как работает search_client_by_phone + Redis get eh:client:<client> + smart_routing + sql/phone_categorization.sql rest1c_gethistory Нет автотестов GET /rest1c_gethistory?clientextid=... GET /rest1c_gethistory?clientid=... GET /rest1c_gethistory/:clientextid Назначение Получение истории заказов. Интеграционная прослойка между PMS и 1С. Формат ответа {status:200_<статус получения данных клиента>_<статус обращения к 1C>, data:<тело ответа от 1С>} {status:500, err:<ошибка>} Примеры статусов: 200_200_200 - OK 200_200_500 - ошибка обращения к 1С (1С вернула что-то отличное от 200) 200_200_504 - не удалось подключиться к 1С 200_504_undefined - не удалось подключиться к REST API PMS Где используется Анкета "домашнего" КЦ (Внешний сервис). Как работает Если определен параметр clientextid, получаем по этому идентификатору клиента через REST API PMS. Если определен параметр clientid, получаем данные клиента из БД (sql/get_client_by_uuid.sql). По просьбе Виктора Вересоа [email protected] удаляем из JSON атрибут @type. Данные клиента в виде JSON отправляем сервису 1С POST-запросом.
Схема подключения Рис 1. Инфраструктурная схема NCC 6.3
В инфраструктуре СТД Петрович Система Naumen Contact Center располагается на четырёх виртуальных серверах в системе виртуализации VMware 5.5. SIP подаётся по трем Mediant – шлюзам, два из которых являются резервными, а также напрямую через Internet (актуально для шлюзов АКЦ и регионов). Подробное их описание содержится в таблице 1. Таблица 1. Используемые шлюзы
Описание рабочего места оператора. Оператор контакт-центра в своей работе помимо Softphone использует ПО 1С8. Softphone установлен на локальной машине оператора, базы 1С8 (всего оператор одновременно использует три экземпляра 1С8: Москва, СПБ, СЗФО) установлены на терминальном сервере, доступ к которому оператор имеет через RDP. Бóльшая часть операторов работает на гарнитурах, меньшая – на IP – телефонах в режиме agentmanager. В связи с тем, что операторы не закреплены за своими рабочими местами, был разработан интерфейс динамической привязки hardphone к Softphone. Со стороны сервера NCC реализован интерфейс привязки, со стороны клиента – веб – интерфейс, в котором по нажатию кнопки используется механизм привязки номера BindNumber. Рис 2. Диаграмма последовательности привязки hardphone к Softphone
Оператор со своего рабочего места заходит по ссылке http://nau02.stdp.ru/bindphone, вписывает свой добавочный номер, далее нажимает кнопку «зарегистрировать». После этого оператор может начать работу. Web-страницу на nau02.stdp.ru обслуживает nginx. Код страницы расположен в каталоге /opt/landingpage. При регистрации нового добавочного номера привязка к старому перестаёт действовать. Посмотреть, зарегистрирован ли номер можно в логе /opt/naumen/nauphone/log/nauagentmanager.log. При использовании гарнитуры предыдущие действия не требуются, после ее подключения оператор может начинать работу сразу. Рис 3. Инфраструктурная схема
В связи с одновременной работой операторов в трех базах 1С8 возникает задача принятия решения, в какой именно базе открыть заказ при нажатии кнопки «Открыть заказ в 1С» (подробнее в пункте 3.3). Данная задача решается на стороне 1С8 путем анализа (запрос oncallparams через websocket connection) параметра вызова citycall, который назначается правилами маршрутизации при поступлении звонка в систему (рис. 4). Рис 4. Правила маршрутизации для идентификации города
2. Маршрутизация звонков Общая логика работы IVR. Изначально все вызовы поступают на три очереди без операторов: IVR SPB, IVR MSK, IVR SZFO. На этих IVR часть вызовов (те, кто нажал какую – либо кнопку в тоновом наборе) уходят на другие очереди в корпоративный контакт – центр СТД Петрович, а часть переливается в аутсорсинговые контакт – центры (Gran, Newcontact – далее по тексту АКЦ). Фреймворк содержится в client/custom_sm3/. В ivr_sm3.xml этот каталог прописан в качестве BaseProduct. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Последнее изменение этой страницы: 2019-04-10; Просмотров: 359; Нарушение авторского права страницы
