# 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_