Сценарий обработки сообщений

Введение

Сценарий обработки контента — служебный сценарий, который запускается после завершения звонка на внешней линии. Сценарий предназначен для постобработки внешнего звонка и анализа специальной XML-структуры, называемой контентом линии. Разберемся с этой структурой поподробнее.

Контент линии — это идентификационная информация по линии, абоненту, времени, а также перечень всех коммутаций с указанием имени сценария, идентификатора и имени оператора, времени начала, времени конца, продолжительности и пр. Контент линии существует только у внешних линий, начинает заполняться с момента поступления звонка по каналу и сбрасывается при завершении этого звонка. Иными словами, данная информация существует только во время звонка. Контент линии помогает отследить все действия внешнего абонента, по каким сценариям IVR он проходил, какие операторы говорили с ним, а какие операторы пропустили звонок.

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

После того как линия положит трубку в контент линии попадут 4 коммутации:

• соединение абонента с главным IVR сценарием
• разговор абонента с секретарем Марией
• разговор абонента с сотрудником Станиславом
• соединение абонента со сценарием вместо отбоя

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

Наряду с контентом линии, в Oktell существует контент цепочки коммутаций (еще его называют контент сессии). Контент сессии существует в рамках цепочки коммутаций и в отличие от контента линии его можно получить как для внешних, так и для внутренних линий.

Следует отметить, что контенты линии и сессии отличаются друг от друга. В контент сессии для данной ситуации попадет еще разговор секретаря Марии с сотрудником Станиславом во время консультативного перевода, потому как этот вызов, как и другие был сделан в рамках одной цепочки. Также в контенте цепочки коммутаций фиксируется информация о пройденных очередях ожидания. Ниже показан пример контента цепочки коммутаций для того же примера (повторяющиеся моменты вырезаны).

Получить контент линии или цепочки коммутаций можно в любой момент с помощью одноименных функций в компоненте «Статус объекта» (действие — определить). Для линии вы можете определить как контент линии (XML), так и цепочки коммутаций (XML, Json). Для сессии (цепочки) доступно только определение контента цепочки коммутаций.

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

<property_cdata key="custominfo"><![CDATA[Любые данные]]></property_cdata>

В контенте цепочки коммутаций это несколько полей — одно в заголовке контента сессии и по одному на каждую коммутацию (показано на рисунке выше):

<property_cdata key="custom"><![CDATA[Любые данные]]></property_cdata>

<property_cdata key="custom"><![CDATA[Любые данные]]></property_cdata>

Определить и установить свои значения в эти пользовательские поля вы можете с помощью одноименных функций в компоненте «Статус объекта«. Для линии доступны пользовательские поля обоих типов контентов, для сессии доступен только контент цепочки.

Сценарий обработки контента

Как было сказано в начале, сценарий обработки контента запускается автоматически после окончания звонка на внешней линии. На вход в качестве параметра запуска сценарию поступает контент линии в формате XML. Получить контент линии можно также с помощью функции «Входной параметр 1«. Далее в сценарии вы можете проанализировать эту структуру и определить различные параметры звонка. Рассмотрим этот процесс на примере задачи.

Задача: необходимо определять пропущенные звонки от клиентов и реализовать автоматическую отправку email директору с указанием номера абонента (callerid), набранного номера (calledid) и времени звонка. Пропущенным звонком в данной задаче будем считать такой, у которого не было ни одного соединения с оператором.

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

Как видно из рисунка, соединения с операторами отмечается дополнительным тегом <abonent index="1"> внутри основного тега <commutation index="1">. Исходя из этого, если количество таких тегов равняется нулю, звонок можно считать пропущенным. Остальные параметры — направление звонка, CallerId, CalledId и время звонка можно также посмотреть из контента, на рисунке они отмечены синим цветом.

Итоговый сценарий выглядит следующим образом:

Компонент «Старт«. Сохраняет контент линии в переменную content.

• Параметр запуска — переменная content (строковая)

Компонент «Вывод контента«. Отладочное уведомление для вывода контента линии.

• Текст — переменная content.
• Способ оповещения — Всплывающее уведомление
• Ключ получателя — внутренний номер администратора. Указать ключ в таком виде намного легче, чем выбирать пользователя в свойстве «Адресат».

Компонент «Количество коммутаций«. Парсер определяет из контента количество коммутаций с абонентами. Поскольку контент представляет из себя XML структуру, используется алгоритм OQuery.

• Документ — переменная content
• Алгоритм — Язык OQuery для HTML
• Поисковый запрос — строка

commutation:has(property_simple[name='abonent'])

Запрос ищет все теги commutation, внутри который есть тег property_simple с атрибутом name=»abonent»

• Функция — Количество элементов
• Результат в переменную — переменная count (строковая)
• Переход и Переход, неудача — на компонент «Пропущенный?». Переход по неудаче сделан для случая, если в контенте не будет ни одной коммутации с абонентом. Дело в том, что если парсер не находит нужных тегов, он возвращает ошибку.

Компонент «Пропущенный?«. Если парсер не нашел нужных тегов, то он перейдет по неудаче, а в переменную он возвратит пустое значение. Компонент сравнивает переменную count с пустой строкой, тем самым определяя пропущенный это звонок или нет.

