Процессы и комбы

Основные понятия

Процесс - ключевое понятие Honey Platform. Всё основное взаимодействие между узлами платформы происходит с использованием процессов. Ниже расскажем, как описывается процесс и каков его жизненный цикл.

Процесс представляет из себя пронумерованные наборы комбов (comb - от слова honeycomb - пчелиные соты) следующих типов:

  • фильтров (filter - возможно назовём просто comb или active comb - активный комб),

  • точек входа (endpoint)

  • точек выхода (output)

  • особых комбов контроля (привести ссылку)

  • аспекты (привести ссылку)

  • продумать ещё комбы-обработчики ошибок, будет ли это отдельный тип или один из комбов контроля

Комбы имеют свойственные их типу параметры, условия входа, а фильтры и точки выхода имеют также миксеры (или микшеры - Mixer), описывающие правила преобразования входящих данных.

В конкретном экземпляре процесса каждый комб находится в одном из свойственных его типу состояний , имеет целочисленный результат выполнения (далее Результат), а также имеет (до момента сбора мусора, разработать механизм и исправить уточнение) набор данных - DataBag.

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

В данном примере отображён процесс с одной точкой входа, одной точкой выхода и 4 комбами.

Выполнение

Жизненный цикл кратко

Для запуска процесса может быть использован механизм запросов (Request), явный запуск процесса из другого процесса или иной Backend-ноды.

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

  1. Только что созданный процесс имеет статус NotRun.

  2. Далее, после создания процесса проверяется условие входа в точку входа.

    1. Если условие не выполняется, процесс переходит в состояние Failed

    2. Если условие выполняется - в состояние InProgress

  3. Далее, смотреть этапы выполнения ниже, процесс может находиться в состояниях InProgress, Idle (сейчас Hold) и Failed

  4. Если при вызове запроса (Request) был указан номер точки выхода, то как только данная точка выхода получит результат 1, запрос будет считаться исполненным. Однако процесс ещё не перейдёт в терминальное состояние и не будет удалён.

  5. За переход в терминальные состояния - Done, Timeout или же в состояние Failed (подумать, стоит ли разделять от живого Failed, возможно, нужен другой статус LifeStatus) отвечает особый комб типа WatchDog (дать ссылку). Комб использует заданную стратегию и контролирует жизнь процесса.

  6. (Пока не внедрено) Состояние LifeStatus (если оно будет отдельно от Status) может принимать значения Work, Done, Trash, Empty. По умолчанию процессу присваивается состояние Work. За перевод в состояние Done должен отвечать кобм WatchDog.

  7. За сборку мусора (Empty) и перевод в состояние Trash ответственен Process Registry

Выполнение процесса

Рассмотрим пример отображённого процесса: условие входа комба 0 зависит от состояния точки входа 0; комбов 1 и 2 - от состояния комба 0; комба 3 - от состояний комбов 1 и 2; точки выхода 0 - от состояния комба 3.

Процесс выполнения процесса содержит следующие шаги:

  1. Запуск процесса - происходит при входе в одну из точек входа. При этом точка входа меняет свой результат на 1, а в DataBag помещаются данные из Input.

  2. Процесс переходит в статус In Progress

  3. Идёт проверка условий входа всех  (в данный момент только те, которые ещё не были выполнены) комбов типа фильтр и точка выхода.

    1. Если ни одно условие не вернуло истину, процесс переходит в статус Idle и выполнение процесса прерывается до обращения ещё к одной точки входа или до выполнения комба контроля

  4. Для каждого комба, у которых условие входа вернуло истину, происходит выполнение действия

    1. Для всех типов - в DataBag записываются данные согласно условиям микшера

    2. Для комбов типа точка выхода - устанавливается результат в 1

    3. Для комбов типа фильтр - исполняется указанное в описании действие

      1. Вернувшийся результат будет результатом комба

      2. Действие может изменять DataBag самостоятельно

  5. Переходим на пункт 3

Рано или поздно не останется невыполненных комбов, у которых результат условия входа будет истиной и процесс перейдёт в статус Idle

