Skip to main content

Общая информация

Основными структурными единицами в BPMS принято считать ноды. Почти все сущности с которыми вы сталкиваетесь внутри проекта являются нодами.

info

Во избежание путаницы стоит заранее обратить внимание на особенность в терминологии: нодами называются почти все элементы системы, при этом есть отдельно выделенный тип элемента системы "Нода"

Таким образом можно утвержать, что любой элемент проекта теперь имеет одинаковую (или очень схожую) структуру:

{
  "nodeType": int,
  "name": "string",
  "title": "string",
  "description": "string",
  "properties": {
    "Prop1": "string",
    "Prop2": booolean,
    "Prop3": int
  },
  "nodeFieldname": "string",
  "childrenNodes": [
    {
      "nodeFieldname": "string",
      "nodeId": int,
      "nodeOrder": int,
      "additionalProperties": {
        "additionalProp1": "string",
        "additionalProp2": booolean,
        "additionalProp3": int
      }
    }
  ]
}

Более конкретную информацию по каждому из полей лучше узнавать непосредственно из описания определенного метода, а ниже будет представлена самая важная информация:

  1. nodeType - Основное свойство каждой ноды, определяющее уровень абстракции. Может быть числом от 1 до 10
    • 1 - Нода (в первоначальном своем определении)
    • 2 - Экран.
    • 3 - Поле.
    • 4 - Виджет.
    • 5 - Группа нод.
    • 6 - Пресет.
    • 7 - Процесс.
    • 8 - Функция.
    • 9 - Коллекция.
    • 10 - Врапер.
  2. name - Уникальное имя ноды. В рамках одного nodeType имена всегда уникальны, при попытке создания элемента с одинаковым именем произойдет перезапись предыдущего элемента
  3. title - Не уникальное имя элемента, использующееся для отображения в интерфейсах
  4. properties - Определение свойств элемента. Указанные здесь настройки будут использоваться как дефолтные при использовании данного элемента без их переопределения
  5. nodeFieldname - Имя, используемое, как ключ, при передаче связанной с данным элементом информацией на backend. Более подробная информация об этом очень важном поле содержится в разделе "Nodes feilds"
  6. childrenNodes - Дочерние элементы (вложенные ноды с более низким уровнем уровнем абстракции). Для использования дочернего элемента обязательно указание его id
    • nodeOrder - Порядковый номер для дочерних элементов в рамках родительского
    • additionalProperties - Переопределение свойств дочерних элементов и/или добавление новых из существующих

Элементы системы типа "Нода"​

Такие элементы являются основными строительными ячейками процесса в BPMS. В свойстве childrenNodes в качестве дочерних нод могут содержаться только пресеты и экраны. Сами же ноды могут быть дочерними элементами для групп нод и процессов.

В каком-то роде ноду можно считать "подпроцессом", который представляет из себя набор пресетов с экранами на одну тематику. Например, нода "Авторизация" содержит в себе все экраны на все случаи развития событий у пользователя в рамках авторизационных мероприятий. "Подпроцесс" ноды начинается, когда логика приложения приводит к показу его экрана и заканчивается, когда происходит переход на какой-либо экран другой ноды.

info

Для большей безопасности во избежание внештатных ситуаций не существует методов API позволяющих удалять созданные ноды из системы

Экраны​

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

Поля​

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

С помощью полей также можно передавать информацию от приложений на сервер, подробнее об этом можно узнать разделе "Nodes feilds"

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

Виджеты​

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

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

Логика работы виджетов такая, что редактирование его отображения будет приводить к его изменению во всех местах, где он был использован. Яркими представителями виджетов могут быть: рекламные баннеры, информационные блоки, повторяющиеся элементы приложения, например, top bar. Визуальный пример:

Виджет

Группы нод​

(На доработке!)​

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

Пресеты​

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

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

Процессы​

С точки зрения BPMS Любое приложение - это процесс. Не смотря на то что визуально процессы собираются из нод на архитектурном уровне они также являются нодами типа "Процессы".

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

Ноды-функции​

(На доработке!)​

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

Исходный код ноды-функции на Python хранится в БД. Это позволяет ей быть открытой для создания и редактирования аналитиками.

