Частина 2. Загальна структура
У цій статті я розповім, з чого складається модуль підприємства.
Якщо розглядати первинну гранулярність підприємства, яке в першому наближенні складається з модулів, то уже на прикладі PLM ми можемо виявити повну структуру типового модуля, кожен елемент якої представлений в екземплярі PLM.
Конфігурація
Перший і головний компонент додатка — файл конфігурації (для Erlang — sys.config, для Elixir — consig.exs), який потрібен для багатьох додатків-залежностей: n2o, kvs, erp, form. Це обов'язковий компонент будь-якого ерланг додатка, який потребує ці залежності.
Більш детально про конфігурацію 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