За завершение процесса ответственен выполняющий его Process Registry, который может либо вызвать комбы контроля, либо, полагаясь на свои знания, включая заданную стратегию выполнения процесса, завершить процесс самостоятельно, переведя его в статус Done.

За очищение данных ответственен также Process Registry. Подробнее в разделе стратегия выполнения.

Выполнение комбов (фильтров)

Выполнение комбов происходит на нодах типа Comb Executor. Как правило, стандартные комбы могут выполняться на стандартных нодах Process Registry, если в стратегии и маппинге не указано обратное.

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

При использовании микшеров данных, отличных от стандартных, ноды типа ProcessRegistry должны поддерживать указанные микшеры.

Шаги выполнения одного комба в процессе

Пошагово выполнение одного комба можно описать так:

  • Process Registry переводит статус комба в InProgress

  • Process Registry вызывает микшер данных, который по указанным в параметрах правилам формирует входящий DataBag

  • Process Registry делает запрос в Comb Executor, передавай в него входящий DataBag

  • В ответ ожидается пара - целочисленный результат и DataBag.

    • Если ответ вернулся и результат положительный, результат записывается в результирующий DataBag и запоминается до окончания жизни процесса (если в стратегии выполнения не указано иное)

    • Если вернулся отрицательный результат, результат записывается в результирующий DataBag и процесс переходит в состояние Fail

    • Если ответ получить не удалось, в результат выполнения комба записывается стандартный результат -1, результирующий DataBag будет пустым, процесс также переходит в состояние Fail

  • Если в процессе используется особый комб типа Error Handler, после приведения процесса в состояние Fail, на следующем шаге выполнения процесса, условие для входа в него будет положительным, а условия для входа в оставшиеся комбы будут отрицательными до возврата состояния процесса в InProgress или Idle.

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

Запрос от Process Registry до Comb Executor не обязан быть http-запросом, транспорт для общения выбирается исходя из настроек инфраструктуры. Если Process Registry и вызываемый им Comb Executor являются одной нодой, возможен простой вызов метода. (Подумать, как более лаконично сформулировать, возможно ссылка на Backend)

Заполнение данных в комбах типа Endpoint и Output

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

За запись данных отвечает Process Registry. Он принимает на вход DataBag и записывает его в чистом виде в DataBag точки входа.

За запись данных в DataBag комба типа Output также отвечает Process Registry.

На очередном шаге цикла проверки состояния комба, если условие входа одного из комбов типа Output возвращает истину, Process Registry вызывает микшер и записывает результат его выполнения в результирующий DataBag этого комба, а целочисленный результат комба устанавливается равным 1.

Описание в файлах

Описание процесса

Процесс описывается в файле с расширением .process, в формате yaml.

Также можно (будет) использовать графический интерфейс для конструирования процесса. В панели отладки доступен просмотр состояния выполнения конкретного процесса (если данные ещё не были очищены сборщиком мусора).

Рассмотрим структуру файла на примере описания процесса


name: GetAccountOwner
module: CorporativePortal
endpoints: 
 - number: 1
   start_condition: "1=1"

outputs: 
 - number: 1
   condition: "p1=1 || p0* || p1*"
   mixer:
    name: DefaultMixer
    rules:
     - "p1.Output => AccountOwner"
     
combs:

 - number: 0
   condition: "e1=1"
   filter: "StandardDataSource"
   parameters:
    condition:
       type: id
       source: parameters
       id: "00000000-0002-0001-0001-888800000000"
    classlist: ["user", "person"]
   mixer:
    name: DefaultMixer
    rules:
     - "e1.Input => Input"

 - number: 1
   condition: "p0=1"
   filter: "StandardModelBuilder"
   parameters:
    model: accountowner
   mixer:
    name: DefaultMixer
    rules:
     - "p0.Output => Input"

  • name - обязательное поле, имя процесса

  • module - опциональное поле, указывается, если процесс относится к модулю

  • endpoints - список точек входа

    • number - целочисленный номер, должен быть уникальным по точкам входа в данном процессе

    • start_condition - условие входа, синтаксис будет описан ниже

  • outputs - список точек выхода

    • number- целочисленный номер, должен быть уникальным по точкам входа в данном процессе

    • condition - условие входа

    • mixer - описание микшера данных

      • name - имя вызываемого микшера, стандартный имеет имя DefaultMixer

      • rules - список правил для маппинга слоев данных, подробнее ниже

      • parameters - опциональное поле, содержит произвольный список параметров в формате ключ - значение. Требуется для пользовательских микшеров

  • combs - список фильтров (или активных комбов)

    • number- целочисленный номер, должен быть уникальным по всем активным комбам в данном процессе

    • condition - условие входа

    • filter - имя исполняемого фильтра

    • parameters - поля для задания параметров, требуемых для фильтра. Может иметь сложную структуру вложенности. Для стандартных фильтров параметры будут описаны в соответствующих разделах

    • mixer - описание микшера данных, аналогично как в outputs

