Интеграции всегда кто-то пишет:
- одна сторона
- другая
- обе
Если одна из сторон не хочет писать, то нужно предоставить документацию к API и доступ к тестовой и рабочей точке.
Интеграции часто пишут:
- внутри приложения
- как внешнее (отдельное) приложение
- 2 внешних отдельных приложения
Обычно сейчас стараются писать как внешнее приложение. В этом случае внешнее приложение опирается на универсальное API интегрируемых приложений.
Если в интегрируемых приложениях не хватает понятий для интеграций, то приложения тоже нужно дорабатывать. Фактически, это добавление новых фич. Например, в одной из систем отсутствует какое-то критическое поле.
Можно выделить транспортный протокол интеграции:
- HTTP
- файлы через NFS
- файлы через FTP
- файлы через эл. почту
- соединение с базой данных
- шина обмена событиями
- …
И способы сериализации данных:
- HTTP-форма
- JSON
- XML
- Таблицы и поля в SQL-базе
- …
Главное при выборе – максимальная типизация для способа сериализации и надежность для транспорта.
Отдельно нужно обсуждать объем и периодичность обновления данных, чтобы знать о нефункциональных требованиях к интеграционному приложению.
Естественно, в интеграциях крайне важно понимать что делать с ошибочными данными (отметать весь блок или отдельные записи, как отдельные записи после ручного исправления повторно загружать в интеграцию) и настроить хороший мониторинг, чтобы максимально быстро узнавать о проблемах.
Поток интеграции – это получение (или отправка) записей определенного типа с возвратом информации об успешности или непринятых записях. Обычно записи являются более-менее конкретными. Например, Адрес, но не то Адрес, то Счет (при этом может быть Счет с Адресом – это нормально). Обычно является единицей работы и оценки.
Мои предпочтения:
- универсальное API интеграции в своем приложении
- отдельное интеграционное приложение для конкретной интеграции
- обычно все или много потоков интеграции внутри интеграционного приложения
- максимально жесткие проверки на валидность данных
- ошибки на уровне отдельной записи
- при технической возможности лучше интегрироваться через БД, т.к. там хорошая типизация, транзакции и т.п., но тут уж как повезет с другой стороной и на что они готовы
- асинхронный подход: когда отправляющая сторона не сразу ждет ответа об обработке отправленной пачки, а сколько надо