# Integration Hub - iHub

An integration is a functionality, app or module that provides connectivity between Odoo and another system. Examples of integrations could be a module that connects to a bank, or an external store, or a 3rd party logistics provider, or literally anything else:

Odoo <------Data------> Integration

All integrations share the same purpose: **Transmit (send / receive) data, and process it.**

The way that integrations transmit data could be a bit different for each, but they all share some common ground:
1. They usually connect to something like APIs, FTPs, DBs, other systems.
1. They all need to be connected using some type of credentials ie: user and pass, secrets, tokens, etc.
2. The data transmission can be automatic (scheduled) and/or manual.
3. The data transmission can be via pull or push, ie: fetching external APIs, webhooks, using Odoo endpoints, etc.

The purpose of the **iHub** module is to unify into a common interface and architecture, any type of integration that needs to be built as an Odoo module or application.

**iHub** provides parameters, workflows and functionalities that as mentioned before, are frequent for integrations like cron job creations, action dates, logs etc.

## Create new integrations

### Anatomy of an integration

When building a new integration module, a normal structure would be:

/my_integration
    | __manifest__.py
    | README.md
    | models
        | my_integration.py
        | ihub_integration.py
        | ...other models
    | data
        | cron_job.xml
        | integration_type.xml
        | ...other data
    | static
        | description
            | icon.png
    | views
        | my_integration.xml
        | ihub_integration.xml
        | ...other views

1. Files `ihub_integration.xml|py` should be defined only if we plan to do any modification to the main integration UI (super_id).
2. `static/description/icon.png` will be used as the default image for the integration. It will be automatically loaded by IHub.
3. `data/integration_type.xml` is where we define the type to create new integrations from it. See `demo_integration/data/integration_type.xml`
4. Since usually all integrations are somehow related to cron jobs, then `data/cron_job.xml` is the place to put them.

An integration will always be composed of 2 models with a 1:1 relation:

  ihub.integration(super_id) + custom.integration.model(sub_id)

When a new integration is created form the UI, the above 2 records will be created and automatically linked. `sub_id`(the specific integration) will contain its own fields + the base fields defined in `super_id`(the ihub integration).

## Model inheritance
1. Methods should be {name}_{integration_type}
2. Fields should have a distinctive name also
3. Logic should be keep to the minimum and everything should be implemented on the sub_id

## View inheritance:
Almost everything should be defined in the view of "sub_id"

Views from "super_id" can be inherited to add custom parameters by using the notebook
and adding the page with an ID

## Picture:
can be changed, but can be placed in static/description/icon.png

## Dates
last_action_date = integration.super_id.get_action_date("last_order_import_date")
last_action_date.date

## Multi-level integration
Integration on top of integrations

                          |-------> Shopware
                          |
  ihub --> Shop Connector |-------> Shopify
                          |
                          |-------> Channel Engine

Direct integrations (transaction_importer, get_my_invoices)

  ihub -->  Transaction Importer

## Ihub Logs, Jobs and Mappers
When creating a new log, job or mapper, the integration they require is always super_id, not sub_id

## Context
Try to never use "integration_id" in the context for anything else that is not the ID of "super_id".
If you need to pass the sub_id around, use something like "connector_id" or "sub_integration_id", etc.