Часть 2. Общая структура

— Часть 1. Введение
— Часть 2. Общая структура
— Часть 3. Первичные цепочки
— Часть 4. Администратор данных
— Часть 5. Администратор процессов
— Часть 6. Структура приложения
— Часть 7. Публикация в GCP

В этой статье я расскажу из чего состоит модуль предприятия.

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

Конфигурация

Первый и главный компонент приложения, его файл конфигурации (для Erlang — sys.config, для Elixir — consig.exs) который нужен для множества приложений-зависимостей: n2o, kvs, erp, form. Это обязательный компонент любого эрланг приложения которое нуждается в этих зависиомостях.

Более подробно про конфигурацию Erlang и Elixir приложений можно почитать тут:

— Erlang
— Elixir

Публикация

Для построение релиза, обычного запуска или публикации в hex.pm с помощью mad, mix или rebar3 вам необходимо файл публикации (для Erlang — rebar.config, для Elixir — mix.exs). Файл публикации содержил план запуска приложений.

Более подробно про публикацию Erlang и Elixir приложений можно почитать тут:

— mad (Erlang)
— rebar3 (Erlang)
— mix (Elixir)

Типовые спецификации

Типовая спецификация — это совокупность определений типов (type), записей (record) и спецификаций функций (spec). Это информация для диалайзера, который помогает определить несоответствие кода этим спецификациям. Все системы сборки поддерживают проверку dialyzer.

В типовых спецификациях мы храним внутренние структуры фреймворков и приложений, а также бизнес-объектов предприятия. Язык описания бизнес объектов поддерживает кортежи (для сообщений) суммы (для протоколов), скалярные и векторные типы (для полей).

Типовые спецификации хранятся в папке include, которая содержит HRL файлы, которые содержат типовые спецификации. Все -spec, -record, -type определения должны быть здесь. В Elixir импортируйте их с помощью Record.extract.

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

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

— bert

Протоколы

Если приложение реализует какой-то протокол, это протокол встраивается в протокольные циклы n2o_mqtt, n2o_ws, n2o_tcp распределеннонго кольца воркеров которые обслуживают запросы клиентских приложений.

Список протоколов определяется в переменной protocols библиотеки N2O:

protocols: [ :n2o_heart, :n2o_nitro, :n2o_ftp, :bpe_n2o, CHAT.TXT ]

А список воркеров которые реализуют эти протоколы на эндпойнтах:

mqtt_services: ['erp', 'plm'], ws_services: ['chat'],

Протоколы, если они реализованы приложенинем, находятся в папке src/protos или lib/protos для Erlang и Elixir соответственно.

Более подробно про N2O протоколы и их использование можно почитать тут:

— n2o

Цепочки

Все данные типизированные типовыми спецификациями хранятся в KVS хранилище. Это Erlang-ориентированная абстракция над записями/кортежами (records, tuples, C-structures) которая позволяется прятать за единым интерфейсом несколько KV хранилищ (включая Mnesia, RocksDB, Cassandra).

Кортежи и их цепочки

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

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

Схемы

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

Первичные корневые цепочки

Чтобы не создавать руками все базовые словари и основные организационные структуры удобно вынести их в так называемые загрузочные модули. Эти записи автоматически создаются при холодном старте приложения ERP. Корневым первичным цепочкам посвящены сразу две следующие части: Часть 3. Создание первичных цепочек, где рассказывается как создавать организационную структуру предприятия в виде загрузочных модулей первичных корневых цепочек. и Часть 4. Создание админинстратора данных, где рассказывается как создать универсальный просмотрщик цепочек в виде отдельного модуля предприятия.

Более подробно про систему хранениня KVS и управление типовыми спецификациями можно почитать тут:

— kvs

Процессы

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

В общем случае бизнес процессы (БП) — это графовое представление алгоритма с именами переходов, состояний и ассоциированых функций. Все бизнес-модули предприятия реализуют какой-то главный БП, и серию вспомогательных процессов. БП призваны решить проблему изоляции распределённой транзакции в виде отдельного процесса виртуальной машины. Этот БП представляет собой обычную функцию action/2, аргументы которой являются идентификаторы цепочек. В качестве эффектов этот БП генерирует данные в других цепочках, реализуя таким образом вычислительную модель исчисления процессов.

Например БП "Счет в Банке" является циклическим рекуррентным процессом который исходит из и входит в одно и тоже состояние (моноид). В качестве аргумента у этой функции состоящей из одного условия есть только скалярная величина — бизнес объект "Транзакция". Таким образом трейс этого процесса будет цепочка транзакций. Операция перевода денег в такой модели будет означать распределённую транзакцию между всеми участниками перевода, контроллируемую отдельным процессом.

В рассматриваемой системе, модуль PLM включает три процесса: 1) Процесс "Счет в Банке" финансового модуля FIN; 2) Процесс "Продукт" модуля PLM; 3) Процесс "Пре-Продукт" модуля PLM. В Части 5. Администратор процессов показано как создать администратор процессов для модуля BPE, который предназначен для ознакомления с системой, а также для примитивного ручного тестирования.

Более подробно про систему управления бизнес-процессами BPE и ее использование можно почитать тут:

— bpe

Страницы

Редакторы

Векторы

Роутер

Более подробно про веб-фреймворк NITRO можно почитать тут:

— nitro