entaxy-public/README.ru.md

149 lines
12 KiB
Markdown
Raw Normal View History

2021-09-06 14:46:59 +00:00
# entaxy-esb
### Languages
[English](README.md)
Подробная документация: [описание системы](documentation/entaxy_main.adoc).\
Инструкция по установке: [установка](documentation/installation/installation-table-of-contents.ru.adoc).\
Инструкция по запуску тестов для универсального коннектора: [тестирование](documentation/connectors/uniform-exchange-service/tests/postman.adoc).
- **extras** - дополнительные модули шины, которые не входят в базовую поставку шины.(Разрабатывается независимо, устанавливается отдельно.)
- **1с** - модуль рaботы с 1с
- **1c-exchange-service** - (Алексей Князев, Бородина Валерия) модуль обработки сообщений, сервис 1с
- **1c-exchange-endpoint** - выставленный soap-сервис 1с
- **1c-exchange-service-endpoint** - выставленный служебный soap-сервис 1с
- **connector** - хранятся входящий и исходящий коннектор к 1c-exchange-endpoint и 1c-exchange-service-endpoint
- **support** - маршруты, которые нужны для корректной работы коннектора
- **1с-storage** - (Алексей Князев) модуль liquibase создания необходимых таблиц в бд для 1с
- **nsi** - (Алексей Князев, Бородина Валерия) модуль обработки сообщений nsi
- **nsi-soap** - (Алексей Князев) модуль с выставленным soap nsi
- **nsi-storage** - (Алексей Князев) модуль liquibase создания необходимых таблиц в бд для nsi
- **big-packet** - (Алексей Князев) сервис больших пакетов
- **bridge** - (Моисеев Михаил) мост между шинами с использованием брокеров
- **db-connector-parent** - (Алексей Князев) коннектор к промежуточной базе
- **db-connector** - (Алексей Князев) коннектор к промежуточной базе, преобразует xml в java объекты и потом через jpa сохраняет в бд, и также обратно
- **db-hyperjaxb3-naming-extension** - (Алексей Князев) - плагин для плагина hyperjaxb3 который делает более человекочитаемые имена для генерируемых из xsd столбцов и таблиц
- **file-archive-connector** - (Бородина Валерия) модуль для работы с системами, которые работают через файловую систему(собирает сообщения в течение часа и собирает их в архив)
- **file-service** - (Алексей Князев) сервис отправки файлов через шину
- **features** - там вообще должна быть одна фича, которая подтягивает фичи по отдельным компонентам. Установив ее мы и устанавливаем продукт в караф
- **platform** - Содержимое типовой поставки
- **runtime** - Компоненты необходимые для запуска и работы платформы
- **base** - То, что стартует до остальных бандлов с низким startlevel или вообще входит в кастомную сборку Карафа
- **branding** - создание логотипа entaxy
- **connecting** - инфраструктура адаптеров и коннекций
- **core** - ядро entaxy
- **initializer** - Инфраструктра инициализации при первом запуске, в том числе проверка, создание и запуск необходимых системных коннекций
- **storage-initializer** - (Моисеев Михаил) все, что относится к хранению данных с общей точки зрения
- **management** - управление артефактами
- **modules** - дополнительные модули entaxy
- **uniform-service** - Универсальный сервис
- **uniform-service-exchange-endpoint** - выставленный универсальный soap-сервис
- **uniform-service-exchange-service-endpoint** - выставленный универсальный служебный soap-сервис
- **connector** - хранятся входящий и исходящий коннектор
- **support** - маршруты, которые нужны для корректной работы коннектора
- **system** - (Андрей Филиппов) собственно, продукт(модуль впоследствии будет удален)
- **auth** - (Сергей Крючков, Моисеев Михаил) все, что относится к авторизации, включая бандлы для конкретных схем авторизации, общий интерсептор для CXF и т.д.
- **common** - общие библиотеки
- **core** - ядро системы, что там будет, пока сложно конкретизировать, но что-то наверняка будет
- **dispatcher** -
- **events** - (Моисеев Михаил) работа с топиками, наша реализация доставки сообщений
- **permission** - (Моисеев Михаил) права доступа
- **template** - (Бородина Валерия) работа с шаблонами для создания профилей, коннекторов и т д
- **error-handler** - (Сергей Крючков) маршруты для обработки ошибок и вспомогательные классы.
- **deployer** - (Бородина Валерия) все, что относится к процессу обработки данных из gui, их преобразования в blueprint и деплоя этого blueprint в шину
- **cellar-deployer** - (Бородина Валерия) деплой blueprint в кластер карафа с помощью cellar
- **deployer-api** - (Моисеев Михаил, Бородина Валерия) интерфейс deployer
- **nexus-deployer** - (Бородина Валерия) деплой сгенерированных blueprint в nexus
- **file-system-deployer** - (Моисеев Михаил) деплой сгенерированных blueprint в файловую систему
- **registry** - (Моисеев Михаил) реестры, определенные в продукте, должна содержать systems, system-groups, services для реализаций конкретных реестров
- **systems** - описание внешней системы в нашей.
- **system-groups** - группы систем, обобщённые по какому-либо признаку
- **profile-commons** - может быть связан коннектором с точкой коммуникации.
- **processes** -
- **service** - это точка коммуникации. (что-то, развернутое под CXF)
- **connectors** - нечто, что связывает профиль с точкой коммуникации
- **system-management** - (Бородина Валерия) управление системами, профилями и коннекторами систем
- **transformer** - видимо, друг deploer'а, реализация трансформаций данных gui -> blueprint
- **test** - тесты для postman
В репозитории использовать английский!
- в комментариях к коммитам
- в коде
## **Правила работы с репозиторием**
Коммиты в мастер глубоко нежелательны, но если нельзя поступить по-другому, предупредите коллег в общем чате с описанием причины.
**Кратко:**
Feature branching - любая разработка ведётся в отдельных ветках(бранчуемся от master/release) после чего делаем pull request.
**Полно:**
**Ветки:**
- *master* - develop ветка от неё бранчуемся, в неё сливаемся
- *release-<version>* - стабильная релизная ветка от неё бранчуемся в случае hotfix-ов.
Условия хранения релизной ветки:
1. заказчик платит за поддержку
2. не истек срок нашей поддержки этого релиза
3. заказчик не произвел переход на новый релиз
- *feature-branch* - ветки разработок, хранится до проверки и слияния с целевой веткой
Именование веток:
* номером задачи из youtrack
* особо осмысленным кратким названием функционала
- *hotfix-branch* - ветки для hotfix-ов, хранится аналогично *feature-branch*
Именование веток - префикс "hotfix-" далее:
* номер задачи из youtrack
* особо осмысленное краткое название исправления
**Pull request**
- **Для фиксов и мелких доработок** назначаем в рецензенты: ведущего разработчика - *Алексея Князева* и *ответственных за функционал/заинтересованных лиц*
ответственных и заинтересованных можно посмотреть в описании проекта выше.
- **Для крупных доработок** к описанным выше лицам добавляем *Андрея Филиппова* и *Сергея Старовойтенкова*
Если не планируется больше доработок в ветке направленной на мерж, при создании pull request-а помечаем **Close branch**
**Camel заголовки**
Заголовки используемые для служебных целей именуются в соответствии с HTTP манифестом, т.е. с большой буквы через тире.
Начинаться должны с "Entaxy-"
**Формат именования конфигурационных файлов**
**Коннекторы:**\
_<project_name>.<system_name>.<connector_type>.<connector_direction>_\
примеры \
_project.1c.odata.in_\
_project.rest1.in_
**Проектные конфиги(специфическая функциональность):**\
_<project_name>.<module_name>_\
примеры\
_project.audit_\
_project2.informer_
**Extras модули:**\
_<manufacturer_prefix>.<module_name>_\
примеры\
_ru.entaxy.eav_\
_org.apache.mdm_
**Платформа:**\
_<manufacturer_prefix>.<platform_part>.<module_name>_\
примеры\
_ru.entaxy.esb.system.management_\
_ru.entaxy.esb.system.bridge_