• Аргумент 1 — переменная count
• Аргумент 2 — пустая строка
• Тип сравнение — «=»
• Переход, если правда — на компонент «Определяем направление»
• Переход, если ложь — на компонент «Стоп 1»

Компонент «Определяем направление«. Определяет направление звонка — входящий или исходящий. Требуемое значение находится в теге <property_simple key="direction" value="1" name="cdIncoming" /> в атрибуте name.

• Документ — переменная content
• Алгоритм — Язык OQuery для HTML
• Поисковый запрос — строка

property_simple[key='direction']

Запрос ищет все теги property_simple с атрибутом key=»direction»

• Функция — Значение атрибута
• Номер элемента — 1
• Атрибут — строка «name»
• Результат в переменную — переменная direction (строковая)
• Переход и Переход, неудача — на компонент «Входящий звонок?».

Компонент «Входящий звонок?«. Поскольку в задании требуется определять только входящие звонки, у которых не было ни одной коммутации, компонент сравнивает полученное направление со строкой «cdIncoming».

• Аргумент 1 — переменная direction
• Аргумент 2 — строка «cdIncoming»
• Тип сравнение — «=»
• Переход, если правда — на компонент «CallerId»
• Переход, если ложь — на компонент «Стоп 2»

Компонент «CallerId«. Определяет CallerId. Требуемое значение находится в теге <property_simple key="callerid" value="88432110000" /> в атрибуте value.

• Документ — переменная content
• Алгоритм — Язык OQuery для HTML
• Поисковый запрос — строка

property_simple[key='callerid']

Запрос ищет все теги property_simple с атрибутом key=»callerid»

• Функция — Значение атрибута
• Номер элемента — 1
• Атрибут — строка «value»
• Результат в переменную — переменная callerid (строковая)
• Переход и Переход, неудача — на компонент «CalledId».

Компонент «CalledId«. Определяет CalledId. Требуемое значение находится в теге <property_simple key="calledid" value="88001112233" /> в атрибуте value.

• Документ — переменная content
• Алгоритм — Язык OQuery для HTML
• Поисковый запрос — строка

property_simple[key='calledid']

Запрос ищет все теги property_simple с атрибутом key=»calledid»

• Функция — Значение атрибута
• Номер элемента — 1
• Атрибут — строка «value»
• Результат в переменную — переменная calledid (строковая)
• Переход и Переход, неудача — на компонент «TimeStart».

Компонент «TimeStart«. Определяет время начала звонка. Требуемое значение находится в теге <property_simple key="timestart" value="06.05.2015 10:06:43.462" /> в атрибуте value.

• Документ — переменная content
• Алгоритм — Язык OQuery для HTML
• Поисковый запрос — строка

property_simple[key='timestart']

Запрос ищет все теги property_simple с атрибутом key=»timestart»

• Функция — Значение атрибута
• Номер элемента — 1
• Атрибут — строка «value»
• Результат в переменную — переменная timestart (строковая)
• Переход и Переход, неудача — на компонент «Вывод параметров».

Компонент «Вывод параметров«. Отладочное уведомление для вывода всех найденных параметров звонка

• Текст — выражение:

'ПРОПУЩЕННЫЙ ЗВОНОК'+endline+
'[callerid] '+[callerid]+endline+
'[calledid] '+[calledid]+endline+
'[timestart] '+[timestart]+endline+
'[direction] '+[direction]

• Способ оповещения — Всплывающее уведомление
• Ключ получателя — внутренний номер администратора.

Компонент «Отправка Email«. Отправляет электронное письмо по пропущенному звонку.

• Почтовый сервер — Согласно общим настройкам. Используются данные для подключения из модуля Общие настройки / Настройки E-mail
• Кому — строка director@oktell.ru
• От кого — строка info@oktell.ru, как правило совпадает с логином для подключения к SMTP-серверу.
• Тема — строка Пропущенный звонок
• Формат — текст
• Содержание письма — выражение:

'ПРОПУЩЕННЫЙ ЗВОНОК'+endline+
'Номер абонента: '+[callerid]+endline+
'Набранный номер: '+[calledid]+endline+
'Время: '+[timestart]

Скачать сценарий: Сценарий обработки контента.oscr (собран на версии 2.12.0.150423)

Назначение сценария

Сценарий обработки контента назначается в модуле Администрирование/Общие настройки на вкладке «Сценарии АТС«. Для того, чтобы назначить сценарий выберите его в выпадающем списке напротив соответствующей строки и поставьте крестик для его активации, затем сохраните настройки. Выбранный сценарий в списке обозначается серым цветом.

Поздравляем! Теперь вы знаете как проанализировать звонок после соединения. Можете переходить к следующему уроку.

Техническая документация: Сценарии АТС

Вопросы и задания

