entaxy-esb

Alternative languages

Russian

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
  • 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- - 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