How Doohickey Works With Open Integration Hub

Doohickey is an integration operator, built to layer onto an existing integration platform. Currently, Doohickey provides the most support for working with Open Integration Hub.

This document describes why Doohickey is necessary to enable Open Integration Hub as an embedded integration platform and how the two systems work together.

Open Integration Hub as a Standalone Platforrm

Open Integration Hub provides many required capabilities for building software product integrations, licensed in an open source, publicly available framework. However, without heavy customization, it is insufficient to handle these embedded integrations at scale.

The following are reasons OIH is well suited as a standalone embedded integration platform:

• OIH is an API based product, which makes ready to embed into another software product
• OIH is deployed via Kubernetes, making it portable to many different cloud platforms
• OIH is open source, so it's code can easily be used and modified within another product
• OIH does follow best practices like using integration components, asynchronous messaging, and event-driven architecture
• OIH provides proper services for handling API credentials
• OIH provides multitenancy out of the box

The following are OIH's shortcomings as a standalone platform:

• OIH does not provide adequate "templating" for building reusable integrations that remain consistent across users
• OIH does not provide facilities for version management and deployment
• OIH does not readilly work with a CI/CD process or best practice development workflow
• OIH requires that you identify all entities by GUID, whiich is cumbersom across separate deployments of OIH (e.g. staging vs. production)
• OIH does not provide a suitable administrative UI--the web UI is for light testing and demoing only.
• OIH does not provide suitable traceability for identifying issues with failed execution of data flows

These shortcomings are not unique to Open Integraton Hub, as most integration platforms are not built for the scalability and multitenancy needs when being embedded into a commercial software product. They are instead built to provide bespoke, single-use integrations, often within an enterprise.

Doohickey & Open Integration Hub

Doohickey is meant to layer on top of an otherwise insufficient integration platform, like Open Integration Hub, to provide the capabilities to embed its integrations into a commercial software product.

Doohickey provides an operator with controls and an API that are more suitable for embedding within another software product. It also provides the templating necessary to roll out consistent versions of integrations times many users. Last, it provides suitable developer tooling (like a CLI) to incorporate fully into a sotware product team's development pipeline.

Doohickey is provided "as a service" so that it's functionality is always available in the cloud. It communicates directly to OIH instances installed into your cloud environments. This allows all data processing to remain under your control while providing the "as a service" benefits of deploying and maintaining the integrations.

Doohickey's object model is similar to OIH's (as well as other integration platforms). The concepts map between OIH and Doohickey as follows:

• Provisioning a Tenant in Doohickey will do the same in OIH. Tenants should be 1:1:1 between Doohickey, OIH, and the tenants ore accounts in your product.
• Configurations are end user unique configs or preferences about how their specific deployment of an integration should behave. They are merged with Templates upon deployment to create runnable OIH flows.
• Configurations also store references to OIH secrets created on behalf of the specific user.
• Definitions are the container for your integration and provide basic metadata. Typically these are named for and scoped by the external product to which you are integrating.
• Definitions contain one or more Templates. These are the directions for outputting one or more OIH flows deploy the integration.
• Connections relate to Oauth Auth Clients stored in OIH.
• Environments related to whole installations of the OIH platform. Typically this is at least a "staging" and "production" instance.

Whenever possible, interact with OIH through Doohickey instead of directly with OIH. There are still occasions where direct interaction with OIH is required, but these are not common. Doohickey will eventually cover them all.