entaxy-public/README.md

158 lines
7.7 KiB
Markdown

# entaxy-esb
### Alternative languages
[Russian](README.ru.md)
Detailed documentation: [system description](documentation/entaxy_main.adoc).\
Installation instructions: [installation](documentation/installation/installation-table-of-contents.ru.adoc).\
Instructions for running tests for the universal
service: [tests](documentation/connectors/uniform-exchange-service/tests/postman.adoc).
- **extras** - additional esb modules(Developed independently, installed separately.)
- **1c** - module for working with 1C
- **1c-exchange-service** - (Alexey Knyazev, Borodina Valeria) message processing module, service 1C
- **1c-exchange-endpoint** - soap-service 1C
- **1c-exchange-service-endpoint** - service soap-service 1C
- **connector** - stored in and out connectors at 1c-exchange-endpoint and 1c-exchange-service-endpoint
- **support** - support routers for connectors
- **1c-storage** - (Alexey Knyazev) liquibase module creating the necessary tables in the database for 1C
- **nsi** - (Alexey Knyazev, Borodina Valeria) module for nsi
- **nsi-soap** - (Alexey Knyazev) module with soap nsi
- **nsi-storage** - (Alexey Knyazev) liquibase module creating the necessary tables in the database for nsi
- **big-packet** - (Alexey Knyazev) big packet service
- **bridge** - (Mikhail Moiseev) bridge between different esb using brokers
- **db-connector-parent** - (Alexey Knyazev) connector to intermediate database
- **db-connector** - (Alexey Knyazev) connector to intermediate database, converts xml into java objects and
then saves it to the database via jpa, and also back
- **db-hyperjaxb3-naming-extension** - (Alexey Knyazev) - plugin for the hyperjaxb3 plugin that makes more
human-readable names for xsd generated columns and tables
- **file-archive-connector** - (Borodina Valeria) module for working with systems that work through the file
system (collects messages within an hour and collects them into an archive)
- **file-service** - (Alexey Knyazev) service for sending files via esb
- **features** - there should generally be one feature that pulls up features for individual components. Having
installed it, we install entaxy in Karaf
- **platform** - Content of a base entaxy
- **runtime** - Components required for launch and work of the platform
- **base** - starts before the bundles with a low startlevel or even enters the custom build of Karaf
- **branding** - logo creation entaxy
- **connecting** - infrastructure of adapters and connections
- **core** - core entaxy
- **initializer** - Initialization infrastructure on first startup, including checking, creating and running
the required system connections
- **storage-initializer** - (Mikhail Moiseev) everything related to data storage
- **management** - artifact management
- **modules** - additional modules entaxy
- **uniform-service** - uniform service
- **uniform-service-exchange-endpoint** - uniform soap-service
- **connector** - stored in and out connectors
- **support** - support routers for connectors
- **system** - (Andrey Filippov) the product(the module will subsequently be removed)
- **auth** - (Sergey Kryuchkov, Mikhail Moiseev) everything related to authorization, including bundles for specific
authorization schemes, a general interceptor for CXF, etc.
- **common** - common libraries
- **core** - the core of the system
- **dispatcher** -
- **events** - (Mikhail Moiseev) work with topics, our implementation of message delivery
- **permission** - (Mikhail Moiseev) permission
- **template** - (Borodina Valeria) work with templates to create profiles, connectors, etc.
- **error-handler** - (Sergey Kryuchkov) error handling routes and helper classes.
- **deployer** - (Borodina Valeria) everything related to the process of processing data from a gui, converting it
to a blueprint and deploying this blueprint to esb
- **cellar-deployer** - (Borodina Valeria) deploy blueprint to karaf cluster using cellar
- **deployer-api** - (Mikhail Moiseev, Borodina Valeria) interface deployer
- **nexus-deployer** - (Borodina Valeria) deploy generated blueprint to nexus
- **file-system-deployer** - (Mikhail Moiseev) deploy generated blueprints to filesystem
- **registry** - (Mikhail Moiseev) product-defined registries should contain systems, system-groups, services for
specific registry implementations
- **systems** - description of the external system in ours
- **system-groups** - groups of systems, generalized by some attribute
- **profile-commons** - can be connected by a connector to a communication point
- **processes** -
- **service** - this is the point of communication. (something deployed under CXF)
- **connectors** - something that links the profile to the point of communication
- **system-management** - (Borodina Valeria) management of systems, profiles and system connectors
- **transformer** - implementation of data transformations gui -> blueprint
- **test** - tests for postman
Use English in the repository!
- in the commit comments
- int the code
## **Repository rules**
Commits to the master are undesirable, but if you cannot do otherwise, warn colleagues in the general chat with a description of the reason.
**short:**
Feature branching - any development is carried out in separate branches (we branch from master / release) and then we
make a pull request.
**full:**
**Branches:**
- *master* - develop branch, we do new branch from it and we merge into it
- *release-<version>* - stable release branch from it we do new branch in case of hotfix.
Release branch storage conditions:
1. customer pays for support
2. our support for this release has not expired
3. the customer did not switch to a new release
- *feature-branch* - development branches, stored until checked out and merged with the target branch\
Branch naming:
* issue number from youtrack
* especially meaningful short name of the functional
- *hotfix-branch* - branches for hotfixes, stored similarly *feature-branch*\
Branch naming - prefix "hotfix-" further:
* issue number from youtrack
* especially meaningful short name of the functional
**Pull request**
- **For fixes and minor improvements** we assign to reviewers: lead developer - *Alexey Knyazev* and *responsible
for functionality / interested parties*
responsible and interested can be found in the description of the project above.
- **For major improvements** to the persons described above, add *Andrey Filippov* and *Sergey Starovoitenkov*
If no more improvements are planned in the merge-directed branch, when creating a pull request, we mark **Close branch**
**Camel Headers**
Headers used for service purposes are named according to the HTTP manifest, i.e. with a capital letter through a dash.
Must start with "Entaxy-"
**Configuration File Naming Format**
**Connectors:**\
_<project_name>.<system_name>.<connector_type>.<connector_direction>_\
examples \
_project.1c.odata.in_\
_project.rest1.in_
**Project configs (specific functionality):**\
_<project_name>.<module_name>_\
examples\
_project.audit_\
_project2.informer_
**Extras modules:**\
_<manufacturer_prefix>.<module_name>_\
examples\
_ru.entaxy.eav_\
_org.apache.mdm_
**Platform:**\
_<manufacturer_prefix>.<platform_part>.<module_name>_\
examples\
_ru.entaxy.esb.system.management_\
_ru.entaxy.esb.system.bridge_