Синтаксис условия входа

Строка с условием входа описывается в виде логического выражения, содержащего операнды и операции ИЛИ (| или ||) и И (& или &&), а также с возможностью группировки скобками.

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

Приоритет выполнения стандартный - И, потом ИЛИ.

Операндами логических выражений являются либо простые выражения, либо логическое выражение заключённое в скобки.

Простые выражения состоят из одного или двух операндов и оператора.

Операндами могут быть:

  • Целые числа - обозначаются числом

  • Фильтры - обозначаются буквой p и номером комба, например p1

  • Endpoint - обозначаются буквой e и номером комба, например e0

  • Особыми комбами (пока не реализовано) , буквы будут описаны позднее

Операторами могут быть:

  • Равенство - символ =, например p1=1 или 1=1 (всегда истина)

  • Неравенство - символы != или ~ , например p1~3 e4!=54

  • Ошибка выполнения - символ * - требуется один операнд - комб, например p1* , p2*

Примеры:

1=1 будет возвращать истину всегда. Может использоваться в эндпоинтах, когда нет особых условий входа

p1=1 || p0* || p1* - вернёт истину, если:

  • либо комб с номером 1 получит результат 1

  • либо хотя бы один из комбов с номером 0 или 1 получит результат меньше 0

  • либо при выполнении этих комбов будет сгенерировано исключение

e0=1 && (p1* || p2 ~ 3) - вернёт истину. если

  • был вход в точку входа 0

  • выполняется одно из условий:

    • результат выполнения комба 1 < 0 или было исключение при выполнении

    • результат выполнения комба 2 не равно 3

Синтаксис правил (Rules) для микшеров

Правила для микшеров задаются в виде набора строк следующего формата:

  • первый операнд - состоит из источника, имени слоя и идентификатора значения

  • оператор =>

  • второй операнд - состоит из имени слоя и идентификатора значения

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

  • p - фильтр

  • e - точка выхода

  • добавить букву или буквы для особых комбов

Именем слоя служат слой, из которого берутся данные для первого операнда и слой, куда данные кладутся для второго

Идентификатор значения - аналогично слою. Стоит отметить. что не все типы данных в Databag поддерживают идентификаторы (Проверить это)

Для копирования всех значений можно указать символ * или обрезать правую часть операнда.

Однако количество частей в операндах должно соответствовать, в первом на 1 больше чем во втором.

Примеры:

"e1.Input => Input"- слой Input из точки входа e1 будет скопирован в слой Input текущего комба

"e1.Input.* => Input.*- аналогично предыдущему

"p2.Output.123 => Data.456" - объект с идентификатором 123 из слоя Output комба p2 будет скопирован в слой Data в объект с идентификатором 456.

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

Фильтры

Пользовательские фильтры

Подробнее о создании пользовательских фильтров описано в разделе Backend.

Описание фильтров происходит в файлах с расширением .filters, в формате yaml

(проверить схему, т.к. реально ещё не проверялось)

module: Module name
filters:
 - name: Filter1
   parameters: 
    - foo
    - "bar[]"
    - "bar[].name"
   executor_nodes:
    - NodeName1
    - NodeName2

В файле указывается модуль, к которому относятся фильтры. В данный момент это поле полностью игнорируется, но в недалёком будущем, backend будет разбит на модули как и frontend.

