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

Материал из Oktell
Перейти к: навигация, поиск
Строка 187: Строка 187:
 
*'''Аргумент 2''' - строка '''1'''
 
*'''Аргумент 2''' - строка '''1'''
 
*'''Тип сравнения''' - "'''='''"
 
*'''Тип сравнения''' - "'''='''"
 +
 +
 +
[[Файл:Урок 22 -008.png|center|800px]]
  
  
Строка 216: Строка 219:
  
  
Пример анализа результат приведен в данном уроке неслучайно. В большинстве случае служебные сценарии имеют дело с анализ ответов от Web-сервисов.  
+
[[Файл:Урок 22 -009.png|center|800px]]
 +
 
 +
 
 +
Пример анализа результата приведен в данном уроке неслучайно. Служебные сценарии часто имеют дело с JSON или XML-структурами, получаемыми от Web-сервисов. В Oktell также есть некоторые моменты, в которых данные передаются в виде XML-структур. Такие структуры требуется расшифровать и записывать отдельные данные в таблицы БД для дальнейшего построения отчетов. Исходя из этого, важно понимать логику анализа получаемых сообщений и производить необходимые действия.  
  
  

Версия 11:45, 29 мая 2014

Наверх К предыдущему уроку


Введение

В предыдущих уроках мы подробно разбирали работу IVR сценариев, компоненты и принципы обработки звонков. IVR сценарий существуют только на активной линии и как только абонент кладет трубку, сценарий сразу прекращает свое выполнение. Порой такое поведение не способно решить некоторые поставленные задачи. К примеру, необходимо отправлять электронное письмо после завершения разговора. Но ведь когда абоненты положат трубку, IVR сценарии завершатся и отправки письма на почту не произойдет. Что делать?

В Oktell существуют служебные сценарии. Сценарии такого типа работают асинхронно без привязки к каким-либо линиям, а значит могут выполняться в произвольные моменты времени. Исходя из этого, такие сценарии могут применяться для выполнения различных процедур на сервере:

  • отправка электронного письма, SMS, IM-сообщения клиенту в заданное время
  • периодический запуск бизнес-процессов в CRM-системе
  • автоматический сбор конференции для совещания
  • сбор данных с внешней системы, расчет и контроль показателей

Служебный сценарий отличается от IVR сценария набором компонентов. Так, отсутствуют компоненты работы с коммутацией и передачи факса, появляются несколько новых компонентов. После создания сценарий можно легко запустить из модуля "Сценарии".

Создание сценария

Задача: создать служебный сценарий вывода текущего времени на экран.

Для создания перейдите в раздел "Администрирование" - модуль "Сценарии". Нажмите кнопку "Создать". Выберите служебный тип сценария и введите название. В примере, "Урок 22"


Урок 22 -001.png


Сценарий вывода времени на экран приведен на рисунке:


Урок 22 -002.png


Любой сценарий всегда начинается с компонента "Старт". В компоненте вы можете указать переменную, в которую сохранится параметр запуска. Компонент может присутствовать в сценарии только один раз.

Компонент "Вывод времени" выводит уведомление с текущим временем адресатам. В компоненте указаны следующие свойства:

  • Адресат - укажите получателя сообщения
  • Текст - функция "Текущие дата и время"
  • Способ оповещения - Всплывающее окно

Служебный сценарий должен всегда заканчиваться компонентом "Стоп".

После создания сценария перейдите на вкладку "Сохранение" и нажмите "На сервер".

Для проверки сценария, выберите его в списке и нажмите кнопку "Запустить". Появится уведомление с текущим временем.


Урок 22 -003.png


В отличии от IVR-сценария, который нужно назначать на внутренний номер и звонить на него, служебный сценарий намного проще запустить. Именно поэтому с его помощью можно легко проверить работу тех или иных функций системы. Например, отправку электронного письма или выполнение некоторого web-запроса. Пользуйтесь этим преимуществом.


Оповещение абонентов с помощью служебного сценария

Служебный сценарий может быть инициатором звонка. Это может быть полезно, например, для оповещения сотрудников или автоматического сбора конференции. Часто это применяется для услуги "заказать обратный звонок с сайта". После заполнения формы на сайте, Oktell генерирует вызов сотрудника, а затем автоматически соединяет его с целевым абонентом или проговаривает ему необходимую информацию.

