Переменные — различия между версиями

Материал из Oktell
Перейти к: навигация, поиск
Строка 43: Строка 43:
  
 
В списке доступных переменных служебные переменные отображаются серым цветом.
 
В списке доступных переменных служебные переменные отображаются серым цветом.
 
Переменные размещаются в хранилище обработчика сценариев и существуют в рамках его жизни. Каждый экземпляр обработчика (даже если они реализуют один и тот же сценарий) имеет свой экземпляр каждой переменной. Запуск вложенных сценариев осуществляется в том же самом обработчике, поэтому переменные с одинаковыми именами имеют одно и то же размещение, и, соответственно, их значения перетекают из сценария в сценарий при запуске и при возврате управления.
 
 
При запуске асинхронных служебных сценариев значения переменных с совпадающими именами и типами копируются в хранилище значений переменных запускаемого обработчика, дальше переменные существуют независимо в каждом обработчике.
 
  
 
При создании переменной можно установить для ее размещения обработчик сценария (локальная), хранилище сессии (сессионная) или глобальное хранилище сервера (глобальная).  
 
При создании переменной можно установить для ее размещения обработчик сценария (локальная), хранилище сессии (сессионная) или глобальное хранилище сервера (глобальная).  
 +
* '''Локальная'''. Переменные размещаются в хранилище обработчика сценариев и существуют в рамках его жизни. Каждый экземпляр обработчика (даже если они реализуют один и тот же сценарий) имеет свой экземпляр каждой переменной. Запуск вложенных сценариев осуществляется в том же самом обработчике, поэтому переменные с одинаковыми именами имеют одно и то же размещение, и, соответственно, их значения перетекают из сценария в сценарий при запуске и при возврате управления. При запуске асинхронных служебных сценариев значения переменных с совпадающими именами и типами копируются в хранилище значений переменных запускаемого обработчика, дальше переменные существуют независимо в каждом обработчике.
 
* '''Сессионная'''. В случае использования сессионных переменных разные на низком уровне обработчики будут связаны между собой через идентификатор сессии, совпадающий с кодом цепочки коммутаций. Например, если создать сессионные переменные с одинаковым именем в нескольких сценариях IVR, в диалоговом и служебном сценарии, то при входящем звонке можно организовать следующую схему: в главном сценарии IVR переменной устанавливается значение. Далее звонок переходит в задачу, в ходе обработки которой запускается сценарий диалога. Обращаясь к сессионной переменной он получит установленное ранее в сценарии IVR значение. При переключении оператором абонента на второй сценарий IVR, там может быть доступно модифицированное в сценарии диалога значение. Служебный сценарий (запущенный асинхронно или как обработчик контента) также будет иметь доступ к значению, установленному ранее в других сценариях. Все это происходит, потому что сессионная переменная хранится на сервере состояний и все сценарии одной сессии обращаются к одной области памяти, поскольку все связаны с обработкой звонка в сессии - цепочке коммутаций, инициированной входящим звонком абонента. Один и тот же сценарий, работающий параллельно в разных сессиях и использующий одну и ту же учетную запись сессионной переменной, фактически работает в разных областях памяти и не имеет пересечений по ее значениям.
 
* '''Сессионная'''. В случае использования сессионных переменных разные на низком уровне обработчики будут связаны между собой через идентификатор сессии, совпадающий с кодом цепочки коммутаций. Например, если создать сессионные переменные с одинаковым именем в нескольких сценариях IVR, в диалоговом и служебном сценарии, то при входящем звонке можно организовать следующую схему: в главном сценарии IVR переменной устанавливается значение. Далее звонок переходит в задачу, в ходе обработки которой запускается сценарий диалога. Обращаясь к сессионной переменной он получит установленное ранее в сценарии IVR значение. При переключении оператором абонента на второй сценарий IVR, там может быть доступно модифицированное в сценарии диалога значение. Служебный сценарий (запущенный асинхронно или как обработчик контента) также будет иметь доступ к значению, установленному ранее в других сценариях. Все это происходит, потому что сессионная переменная хранится на сервере состояний и все сценарии одной сессии обращаются к одной области памяти, поскольку все связаны с обработкой звонка в сессии - цепочке коммутаций, инициированной входящим звонком абонента. Один и тот же сценарий, работающий параллельно в разных сессиях и использующий одну и ту же учетную запись сессионной переменной, фактически работает в разных областях памяти и не имеет пересечений по ее значениям.
 
* '''Глобальная'''. Именованная глобальная серверная переменная размещается в единой области памяти для всех сценариев всех сессий. Ее задача - избавить служебные сценарии от необходимости кэшировать значения в БД. Можно воспользоваться системой мини-транзакций при работе с глобальными переменными: если название переменной начинается с комбинации ''lock_'', то после каждого возврата ее значения осуществляется блокировка на 100 мс, чтобы взявший ее значение сценарий сумел успеть принять решение и занести в нее новое значение.  
 