Далее идёт список фильтров с полями:

  • name - имя фильтра, обязательно боле

  • parameters - список используемых параметров, необходим для тестирования и валидации:

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

    • если параметр является списком или массивом, необходимо после имени указать []

    • структуру элемента массива можно описать, указав символ [] у имени массива

  • executor_nodes - ноды по умолчанию, на которых данный фильтр может выполняться:

    • поле опциональное

    • значения могут переопределяться для каждого контура, см раздел Дать ссылку на раздел.

    • если для фильтра не задана (и не переопределена в контуре) ни одна нода для выполнения, то ProcessRegistry пробует выполнить фильтр на своей ноде, и в случае, если выполнение не возможно, процесс завершается с ошибкой

Фильтр StandardDataSource

Фильтр переименовать во что-то более подходящее

Данный фильтр используется для получения данных из DataSource. Если в файлах .filters и в настройках контура не указано обратное, данный фильтр может выполняться на любом Process Registry, который выполняет текущий процесс.

В текущий момент реализация старая, необходимо обновить под описание

Основными параметрами фильтра являются:

  • request - запрос на получение данных

  • variables - переменные, используемые в запросе

Пример запроса (синтаксис нужно будет утвердить)

WHERE Class1.Property1 = @variable1 OR Class1.Property2 > Class2.Property1
SELECT Class1, Class2, Link_Class1_Class3
EXPAND Class1.Link_Class1_Class3.Class3
INTO 'Output';

Данный запрос отработает следующим образом:

  • Найдёт все объекты, которым назначены Class1, Class2 (SELECT)

  • Отфильтрует их согласно условию WHERE

  • Для класса Class1 найдёт все линки Link_Class1_Class3

  • По всем объектам из предыдущей выборки, у которых есть класс Class1 и линк Link_Class1_Class3 найдёт все объекты Class3

  • Сформирует HoneyObject, у которого будет ClassValue для Class1, Class2, в Class1 будут все Link_Class1_Class3, внутри которого будут объекты Class3

  • Поместит результат в слой данных Output

Подробнее о синтаксисе запроса будет в разделе Придумать название и дать ссылку

Фильтр StandardModelBuilder

Данный фильтр используется для построения моделей (Model) из объектов (Honey object)

В данный момент реализация старая, в которой может быть сформирована одна модель.

Основным параметром является rules - массив правил преобразования 

      parameters:
        rules:
          - from: Input
            to: Employees
            model: employee
          - from: User
            to: Users
            model: userWithRoles
            override:
              - path: userWithRoles.Roles
                model: otherRoleModel

Особые комбы

Особые комбы - комбы, условие запуска которых отличается от фильтров и может не зависеть от описания процесса.

Обработчик ошибок

Вставить информацию об обработчике ошибок

Сторожевой таймер (Watchdog)

Вставить информацию про сторожевой таймер

Аспекты

Согласно парадигме Аспектно-Ориентированного Программирования аспектом можно назвать метод, выполняющий некую сквозную функциональность.

В Honey Platform аспекты могут подключаться в разделе aspects

aspects:
   - name: Logging
   - name: Auth
     parameters: 
       - type: basic

Каждый аспект описывается обязательным полем name и опциональным списком параметров

Аспект должен быть определён в файле с расширением .aspect, либо на уровне кода для каждой ноды Process Registry, исполняющей используемые данный аспект процессы.

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

Подробнее про аспекты будет сказано в разделе которого ещё нет.

Ниже будут кратко описаны некоторые стандартные аспекты.

Логирование (Logging)

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

Обязательных параметров нет, можно указать параметры:

  • MinimalLevel - минимальный уровень для логирования

  • подумать и дописать ещё параметров

Аутентификация и авторизация (Auth)

Обеспечивает аутентификацию и авторизацию при выполнении запросов.

Может использоваться со стандартным фильтром Auth, который ещё не реализован.

Подробнее про аспект можно будет почитать в статье, которой ещё нет.

Транзакции

Honey Platform, при правильной организации данных, обеспечивает транзакционность при выполнении процессов.

Подробнее в статье которой ещё нет.

PreviousДанные и источники данныхNextDeployment

Last updated