Рассмотрим процесс создания такого сценария.

Задача: С помощью служебного сценария дозвониться до клиента компании, а затем проиграть ему IVR-сценарий с приветствием.

Поставленную задачу начинаем с создания IVR-сценария "Урок 22 (IVR)". Сценарий должен проигрывать звуковой файл приветствия, а затем разрывать соединение. Вид сценария показан на рисунке:


Урок 22 -004.png


Компонент "Приветствие" воспроизводит звуковой файл абоненту.

  • Режим - Файл полностью
  • Файл - выберите mp3-файл приветствия.

Сохраните данный сценарий на сервер.

Переходим к созданию служебного сценария "Урок 22 (Дозвон)". Служебный сценарий предназначен для дозвона до абонента, а затем для передачи управления созданному IVR-сценарию. На рисунке показан вид сценария:


Урок 22 -005.png


Основной компонент "Дозвон" совершает вызов абоненту по определенным линиям. Если абонент поднимает трубку, то компонент запускает IVR-сценарий на линии абонента, при этом сам переходит к дальнейшим компонентам. Устанавливаются следующие основные свойства:

  • Номер/команда - введите телефон для вызова. В примере, 89045642434

ВНИМАНИЕ: Все внешние номера при наборе используют "Служебный сценарий набора внешних/быстрых номеров". Сценарий будет рассматриваться в последующих уроках.

  • Среда - Внешняя сеть указывается для совершения внешних вызовов, Внутренний номерной план для вызова на внутренние номера. В примере, Внешняя сеть.
  • Обслуживание - IVR. Варианты "Управляющий модуль" и "Управляющий модуль с ожиданием в сценарии" применяются в особых случаях.
  • Направления - выберите линии, по которым будет совершаться звонок. В примере, линии Sipnet.
  • Сценарий IVR - выберите обслуживающий сценарий. В примере, Урок 22 (IVR)

Для проверки сценария в компоненте "Дозвон" временно укажите свой внутренний номер. Вы также можете обозначить особую обработку случаев, когда абонент занят или не отвечает (или других переходов). После создания сценариев, сохраните его на сервер.

Запустив данный сценарий система дозвонится до указанного абонента, а затем проиграет ему файл приветствия.


Коммутация двух абонентов в служебном сценарии и анализ отчета

Как можно догадаться, соединить двух абонентов можно, пользуясь компонентом "Дозвон" и переключением в IVR-сценарии. Однако, служебный сценарий позволяет соединять двух абонентов напрямую без использования лишних IVR-сценариев. Для этого используется компонент "Коммутатор".

Задача: Скоммутировать двух абонентов с помощью служебного сценария. Оповестить администратора о результате операции.

Создадим служебный сценарий "Урок 22 (Коммутатор)". Вид сценария показан ниже:


Урок 22 -006.png


Компонент "Коммутатор" осуществляет вызов двух абонентов, затем объединяет их в коммутацию. Рассмотрим простейшую настройку компонента:

  • Детальная настройка - подразумевает настройку коммутатора с помощью некоторой XML-структуры, в которой указываются все параметры для осуществления коммутации. В примере, установлено Нет и будет разобрано ниже.
  • Абоненты А - указывается первый абонент для соединения. Вы можете указать внутренний или внешний номер, имя пользователя системы или линию. При указании нескольких абонентов, они указываются через запятую, а соединение происходит с первым ответившим. В примере, внутренний номер 601.
  • Абоненты Б - аналогично свойству "Абоненты А". В примере, внешний номер 89091231231
  • Последовательность - порядок вызова абонентов - последовательно или одновременно. В примере используется "Сначала А, потом Б"
  • CallerID для A - вы можете указать собственный CallerID, который будет отображаться при звонке. Однако, будьте внимательны - подставлять CallerID при внешнем звонке можно только, если это допускает ваш провайдер связи. Уточните этот момент. Так как Абонент А является внутренним номером, то в поле указано "Коммутатор".
  • CallerID для Б - заполняется аналогично свойству "CallerID для A". В пример, не указан, так как Абонент Б является внешним номером.


