Част 2. Обща структура
В тази статия ще разкажа от какво се състои модулът на предприятието.
Ако вземем предвид основната детайлност на предприятието, която в първоначалното си структуриране се състои от модули,тогава вече чрез примера на PLM можем да намерим пълната структура на типичен модул, всеки елемент от който е представен в PLM инстанция.
Конфигурация
Първият и основен компонент на приложението е конфигурационният файл (за Erlang - sys.config, за Elixir - consig.exs), който е необходим при определянето на зависимостите за всяко приложения: n2o, kvs, erp, form. Това е задължителен компонент на всяко приложение на Erlang, което се нуждае от тези зависимости.
Можете да прочетете повече за конфигурацията на приложенията Erlang и Elixir тук:
Публикация/Издание (Релииз)
За да изградите, стартирате или публикувате издание в hex.pm, може да използва един то инстументите за изграждане на проложения mad, mix или rebar3. В зависимост от избраният инструмент се гнерира файл (за Erlang и mad тоеа е rebar.config, за Elixir - mix.exs) съдържащ инструкции за това как приложението да бъде стартиране или пакетирано като релииз.
Можете да прочетете повече за публикуването на приложения за Erlang и Elixir тук:
— mad (Erlang)
— rebar3 (Erlang)
— mix (Elixir)
Типични спецификации
Типична спецификация е съвкупност от дефиниции на типове (type), запис (record) и спецификация на функциите (spec). Dialyser е инструмент за валидиране на тези специфинации, като неговата задача е да идентифицира несъответствие на кода и тези спецификации. Всички системи за изграждане, поддържат свой инструмент за валидиране на тези специфинации.
В типичните спецификации съхраняваме вътрешните рамкови структури и приложения, както и бизнес обектите на предприятието. За описанието на бизнес обекти Езикът поддържа кортежи, суми, скалари и векторни типове.
Типичните спецификации се съхраняват в HRL файлове, в папката include. За да бъде възможно най-валидна, тя трябва да има дефинирани всички -spec, -record, -type определения. Импортирайте ги с Record.extract в Elixir.
Ако програмата не съдържа папки include (например като PLM модул-a), тогава това означава, че модулът не дефинира никакви допълнителни типове, но това не означава, че не използва външно дефинирани такива.
Можете да прочетете повече за стандартните спецификации и поддържаните езици за програми тук:
— 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. Това е ориентирана към Ерланг абстракция върху записи/кортежи (records, tuples, C-structures), което ви позволява да скриете множество KV хранилища зад един интерфейс (включително Mnesia, RocksDB, Cassandra).
Кортежи(тюпъл) и техните вериги
В основата на KVS са концепциите за тюпъл (кортежи) и верига. Видовете тюпли са дефинирани в стандартните спецификации, а веригите са последователности от тюпли, като цяло от всякакъв тип, като по този начин може да мислите за тях като хетерогенни и хомогенни вериги.
Всяка верига е индексирана от своя идентификатор, който представлява сегментиран йерархичната път във виртуална файлова система. Това е за да позволи на префиксираните търсения да избират всички деца от определен подраздел в йерархията на идентификатора на веригата. Като част от вериката са и всички идентификатори на всички вериги.
Схеми
Всеки корпоративен модул може да включва една или повече схеми. Схема е съвкупност от стандартни спецификации, с други думи набор от кортежи и техните типове, като форма на разпространение на стандартна спецификация.
Първични коренни вериги
За да не създавате на ръка всички основни речници и основни организационни структури, е удобно да ги въведете в така наречените стартиращи модули. Тези записи се създават автоматично, когато ERP приложението се стартира студено. Към основните първични вериги има две части: Част 3. Създаване на първични вериги, която описва как да се създаде организационната структура на предприятието под формата на зареждащи модули на първични коренни вериги. и част 4. Създаване на администратор на данни, който да ви каже как да създадете универсален верижен браузър като отделен корпоративен модул.
Можете да прочетете повече за KVS и управление на спецификациите на модела тук:
— kvs
Процеси
Ако цялата информация на корпоративната информационна система се съхранява във вериги, тогава развитието на тези данни става чрез бизнес процеси. Бизнес процесите са предназначени да решат определени проблеми, свързани с мащабирането на бизнес логиката в производството, така че тази част от предприятието е добре стандартизирана от 2008 г. насам, с появата на повече или по-малко универсален стандарт BPMN, който частично се поддържа от системата за управление на процесите BPE.
По принцип бизнес процесите (BP) са графични представяния на алгоритъм с имена на преходи, състояния и свързани функции. Всички бизнес модули на предприятието внедряват някои основни BP и серия от спомагателни процеси. Призивът на BP е да реши проблема с изолирането на разпределената транзакция като отделен процес на виртуална машина. Този BP е нормална функция action/2 чиито аргументи са идентификаторите на веригата. Като ефект, този BP генерира данни в други вериги, по този начин се прилага изчислителен модел на изчисление на процесите.
Например BP -> „Сметка в банката“ е цикличен/рекурсивен процес, който излиза и влиза в същото състояние (моноид). Като аргумент тази функция, която се състои от едно условие, само скаларна стойност - бизнес обект „Транзакция“. Следователно, следата на този процес е веригата на транзакциите (exp: [t1,t2,t3,t4,..], t ∊ T :: „Транзакция“). Операция за превод на пари в такъв модел биозначавала разпределена транзакция между всички участници втранзакцията, контролирана от определен процес.
В разглежданата система PLM включва три процеса: 1) Процес „Сметка в банката“ на финансовия модул FIN; 2) Процес "Продукт" на PLM модула; 3) Процес "Пре-Продукт" на модул PLM. В Част 5. Администраторът на процеси ви показва как да създадете администратор на процес за BPE модул и същевременно да се запознаване със системата,както се дава и възможност и за примитивно ръчно тестване.
Можете да прочетете повече за BPE системата за управление на бизнес процесите и нейното използване тук:
— bpe
Страници
Редактори
Вектори
Маршрутизатори
Можете да прочетете повече за уеб рамката на NITRO тук:
— nitro