ERP.СТРУКТУРА

УНІФІКАЦІЯ

Якщо розглядати первинну гранулярність підприємства, яке в першому наближенні складається з модулів, то уже на прикладі 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 можна почитати в Главі СТОРІНКИ КНИГИ N2O (VOL.2 Green Book).