В первой части мы пробежались по основам интеграций, взглянули на понятие жизненного цикла и разобрали виды интеграций. В этой части сконцентрируемся на интеграционном контракте и инструментах его реализующих.
Вообще, любая интеграция начинается с оценки её необходимости. Обычно, это инициирует менеджер продукта, или другой человек, несущий ответстенность за бизнес систему и/или бизнес процесс. Например, вы разрабатываете систему по оценке затрат в капитальном строительстве - вам нужно брать сметы из другой системы, а значит нужна интеграция. Или, возможно вы менеджер и вам нравится заводской формат работы, нужно, чтобы вашей системе отчётов проходили выгрузки о посещении сотрудниками офиса, значит нужна интеграция со СКУД-ом; Вы хотите смотреть посещаемость вашего сайта и для этого интегрируетесь с какой-нибудь системой продуктовой аналитики и т.д. Отмечу здесь важную деталь, одни интеграции функциональные и без них система просто не сможет работать, они нужны для реализации фунциональных требований продукта, другие интеграции нефункциональны, и нужны больше для обеспечения определенных свойств системы. То, как будут реализованы функциональные интеграции должно быть задачами первого приоритета, если вы занимаетесь проектированием интеграционной архитектуры.
В целом, если вам достаётся какая-то система и в ней оказываются реализованы какие-то интеграции, то они 100% решали какие-то проблемы, делать интеграции долго и дорого, довольно сложно придумать адекватный кейс, когда было потрачено много денег и сил на бессмысленную интеграцию (хотя возможность этого я допускаю). По этому примем за некоторый постулат, что если интеграция реализована, то она зачем-то была нужна. Этот факт помогает нам лучше спать по ночам, когда мы видим какое-то незадокументированное взаимодействие между системами.
Перейдем ближе к разбору интеграционного контракта:
По контракту должно быть понятно, какую задачу он решает. Обычно используются диаграммы, иллюстрирующие обмен информацией между БС, это могут быть схемы L1 из С4, модели информационных потоков из ARIS-a или банальные box&arrows, всё это лишь разные формы представления схожей идеи: от кого, кому и какая информация передаётся. Информация даётся на уровне сущностей верхнего уровня, без детализации их структуры (бизнес-сущностей по другому или концептуальных моделей). Так происходит, поскольку на начальном этапе важнее определить необходимость реализации той или иной интеграции, чем погружаться вглубь и всё детализировать. Рассмотрим всё это на примере проектирования системы мониторинга состояния людей подключенных к ИВЛ:
Пример
Целью системы пусть будет консолидация данных о состоянии пользователей и уменьшение числа летальных исходов за счёт более оперативного реагирования персонала. Представим, что этап бизнес анализа уже был и мы понимаем, у каких смежных систем есть реальный запрос на эту интеграцию, я акцентирую на этом внимание лишь потому, что необходимасть в интеграции между конкретным системами часто вообще не очевидна, в крупном бизнесе может быть не понятно, кто инициатор идеи или откуда пошёл этот запрос, а попытки выяснить будут затруднены не очевидностью из описания и названия системы её реального функционала. Хорошо, если есть какая-нибудь схема с описанием бизнес процесса или хотя бы просто, какое-то словесное описание (бизнес схемы не проще, а часто даже сложнее чем инженерные схемы, например в eEPC нотации. Вообще, виды и способы описания бизнес процессов это тема отдельной статьи, сейчас лишь отошлю к стартовому обзору). Описание ценно не само по себе, оно даёт нам понимание о том, как должны взаимодействовать друг с другом люди, участвующие в процессе. Добавим ещё к условию так называемый stakeholder needs в виде отчётов на корп. почту. Как это может выглядеть на практике (stakeholder needs - хотелки, в отличие от stakeholder requipments ещё не обремлены в реальные требования или в целом, являются больше пожеланиями, но не так критичны, см.):
Сперва разберём, что уже есть на диаграмме. По идее, способ отображения информации закреплен некоторым нормативом компании, т.е. бледно-розовым у нас фиксируются БР, а темно синим будем фиксировать БС. Внутри моделируемой системы мы можем кратко описать основные её функции, а стрелками указывать направление информационных потоков. Каждый голубой параллелограмм будет говорить о тех самых верхнеуровневых сущностях, которые мы передаём.
И вот у бизнеса возникает потребность, он хочет оценивать ещё экономические эффекты связанные с затратами на обслуживание системы. Для этого ему нужно понимать, сколько аппаратов ИВЛ в эксплуатации, сколько персонала с ними работает, количество необходимых медикаментов, чтобы оценить экономические затраты на всё это. Наша система, не покрывает целиком запросы этой OPEX-овой системы, однако может дать часть нужных ей данных в необходимом виде. В действительности, хороший вопрос: должна ли OPEX-система брать данные именно из системы мониторинга состояния людей? Пока что сделаем допущение, что в компании нет консолидированной системы для оценки используемых ресурсов (см. ERP-системы) и мы предлагаем единственный реальный вариант.
На этой схеме, мы уже выделили формально поток информации между БС-ами, с точки зрения технического специалиста, схема конечно даёт мало понимания и не отвечает на вопросы будущей реализации, но когда мы проектируем интеграционную архитектуру, у нас могут быть в планах на интеграцию ни одна и ни две, а вполне себе 20 систем на интеграцию, на ближайшие 2-3 года. По этому мы и хотим сперва как бы зафиксировать их перечень, не акцентируя внимания на технических деталях, по типу того, будем ли мы использовать шину данных или будем интегрироваться как-то иначе. Это всё позволит нам в дальнейшем принять решение о способе организации этих интеграций. Но вернемся к контракту. Как мы можем дополнит схему? Сконцентрируемся на выделенной пунктиром области
В ходе коммуникаций с разработчиками OPEX-системы мы выяснили, что весь фин.учёт они ведут на базе 1С систем. Вы знаете, что когда-то больница уже закупала 1С Шину для интеграций между 1С системами в контуре больницы и идёте договариваться о переиспользовании этого решения для реализации интеграции ещё и с вами. Опустим детали этого не быстрого процесса, но конечная цель, которую вы намечаете, заключается в том, чтобы убедить бизнес в потребности разработки адаптера для новоиспеченной КШД, который позволит интегрироваться не только между 1С системами, но и с вашим Сервисом Оперативных Оповещений, а также любой другой не 1С системой в будущем. Убедить может и не удастся, сверху может наложиться политика компании, фин.планы, приоритеты и многое другое, что может сделать такой выбор даже вредным или просто бессмысленным, но это находится вне фокуса статьи и нам для примера удобно считать, что этот вариант оказался жизнеспособным.
Что нам даёт эта схема?
Она показывает верхнеуровнего, что передаётся между нашими системами (два списка: список ИВЛ и список мед.работников), мы понимаем какие протоколы задействованы (Rest и SOAP), видим типы систем, с которыми взаимодействуем (1С системы), понимаем, что взаимодействие у нас не прямое, а посредством корпоративной шины данных (и это хорошо, мы вынесли с проектной команды ответственность за конвертацию данных в нужный принимающей системе формат, да ещё и с точки зрения корпоративной архитектуры - заложили фундамент под будущие расширения), также по схеме мы понимаем кто предоставляет какой интерфейс. Но чего опять не хватает? Схема не даёт детального понимания, что конкретно передаётся (какого типа сообщения, как выглядит их структура), нам не ясно кто выступает инициатором подключения и как выглядит само взаимодействие (конкретно в этом примере +- понятно из-за использования HTTP, а так могли быть вопросы синхронное оно или асинхронное и т.д.), есть ли какая-то схема преобразования данных на стороне КШД, какие вообще методы дёргаются.
DTO
И так, теперь нам нужно DTO. Вообще, DTO является частным случаем модели данных, они могут применяться также для моделирования баз данных, но мы их используем для моделирования интеграционных сообщений. В различных архитектурных инструментах (типо Archimate или Aris) есть возможность создания ссылок между диграммами разного уровня, иными словами их детализация. Пример будет привендён в craw's foot нотации
На этапе бизнес анализа мы уже выяснили, какие показатели нужны при оценке затрат и при этом доступны из нашей системы: список мед. персонала с закрепеленными за ними пациентами, потому что их количество влияет на размеры выплат и на премии, также мы исключаем пациентов без закрепленных за ними мед. работников и говорим, что для оценки затрат на мед. работников нам нужно знать их график работы и должность. Также включаем список оборудования. Настоящая диаграмма иллюстративна, она не отражает полноту моделирования реальной ситуации, тем не менее даёт понимание основных принципов. На схеме показаны передаваемые сущности и до уровня атрибутов расписана сущность Мед. работника, в идеальном случае расписывается каждый передаваемый объект, стоит также отметить, что атрибутиы могут быть и у головной сущности.
Теперь у нас есть понимание структуры передаваемых сообщений, продолжая переговоры с коллегами из принимающей системы мы договариваемся, что поскольку данных достаточно мало и ведение рабочей отчётности завязано на определенные административные процессы, нам достаточно передавать эти данные лишь один раз в сутки, под конец рабочего дня. Тем не менее, пусть инициатором запроса будет выступать наша система и мы будем готовить данные к передаче в удобный для нашего сервиса момент времени. Нам удаётся договориться, что использование Rest-а будет хорошим выбором, по скольку коллегам из КШД удобно разрабатывать gateway как некоторый веб-сервис с подключением к нему посредством HTTP протокола, а у нас не предполагается огромного списка данных и мы можем весь срез передавать одним сообщением, например, в json формате. Отразим это на интеграционной схеме
Из основного, сейчас не достаёт описания схемы взаимодействия между нашими сервисами. Интеграционная схема показывает статическую картинку, как бы срез взаимодействия и основные потоки данных. Однако взаимодействие предполагается у нас синхронное. Что может происходить в динамике? Сперва, у нас должна быть аутентификация сервиса - gateway должен убедиться, что к нему стучится правильный сервис, с правильным протоколом и его версией, а также по правильному порту. Далее, запрос на доступность его к получению данных и при подтверждении, отправка ему сообщения с получением положительного статуса приёмки и стратегия действий в случае отрицательного ответа (отмечу, что это может быть как отрицательный код ответа на уровне HTTP или отрицательный статус ответа на уровне json-а в теле ответа, отрицательные ответы надо смотреть на разных уровнях вложенности).
Диаграмма активности
Описание взаимодействия обычно моделируется в виде диаграммы активности из UML, в компаниях, где активно применяются SAP системы и/или используется ARIS, часто адаптируют eEPC нотацию, для аналогичного моделирования, хоть это и нотация для моделирования бизнес процессов. Также, я встречал схему интеграционного моделирования в виде диаграммы последовательностей, но это реально плохая идея, по скольку на ней довольно сложно моделировать разветвления в интеграционном сценарии, эта диаграмма больше подходит для описания жизненного цикла, чем для интеграционного сценария). В целом, это может быть и просто блок-схема, однако диаграмма активности обладает чуть большей семантикой и в целом, предпочтительней.
Эта схема может являться детализацией стрелки к интерфейсу на схеме интеграционного взаимодействия, а сообщение по отправке и подготовке данных может быть привязано к созданной ранее логической модели данных. Сама схема может быть расширена добавлением третьего столбца, на котором будут замоделированы шаги по обмену данными между КШД и Системой расчёта оперативных экономических эффектов. Также, мы можем дополнить схему описанием того, что будут трансформироваться передаваемые данные из одного формата в другой json(rest)->xml(soap). Мы можем добавить стратегии реагирования на возникающие ошибки помимо логирования и указать дополнительные шаги в виде информирования нужных людей, это уже будет являться частью документа по оказанию сервиса и устранению проблем. Вообще, работа с сервисной команда, это ещё одна сторона взаимодействия в интеграции, которую я не затрагивал ранее, то как это будет выглядеть сильно зависит от процесса оказания сервиса в компании (если он есть конечно), количества линий поддержки и наличествующий бизнес процессов, скажу лишь, что это отдельная, идущая параллельно процессу интеграции довольно большая деятельность.
И так, мы рассмотрели то, как может выглядеть процесс разработки интеграционного контракта и какие артефакты помогают описать все нужные аспекты интеграционного контракта. Стоит отметить, что полное графическое моделирование требует достаточно большого количества времени и нужно для прогнозирования и контроля за интеграциями, если интеграций мало, например одна, как в примере и у нас небольшая компания, то часть шагов может быть опущена или представлена в другом виде. Например схемы интеграций и инфопотоков можно объединить, DTO можно описывать сразу в формате json-a, а сценарий взаимодействия вообще описать словами и зафиксировать в том же ADR.
Однако исключение того или иного этапа и артефакта как раз и приведёт к малому контролю и прогнозированию сроков интеграции, к вольностям в трактовке и как следствие, к проблемам во время реализации интеграции (поскольку процесс будет пониматься по разному), сроки завершения работ будут увеличены, а будущие специалисты не будут понимать, зачем всё это было нужно.