• Зачем нужен сценарий обработки контента? Что такое контент, какие виды контента существуют?
• Дополните данный сценарий информацией о том, какой внутренний номер пропустил данный звонок. Передать значение из главного сценария в сценарий контента вы можете с помощью сессионной переменной, либо через пользовательское поле в контенте. Попробуйте оба варианта.
• Реализуйте в сценарии определение параметров успешного звонка: CallerId, CalledId, время звонка, номер внешней линии, имя и идентификатор последнего обслужившего сотрудника. Все найденные параметры сохраняйте в базу данных.
• Настройте сценарий обработки контента для отправки всех записей разговоров в цепочке коммутаций на электронную почту. Таким образом, если клиент разговаривал с несколькими сотрудниками, в письмо должны быть вложены все разговоры клиента. Используйте статью: Отправка записей разговоров на e-mail. Модифицируйте сценарий для отправки записей разговоров только в тех случаях, когда клиент поставил оценку 1 или 2 в сценарии вместо отбоя.

Техническая документация / Администрирование / Общие Настройки / Системные настройки / Сценарии АТС

Сценарии IVR

Сценарий IVR маршрутизации входящих звонков (главный)

Cценарий IVR входящей маршрутизации (или как его еще называют Главный сценарий) обрабатывает все входящие вызовы, поступающие в систему с внешних линий. Сценарий запускается исключительно на внешних линиях. Как правило, сценарий осуществляет звуковое воспроизведение, переключение на сотрудников, перевод звонка в другие вложенные сценарии или проекты call-центра. В списке сценариев (Администрирование/Сценарии) главный сценарий выделяется красным цветом. Он также может быть выбран непосредственно в контекстном меню списка сценариев «Назначить главным» или нажатием кнопки «Главный». Сценарий обязательно должен быть выбран в системе, иначе вы не сможете принять ни один вызов.

Смотрите также: Урок 24 IVR сценарий входящей маршрутизации

Сценарий IVR маршрутизации исходящих звонков

Сценарий IVR исходящей маршрутизации обрабатывает все вызовы, поступающие с внутренних линий. Запускается исключительно на внутренних линиях. Сценарий ожидает ввода номера, а затем производит маршрутизацию на внешние либо внутренние линии. Необходимо иметь в виду, что устройства по-разному набирают и передают номер в сценарий. Например, снятая трубка на аналоговом или USB аппарате приведет к запуску сценария с пустым значением функции CalledId. В то же время дозвон с IP-телефона в качестве функции CalledId будет возвращать всю последовательность цифр, набранную на аппарате до нажатия CALL. Исходя из этого, в начале сценария необходимо оценивать набранный номер через функцию «Внешний номер (CalledId)«.

В стандартном сценарии переключение на внутренние номера происходит, если длина номера 3 символа. Если вы собираетесь использовать 4х-символьный номерной план или длиннее, необходимо подкорректировать данный сценарий. Следует также учесть, что вызовы на короткие номера через внешние линии по умолчанию заблокированы.

Если сценарий не назначен, для исходящего звонка на внешний номер выбирается первая свободная внешняя линия.

Смотрите также: Урок 25 Маршрутизация исходящих вызовов

Сценарий IVR маршрутизации при переводе звонка

IVR сценарий переключения активируется во время Flash-переключения (консультативного перевода). Сценарий может запускаться как на внешней, так и на внутренней линии. Аналогичен сценарию исходящей маршрутизации, с небольшими дополнениями. Изначально сценарий запускается на внутренней линии сотрудника, когда во flash-буфере находится абонент и потенциально готовится перевод звонка. Номер для переключения определяется через функцию «Внешний номер (CalledId)»

Если во время работы сценария, переключающий пользователь положит трубку и тем самым произведет переключение, то в сценарий попадет линия переключаемого. Эта линия может быть как внешней (если это клиент), или внутренней (если переключают сотрудника). Для этого случая в сценарии по умолчанию установлен режим подмены обслуживаемой линии при переключении на него (определяется служебной переменной Режим Flash). Включенный режим Flash означает, что при переключении сценарий подменит внутреннюю линию на линию переключаемого абонента и начнет свою работу с того же компонента, на котором он остановился. Если выключить режим Flash, то в момент переключения сценарий начнет свою работу с компонента Старт. Подробнее о режиме перевода с подменой обслуживаемой линии в описании служебной переменной «Режим FLASH». Режим Flash во вложенных сценариях автоматически не включен и его надо устанавливать вручную.

Если сценарий не выбран, используется сценарий исходящей маршрутизации (если активирован) или общий режим работы.

Смотрите также: Урок 26 IVR сценарий переключения

Сценарий IVR маршрутизации межсерверных звонков

Сценарий активируется когда звонок поступает по каналу межсерверного взаимодействия. Сценарий запускается на внешней линии. Аналогичен сценарию входящей маршрутизации. Если не выбран, используется главный сценарий входящей маршрутизации.

Смотрите также: Настройка межсерверного взаимодействия

Сценарий IVR sip-transfer-переключения

Сценарий активируется во время Transfer-переключения (слепого перевода). Сценарий запускается сразу на линии переключаемого, который может быть как внутренней, так и внешней линией. Аналогичен сценарию переключения. Произвести transfer-переключение можно через команду XFER (TRAN, Transfer) на IP-телефоне или через клиентское приложение. На различных моделях телефонов комбинации могут отличаться. Номер для переключения определяется через функцию «Входной параметр 1» или как параметр запуска у компонента «Старт». Если не выбран, используется сценарий исходящей маршрутизации.

