Урок 28 Служебный сценарий обработки контента — различия между версиями
Строка 21: | Строка 21: | ||
− | + | ==Сценарий обработки контента == | |
− | + | ||
− | + | ||
− | Сценарий | + | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
Осуществляет чтение или изменение пользовательского поля выбранного контента. В ходе работы с каналом системой производится сбор и формирование контента. Это XML документ, который существует в памяти сервера и постоянно пополняется происходящими действиями в ходе обработки вызова. Контент линии существует только у внешних линий, формируется при поступлении или совершении звонка по каналу, и сбрасывается при завершении этого звонка. | Осуществляет чтение или изменение пользовательского поля выбранного контента. В ходе работы с каналом системой производится сбор и формирование контента. Это XML документ, который существует в памяти сервера и постоянно пополняется происходящими действиями в ходе обработки вызова. Контент линии существует только у внешних линий, формируется при поступлении или совершении звонка по каналу, и сбрасывается при завершении этого звонка. | ||
Строка 34: | Строка 27: | ||
Может быть передан в служебный сценарий, запускаемый по окончании обработки вызова по внешнему каналу. Также существует контент цепочки коммутаций, который формируется пока существует обозначенная цепочка. При присоединении или отбое каналов из цепочки ее контент существует, наполняется и может быть обработан внешним образом. | Может быть передан в служебный сценарий, запускаемый по окончании обработки вызова по внешнему каналу. Также существует контент цепочки коммутаций, который формируется пока существует обозначенная цепочка. При присоединении или отбое каналов из цепочки ее контент существует, наполняется и может быть обработан внешним образом. | ||
− | |||
− | |||
Версия 08:10, 5 мая 2015
Наверх | К предыдущему уроку | К следующему уроку |
Введение
Сценарий обработки контента - служебный сценарий, который запускается после завершения звонка (коммутации) на внешней линии. Сценарий предназначен для постобработки внешнего звонка и анализа специальной XML-структуры, называемой контентом линии. Разберемся с этой структурой поподробнее.
Контент линии - это идентификационная информация по линии, абоненту, времени, а также перечень всех коммутаций с указанием имени сценария, идентификатора и имени оператора, времени начала, времени конца, продолжительности и пр. Контент линии существует только у внешних линий, начинает заполняться с момента поступления звонка по каналу и сбрасывается при завершении этого звонка. Иными словами, данная информация существует только во время звонка. Контент линии помогает отследить все действия внешнего абонента, по каким сценариям IVR он проходил, какие операторы говорили с ним, а какие операторы пропустили звонок.
Наряду с контентом линии, в Oktell существует контент цепочки коммутаций. Контент цепочки существует в рамках цепочки коммутаций и в отличие от предыдущего аналога, его можно получить как для внешних, так и для внутренних линий.
Следует отметить, что контенты линии и цепочки коммутаций отличаются друг от друга. Представим ситуацию, в которой секретарь консультативно переключил внешнего абонента на другого сотрудника. В контент линии попадут две коммутации — абонента с секретарем и абонента с сотрудником. В контент цепочки коммутации в данном случае попадут три коммутации - абонента с секретарем, секретаря с сотрудником и абонента с сотрудником, потому как все три вызова были сделаны в рамках одной цепочки.
Получить контент линии или цепочки коммутаций можно в любой момент с помощью одноименных функций в компоненте "Статус объекта".
Сценарий обработки контента
Осуществляет чтение или изменение пользовательского поля выбранного контента. В ходе работы с каналом системой производится сбор и формирование контента. Это XML документ, который существует в памяти сервера и постоянно пополняется происходящими действиями в ходе обработки вызова. Контент линии существует только у внешних линий, формируется при поступлении или совершении звонка по каналу, и сбрасывается при завершении этого звонка.
Может быть передан в служебный сценарий, запускаемый по окончании обработки вызова по внешнему каналу. Также существует контент цепочки коммутаций, который формируется пока существует обозначенная цепочка. При присоединении или отбое каналов из цепочки ее контент существует, наполняется и может быть обработан внешним образом.
Запуск данного сценария происходит автоматически после окончания звонка. Какой именно служебный сценарий будет отвечать за обработку контента выбираем и назначаем в разделе Администрирование / Общие настройки / Сценарии АТС / Служебный сценарий обработки контента.
Прежде чем обрабатывать контент,нужно ознакомиться в каком виде он нам становиться доступным. Для этого создадим простой служебный сценарий - "обработка контента".
В компоненте старт, выбираем параметры запуска, а точнее создаем переменную в которую система передаст эти самые параметры запуска,в нашем случае это и будет контент.
Далее используем компонент "Сохранение контента" для того что бы создать физический файл в который сохраниться наш контент. Для этого,в качестве контента указываем нашу переменную "Контент", затем для удобства последующего просмотра выбираем тип - txt.
Файл - выбираем категорию где наш файл создастся и указываем название файла. После этого сохраняем сценарий,назначаем его в качестве "Служебного сценария сбора контента", после чего производим звонок.
Переходим в категорию,которую указали для сохранения контента и раскрываем с помощью блокнота.
Как видно из данного файла - весь контент "обрамлен" в xml. Соответственно для последующего разбора данных мы будем использовать компонент парсер текста, с использованием поискового языка OQuery.
Давайте рассмотрим структуру более подробно. Для примера возьмем строчку из контента:
- <property_simple key="idchain" value="21819d69-6d1e-40b5-898b-a6c387a555bc" />
В данной строке property_simple - является тегом, key="idchain" - уточняющий атрибут, value="21819d69-6d1e-40b5-898b-a6c387a555bc" - конкретизирующий атрибут.
Таким образом для того что бы получить значение ID цепочки коммутации строим следующий поисковый запрос:
- property_simple[key="idchain"]
Где, следуя синтаксису OQuery, property_simple - тег,[key="idchain"] - атрибут с известным нам значением и названием.
Далее рассмотрим служебный сценарий сбора контента, в котором используя последовательный парсинг контента, мы получим необходимые значения и сохраним все в БД.
Во первых создадим таблицу в БД, в которую будем в итоге складировать все полученные данные. В ходе примера получим следующие данные:
- ID цепочки коммутации,
- Номер внешней линии,
- CallerID,
- CalledID,
- Время начала,
- Время конца,
- Имя пользователя, обслужившего вызов последним,
- Номер линии,обслужившей вызов последней,
- ID пользователя,обслужившего вызов последним.
Из такого набора данным все поля делаем NVarchar,кроме Время начала,Время конца,которые создаем как Date/time.
Далее переходим непосредственно к нашему сценарию.
Рассмотрим настройки компонента "Парсер"
- Документ - переменная "Контент".
- Алгоритм - Язык OQuery
- Поисковый запрос - property_simple[key="idchain"]
- Функция - что нужно нам найти в документе - значение атрибута.
- Номер элемента - оставляем пустым.
- Атрибут - value
- Результат в переменную - указываем переменную в которую будем сохранять результат парсера.
Таким же образом настраиваем и все последующие парсеры,не забывая изменять значение атрибута key в поисковом запросе на соответствующий нашему запросу, т.е. следующий парсер будет уже искать номер линии соответственно: property_simple[key="linenumber"] а так же указываем другую переменную.
Стоит отметить, что парсер позволяет сохранить информацию только в текстовом виде, соответственно при получении временных данных, их прежде всего сохраняем в строковую переменную,а затем при необходимости преобразуем в переменную типа Дата/время.
Так же для того что бы найти первый тег можно использовать указательный суффикс ":first" и для поиска последнего значения ":last". Таким образом для поиска времени поступления звонка воспользуемся суффиксом :first, поисковый запрос будет выглядеть так:
- (property_simple[key="timestart"]):first.
А для поиска времени окончания коммутации используем суффикс ":last" - (property_simple[key="timestop"]):last.
Так же суффиксом ":last" воспользуемся,для того что бы определить имя последнего оператора,принявшего звонок, его id и номер его линии.
Затем произведем преобразование строчной даты и времени в тип Дата\время и произведем запись в БД,в нашу таблицу.
После чего сохраним сценарий на сервере и совершим тестовый звонок. Открыв нашу таблицу мы увидим данные,которые мы собрали с помощью служебного сценария сбора контента.
Пример сценария:
Поздравляем! Теперь вы знаете как проанализировать звонок после соединения. Можете переходить к следующему уроку.
Техническая документация: Сценарии АТС
Вопросы и задания
Наверх | К предыдущему уроку | К следующему уроку |