* '''Глобальная'''. Именованная глобальная серверная переменная размещается в единой области памяти для всех сценариев всех сессий. Ее задача - избавить служебные сценарии от необходимости кэшировать значения в БД. Можно воспользоваться системой мини-транзакций при работе с глобальными переменными: если название переменной начинается с комбинации ''lock_'', то после каждого возврата ее значения осуществляется блокировка на 100 мс, чтобы взявший ее значение сценарий сумел успеть принять решение и занести в нее новое значение.  

Версия 08:52, 28 марта 2013

Наверх


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


Переменные в сценариях принадлежат к одному из типов:

  • Число (целое или десятичное);
  • Строка;
  • Дата/время;
  • Поле таблицы;
  • Служебные (только для присвоение значений).


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

В именах переменных не допускаются символы '[', ']', '\'. Запрещены также дублирующие имена.


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

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

Cl cc scra f1 2.png


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


ВНИМАНИЕ! Использовать переменные типа «Поле» в сценарии рекомендуется в режиме «1 чтение, 1 запись». Если необходимо использовать значение переменной типа «Поле таблицы» в сравнении или других промежуточных объектах, с точки зрения скорости работы лучше после считывания из базы сохранять ее значение во временной переменной (число, строка, дата/время) и использовать на протяжении сценария именно временную переменную.


ВНИМАНИЕ! Связь переменных типа «Поле» осуществляется как с локальными таблицами абонентов, так и с внешними. Однако, если внешняя таблица абонентов формируется только лишь на базе запроса в БД, связь не будет осуществлена. Поиск полей производится только среди столбцов указанной базовой таблицы БД вне зависимости от того, используется ли параллельно с этим запрос в БД. Подробнее в разделе Таблицы абонентов.


В каждом типе сценариев существует перечень служебных переменных. Они доступны только в компоненте «Присвоение значения переменной» в качестве приемщика значения. Такие переменные связывают логику выполняющейся задачи с исходом выполнения сценария. Принимая в расчет соответствующие значения в случае их корректности, сервисы-владельцы сценариев будут действовать соответствующим образом. По умолчанию значения переменных выставлены в «-1», что указывает обслуживающим сервисам на отсутствие необходимости учета.

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

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

  • Локальная. Переменные размещаются в хранилище обработчика сценариев и существуют в рамках его жизни. Каждый экземпляр обработчика (даже если они реализуют один и тот же сценарий) имеет свой экземпляр каждой переменной. Запуск вложенных сценариев осуществляется в том же самом обработчике, поэтому переменные с одинаковыми именами имеют одно и то же размещение, и, соответственно, их значения перетекают из сценария в сценарий при запуске и при возврате управления. При запуске асинхронных служебных сценариев значения переменных с совпадающими именами и типами копируются в хранилище значений переменных запускаемого обработчика, дальше переменные существуют независимо в каждом обработчике.
  • Сессионная. В случае использования сессионных переменных разные на низком уровне обработчики будут связаны между собой через идентификатор сессии, совпадающий с кодом цепочки коммутаций. Например, если создать сессионные переменные с одинаковым именем в нескольких сценариях IVR, в диалоговом и служебном сценарии, то при входящем звонке можно организовать следующую схему: в главном сценарии IVR переменной устанавливается значение. Далее звонок переходит в задачу, в ходе обработки которой запускается сценарий диалога. Обращаясь к сессионной переменной он получит установленное ранее в сценарии IVR значение. При переключении оператором абонента на второй сценарий IVR, там может быть доступно модифицированное в сценарии диалога значение. Служебный сценарий (запущенный асинхронно или как обработчик контента) также будет иметь доступ к значению, установленному ранее в других сценариях. Все это происходит, потому что сессионная переменная хранится на сервере состояний и все сценарии одной сессии обращаются к одной области памяти, поскольку все связаны с обработкой звонка в сессии - цепочке коммутаций, инициированной входящим звонком абонента. Один и тот же сценарий, работающий параллельно в разных сессиях и использующий одну и ту же учетную запись сессионной переменной, фактически работает в разных областях памяти и не имеет пересечений по ее значениям.
  • Глобальная. Именованная глобальная серверная переменная размещается в единой области памяти для всех сценариев всех сессий. Ее задача - избавить служебные сценарии от необходимости кэшировать значения в БД. Можно воспользоваться системой мини-транзакций при работе с глобальными переменными: если название переменной начинается с комбинации lock_, то после каждого возврата ее значения осуществляется блокировка на 100 мс, чтобы взявший ее значение сценарий сумел успеть принять решение и занести в нее новое значение.

ВНИМАНИЕ! Ранее до версии 2.8.130328 сессионные переменные назывались глобальными. Их различие существенно!

Любой служебный сценарий перенимает номер сессии от запускающего объекта - другого сценария, задачи, линии. Служебные сценарии, стартующие вне канальных сессий (цепочек) генерируют уникальный код. При организации набора номера в служебном сценарии (компонент «Дозвон») в качестве кода цепочки активированного канала устанавливается код сессии служебного сценария, но не более 1 раза и только в случае, если код сессии сценария не был передан извне. В остальных случаях код цепочки будет генерироваться. Так происходит во избежание дублирования кодов цепочек в разных по смыслу звонках.