7.7 KiB
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:
<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