Урок 22 -007.png


  • Запись - в компоненте вы можете дополнительно установить параметры записи разговора. В примере, записываются все разговоры.
  • Ожидать отчета - при необходимости анализа результата коммутации или неудачи вы можете дополнительно указать в этом свойстве "Да, полный отчет" или "Да только результат", а затем указать переменную в которую он будет сохраняться. В примере, указано свойство "Да, полный отчет".
  • Отчет в переменную - указана переменная Отчет (строковая).

Аналогичная настройка может быть осуществлена с помощью следующей XML-структуры. В этом случае свойство "Детальная настройка" должно быть установлена в положение "Да". Синим цветом выделены установленные ранее поля.

"<task>
 <taskid></taskid>
 <taskcode></taskcode>
 <sessionid></sessionid>
 <projectid></projectid>
 <mode>0</mode>
 <recordmode>1</recordmode>
 <svcownertext></svcownertext>
 <attachedcctask></attachedcctask>
 <attachedidinlist></attachedidinlist>
 <agroup>
  <a>601</a>
  <a></a>
 </agroup>
 <bgroup>
  <b>89091231231</b>
  <b></b>
 </bgroup>
 <a_callerid>Коммутатор</a_callerid>
 <a_callername></a_callername>
 <a_music></a_music>
 <a_queuepriority></a_queuepriority>
 <a_usequeue></a_usequeue>
 <a_timeoutsec></a_timeoutsec>
 <b_callerid></b_callerid>
 <b_callername></b_callername>
 <b_music></b_music>
 <b_queuepriority></b_queuepriority>
 <b_usequeue></b_usequeue>
 <b_timeoutsec></b_timeoutsec>
</task>" 

При запуске такого служебного сценария, вначале произойдет вызов до абонента А (номер 601), затем до абонента Б (внешний номер 89091231231).

Остальные компоненты отвечают за отладку и уведомление администратора об успешной или неуспешной коммутации. Рассмотрим краткое описание компонентов:

Компонент "Ошибка". Сообщает администратору об ошибке в настройке коммутатора.

  • Текст - строка Ошибка коммутатора
  • Цвет фона - красный (255, 0, 0) для большей наглядности


Компонент "Вывод отчета". Выводит на экран отчет о коммутации.

  • Текст - выражение
'[Отчет]'+endline+ 
[Отчет]


Компонент "success". Определяет статус коммутации, тег <success> (0- неудача, 1- успех).

  • Документ - переменная Отчет
  • Алгоритм - Языка OQuery для HTML
  • Поисковый запрос - строка success
  • Функция - Содержимое
  • Результат в переменную - переменная success (строковая)

Компонент "success=1?". Определяет успешен ли звонок.

  • Аргумент 1 - переменная success
  • Аргумент 2 - строка 1
  • Тип сравнения - "="


Урок 22 -008.png


Компонент "Успешно соединились". Уведомляет администратора об успешной коммутации абонентов.

  • Текст - строка Успешно соединились


Компонент "errorid". В случае неудачного звонка определяется номер причины, по которой абоненты не соединились друг с другом.

  • Документ - переменная Отчет
  • Алгоритм - Языка OQuery для HTML
  • Поисковый запрос - строка errorid
  • Функция - Содержимое
  • Результат в переменную - переменная errorid (строковая)


Компонент "errorstr". Аналогично определятся строка с расшифровкой причины.

  • Документ - переменная Отчет
  • Алгоритм - Языка OQuery для HTML
  • Поисковый запрос - строка errorstr
  • Функция - Содержимое
  • Результат в переменную - переменная errorstr (строковая)


Компонент "Неуспешное соединение". Выводит администратору сообщение о неуспешном соединении абонентов.

  • Текст - выражение
'Неудачное соединение'+endline+
'[errorid] '+[errorid]+endline+
'[errorstr] '+[errorstr]


Урок 22 -009.png


Пример анализа результата приведен в данном уроке неслучайно. Служебные сценарии часто имеют дело с JSON или XML-структурами, получаемыми от Web-сервисов. В Oktell также есть некоторые моменты, в которых данные передаются в виде XML-структур. Такие структуры требуется расшифровать и записывать отдельные данные в таблицы БД для дальнейшего построения отчетов. Исходя из этого, важно понимать логику анализа получаемых сообщений и производить необходимые действия.


Наверх К предыдущему уроку