Переменные — различия между версиями
Peter (обсуждение | вклад) |
Peter (обсуждение | вклад) |
||
| Строка 43: | Строка 43: | ||
В списке доступных переменных служебные переменные отображаются серым цветом. | В списке доступных переменных служебные переменные отображаются серым цветом. | ||
| − | |||
| − | |||
| − | |||
| − | |||
При создании переменной можно установить для ее размещения обработчик сценария (локальная), хранилище сессии (сессионная) или глобальное хранилище сервера (глобальная). | При создании переменной можно установить для ее размещения обработчик сценария (локальная), хранилище сессии (сессионная) или глобальное хранилище сервера (глобальная). | ||
| + | * '''Локальная'''. Переменные размещаются в хранилище обработчика сценариев и существуют в рамках его жизни. Каждый экземпляр обработчика (даже если они реализуют один и тот же сценарий) имеет свой экземпляр каждой переменной. Запуск вложенных сценариев осуществляется в том же самом обработчике, поэтому переменные с одинаковыми именами имеют одно и то же размещение, и, соответственно, их значения перетекают из сценария в сценарий при запуске и при возврате управления. При запуске асинхронных служебных сценариев значения переменных с совпадающими именами и типами копируются в хранилище значений переменных запускаемого обработчика, дальше переменные существуют независимо в каждом обработчике. | ||
* '''Сессионная'''. В случае использования сессионных переменных разные на низком уровне обработчики будут связаны между собой через идентификатор сессии, совпадающий с кодом цепочки коммутаций. Например, если создать сессионные переменные с одинаковым именем в нескольких сценариях IVR, в диалоговом и служебном сценарии, то при входящем звонке можно организовать следующую схему: в главном сценарии IVR переменной устанавливается значение. Далее звонок переходит в задачу, в ходе обработки которой запускается сценарий диалога. Обращаясь к сессионной переменной он получит установленное ранее в сценарии IVR значение. При переключении оператором абонента на второй сценарий IVR, там может быть доступно модифицированное в сценарии диалога значение. Служебный сценарий (запущенный асинхронно или как обработчик контента) также будет иметь доступ к значению, установленному ранее в других сценариях. Все это происходит, потому что сессионная переменная хранится на сервере состояний и все сценарии одной сессии обращаются к одной области памяти, поскольку все связаны с обработкой звонка в сессии - цепочке коммутаций, инициированной входящим звонком абонента. Один и тот же сценарий, работающий параллельно в разных сессиях и использующий одну и ту же учетную запись сессионной переменной, фактически работает в разных областях памяти и не имеет пересечений по ее значениям. | * '''Сессионная'''. В случае использования сессионных переменных разные на низком уровне обработчики будут связаны между собой через идентификатор сессии, совпадающий с кодом цепочки коммутаций. Например, если создать сессионные переменные с одинаковым именем в нескольких сценариях IVR, в диалоговом и служебном сценарии, то при входящем звонке можно организовать следующую схему: в главном сценарии IVR переменной устанавливается значение. Далее звонок переходит в задачу, в ходе обработки которой запускается сценарий диалога. Обращаясь к сессионной переменной он получит установленное ранее в сценарии IVR значение. При переключении оператором абонента на второй сценарий IVR, там может быть доступно модифицированное в сценарии диалога значение. Служебный сценарий (запущенный асинхронно или как обработчик контента) также будет иметь доступ к значению, установленному ранее в других сценариях. Все это происходит, потому что сессионная переменная хранится на сервере состояний и все сценарии одной сессии обращаются к одной области памяти, поскольку все связаны с обработкой звонка в сессии - цепочке коммутаций, инициированной входящим звонком абонента. Один и тот же сценарий, работающий параллельно в разных сессиях и использующий одну и ту же учетную запись сессионной переменной, фактически работает в разных областях памяти и не имеет пересечений по ее значениям. | ||
* '''Глобальная'''. Именованная глобальная серверная переменная размещается в единой области памяти для всех сценариев всех сессий. Ее задача - избавить служебные сценарии от необходимости кэшировать значения в БД. Можно воспользоваться системой мини-транзакций при работе с глобальными переменными: если название переменной начинается с комбинации ''lock_'', то после каждого возврата ее значения осуществляется блокировка на 100 мс, чтобы взявший ее значение сценарий сумел успеть принять решение и занести в нее новое значение. | * '''Глобальная'''. Именованная глобальная серверная переменная размещается в единой области памяти для всех сценариев всех сессий. Ее задача - избавить служебные сценарии от необходимости кэшировать значения в БД. Можно воспользоваться системой мини-транзакций при работе с глобальными переменными: если название переменной начинается с комбинации ''lock_'', то после каждого возврата ее значения осуществляется блокировка на 100 мс, чтобы взявший ее значение сценарий сумел успеть принять решение и занести в нее новое значение. | ||
Версия 08:52, 28 марта 2013
Переменная сценария – это величина, хранящая свое значение на всем протяжении выполнения сценария. У некоторых объектов существует доступ к чтению значения переменной и к его изменению.
Переменные в сценариях принадлежат к одному из типов:
- Число (целое или десятичное);
- Строка;
- Дата/время;
- Поле таблицы;
- Служебные (только для присвоение значений).
Все переменные сценария определяются на этапе его создания. При назначении свойств, имеющих своим значением переменную, пользователь может редактировать список переменных, а также выбирать и подставлять в значение свойства ссылку на конкретную переменную.
В именах переменных не допускаются символы '[', ']', '\'. Запрещены также дублирующие имена.
Переменные используются в сценарии для переноса значения из одних объектов в другие. Например, заполнение переменной может происходить в БД (соответственно компонент «Запрос в БД»), а использование при воспроизведении этого значения абоненту (компонент «Воспроизведение числа») или при определении необходимой ветки сценария (компонент «Сравнение») путем выбора следующего обрабатываемого объекта на основании значения этой переменной.
Для работы с переменными (создание, удаление, подстановка) служит соответствующая вкладка окна Аргументы. При подстановке переменной в качестве значения свойства объекта ее значение вычисляется или назначается (в зависимости от типа свойства) в сценарии в момент работы объекта-владельца.
Переменные типа «Поле таблицы» используются в сценарии наравне с другими переменными, но имеют совершенно иную структуру. Каждый запрос на получение данных из такой переменной обращается к таблице абонентов, прикрепленной к текущей выполняемой задаче. По имени такой переменной ищется столбец в соответствующей таблице и производится запрос данных из ячейки на пересечении найденного столбца со строкой, содержащей информацию о текущем абоненте. При записи производится аналогичное действие. Если не найден столбец с указанным именем, либо строка с кодом текущего абонента, действие по записи не производится, а при чтении возвращается пустая строка. Подобный усложненный характер работы обусловлен тем, что сценарий создается независимо от задачи и таблицы абонентов и не имеет информации о них до начала выполнения на сервере. В дальнейшем в руководстве переменные типа «Поле таблицы» не будут рассматриваться обособленно, работа с ними полностью аналогична переменным других типов.
В списке доступных переменных переменные типа «Поле таблицы» отображаются зеленым цветом.
ВНИМАНИЕ! Использовать переменные типа «Поле» в сценарии рекомендуется в режиме «1 чтение, 1 запись». Если необходимо использовать значение переменной типа «Поле таблицы» в сравнении или других промежуточных объектах, с точки зрения скорости работы лучше после считывания из базы сохранять ее значение во временной переменной (число, строка, дата/время) и использовать на протяжении сценария именно временную переменную.
ВНИМАНИЕ! Связь переменных типа «Поле» осуществляется как с локальными таблицами абонентов, так и с внешними. Однако, если внешняя таблица абонентов формируется только лишь на базе запроса в БД, связь не будет осуществлена. Поиск полей производится только среди столбцов указанной базовой таблицы БД вне зависимости от того, используется ли параллельно с этим запрос в БД. Подробнее в разделе Таблицы абонентов.
В каждом типе сценариев существует перечень служебных переменных. Они доступны только в компоненте «Присвоение значения переменной» в качестве приемщика значения. Такие переменные связывают логику выполняющейся задачи с исходом выполнения сценария. Принимая в расчет соответствующие значения в случае их корректности, сервисы-владельцы сценариев будут действовать соответствующим образом. По умолчанию значения переменных выставлены в «-1», что указывает обслуживающим сервисам на отсутствие необходимости учета.
В списке доступных переменных служебные переменные отображаются серым цветом.
При создании переменной можно установить для ее размещения обработчик сценария (локальная), хранилище сессии (сессионная) или глобальное хранилище сервера (глобальная).
- Локальная. Переменные размещаются в хранилище обработчика сценариев и существуют в рамках его жизни. Каждый экземпляр обработчика (даже если они реализуют один и тот же сценарий) имеет свой экземпляр каждой переменной. Запуск вложенных сценариев осуществляется в том же самом обработчике, поэтому переменные с одинаковыми именами имеют одно и то же размещение, и, соответственно, их значения перетекают из сценария в сценарий при запуске и при возврате управления. При запуске асинхронных служебных сценариев значения переменных с совпадающими именами и типами копируются в хранилище значений переменных запускаемого обработчика, дальше переменные существуют независимо в каждом обработчике.
- Сессионная. В случае использования сессионных переменных разные на низком уровне обработчики будут связаны между собой через идентификатор сессии, совпадающий с кодом цепочки коммутаций. Например, если создать сессионные переменные с одинаковым именем в нескольких сценариях IVR, в диалоговом и служебном сценарии, то при входящем звонке можно организовать следующую схему: в главном сценарии IVR переменной устанавливается значение. Далее звонок переходит в задачу, в ходе обработки которой запускается сценарий диалога. Обращаясь к сессионной переменной он получит установленное ранее в сценарии IVR значение. При переключении оператором абонента на второй сценарий IVR, там может быть доступно модифицированное в сценарии диалога значение. Служебный сценарий (запущенный асинхронно или как обработчик контента) также будет иметь доступ к значению, установленному ранее в других сценариях. Все это происходит, потому что сессионная переменная хранится на сервере состояний и все сценарии одной сессии обращаются к одной области памяти, поскольку все связаны с обработкой звонка в сессии - цепочке коммутаций, инициированной входящим звонком абонента. Один и тот же сценарий, работающий параллельно в разных сессиях и использующий одну и ту же учетную запись сессионной переменной, фактически работает в разных областях памяти и не имеет пересечений по ее значениям.
- Глобальная. Именованная глобальная серверная переменная размещается в единой области памяти для всех сценариев всех сессий. Ее задача - избавить служебные сценарии от необходимости кэшировать значения в БД. Можно воспользоваться системой мини-транзакций при работе с глобальными переменными: если название переменной начинается с комбинации lock_, то после каждого возврата ее значения осуществляется блокировка на 100 мс, чтобы взявший ее значение сценарий сумел успеть принять решение и занести в нее новое значение.
ВНИМАНИЕ! Ранее до версии 2.8.130328 сессионные переменные назывались глобальными. Их различие существенно!
Любой служебный сценарий перенимает номер сессии от запускающего объекта - другого сценария, задачи, линии. Служебные сценарии, стартующие вне канальных сессий (цепочек) генерируют уникальный код. При организации набора номера в служебном сценарии (компонент «Дозвон») в качестве кода цепочки активированного канала устанавливается код сессии служебного сценария, но не более 1 раза и только в случае, если код сессии сценария не был передан извне. В остальных случаях код цепочки будет генерироваться. Так происходит во избежание дублирования кодов цепочек в разных по смыслу звонках.