Смотрите также: Урок 26 IVR сценарий переключения

Сценарий IVR вместо отбоя внешней линии

Активируется в момент разрыва соединения с внешней линией по инициативе внутреннего пользователя системы (оператор первым положил трубку) или сервера (командой «Мягкий сброс»). Сценарий запускается только на внешней линии. Если сценарий не указан, то внешняя линия получает отбой и абонент слышит гудки. Сценарий вместо отбоя позволяет дополнительно проанализировать сессионные переменные, задать вопрос анкеты о качестве связи или обслуживания, или даже переключить ее снова на любого абонента.

Смотрите также: Урок 27 IVR сценарий вместо отбоя внешней линии

Сценарий IVR запроса пароля

При активации режима Мобильная статистика путем указания множества масок номеров, вызовы на которые необходимо фиксировать, контролировать и подсчитывать, система при наборе попадающего под установленный набор масок номера и невозможности определения инициатора звонка (пользователя) осуществляет запрос пароля и переадресацию посредством указанного сценария (по умолчанию «(Служебный) Запрос пароля«).

Служебные сценарии

Служебный сценарий преобразования CallerId

Запускается в момент поступления звонка (запроса INVITE) в систему. Используется для преобразования определившихся CallerId и CalledId к соответствующему виду, установленному в компании. Как правило, все номера преобразуют в формат, который принимает основной провайдер, тем самым облегчая call-back. В качестве неявных параметров в сценарий передаются:

• Входной параметр 1 — определившийся номер абонента CallerId
• Входной параметр 2 — набранный номер CalledId.

При необходимости корректировки CallerId, вам нужно переопределенное значение сохранить в служебной переменной «Возвращаемое значение 1». Для изменения CalledId присвойте его значение служебной переменной «Возвращаемое значение 2». Код инициатора запуска служебного сценария — 13.

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

Смотрите также: Определение CallerID и CalledID

Служебный сценарий получения данных из справочника РосФирм

Запускает асинхронный служебный сценарий одновременно с главным сценарием. Основная задача сценария получить информацию об абоненте и присвоить ее текущей линии (через компонент «Статус объекта», свойство — название абонента). Информацию об абоненте вы можете получить через различные справочники и веб-сервисы. Одним из таких справочников является РОСФИРМ, содержащий 796 тысяч предприятий Российской Федерации. Таким образом, при входящем звонке Oktell получает из справочника информацию о названии компании, соответствующей определившемуся номеру телефона, присваивает ее текущей линии (пользуясь функцией «Guid-идентификатор линии«) и затем отображает во время поступления звонка сотруднику. Код инициатора запуска служебного сценария — 28.

• Входной параметр 1 — номер абонента CallerId
• Входной параметр 2 — набранный номер CalledId

ВНИМАНИЕ: Если переключение на сотрудника в главном сценарии произойдет раньше, чем отработает статус объекта, то сотруднику информация об абоненте не отобразится. В статистике АТС эта информация также присутствовать не будет. Исходя из этого, следует обеспечить скорость выполнения сценария или воспользоваться переменными для блокировки или приостановки работы главного сценария.

Служебный сценарий набора внешних/быстрых номеров

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

1. При наборе внутреннего быстрого номера (код инициатора 15)
2. При наборе внутреннего стандартного номера, содержащего одну или несколько записей о звонках на внешние номера — запуск осуществляется для каждого (код инициатора 24)
3. При вызове внешнего номера из конференции (код инициатора 23).

В качестве неявных параметров в сценарий передаются:

• Входной параметр 1 — внешний номер, подлежащий набору
• Входной параметр 2 — время ожидания ответа в секундах, которое было бы применено системой при работе без сценария,
• Входной параметр 3 — внутренний номер, посредством которого осуществляется вызов внешнего (внутренние быстрые, внутренние стандартные номера) или пустая строка в случае вызова напрямую (из конференции).

Смотрите также: Сценарий набора внешних/быстрых номеров.

Служебный сценарий обработки контента

Сценарий запускается после завершения коммутации с внешней линией и предназначен для постобработки внешнего звонка. На вход сценария поступает контент линии — XML структура с идентификационной информацией по линии, абоненту, времени, а также перечень всех коммутаций с указанием имени сценария, идентификатора и имени оператора, времени начала, времени конца, продолжительности и пр. Для разбора полученной структуры следует использовать компонент «Парсер» с алгоритмом OQuery. Код инициатора запуска служебного сценария — 25.

• Входной параметр 1 — контент линии в XML-формате

Смотрите также: Служебный сценарий обработки контента

Служебный сценарий отправки электронной почты

Сценарий запускается, когда пользователь выберет в модуле «Телефон» действие «Отправить e-mail» и после ввода параметров нажмет ОК. Действие доступно только во время разговора, подробнее в технической документации. Предназначен для отправки электронной почты на указанный адрес. Код инициатора запуска служебного сценария — 30.

В качестве неявных параметров в служебный сценарий передаются:

