Служебный сценарий обработки контента
Материал из Oktell
Версия от 08:42, 18 апреля 2014; Oktell Support (обсуждение | вклад)
- В ходе обработки внешнего звонка сервером производится сбор так называемого контента.
- Это идентификационная информация по линии, абоненту, времени, а также перечень
- всех коммутаций с указанием имени сценария, :идентификатора и имени оператора, времени начала,
- времени конца, продолжительности и пр.
- Запуск данного сценария происходит автоматически после окончания звонка.
- Какой именно служебный сценарий будет отвечать за обработку контента выбираем и назначаем
- в разделе Администрирование,общие :настройки,сценарии АТС, "служебный сценарий обработки контента".
- Прежде чем обрабатывать контент,нужно ознакомиться в каком виде он нам становиться доступным.
- Для этого создадим простой служебный сценарий - "обработка контента".
- В компоненте старт, выбираем параметры запуска, а точнее создаем переменную в которую система
- передаст эти самые параметры запуска,в нашем случае это и будет контент.
- Далее используем компонент "Сохранение контента" для того что бы создать физический
- файл в который сохраниться наш контент.
- Для этого,в качестве контента указываем нашу переменную "Контент"
- Затем для удобства последующего просмотра выбираем тип - 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 и номер его линии.
- Затем произведем преобразование строчной даты и времени в тип Дата\время и произведем запись в БД,в нашу таблицу.
- После чего сохраним сценарий на сервере и совершим тестовый звонок.
- Открыв нашу таблицу мы увидим данные,которые мы собрали с помощью служебного сценария сбора контента.
Пример сценария: Файл:Content.zip