The revolution in data synchronization — the Open Integration Hub enables simple data synchronization between any software applications and thus accelerates digitalisation

Visit the official Open Integration Hub homepage

• Table of Content
• Introduction
• Contribution
  • Contribution Guidelines
  • Code of Conduct
• Contact
• Content
  • Folders
  • Documents
• Workgroup
  • Information
  • Member
    • OIH APIs
    • Secure Access Control
    • Repository Management
    • Message Processing
    • Management Services
• Wording
• Contribution

This repository contains all developing tasks considering the finalisation of the Open Integration Hub prototype, including the core components "Integration Services" and "Data Hub". Additionally, this repository includes the development of the microservices and the primary purpose is to develop the platform prototype as the basis for further use.

Before you contribute please read our contribution guidelines.

To see how members of the community are expected to behave, please read the code of conduct. We apply the code of conduct defined by the Contributor Covenant, which is used across many open source projects, such as NodeJS, Atom and Kubernetes.

When looking for further information or support, please contact: [email protected].

The following illustration shows how the microservices are aggregated within the workgroups:

• ManagementServices: Contains all concepts for management services such as logging and monitoring, reporting and analytics
• MessageProcessing: Includes all descriptions regarding message processing, communication router, scheduler and the resource coordinator
• OihAPIs: Describes the Open Integration Hub REST-APIs i.e. integration framework api and smart data framework api, which allows corresponding managing of the OIH platform
• Protocols: Collection of all taken protocols
• RepositoryManagement: Contains all repository service concepts such as Integration Component- and Content Repository
• SecureAccessControl: Includes microservices to manage secure access. This includes the Identity-, User- and Secure-Key-Management

• CONTRIBUTING: Contains the contribution guideline
• DataHub: Describes the concept of the smart data framework, using adapters/ transformer and a smart data framework adapter
• InfrastructureAndTechnologies: Lists the technologies used in the OIH and the motivation behind them
• IntegrationServices: Includes an overview of the intergration framework services as well as a short description for each microservice. It describes the integration into the kubernetes environment with message oriented middleware as the basis for communication
• MicroserviceDescriptionTemplate: Gives a brief overview of what a microservice description should look like
• MicroserviceOverview: Table of all integration framework microservices with their company in charge and the official deadline
• TestingTools: Table of possible testing tools with their main feautures

The integration components are lightweight and stand-alone Docker images that include everything needed to run the component, including the component's code, a runtime, libraries and dependencies. The component images are stored in an integration component repository (s. RepositoryManagement/Integration Component Repository).

There are two ways to trigger a flow execution: to poll changes periodically or to receive notifications through webhooks. The majority of integration flows poll perform polling as the most of APIs out there don't support webhooks. The polling is performed periodically with the help of the Scheduler.

Because Integration Hub is a multi-tenant environment, it is theoretically possible that some tenants cause starvation of others through an unfair usage of shared resources. The Resource Coordinator enforces every tenant to comply with the defined policies on resource sharing.

Please read more details on scheduler and resource coordinator (s. MessageProcessing/SchedulerResourceCoordinator).

In contrast to polling a flow can be started by an external event. Modern APIs provide support for webhooks in order to avoid wasting of resources when polling. The external system can be configured with a webhook url to be called upon changes in the external system. The Communication Router is used to expose externally-reachable URLs for integration flows that can be used to implement webhook-triggered flows. These URLS may be registered in external systems to sent notifications to. See more details on communication router (s. MessageProcessing/CommunicationRouter).

Integration Hub micro-services and integration flows are running in a Kubernetes cluster. Read details on cluster-level logging architectures (s. ManagementServices/LoggingMonitoring).

All the communication between steps of an integration flow in runtime is happening through a message broker. Two steps of an integration flow are separate Docker container isolated from each other. They are connected through a messaging queue than provides them a reliable and asynchronous communication protocol. See more details on message oriented middleware (s. MessageProcessing/MessageOrientedMiddleware).

An integration flow defines how data flow between various external systems and how these data are transformed between steps of that flow. However an integration flow does not define how to connect to these external systems. An integration can be considered as a clonable template that must not contain any sensible user data, such as API credentials. The API credentials are stored in the secure-key-management (s. SecureAccessControl/SecureKeyManagement).

Identity and Access Management (short: IAM) is one of the core components in OIH which is needed to provide a secure authentication and authorization of users/clients. The IAM Service can be configured to use JWT tokens with HMAC or RSA. It has also support for OpenId Connect. (s. IAM Concept)

All connected solutions to the Open Integration Hub and the work they are doing there are represented by an "integration flow". These flows have to be stored, retrieved, updated and deleted. The Integration Content Repository will provide these functionabilities.

/RepositoryManagement/IntegrationContentRepository

• Each workgroup has at least one status call every two weeks
• Every Committer must attend the status call
• The governance model defines the workgroup members' roles into managers, committers or contributors

Within the project different terms and abbreviations are frequently used. All terms and abbrevations are explained within the glossary and our list of abbrevations.

Before you contribute, please read the contribution guideline.