• Входной параметр 1 — адреса получателей (возможно несколько через запятую)
• Входной параметр 2 — тема сообщения
• Входной параметр 3 — тело сообщения
• Входной параметр 4 — путь к каталогу с файлами для вложения.

Среди явных параметров (через функции) — информация о пользователе-инициаторе запуска и его линии, а также идентификатор сессии/цепочки коммутаций.

ВНИМАНИЕ! Рекомендуется разделить адреса и отправить письмо на каждый адрес отдельно, так как в случае единой отправки и ошибки в одном из адресов, письмо не будет отправлено никуда.

ВНИМАНИЕ! Вложения, выбранные пользователем-инициатором, предварительно закачиваются на сервер в указанный в параметре 4 каталог. От сценария требуется просмотр каталога, считывание имен всех файлов, и указание их в качестве вложений компонента Отправка Email.

Служебный сценарий отправки SMS-сообщения

Сценарий запускается, когда пользователь выберет в модуле «Телефон» действие «Отправить SMS» и после ввода параметров нажмет ОК. Действие доступно только во время разговора, подробнее в технической документации. Применяется для отправки SMS на указанный адрес. Код инициатора запуска служебного сценария — 29.

В качестве неявных параметров в служебный сценарий передаются:

• Входной параметр 1 — номер получателя
• Входной параметр 2 — текст сообщения.

Среди явных параметров (через функции) — информация о пользователе-инициаторе запуска и его линии, а также идентификатор сессии/цепочки коммутаций.

Служебный сценарий набора внутренних номеров при приглашении в конференцию

Активируется при добавлении внутреннего номера в конференцию. Если сценарий выключен, набор осуществляется через встроенный менеджер очередей. При необходимости расширить географию внутренних абонентов может потребоваться разбор номера и, в зависимости от различных параметров, перенаправление как во внешнюю, так и во внутреннюю сеть. В этом случае в служебном сценарии необходимо использовать компонент Дозвон с обслуживанием «Управляющий модуль с ожиданием в сценарии».

Также этим путем может быть организована внешняя очередь, реализованная как некий сервис. В обычных условиях если сценарий так и не получил ответа и вернул управление безрезультатно, конференция отбивает участника, выставляя ему состояние «не ответил». Однако при установке значения «1» служебной переменной «Возвращаемое значение 1» и безрезультатном возврате управления из сценария конференция тем не менее оставляет участника в состоянии «Ожидание ответа». На основе идентификационных параметров в асинхронном служебном сценарии может быть произведен последующий вход в конференцию произвольного канала с привязкой именно к этому участнику (посредством IVR сценария и компонента Конференция). В качестве кода участника и кода конференции могут быть использованы как строковые представления идентификаторов, так и коды идентификаторов — уникальные целые числа, являющиеся функциями от соответствующих guid-идентификаторов. См также Сценарии. Функции.

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

• Входной параметр 1 — вызываемый внутренний номер
• Входной параметр 2 — время ожидания ответа в секундах, которое было бы применено системой при работе без сценария

Код инициатора запуска служебного сценария — 17.

Служебный сценарий прерывания набора внутренних номеров в конференции

Активируется в момент исключения вызываемого внутреннего номера из конференции. Может быть использован для зачистки информации из внешней очереди (кейс описан выше), когда в ходе ожидания ответа был произведен обрыв приглашения.

На вход через стандартные функции служебных сценариев принимает идентификатор и код идентификатора конференции, номер комнаты, идентификатор и код идентификатора вызываемого участника (вызов которого в данном случае прерывается). В качестве неявных параметров передается:

• Входной параметр 1 — внутренний номер, вызов к которому был отклонен

Код инициатора запуска служебного сценария — 19.

Служебный сценарий обработки завершения конференции

Активируется сразу после завершения любой конференции. На вход через стандартные функции служебных сценариев принимает идентификатор, код идентификатора конференции, номер комнаты. В качестве неявных стартовых параметров передаются:

• Входной параметр 1 — путь к файлу с записью
• Входной параметр 2 — название конференции
• Входной параметр 3 — описание конференции

Код инициатора запуска служебного сценария — 20.

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

Служебный сценарий обработки текстового SIP-сообщения

Запускается при получении sip-сервером сообщения MESSAGE. Сценарий обрабатывает сообщение и, в случае надобности, отправляет ответ, пользуясь компонентом «Уведомление» со способом оповещения «SIP-сообщение«. В качестве неявных параметров в служебный сценарий передаются:

• Входной параметр 1 — текст сообщения
• Входной параметр 2 — CallerId отправителя
• Входной параметр 3 — CallerName отправителя
• Входной параметр 4 — идентификатор внутренней линии
• Входной параметр 5 — полный текст SIP-сообщения

Код инициатора запуска служебного сценария — 37

Служебный сценарий уведомления об смене основных состояний пользователя

Запускается при изменении состояния пользователя в системе. На вход через стандартные функции служебных сценариев принимает идентификатор пользователя. В качестве неявных стартовых параметров передаются:

• Входной параметр 1 — идентификатор пользователя
• Входной параметр 2 — код операции, где

1 — вход/выход из системы

2 — вход/выход из Call-центра

3 — вход/выход из статуса «Перерыв»

