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

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

Если рассматривать первичную гранулярность предприятия, которое в первом приближении состоит из модулей, то уже на примере 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.

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

Типовые спецификации хранятся в HRL файлах, в папке include. Все -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