Интеграции

Интеграции всегда кто-то пишет:

  • одна сторона
  • другая
  • обе

Если одна из сторон не хочет писать, то нужно предоставить документацию к API и доступ к тестовой и рабочей точке.

Интеграции часто пишут:

  • внутри приложения
  • как внешнее (отдельное) приложение
  • 2 внешних отдельных приложения

Обычно сейчас стараются писать как внешнее приложение. В этом случае внешнее приложение опирается на универсальное API интегрируемых приложений.

Если в интегрируемых приложениях не хватает понятий для интеграций, то приложения тоже нужно дорабатывать. Фактически, это добавление новых фич. Например, в одной из систем отсутствует какое-то критическое поле.

Можно выделить транспортный протокол интеграции:

  • HTTP
  • файлы через NFS
  • файлы через FTP
  • файлы через эл. почту
  • соединение с базой данных
  • шина обмена событиями

И способы сериализации данных:

  • HTTP-форма
  • JSON
  • XML
  • Таблицы и поля в SQL-базе

Главное при выборе – максимальная типизация для способа сериализации и надежность для транспорта.

Отдельно нужно обсуждать объем и периодичность обновления данных, чтобы знать о нефункциональных требованиях к интеграционному приложению.

Естественно, в интеграциях крайне важно понимать что делать с ошибочными данными (отметать весь блок или отдельные записи, как отдельные записи после ручного исправления повторно загружать в интеграцию) и настроить хороший мониторинг, чтобы максимально быстро узнавать о проблемах.

Поток интеграции – это получение (или отправка) записей определенного типа с возвратом информации об успешности или непринятых записях. Обычно записи являются более-менее конкретными. Например, Адрес, но не то Адрес, то Счет (при этом может быть Счет с Адресом – это нормально). Обычно является единицей работы и оценки.

Мои предпочтения:

  • универсальное API интеграции в своем приложении
  • отдельное интеграционное приложение для конкретной интеграции
  • обычно все или много потоков интеграции внутри интеграционного приложения
  • максимально жесткие проверки на валидность данных
  • ошибки на уровне отдельной записи
  • при технической возможности лучше интегрироваться через БД, т.к. там хорошая типизация, транзакции и т.п., но тут уж как повезет с другой стороной и на что они готовы
  • асинхронный подход: когда отправляющая сторона не сразу ждет ответа об обработке отправленной пачки, а сколько надо