Component Repository

Introduction

The Component Repository stores information about integration components.

API Reference Implementation Service File

Technologies used

How it works

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. Each component is based on an Open Integration Hub parent image which provides the component runtime. For example, for Java component the parent images provides the JDK and for Node.js component the parent image provides NPM and Node.js.

The component images are stored in a Docker Registry. A Docker Registry is a stateless, highly scalable storage for Docker images. Any open source integration component can be stored and distributed in/from Docker Cloud so that they are available to any Open Integration Hub installation (cloud or on premise) out of the box. For private components, a private Docker Registry can be maintained locally so that no components are exposed to the cloud. Each on premise installation could decide whether to use private repos on Docker Cloud or installing a private Docker Registry on premise for their private components.

Components

A component is described by a JSON document, containing all information required to be used by flows. The two most important parts of a component are the ‘image version’ pulled from dockerhub and its ‘id’ which is used in the flows. For (a minimal) example:

{
  "distribution": {
    "type": "docker",
    "image": "juanspada/shopify:latest"
  },
  "access": "public",
  "isGlobal": true,
  "active": false,
  "name": "shopify",
  "description": "generated connector for shopify",
  "repository": "https://github.com/openintegrationhub/Shopify-Component",
  "maintainer": "",
  "actions": {},
  "triggers": {},
  "owners": [
    {
      "id": "string",
      "type": "user"
    },
    {
      "id": "5f5632f3743e880011fd4b35",
      "type": "user"
    }
  ],
  "createdAt": "2021-03-03T11:51:55.065Z",
  "updatedAt": "2021-03-03T15:18:09.861Z",
  "id": "603f785b9fa556001b96f9b1"
}

For a full overview and more details, please refer to the Schemas section in the API Reference.

Component Repository API

The Component Repository offers a REST API through which components can be saved, retrieved, updated, started or stopped. To interact with this API, the user must supply a valid bearer token generated by the Identity Management.

List of supported Methods and Routes

endpoint	method	description	comments
/components	GET	Returns a list of all components
/components	POST	Stores a new component	The supplied data is validated for completeness and errors
/components/{id}	GET	Returns one particular component by ID
/components/{id}	DELETE	Deletes a components by ID
/components/{id}	PATCH	Updates a components with new data
/components/global/{id}/start	POST	Starts a global component with ID
/components/global/{id}/stop	POST	Stops a global component with ID
/enrich/{id}	PATCH	Automatically finds component data	Will attempt to fetch action/trigger data

For further details and examples, please refer to the API Reference

Automatic Enrichment

Through the use of the /enrich/id endpoint, the component repository can attempt to automatically fill out information about the component’s available actions and triggers from a public github repository. The repository’s URL can be either provided as a query string (see also the API documentation), or alternatively it will fallback on the content of the component’s repository field. If the provided github repository is found, the component repository will check the component.json (if present) and copy its functions data to the component’s entry. Additionally, if the component.json specifies schema files used as part of its actions and triggers, the component repository will also attempt to find and append that information.

Ownership and Permissions

Each component contains an array of owners. A component which is not global can only be accessed if the current user (as identified by their bearer token) is among those owners.

Additionally, manipulation of components limited and defined by the permissions of the current user. For further information about permissions, please refer to the documentation of the Identity Management.

Interaction with other Services

The Component Repository interacts with these Services:

Identity Management: The Component Repository relies on a bearer token supplied by the Identity Management to determine which components the current user may see, and which actions they may take.
Component Orchestrator: The Component-orchestrator gets the information it needs for the component used in a flow template from the Component-repository.