4 — вход/выход из ручного режима Call-центра

5 — вход/выход из статуса «Переадресация»

• Входной параметр 3 — код действия, где 1 — вход в состояние, 0 — выход из состояния

Код инициатора запуска служебного сценария — 34

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

Выполняется при изменении учетной записи пользователя в разделе Пользователи. На вход через стандартные функции служебных сценариев принимает идентификатор администратора. В качестве неявных стартовых параметров передаются:

• Входной параметр 1 — идентификатор изменяемого пользователя
• Входной параметр 2 — код операции (1-создание, 2-изменение, 3-удаление)
• Входной параметр 3 — логин
• Входной параметр 4 — пароль (непустой только в случае создания или изменения, в ходе которого изменен в том числе пароль)
• Входной параметр 5 — имя

Код инициатора запуска служебного сценария — 33.

Служебный сценарий внешней авторизации пользователя

Выполняется в момент авторизации пользователя в систему. Работает только для авторизации в толстом (windows) клиентском приложении. Сценарий предназначен для анализа введенных значений логина и пароля, которые могут не совпадать с существующими учетными записями. Для проверки значений сценарий использует внешнюю систему (CRM, внешнюю БД) через веб-запрос или путем обращения к БД. Если данные верны, следует присвоить логин существующего пользователя Oktell, под которым будет произведен вход в систему, в служебную переменную «Возвращаемое значение 1» .

На вход через стандартные функции служебных сценариев принимает идентификатор пользователя. В качестве неявных стартовых параметров передаются:

• Входной параметр 1 — введенный логин
• Входной параметр 2 — введенный пароль
• Входной параметр 3 — имя хоста клиентской станции

Код инициатора запуска служебного сценария — 36.

Служебный сценарий обработки ошибки авторизации

Сценарий используется только для неверных авторизаций через WebSocket или Http. Для неверных авторизаций с толстого клиента работать не будет. Запускается если с определенной станции число неверных запросов на авторизацию превысило 20 раз в 10 минут. Сценарий предназначен для предупреждения администратора о возможной DDOS-атаке или переборе пароля. Если число запросов превышает 20 раз за 20 секунд, IP-адрес попадает в бан.

В качестве неявных стартовых параметров передаются:

• Входной параметр 1 — IP-адрес отправки запросов.
• Входной параметр 2 — введенный логин
• Входной параметр 3 — введенный пароль в md5
• Входной параметр 4 — сессия, если клиент авторизуется под активной сессией
• Входной параметр 5 — код причины неверной авторизации. Код возвращается в виде 1xx — для WebSocket подключения и 2xx — для http-запросов. Возможны следующие коды (последние два знака):

• 01 — Учетная запись не найдена
• 02 — Неверная сессия
• 03 — Сессия не найдена
• 04 — Сценарий внешней авторизации запретил вход
• 05 — Сценарий внешней авторизации вернул неверный логин
• 06 — Сценарий внешней авторизации превысил время таймаута 10 секунд
• 07 — Неверный пароль
• 08 — Доступ запрещен для роли

Инициатор запуска — 38

Служебный сценарий поиска записи разговора

Сначала файл записи ищется по стандартному пути. Если не найден — запускается сценарий «Служебный сценарий поиска записи разговора».

На вход в качестве неявных стартовых параметров передаются:

• Входной параметр 1 — id коммутации или конференции.
• Входной параметр 2 — тип звонка (0 — коммутация, 1-конференция)
• Входной параметр 3 — тип операции с файлом (1 — скачать, 0 — удалить)

В служебную переменную «Возвращаемое значение 1» должен быть сохранен путь к скачанному файлу на сервере или строка «double».

При запросе из толстого клиента — ожидание сценария 200 мс синхронно и потом ответ «файл занят, попробуйте позже».
При запросе из веб приложения — ожидание синхронно не более минуты.

Борьба с дубликатами запросов, поступившими пока файл еще качается в другой сессии сценария — на самом сценарии.
Если сценарий отказывает на очередной запрос в запуске по причине дубликата (еще не завершившегося сценария) — нужно вернуть строку «double», тогда пользователь увидит «файл занят, попробуйте позже» вместо «файл не найден».
Рекомендуется скачивать во временное хранилище, а затем переносить по исходному месторасположению.

Основные сценарии использования

В своей основе SOAP-сообщениеявляется единицей односторонней передачи
данных междуSOAP-узлами,
отSOAP-отправителякSOAP-получателю,
поэтому SOAP-сообщения должны компоноваться
приложениями с целью реализации более
сложных шаблонов взаимодействия, начиная
шаблонами взаимодействия типа
«запрос/отклик» и кончая множественными
двунаправленными (двусторонними)
«диалоговыми» вариантами обмена
сообщениями.

Учебник раскрывает структуру SOAP-сообщений
и обмена ими в нескольких простых
сценариях использования, применительно
к реализации приложения бронирования
путешествия. Различные аспекты сценария
этого приложения будут использоваться
в учебнике и в дальнейшем. В этом сценарии
приложение бронирования путешествия
осуществляет бронь на планируемую
поездку для сотрудника компании в ходе
взаимодействия с сервисом продажи
билетов. Информация, которой обмениваются
приложение бронирования путешествия
и сервис продажи билетов, посылается в
виде SOAP-сообщений.

