Механизм Правил

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

Для каждого правила, в котором участвует параметр:

• проверяется заблокировано ли правило, если заблокировано - дальше обработка по нему не идет;
• проверяется серверное оно или выполняется на EDGE, если не серверное - дальше обработка по нему не идет;
• проверяется заблокировано ли правило на этом контроллере, если заблокировано - дальше обработка по нему не идет;

Обработка правила

1. Модуль engine получает данные о Правиле.
2. Загружает из БД связанное с задачей правило по его идентификатору - если правило не найдено завершает выполнение.
3. Загружает из БД связанный с задачей контроллер по его идентификатору - если не найден завершает выполнение.
   3.1 Выполняет проверки что правило по прежнему не заблокировано, серверное и не заблокировано на контроллере (что не произошло изменений с момента отправки его в обработку).
4. Загружает из БД связанные с правилом измеряемые параметры.
5. Если параметры содержат хотя бы один заблокированный параметр - выполнение завершается.
6. Если параметры содержат хотя бы один параметр в недостоверном статусе - выполнение завершается.
7. Загружает из БД связанные с правилом вычисляемые параметры.
8. Если параметры содержат хотя бы один заблокированный параметр - выполнение завершается.
9. Если параметры содержат хотя бы один параметр в недостоверном статусе - выполнение завершается.
10. Выполняется Триггер с подставленными в него значениями параметров.
11. Если в результате выполнения Триггера получено логическое FALSE - выполнение завершается (значит правило не сработало и ничего делать не нужно).
12. Выполняется проверка расписания правила, если расписание задано и текущий момент времени не попал в расписание (правило не должно срабатывать по расписанию) - выполнение завершается.
13. Проверить, задана ли задержка на исполнение Действий.
14. Если есть задержка, проверить, есть ли в хранилище запись для данного правила .
15. Если запись есть - завершить выполнение, если нет - добавить запись, в качестве времени выполнения
16. Если правило сработало, оно без задержки и соответствует расписанию - для каждого его действия отправляются данные в шину на обработку для применения его уставок. Так же отправляется событие E2017 о срабатывании правила.

Обработка цепочки правил

модуль periodic.

1. Задание выбирает из хранилища все записи об отложенном выполнении серверных правил (ruleId, controllerId, execTime).
2. Для записей, где время execTime менее текущего (пришло время выполнять) - данные о всех Действиях отправляются в шину на исполнение и удаляется запись из хранилища.

модуль engine

3. Из шины вычитываются данные, производят проверку по всем условиям возможности применения уставки (что контроллер есть, что правило не заблокировано, что параметр на который действует уставка не уделан и не в ручном управлении, что время его последнего значения не более времени выполнения уставки (не имеет более свежее чем уставка значение), что устанавливаемое значение отличается от текущего).
4. Если применить Действие нельзя, то выходим из алгоритма, если все условия соблюдены, то отправляются данные об уставке в шину на исполнение, формируется 4006 событие и проверяется наличие следующего шага в Дейсвиях
5. Если в action_condition есть следуещие шаги (RuleAction.id = action_condition.owner_action_id), то в очередь ActionCondition отправляются данные сondition, condition_action_id с параметром задержки в очереди delay.
6. Модуль engine по подписке получает данные из шины и проверяет условие.
7. Если условие выполняется (true), либо не заданы, то в шину помещаются данные о следующем Действии и алгоритм переходит на шаг 2).

Общая схема процесса обработки правил

Процесс обработки Глобальных Правил

Обработка правил в модуле engine

По приходу измерения выполняются следующие действия:

1. Вычисляются идентификаторы измерений;
2. Проверяется участвует ли параметр в каких либо глобальных правилах. Для этого используется кэш в redis, в котором хранятся данные .
3. Для каждого правила, в котором участвует параметр:
   • проверяется заблокировано ли правило , читается из БД, если заблокировано - дальше обработка по нему не идет;
   • в шину отправляется карта – идентификатор глобального правила, time – время измерения { globalRuleId ,time};
   • обработка сообщений из шины осуществляется стандартным способом обработки jms сообщений на 6 нитях.

Основной процесс выполнения правила из очереди GlobalRuleExec

1. Читается правило по идентификатору из сообщения, если правила нет процесс далее не идет;
2. Для Правила читаются списки параметров, если Правило содержит хоть один заблокированный параметр, выполнение прекращается;
3. Читаются списки CDP и CCP из redis, если правило содержит хоть один параметр имеющий неопределенное состояние (недостоверное), выполнение прекращается;
4. На основании значений из редиса делаются вставки значений параметров в выражение условия правила и javascript’том выполняется условие (используются стандартные сервисы выполнения выражений);
5. Если результат выражения правила false, выполнение прекращается
6. Читаются все действия глобальных правил .

Для каждого действия выполняется:

1. Читается представление связанного параметра из redis, если значение параметра связанного с действием установлено позже момента срабатывания правила, менять его не нужно; такая ситуация может произойти например в случае когда срабатывание правил вызвано приходом на актуальных архивных данных из прошлого, выполнение действия дальше не идет.
2. Далее, как в выполнении условия, читаются списки параметров из БД redis, участвующие в выражении
3. вычисление действий выполняется стандартными сервисами вычислений значений
4. Если вычисленное значение отличается от текущего, тогда отправляется новое значение в шину.
5. отправляется событие 4006 в шину с текстом сообщения <идентификатор параметра>=значение, global rule <идентификатор>.