Если нода-функция находится на процессе, её исполнение начинается в том же случае, когда обычная нода была бы передана на клиент. Конец выполнения функции логически соответствует запросу следующего экрана через action = next.

Входные и выходные параметры ноды задаются соответственно через задание свойств:

  • functionInputParameters - объект содержащий словарь входных данных
  • functionOutputParameters - объект содержащий словарь выходных данных

Если необходимо передавать данные последовательно через несколько нод-функций, промежуточные вычисления также нужно сохранять в {{field.id}}.

Врапперы​

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

Враппер

Использование врапперов помогает настроить компоновку элементов на экране. Для этого используются специальные свойства врапперов:

  • direction - строка отвечающая за направление контента
    • column
    • row
  • contentAlign - строка отвечающая за расположение контента внутри столбца или строки
    • start
    • center
    • end
    • space-between
    • space-around

Помимо компоновки элементов во враппере, элементы могут позиционироваться еще и внутри контейнера враппера с помощью свойства:

  • align - строка
    • start
    • center
    • end

Расположение элементов в строке​

Расположение элементов в строке

Расположение элементов в столбце​

Расположение элементов в столбце

Расположение элементов внутри контейнера враппера​

Расположение элемента внутри контейнера врапера

Общие свойства для полей, виджетов и врапперов​

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

  1. order - число (int) порядковый номер элемента на текущем уровне
  2. align - строка (string) определяющая выравнивание элемента относительно экрана (или другого контейнера).
    • Выравнивание элемента
  3. paddingTop
  4. paddingBottom
  5. paddingLeft
  6. paddingRight
  7. paddingMeasure - Единица измерения padding’a элемента. Padding задаёт расстояние от внутреннего края границы или края блока до воображаемого прямоугольника, ограничивающего содержимое блока. Основное предназначение padding — создать пустое пространство вокруг содержимого элемента, например текста, чтобы он не прилегал плотно к краю элемента.
  8. marginTop
  9. marginBottom
  10. marginLeft
  11. marginRight
  12. marginMeasure - Единица измерения margin’a элемента. Margin устанавливает пустое пространство от внешнего края border, padding или содержимого блока. Под margin нет своего фона и он принимает фон родительского элемента.
    • Позиционирование элемента

Таблица доступных childrenNodes для элементов​

Таблица доступных childrenNodes для элементов

Особенности создания и редактирования нод​

При создании новой ноды нужно учитывать:

  • Поле "nodeType" задаются вместе с нодой раз и навсегда, и в дальнейшем не меняется.
  • Поле "title" - это не уникальное имя элемента, использующееся для отображения в интерфейсах. Поле, что у родительской, что у дочерних нод можно изменить только с помощью метода PATCH /bpm/editor/nodes/:node_id/nodesParam.
  • Поле "description" - это описательное поле, его можно передавать в теле запроса на создание и редактирование ноды, но в ответе оно возвращаться не будет (значение этого поля содержится в nodes_param). Поле можно изменить.
  • Поле "properties" - содержит объект со свойствами элемента. Свойства могут быть переопределены.
  • Поле "nodeFieldname" - уникальное имя, используемое, как ключ, при передаче связанной с данным элементом информацией. Это поле необходимо в основном только для тех нод, которые могут принимать внешние данные с экранов клиентских приложений для сохранения и обработки на сервере. В большинстве случаев, это ноды типа "Поле". Более подробная информация содержится в разделе "Nodes feilds".
    • Поле можно изменить, но нежалательно. В случае изменения этого поля, старое значение никуда не исчезает, оно остается в базе, так как нода может иметь старые привязки по старому имени.
    • Существует функционал позволяющий заполнять это поле автоматически, генерируя строку из остальных параметров путем конкатенации, но в данное время функционал отключен и не используется.
info

