|
||
---|---|---|
documentation | ||
features | ||
platform | ||
system | ||
.gitignore | ||
LICENSE.txt | ||
pom.xml | ||
README.md | ||
README.ru.md |
entaxy-esb
Alternative languages
Detailed documentation: system description.
Installation instructions: installation.
Instructions for running tests for the universal service: tests.
- 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
- 1c-exchange-service - (Alexey Knyazev, Borodina
Valeria) message processing module, service 1C
- 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
- 1c - module for working with 1C
- 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
- initializer - Initialization infrastructure on
first startup, including checking, creating and running the required
system connections
- 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
- uniform-service - uniform service
- base - starts before the bundles with a low
startlevel or even enters the custom build of Karaf
- runtime - Components required for launch and work
of the platform
- 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- - stable release branch from it we do new branch in case of hotfix.
Release branch storage conditions:- customer pays for support
- our support for this release has not expired
- 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:
...
examples
project.1c.odata.in
project.rest1.in
Project configs (specific functionality):
.
examples
project.audit
project2.informer
Extras modules:
.
examples
ru.entaxy.eav
org.apache.mdm
Platform:
..
examples
ru.entaxy.esb.system.management
ru.entaxy.esb.system.bridge