1. Общий обзор

В xRM Onyma разработчик может расширить функции (ядра или UAPI) без изменения их кода. Для этого создана система обработки событий (EPS, Event Processing System). При наступлении определенного события — успешного обновления отчета, подключения услуги, заключения контракта, запуска процесса — система рассылает всем «заинтересованным сторонам» сообщение. В сообщение входит идентификатор события, а также дополнительные параметры: номер договора, ID отчета, процесса или услуги.

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

2. Раздел Система | Обработка событий

Здесь собрано всё нужное для работы с событиями.

Рассмотрим все разделы по порядку.

2.1. Задачи

Раздел: Система | Обработка событий | Задачи.

Пользовательская функция может запускаться с разными настройками. Управлять можно:

• Постановкой/отсутствием постановки в очередь;
• Количеством попыток запуска;
• Временем ожидания отклика (в минутах);
• Временем жизни (не обработанная в течение указанного срока задача считается неактуальной);
• Приоритетом выполнения...

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

В правилах обработки событий чаще всего используются следующие виды задач:

• STD_ASYNCH_TASK  — задача с постановкой в очередь;
• STD_SYNCH_TASK — задача без постановки в очередь.

2.1.1. Настройка предельной загрузки системы задачами выбранного типа («троттлинг»)

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

Загрузка указывается в поле Троттлинг и измеряется числом задач на промежуток времени в секундах. Число задач отделяется от промежутка времени знаком /. В нашем примере системе разрешено запускать не более 3 задач в 10 минут (600 с).

2.2. Параметры

Раздел: Система | Обработка событий | Параметры.

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

В карточке параметра всего два поля: Название и Описание:

2.3. Обработчики

Раздел: Система | Обработка событий | Обработчики.

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

В настройках сущности, во вкладке Задачи (подписка), можно указать задачи, которые она должна будет обрабатывать:

2.4. События

Раздел: Система | Обработка событий | События.

В этом разделе находится общий список событий. Здесь же можно создавать новые события (кнопка Добавить).

В карточке события, в одноименной вкладке, хранится список назначенных ему параметров (назначить можно только параметры, уже созданные в разделе Система | События | Параметры). Не более двух параметров можно пометить как ключевые. Ключевые параметры используются правилами при отборе событий для обработки.

Событие (вместе с правилом) может быть создано и в карточке модели процесса (вкладка Настройка событий):

2.5. Правила

Раздел: Система | Обработка событий | Группы правил.

Разбором и обработкой сообщений о событиях занимаются правила. Общего списка правил в интерфейсе xRM Onyma нет. Все правила распределены по группам, в зависимости от области применения: процессы, биллинг и другие. Правил вне группы не бывает. В пределах группы каждое событие может быть обработано только один раз.

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

Обратите внимание: порядок выполнения правил из разных групп непредсказуем.

Кроме того, в правило входят настройки выполнения задачи, статус (включено/выключено) и вид отклика на событие:

• Запуск функции API (синхронный или асинхронный);
• Отправка сообщения.

2.6. Очередь

Раздел: Система | Обработка событий | Очередь.

В этом разделе выведен список задач с постановкой в очередь. Цветовая разметка помогает отличить успешно отработавшие задачи от неудачных.

2.7. Лог

Раздел: Система | Обработка событий | Лог.

В этом разделе находится список всех отработавших задач.

В карточке задачи — подробности ее выполнения и значения параметров:

3. Настройки фоновых заданий

Настройки заданий, работающих в фоновом режиме, производятся в разделе Система | Фоновые задания:

3.1. Расписание

В разделе Расписание отображается список фоновых заданий и их настройки:

Настройки задания, запускающего демон onm.mps.OraDaemon:

3.1.2. Запуск собственного обработчика вместо стандартного демона

Обратите внимание на поле Тело задания. Если в скобках после имени стандартного демона onm.mps.OraDaemon указать имя пользовательского обработчика, он будет запускаться вместо стандартного демона:

Обработчики создаются в разделе Система | Обработка событий | Обработчики.

3.1.3. Многозадачность

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

3.2. Классы

Фоновые задания делятся на классы. Создать новый класс или изменить существующий вы можете в разделе Система | Обработка событий | Классы.

Каждому классу можно назначить допустимое количество одновременно запущенных обработчиков — в численном значении или в проценте от общего числа фоновых заданий:

Созданный или настроенный класс связывается с заданием в разделе Система | Фоновые задания | Расписание:

4. Обработка события

4.1. Пользовательская функция

Для того, чтобы при срабатывании правила запускалась функция API, в поле Задача нужно выбрать STD_SYNCH_TASK или STD_ASYNCH_TASK.

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

4.1.1. Полезные советы

Одно событие — одна функция. Несколько откликов на одно и то же событие лучше помещать в одну функцию.

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

Правильный выбор места для обработчика. Внутри бизнес-процесса происходит множество событий, причем некоторые из них повторяются: начало процесса, начало шага, создание объекта, изменение атрибута… Обрабатывать следует или уникальное, точно привязанное к нужному месту в процессе событие, или же повторяющееся — но с проверкой ID действия, откликаясь только на нужные.

Обратите внимание: изменение атрибута порождает событие только в том случае, если в свойствах нужного атрибута выставлен флажок: Активность EPS.

4.1.2. Синхронность и асинхронность

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

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

Синхронность/асинхронность выполнения зависит от двух настроек c именем Тип: в карточке правила и в карточке задачи.

На практике для синхронно запускаемых обработчиков оператор выбирает в настройках правила задачу STD_SYNCH_TASK и тип Синхронная обработка, а для асинхронных — STD_ASYNCH_TASK и Асинхронную обработку.

Особенности выполнения задач без постановки в очередь (STD_ASYNCH_TASK) в зависимости от типа обработки:

4.2. Отправка сообщения

Настроить событие с отправкой сообщений можно из модели процесса (вкладка Настройка событий).

Обратите внимание: при создании события из модели процесса автоматически создается и правило обработки (поле Правило EPS в карточке процесса).

Если в поле Тип выбрать Информирование по email, на форме появятся новые поля:

• Документ;
• Формат док-та;
• Сообщение.

Поле Сообщение задает тело сообщения при отсутствии документа и тему — при его наличии. Сообщение можно построить при помощи конструктора: