ERP.ВСТУП

МОДУЛІ ПІДПРИЄМСТВА

МІА: Підприємство — це продукт компанії ІНФОТЕХ, який складається з комплексу бібліотек (N2O.DEV) та підсистем-додатків (модулів підприємства ERP.UNO), що використовують загальну шину і загальну розподілену базу даних.


  N2O.DEV ERP.UNO МІА: Підприємство ROOTS
  ------- ------- ----------------- -----------
  active  acc     crm               n2o.dev
  bert    bank    cart              erp.uno
  bpe     chat    agent             infotech.gov.ua
  form    plm     scan              synrc.com
  fs      db      wms
  kvs     sample  xio
  mach    erp
  mad     fin
  n2o     fix
  nitro   ldap
  pie     pm
  rest    tms
  sh      scm
  rt      review
  base    rocksdb
  mnesia  bench

LDAP — Сервер аутентифікації, зберігання ключів та директорія підприємства.

ERP — Даний модуль зберігає основну ієрархічну структуру підприємства, її схему, записи про персонал, інвентар, компанії та офіси підприємства.

FIN — Фінансовий модуль підприємства, зберігає бізнес процеси, які представляють собою рахунки учасників системи: персонал (для нарахування зарплат), рахунки та субрахунки підприємства (для здійснення економічної діяльності) і зовнішні рахунки в платіжних системах.

ACC — Система управління персоналом: зарплатні відомості, календар підприємства, відпустки, декретні відпустки, інші календарі.

SCM — Система управління ланцюжком поставок: головний БП системи — експедиційний процес доставки товарів ланцюжку одержувачів за допомогою транспортних компаній.

CRM — Система управління клієнтами: являє собою розширення більш абстрактного додатку CHAT.

PLM — Система управління життєвим циклом проектів і продуктів. Також містить CashFlow та P&L звіти.

PM — Система управління проектами підприємства з деталізацією часу і протоколів прийому-передачі (прийняті коміти в гитхабі).

WMS — Система управління складом.

TMS — Система управління транспортом підприємства.

Модуль PLM

В цьому документі описана система управління життєвим циклом продуктів і проектів — Product Lifecycle Managenent (PLM). На базі PLM модуля ми розробили систему управління аутсорсинговим підприємством Quanterall з можливістю інвестування та обліком опціонів для програмістів.

Цілі проекту:

— Підвищення прозорості ведення бізнесу;
— Видача опціонів з прибутку;
— Автоматизація підприємства.

Задачі проекту:

— Створення панелі управління директора, працівників та інвесторів;
— Попроектна звітність (СashFlow, P&L);
— Управління опціонами програмістів;
— Інвестування в проекти іншими інвесторами (зі страхуванням).

Бізнес процеси:

— Бізнес-процес — рахунок учасника проекту (FIN);
— Головний бізнес-процес модуля — довгоживучий проект-продукт (PLM);
— Створення проекту із залученням інвестицій під заставу прибутку від інших проектів (Pre-PLM);
— Щомісячний процес розподілу прибутку (PLM-Calc): після вирахування згортки виплачених зарплат зі згортки оплачених рахунків клієнтам по CashFlow ми формуємо список статей: 1) страховий фонд (який відкушується якщо ми використовуємо цей проект в якості застави для кредиту на інший проект; 2) опціони програмістів, видаються автоматично людям, які працюють над цим проектом; інші люди також можуть брати участь; 3) наш заробіток (вільний пул або резервація); 4) R&D відрахування (обов'язкові).

Інструкція розробника PLM

Інструкція розробника PLM включає покроковий опис процесу створення підсистеми PLM з використанням бібліотек SYNRC: 1) Адміністративна частина: KVS, BPE, FORM; 2) Модулі конфігурації PLM: PLM, FIN, LDAP.

Система PLM залежить також від інших модулів підприємства: FIN — фінансовий модуль управління персональними рахунками та рахунками підприємства; ACC — модуль управління персоналом і контрагентами; ERP — модуль інкапсуляції організаційної структури підприємства; LDAP — система управління ідентифікаторами та ключами. Окрім модулів підприємства тут також розглядаються бібліотеки, залежності модуля PLM: BPE — система управління бізнес процесами підприємства; KVS — система зберігання даних; FORM — система генерації форм. PLM залежить і від інших бібліотек, які в цьому документі не розглядаються: N2O — система управління з'єднаннями та протоколами; NITRO — система генерації HTML5.

УПРАВЛІННЯ РЕСУРСАМИ

Головним чином інформаційна структура нашого підприємства складається з обчислювальних ресурсов (додатки, запущені в шині) та накопичувальних ресурсів (дані, збережені в базі даних).

