'subscr' capability для WebSocket User API

Обзор

С помощью модуля производится подписка на события системы.

Выделяются следующие категории событий:

  • События об изменениях в модели данных - как статической, так и динамической (modelevents.data_changed).

  • События телефонии (callevents).

  • События сценариев IVR (ivrevents).

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

Построение запросов

  1. Общий вид запроса:

[
  "subscribe",
  {
    "qid":"16066361-dfc0-49f6-b734-9b3dda09db22",
    "objects": ...,
    "events": ...,
    "expires": ...,
    "id": ...
    "exargs": ...
    ...
  }
]

  • objects - список объектов для фильтрации событий. Может быть указано значение "any" или список значений, например ["sipuser1","sipuser2"].

  • events - список событий для фильтрации типов событий. Указывается список строк, каждая из которых представляет отдельный тип события, например callevents.dlg_start. Для ряда классов допустимо указывать callevents.*.

  • expires - время жизни подписки в секундах. При необходимости подписчик должен продлить подписку повторной отправкой запроса с ненулевым значением expires.

  • id - идентификатор подписки, который будет указываться при отправке уведомлений.

  • exargs - объект со специфическими настройками подписки. В частности при подписке на modelevents.data_changed может быть установлен фильтр (filter) и маскировка (mask).

Допустима подписка на несколько событий или объектов.

Исключение составляет тип событий modelevents.data_changed, подписка на который должна содержать ровно один объект (название класса или путь к классу в REST-API) и ровно один тип событий (сам modelevents.data_changed).

callevents

События подлежащие отправке перечислены здесь.

ivrevents

События подлежащие отправке перечислены здесь.

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

modelevents.data_changed

События этого типа генерируются сразу же при проведении изменений в модели данных - как статической (dc), так и динамической (dms).

При обработке запроса subscribe производится авторизация на операцию чтения элементов коллекции. Соответственно, пользователю должна быть добавлена роль, имеющая разрешение на маршрут к endpoint элемента коллекции методом GET.

Событием notify доставляются данные о проведенной операции, а также текущее значение измененной сущности с поправкой на маску (exobj.mask). При создании подписки с фильтром (exobj.filter), события могут быть отфильтрованы. Доставляемые события всегда приводятся к create, update и delete на основании сравнения предыдущего значения и нового значения с фильтром. Так, если предыдущее значение не попадало под фильтр, а после изменения попадает, то событие будет доставлено и иметь операцию create несмотря на то, что реально была проведена операция update или replace.

Виды операций:

  • create - сущность создана и попадает под фильтр, либо изменена так, что теперь попадает под фильтр подписки.

  • update - сущность изменена, и оба значения - прошлое и текущее - попадают под фильтр подписки.

  • delete - сущность удалена, либо изменена так, что теперь не попадает под фильтр подписки.

  • reload - очередь обработки запросов по классу перезагружена. Для обеспечения целостности требуется повторный REST-запрос на выборку элементов из коллекции с фильтром.

  • clear - коллекция очищена.

  • corrupt - при обработке запроса по сущности возникла проблема с хранилищем, текущее состояние сущности может быть рассогласовано, и требуется обновление сущности REST-запросом.

Ссылки

  • Персонализация
  • Увеличить шрифт
  • Уменьшить шрифт