Post #283

Одна из простых и недооцененных техник при разработке интеграций — составление регламента взаимодействия систем. В примерах, которые можно найти в Интернете, это обычно целый документ, раскрывающий все аспекты интеграции — вплоть до вопросов безопасности, протоколов, форматов запросов и ответов, и описания ошибок. Но в первом приближении это может быть одна таблица с полями: |Система-источник|Система-приёмник|Состав данных|Фильтр|Режим обмена|Цель|Комментарий То есть, нам нужно указать: 1. Откуда куда какие данные попадают. Детализация тут может быть до названия ("Реквизиты карточки документа"), до перечисления полей ("Карточка документа: Идентификатор документа, Наименование документа, Автор документа, Дата создания, Дата последнего изменения, Номер версии") или даже до конкретного формата (JSON/XML, ссылка на схему). 2. Когда они попадают? По расписанию? По событию внутри системы? По запросу пользователя? ("Запрашиваются при выборе документов, измененных с момента последнего обращения к системе", "выгружается вручную сотрудником время от времени по собственной инициативе") — это в поле "Режим обмена". Тут же можно указать, за кем инициатива по старту передачи — "по запросу <наименование системы-приёмника>" / "по инициативе <наименование системы-источника>" (или, может, по инициативе внешнего оркестратора). Можно это вынести в отдельное поле — "стиль взаимодействия": синхронный запрос / асинхронный запрос / подписка. 3. Фильтр — что именно передаётся. Одна запись, соответствующая запросу (когда запрос по ID), со всеми полями, или только с изменившимися? Набор записей, отобранных по определенному условию? ("Документы с датой обновления, большей даты в запросе"). 4. Цель — пожалуй, самое важное поле. Для чего интеграция? В рамках какого процесса? Тут можно указать также метрики и даже ROI. 5. В комментарий можно положить всё, что не вошло в другие поля, например — способ аутентификации или требования по обезличиванию, или технологию передачи (по шине, http-запросом, через файловое хранилище, по почте(!)). Если однотипных комментариев наберётся много — можно завести для них отдельную колонку. Такую таблицу хорошо бы завести для всех интеграций в ИТ-ландшафте — чтобы не разбирать каждый раз, что куда передается и по какому расписанию. Очень помогает при разработке новых интеграций. Самое интересное при исследовании — внести ручной перенос данных. Вот это прямо источник предложений по оптимизации работы! Дальше эту простую таблицу можно наращивать и обогащать деталями: ссылками на форматы запросов и ответов, точными названиями адресов, эндпоинтов, топиков; ссылками на спецификации OpenAPI и AsyncAPI, и т.д. Получится описание актуальной архитектуры, и каждый следующий проект будет делать легче, а оформлять в том же формате, но как проект изменений. Но начать можно с простой инвентаризации взаимодействий. Первый шаг научного подхода — классификация и учёт!