SOA архітектура в якості моделі управління обчислювальними ресурсами пропонує асинхронний протокол віддаленого виклику на шинах. Разом з N2O можно використовувати MQTT та інші шини, за допомогою наступних протоколів: TCP, WebSocket. Ці асинхронні протоколи часто називають протоколами реального часу, оскільки в них функції відправки повідомлень завжди миттєво повертають результат. Що ж стосується протоколів для публікації і доступу до даних, то тут може виявитися доречним використання синхронного HTTP протоколу.

Обчислювальні ресурси

Для SOA архітектури традиційно використовуються асинхронні протоколи доступу до обчислювальних ресурсів. Зазвичай це серверні воркери, які підключені до шини і обслуговують API певного додатку. Кожен додаток має власне консистентне хеш-кільце воркерів. В мережі одночасно працює багато кілець-додатків.


config :n2o,
  tcp_services: ['ldap'],
  ws_services: ['chat'],
  mqtt_services: ['erp', 'bpe']

За допомогою config.exs файлу можна налаштувати необхідну конфігурацію серії консистентних кілець, кожне з яких працює на власному транспортному протоколі. В даному прикладі показано карту Erlang серверів, які обслуговують черги додатків в шині:


> PLM.vnodes
[
  {{:tcp, '/ldap/tcp/4'}, [:n2o_tcp]},
  {{:tcp, '/ldap/tcp/3'}, [:n2o_tcp]},
  {{:tcp, '/ldap/tcp/2'}, [:n2o_tcp]},
  {{:tcp, '/ldap/tcp/1'}, [:n2o_tcp]},
  {{:ws, '/chat/ws/4'}, [:n2o_ws]},
  {{:ws, '/chat/ws/3'}, [:n2o_ws]},
  {{:ws, '/chat/ws/2'}, [:n2o_ws]},
  {{:ws, '/chat/ws/1'}, [:n2o_ws]},
  {{:mqtt, '/erp/mqtt/4'}, [:n2o_mqtt]},
  {{:mqtt, '/erp/mqtt/3'}, [:n2o_mqtt]},
  {{:mqtt, '/erp/mqtt/2'}, [:n2o_mqtt]},
  {{:mqtt, '/erp/mqtt/1'}, [:n2o_mqtt]},
  {{:mqtt, '/bpe/mqtt/4'}, [:n2o_mqtt]},
  {{:mqtt, '/bpe/mqtt/3'}, [:n2o_mqtt]},
  {{:mqtt, '/bpe/mqtt/2'}, [:n2o_mqtt]},
  {{:mqtt, '/bpe/mqtt/1'}, [:n2o_mqtt]},
  {{:caching, 'timer'}, [:n2o]}
]

Завдяки такій деталізації можна проектувати гетерогенні системи, включаючи необхідний набір протоколів на портах потрібних машин. Ця же система дозволяє отримати балансування навантаження, підключаючи фізичні ресурси до певних черг шини даних.

В нашій моделі асинхронні протоколи використовуються для управління обчислювальними ресурсами підприємства.

Накопичувальні ресурси

Розподілені хеш-кільця використовуються не тільки для розподілених обчислень, але і для зберігання даних. Деякі бази даних, наприклад RocksDB та Cassandra, використовують глобальний простір ключів для даних (на відміну від таблично-орієнтованих баз). Саме для таких баз і створено библиотеку KVS, де в якості синхронного транзакційного інтерфейсу — API ланцюжків з гарантією консистентності. Нижче наведено приклад структури ланцюжків екземпляру системи PLM:


> :kvs.all :writer
[
  {:writer, '/bpe/proc', 2},
  {:writer, '/erp/group', 1},
  {:writer, '/erp/partners', 7},
  {:writer, '/acc/synrc/Kyiv', 3},
  {:writer, '/chat/5HT', 1},
  {:writer, '/bpe/hist/1562187187807717000', 8},
  {:writer, '/bpe/hist/1562192587632329000', 1}
]

В нашій моделі синхронні протоколи використовуються для управління накопичувальними ресурсами підприємства і транзакційного процесингу.

Типові специфікації

Протоколи визначаються типовими специфікаціями і генеруються для наступних мов: Java, Swift, JavaScript, Google Protobuf V3, ASN.1. Також ми генеруємо валідатори даних по цих типових анотаціях і вбудовуємо ці валідатори в тракт наших розподілених протоколів, тому ми ніколи не дозволимо клієнтам зіпсувати сторадж. Для веб додатків у нас развинута система валідації — як для JavaScript, так і на стороні сервера. Бізнес логіка повністью ізольована в нашій системі управління бізнес процесами, де кожен бізнес процесс є процесом віртуальної машини. Всі ланцюжки модифікуються атомарним чином, підтримують flake адресацію, і не вимагають додаткової ізоляції у своєму примітивному використанні. Тому ви можете трактувати базу як розподілений кеш і використовувати її з фронт додатків для примітивних випадків.