Служебный сценарий обработки контента — различия между версиями

Версия 07:22, 25 марта 2013

В ходе обработки внешнего звонка сервером производится сбор так называемого контента.

Это идентификационная информация по линии, абоненту, времени, а также перечень

всех коммутаций с указанием имени сценария, :идентификатора и имени оператора, времени начала,

времени конца, продолжительности и пр.

Запуск данного сценария происходит автоматически после окончания звонка.

Какой именно служебный сценарий будет отвечать за обработку контента выбираем и назначаем

в разделе Администрирование,общие :настройки,сценарии АТС, "служебный сценарий обработки контента".

Прежде чем обрабатывать контент,нужно ознакомиться в каком виде он нам становиться доступным.

Для этого создадим простой служебный сценарий - "обработка контента".

В компоненте старт, выбираем параметры запуска, а точнее создаем переменную в которую система

передаст эти самые параметры запуска,в нашем случае это и будет контент.

Далее используем компонент "Сохранение контента" для того что бы создать физический

файл в который сохраниться наш контент.

Для этого,в качестве контента указываем нашу переменную "Контент"

Затем для удобства последующего просмотра выбираем тип - 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