Конечным получателем SOAP-сообщения,
отправленного приложением бронирования
путешествия, является сервис продажи
билетов, но на пути к конечному получателю
SOAP-сообщение может проходить через один
или несколько SOAP-посредников,
каждый из которых может некоторым
образом на него воздействовать.
Простейшими примерами подобных
SOAP-посредников могут быть узлы,
протоколирующие запросы, осуществляющие
их аудит или вносящие изменения в каждый
запрос на бронирование путешествия.
Примеры, а также более детальное
обсуждение поведения и роли SOAP-посредников
отложим дораздела
5.1.

Раздел 2.1описывает запрос на бронирование путешествия в виде soap-сообщения, который дает возможность описать различные составляющие soap-сообщения.

В разделе
2.2.1с помощью того же сценария
демонстрируется отклик сервиса продажи
билетов в виде другого SOAP-сообщения,
формирующего часть диалогового обмена
сообщениями как набор различных
альтернатив, удовлетворяющих ограничениям
присланного запроса на бронирование
путешествия.

Раздел
2.2.2предполагает, что будущим
путешественником были одобрены различные
параметры бронирования путешествия, и
далее, посредством обмена сообщениями
между приложением бронирования
путешествий и сервисом продажи билетов,
смоделированного как вызов удаленной
процедуры (RPC), подтверждается оплата
брони.

Раздел 2.3демонстрирует примеры обработки ошибок. Soap-сообщения

Пример
1показывает данные, необходимые
для работы приложения бронирования
путешествий, в видеSOAP-сообщения.

Пример 1

<?xml
version=’1.0’ ?>

<env:Envelope
xmlns:env=”http://www.w3.org/2003/05/soap-envelope”>

<env:Header>

<m:reservation
xmlns:m=”http://travelcompany.example.org/reservation”

env:role=”http://www.w3.org/2003/05/soap-envelope/role/next”

env:mustUnderstand=”true”>

<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>

<m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime>

</m:reservation>

<n:passenger
xmlns:n=”http://mycompany.example.com/employees”

env:role=”http://www.w3.org/2003/05/soap-envelope/role/next”

env:mustUnderstand=”true”>

<n:name>Еke
Jуgvan Шyvind</n:name>

</n:passenger>

</env:Header>

<env:Body>

<p:itinerary

xmlns:p=”http://travelcompany.example.org/reservation/travel”>

<p:departure>

<p:departing>New
York</p:departing>

<p:arriving>Los
Angeles</p:arriving>

<p:departureDate>2001-12-14</p:departureDate>

<p:departureTime>late
afternoon</p:departureTime>

<p:seatPreference>aisle</p:seatPreference>

</p:departure>

<p:return>

<p:departing>Los
Angeles</p:departing>

<p:arriving>New
York</p:arriving>

<p:departureDate>2001-12-20</p:departureDate>

<p:departureTime>mid-morning</p:departureTime>

<p:seatPreference/>

</p:return>

</p:itinerary>

<q:lodging

xmlns:q=”http://travelcompany.example.org/reservation/hotels”>

<q:preference>none</q:preference>

</q:lodging>

</env:Body>

</env:Envelope>

Образец SOAP-сообщения бронирования
путешествия, содержащий заголовочный
блок и тело сообщения

SOAP-сообщение примера
1содержит два специфичных для
SOAP субэлемента, находящихся внутри
более общего элементаenv:Envelope,
а именноenv:Headerиenv:Body.
Содержимое этих элементов определяется
приложением и не рассматривается
спецификацией SOAP, хотя в дальнейшем
будет немного сказано о том, как подобные
элементы должны обрабатываться.

Заголовочный
элемент SOAPне является
обязательным, однако он был включен в
пример для того, чтобы объяснить некоторые
функции SOAP. Заголовок SOAP является
расширением, предоставляющим способ
передачи в SOAP-сообщениях информации,
вообще говоря не являющейся полезной
для приложения. Подобная «контрольная»
информация включает, например, директивы
прохождения сообщения или контекстную
информацию, относящуюся к обработке
сообщения. Это позволяет подстраивать
SOAP-сообщения под каждое конкретное
приложение. Следующие непосредственно
заenv:Headerдочерние элементы называютсязаголовочными
блоками. Они представляют
логическую группировку данных, которые,
как показано позже, могут быть индивидуально
адресованы SOAP-узлам, встречаемым
сообщением на пути от отправителя к
конечному получателю.

Заголовки SOAP были созданы в предположении
появления различных вариантов
использования SOAP, многие из которых
будут вовлекать во взаимодействие
другие обрабатывающие SOAP-сообщения
узлы, называемые SOAP-посредниками– на пути сообщения отначального
отправителя SOAP-сообщениядоконечного
SOAP-получателя. Это позволяет
SOAP-посредникам предоставлять дополнительные
сервисы. Заголовки, как показано далее,
могут быть просмотрены, вставлены,
удалены или пересланы SOAP-узлами,
встреченными напути
SOAP-сообщения. (Однако, необходимо
помнить, что спецификации SOAP не описывают
содержимое заголовочных элементов, или
то, как SOAP-сообщения маршрутизируются
между узлами. Они также не описывают
каким образом определяется маршрут
сообщения и т. д. Эти вопросы решаются
приложением в целом и могут быть предметом
рассмотрения других спецификаций.)

