158 lines
7.7 KiB
Markdown
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_
|
|
|