Служебный сценарий обработки контента — различия между версиями
| (не показаны 4 промежуточные версии этого же участника) | |||
| Строка 1: | Строка 1: | ||
[[Практики|'''Наверх''']] | [[Практики|'''Наверх''']] | ||
| − | + | В ходе обработки внешнего звонка сервером производится сбор так называемого контента. Это идентификационная информация по линии, абоненту, времени, а также перечень всех коммутаций с указанием имени сценария, идентификатора и имени оператора, времени начала, времени конца, продолжительности и пр. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | Запуск данного сценария происходит автоматически после окончания звонка. Какой именно служебный сценарий будет отвечать за обработку контента выбираем и назначаем в разделе Администрирование / Общие настройки / Сценарии АТС / Служебный сценарий обработки контента. | |
| − | + | ||
| − | + | Прежде чем обрабатывать контент,нужно ознакомиться в каком виде он нам становиться доступным. Для этого создадим простой служебный сценарий - "обработка контента". | |
| − | |||
| − | |||
| − | [[Файл: | + | [[Файл:con01.png|center]] |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| + | В компоненте старт, выбираем параметры запуска, а точнее создаем переменную в которую система передаст эти самые параметры запуска,в нашем случае это и будет контент. | ||
| − | |||
| − | [[Файл: | + | [[Файл:con02.png|center]] |
| − | + | Далее используем компонент "Сохранение контента" для того что бы создать физический файл в который сохраниться наш контент. Для этого,в качестве контента указываем нашу переменную "Контент", затем для удобства последующего просмотра выбираем тип - txt. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | Файл - выбираем категорию где наш файл создастся и указываем название файла. После этого сохраняем сценарий,назначаем его в качестве "Служебного сценария сбора контента", после чего производим звонок. | |
| − | + | Переходим в категорию,которую указали для сохранения контента и раскрываем с помощью блокнота. | |
| − | + | ||
| − | + | ||
| − | |||
| − | + | [[Файл:con1.png|center]] | |
| − | |||
| − | + | Как видно из данного файла - весь контент "обрамлен" в 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 цепочки коммутации, | *ID цепочки коммутации, | ||
*Номер внешней линии, | *Номер внешней линии, | ||
| Строка 64: | Строка 55: | ||
*ID пользователя,обслужившего вызов последним. | *ID пользователя,обслужившего вызов последним. | ||
| − | + | Из такого набора данным все поля делаем NVarchar,кроме Время начала,Время конца,которые создаем как Date/time. | |
| − | |||
| − | : | + | [[Файл:con7.png|center]] |
| − | |||
| − | :Рассмотрим настройки компонента "Парсер" | + | Далее переходим непосредственно к нашему сценарию. |
| + | |||
| + | [[Файл:con2.png|center]] | ||
| + | |||
| + | Рассмотрим настройки компонента "Парсер" | ||
*Документ - переменная "Контент". | *Документ - переменная "Контент". | ||
*Алгоритм - Язык OQuery | *Алгоритм - Язык OQuery | ||
| Строка 81: | Строка 74: | ||
*Результат в переменную - указываем переменную в которую будем сохранять результат парсера. | *Результат в переменную - указываем переменную в которую будем сохранять результат парсера. | ||
| − | [[Файл:con3.png]] | + | [[Файл:con3.png|center]] |
| − | + | Таким же образом настраиваем и все последующие парсеры,не забывая изменять значение атрибута | |
| − | + | key в поисковом запросе на соответствующий нашему запросу, т.е. следующий парсер будет уже искать | |
| − | + | номер линии соответственно: property_simple[key="linenumber"] | |
| − | + | а так же указываем другую переменную. | |
| − | + | Стоит отметить, что парсер позволяет сохранить информацию только в текстовом виде, соответственно | |
| − | + | при получении временных данных, их прежде всего сохраняем в строковую переменную,а затем при | |
| − | + | необходимости преобразуем в переменную типа Дата/время. | |
| − | + | Так же для того что бы найти первый тег можно использовать указательный суффикс ":first" и для поиска последнего значения ":last". | |
| − | + | Таким образом для поиска времени поступления звонка воспользуемся суффиксом :first, поисковый запрос будет выглядеть так: | |
| − | + | ||
| − | + | ||
:'''(property_simple[key="timestart"]):first'''. | :'''(property_simple[key="timestart"]):first'''. | ||
| − | |||
| − | : А для поиска времени окончания коммутации используем суффикс ":last" - '''(property_simple[key="timestop"]):last'''. | + | [[Файл:con4.png|center]] |
| + | |||
| + | |||
| + | А для поиска времени окончания коммутации используем суффикс ":last" - '''(property_simple[key="timestop"]):last'''. | ||
| + | |||
| + | |||
| + | [[Файл:con5.png|center]] | ||
| + | |||
| + | |||
| + | Так же суффиксом ":last" воспользуемся,для того что бы определить имя последнего оператора,принявшего звонок, его id и номер его линии. | ||
| + | |||
| + | Затем произведем преобразование строчной даты и времени в тип Дата\время и произведем запись в БД,в нашу таблицу. | ||
| − | |||
| − | : | + | [[Файл:con6.png|center]] |
| − | + | ||
| − | |||
| − | + | После чего сохраним сценарий на сервере и совершим тестовый звонок. Открыв нашу таблицу мы увидим данные,которые мы собрали с помощью служебного сценария сбора контента. | |
| − | |||
| − | : | + | [[Файл:con8.png|center]] |
| − | |||
| − | Пример сценария: | + | Пример сценария: [[Media:Content.zip|Content.zip]] |
| − | [[ | + | |
Текущая версия на 10:54, 31 марта 2023
В ходе обработки внешнего звонка сервером производится сбор так называемого контента. Это идентификационная информация по линии, абоненту, времени, а также перечень всех коммутаций с указанием имени сценария, идентификатора и имени оператора, времени начала, времени конца, продолжительности и пр.
Запуск данного сценария происходит автоматически после окончания звонка. Какой именно служебный сценарий будет отвечать за обработку контента выбираем и назначаем в разделе Администрирование / Общие настройки / Сценарии АТС / Служебный сценарий обработки контента.
Прежде чем обрабатывать контент,нужно ознакомиться в каком виде он нам становиться доступным. Для этого создадим простой служебный сценарий - "обработка контента".
В компоненте старт, выбираем параметры запуска, а точнее создаем переменную в которую система передаст эти самые параметры запуска,в нашем случае это и будет контент.
Далее используем компонент "Сохранение контента" для того что бы создать физический файл в который сохраниться наш контент. Для этого,в качестве контента указываем нашу переменную "Контент", затем для удобства последующего просмотра выбираем тип - 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