Тело
SOAP-сообщенияявляется обязательным
элементом внутриenv:Envelope,
содержащим основную информацию
SOAP-сообщения, которая должна быть
передана из начальной точки пути
сообщения в конечную.

В примере
1, заголовок содержит два
заголовочных блока, каждый из которых
определен в собственном пространстве
имен XML, и отражает некоторый аспект
общей обработки тела SOAP-сообщения. Для
приложения бронирования путешествия,
подобная, принадлежащая к запросу в
целом, «метаинформация» содержится в
заголовочном блокеreservation,
который представляет собой ссылку на
этот экземпляр запроса, а также содержит
его временную отметку. «Метаинформация»,
служащая для идентификации будущего
путешественника, содержится в блокеpassenger.

Заголовочные блоки reservationиpassengerдолжны обрабатываться следующим
SOAP-посредником, встреченным на пути
сообщения, либо, в случае отсутствия
узла-посредника, конечным получателем
сообщения. На тот факт, что сообщение
адресовано следующему SOAP-узлу, встреченному
на пути сообщения, указывает присутствие
атрибутаenv:roleсо значением
«http://www.w3.org/2003/05/soap-envelope/role/next» (здесь и
далее просто «next»). Этот атрибут реализуетроль,
исполнять которую обязаны все SOAP-узлы.
Присутствие же атрибутаenv:mustUnderstandсо значением «true» указывает на то, что
узел (узлы), обрабатывающий заголовочные
блоки, должен обрабатывать их в строгом
соответствии с их спецификациями либо
не обрабатывать SOAP-сообщение вовсе и
выдать сообщение об ошибке. Необходимо
отметить, что если заголовочный блок
обрабатывается, ввиду ли присутствияenv:mustUnderstand=»true»либо по какой-либо другой причине, такой
блок должен быть обработан в соответствии
со спецификацией этого блока. Спецификации
заголовочных блоков определяются
конкретным приложением и не являются
предметом рассмотрения SOAP. Подробное
изложение обработки SOAP-сообщения в
зависимости от значений вышеупомянутых
атрибутов содержится вразделе
3.

Решение по поводу того, какие данные
поместить в заголовочный блок и тело
SOAP-сообщения, должно быть принято на
этапе проектирования приложения.
Необходимо помнить, что заголовочные
блоки могут быть адресованы различным
узлам, которые могут встречаться на
пути сообщения от отправителя к конечному
получателю. Подобные промежуточные
SOAP-узлы могут предоставлять дополнительные
услуги, используя данные, содержащиеся
в этих заголовочных блоках. В примере
1, данные о пассажире помещены
в заголовочный блок для того, чтобы
проиллюстрировать их использование
SOAP-посредником для выполнения некоторой
дополнительной обработки. Например,
как показано далее вразделе
5.1, уходящее сообщение изменяется
SOAP-посредником путем добавления в
качестве еще одного заголовочного блока
политик совершения путешествия
пассажиром.

Элемент env:Bodyи ассоциированные с ним дочерние элементыitineraryиlodging,
вовлечены в обмен информацией междуначальным
отправителем SOAP-сообщенияи
SOAP-узлом на его пути, выступающим в роликонечного
получателя SOAP-сообщения, которым
является сервис продажи билетов. Поэтому
элементenv:Bodyс его содержимым всецело адресован
конечному получателю и должен быть им
понят. Средства, посредством которых
SOAP-узел может выполнять эту роль, не
определяются спецификацией SOAP. Они
определяются общей семантикой приложения
и ассоциированного с ним потоком
сообщений.

Необходимо отметить, что SOAP-посредник
может играть роль конечного получателя
для рассматриваемого сообщения и таким
образом также может обрабатывать
env:Body.
Однако, хотя такой тип поведения и не
может быть предугадан, это не означает,
что обработка сообщения может производиться
без должного внимания, поскольку в этом
случае могут быть искажены первоначальные
намерения отправителя сообщения. Это
может иметь нежелательные побочные
эффекты (такие как необработка заголовочных
блоков, которые могут быть адресованы
узлам-посредникам, находящимся далее
на пути следования сообщения).

SOAP-сообщение, подобное представленному
в примере
1, может быть передано посредством
различных нижележащих протоколов и
использоваться в различныхшаблонах
обмена сообщениями. Например,
для web-доступа к сервису продажи билетов,
оно может быть помещено в тело http- запроса
POST. В случае привязки к другому протоколу,
оно может быть отправлено в email-сообщении
(см.раздел
4.2).Раздел
4далее опишет то, как SOAP-сообщения
могут передаваться посредством различных
нижележащих протоколов. Сейчас же
предположим, что механизм для передачи
сообщения уже существует, и в дальнейшей
части этого раздела сконцентрируемся
на деталях SOAP-сообщений и их обработки.