Коротко об особенностях поля "nodeFieldname"! В текущем флоу метод POST /bpm/editor/nodes имеет возможность с помощью этого поля создавать новую сущность "nodes_fieldname" без сопутствующих настроек вместе с нодой любого типа (нода типа "process" сама по себе не создается с полем "nodeFieldname", тем не менее новая сущность "nodes_fieldname" все равно создается в базе). Эта возможность не является правильным алгоритмом действий, это временная мера обусловленная технической необходимостью.

  • Можно добавлять в качестве дочерних "childrenNodes" только уже существующие ноды.
  • Тип дочерней ноды должен быть допустимым. Для каждого типа нод - разные дочерние типы, подробнее об этом можно узнать в отдельных статьях по каждому типу или в таблице.
  • Дочерние элементы должны быть одинакового типа. Пример: для ноды с типом "нода", дочерними элементами могут быть только пресеты или экраны. Теоретически, нет механизмов, которые запретят добавлять ноды разных возможных типов в качестве дочерних. То есть технически можно добавить к родительской ноде пресеты и экраны одновременно, но такая работа инструмента будет неправильной и может привезти к непредсказуемым последствиям (большая вероятность ошибки 500).
  • Максимальная вложенность в родительскую ноду -1 уровень. Вложенность может быть больше, если при этом не планируется редактировать свойства вложенных нод, плюс имя поля "childrenNodes" дочерних нод должно соответствовать типу вложенных нод (например, "screens"). Механизм многоуровневой вложенности нод не является основным функционалом, поэтому если нужно составить "матрешку" и вложить ноды в дочерние ноды, лучше использовать эндпоинты создания и редактирования нод повторно.
  • Дочерние ноды можно частично редактировать во время добавления в новую ноду.
    • Можно изменять свойства, внося изменения в объект поля "additionalProperties".
    • Можно изменить порядок отображения вложенной ноды с помощью поля "order".
    • Можно изменить уникальное имя вложенной ноды в поле "fieldname", но делать этого не желательно (поле аналогично полю родительской ноды "nodeFieldname")
  • Все дочерние ноды будут сохранены в базе с новыми "id" (то есть все они копируются).
  • Для дочерних нод существует флаг "isMove", который может оставить для дочерней ноды ее старый "id", а не присваивать новый, но использование этого флага также нежелательно (флаг для проведения технических работ).
  • Eсли редактируемая нода уже имела вложенные дочерние ноды, то они не будут повторно копироваться с новыми "id", а оставят свой существующий "id", даже если в них внесут изменения
  • Не могут иметь дочерних нод ноды следующих типов:
    • Группы нод
    • Ноды функции
    • Поля
    • Процессы

При создании ноды типа "field" ("nodeType": 3):

  • Значение, что введено в поле "name", отображается как тип этого поля под ключом "nodeType". Например: {"name": "input.dropDownList"} -> {"nodeType": "input.dropDownList"}. Это не баг, это техническая необходимость.
  • Поле "title" отсутствует.
  • Значение, что введено в поле "nodeFieldname", отображается как имя этого поля под ключом "name". Например: {"nodeFieldname": "qa.field.test.correct21"} -> {"name": "qa.field.test.correct21"}. Это не баг, это техническая необходимость.
  • Одновременно с нодой типа "field" ("nodeType": 3), создается сущность "nodes_fieldname" без дополнительных параметров.
info

Вероятно, что в будущем флоу поле "nodeFieldname" будет принимать только ID сущности "nodes_fieldname", которая должна быть предварительно создана с помощью метода POST /bpm/editor/nodes/fieldName, где помимо имени "переменной", есть ряд других параметров (подробности в разделе "Nodes feilds"). Также планируется, что приложение должно уметь различать поля разных типов (Text, TextInput, TextView, DropDown и т.д.) и по разному их обрабатывать.

Особенности удаления нод​

Стоит отметить что полное удаление ноды из системы невозможно. Нода просто получает отметку в базе "deleted_at". Ту же самую отметку получают и все остальные вложенные в неё ноды.

Например: если нода с типом "Процесс" ("nodeType": 7) удаляется, то все ноды остальных типов вложенные в этот процесс также полуают отметку в базе "deleted_at". Более того удаляются все настроенные для этих нод действия ("action_processes"), если таковые имеются.

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

Например: ноду с типом "Поле" ("nodeType": 3) можно добавить во множество разных экранов, пресетов, нод и процессов. При этом удаление любой из этих копий не будет влиять на остальные.