entaxy/entaxy-public
14
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
a8b20d2ac9
entaxy-public/README.md

7.7 KiB
Raw Blame History

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:
...
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