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

Что такое интеграция?

В этом блоке я хочу остановиться на более простом определении интеграции в контексте множества существующих.

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

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

В чем сложность интеграции?

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

2. При реинжнириге процессов часто выясняется, что старые системы дают качественные показатели надежности, но с позиции аналитика, совершенно не упрощают интеграцию.

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

4. Изменчивость требований «на ходу». Особенно если в интеграции участвует более двух систем.

5. Требования информационной безопасности. Интеграция, в первую очередь история про обмен данными и часто это персональная информация как клиента, так и компании, требующая соблюдения правил для ее защиты\

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

Как не оступиться?

Принять, что готового шаблона нет и быть не может. Для каждой конкретной задачи процесс будет меняться. Тут можно спросить, а почему ниже еще много букв? Да, шаблона нет, но дать общие рекомендации можно. С этой целью и пройдемся по базовым этапам реализации интеграционного взаимодействия систем.

Техническая документация

Какой бы не была задача: создание новой интеграции, доработка или реинжениринг, все начинается с документации (ТЗ, ЧТЗ, СТП, API). И писать ее именно вам. Главная задача документации – максимально точно описать то, что хотят от итогового функционала.

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

Один из последних проектов поставил перед командой задачу по замене старой схемы интеграции (DBLink) на новую WS (обмениваясь данными по протоколам SOAP и REST). Необходимо было четко выявить участников существующего процесса интеграции (ASIS) и определить процессы, в которых нужно не только отказаться от DBLink, но и от других систем, ранее участвующих в обмене и обработке данными. Наша система – Siebel CRM, а смежной выступала АБС (ЦФТ), которая обрабатывала полученные данные и предоставляла ответ о результате операции.

На что было бы важно обратить внимание?

1. Цель
   Важно понимать в чем заключается основная цель интеграции – какую задачу предстоит решить в конечном итоге.

2. Описание бизнес-процесса
   Детальное описание возможных сценариев интеграционного бизнес-процесса. Важно избегать любых разночтений в требованиях

3. Способ интеграционного взаимодействия.
   Выбор способа передачи данных зависит от множества требований, предъявляемых не только бизнес-заказчиком, но и информационной безопасностью (ИБ), архитекторами и т.д.

4. Данные
   При описании документации важно понимать, какие данные необходима передавать или подучать, их обязательность, формат и т.д. Если это не описать, то в будущем точно придется потратить ресурсы на дополнительную проработку и анализ.

5. Проектная документация смежной системы.
   При описании взаимодействия необходимо ознакомиться с документацией смежной системы. Это позволяет снизить риски внезапного выявления важных особенностей смежной системы. Если даже вам говорят, что подобной документации нет - это не повод сдаваться. Кто-то же создал смежную систему, а значит без документации ее не могли допустить до запуска на «продуктиве». Понимание смежной системы качественно упростит вам задачу

6. Тестирование. Никогда не поздно начать смотреть в сторону планирования тестирования. Уже на стадии проектирования аналитик должен создавать «юз-кейсы», которые и лягут в основу ТЗ и сценариев тестирования.

Будьте убедительны и идите до конца. Всегда есть тот, кто ответит на ваши вопросы. Даже если это вы сами.

Скиллы в помощь

В зависимости от участников команды и скиллов ее участников, выстраивается внутренняя модель взаимодействия.

На предыдущем проекте по отказу от технологии DBLink в команде не было архитектора, чье отсутствие покрывалось обсуждением каждого вопроса внутри команды на этапе проектирования. На основе общих знаний нам удалось определить правильные подходы для решения задачи.

Одной из поставленных задач было «распилить» один большой сервис на множество небольших (микросервисы) с изменением технологии интеграции. Было необходимо реструктурировать функционал и доработать логику и систему хранения данных

На старте не было никакой уверенности в правильно выбранном пути. После использования метода «проб и ошибок» пришли к логически верному решению.

Не стоит преуменьшать значимость аналитика, особенно на старте работ в начале проектирования. На этом этапе важно не забывать о формате данных, обязательности, структуре этих данных и т.д. Это позволит соблюсти правила соответствия передаваемых данных для смежной системы

Нужные и важные навыки аналитика

1. Понимание, что такое API

2. Понимание основных требований к сервисам

3. Понимание видов интеграционного взаимодействия (синхронно или асинхронно)

4. Понимание работы очередей сообщений

5. Понимание работы шины данных

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

Что же такое API?

Для начала нужно определить на какие вопросы нам отвечает API:

1. Как ко мне и к моей системе можно обратиться?

2. «Ко мне можно обращаться так и так, я обязуюсь делать то и это»

API внешней системы сообщает нам каким образом обратиться к этой системе. При каких случаях на стороне смежной системы запустятся те или иные алгоритмы или процессы, которые зависят от набора переданных параметров. Какие данные смежная система готова возвращать в ответ, в каких случаях от них поступит запрос, и в каком виде необходимо направлять ответ.

Основные требования к описанию сервиса

1. Сохранение единой структуры сообщения
   При описании веб-сервиса необходимо сохранять структуру иерархии его объектов. (разработчики опираются на нее при формировании сообщения)

2. Полнота описания данных по каждому значению будущего сообщения
   

   1. Идентификатор – системное наименование;

   2. Название – бизнес название

   3. Поле таблицы – источник хранения значения в БД. Записывается через точку (значение.таблица)

   4. Тип данных – числовой, текстовый, справочник, дата и т.д.

   5. Размерность – ограничение по количеству символов. Например, если поле представляет собой «чек-бокс», то его размерность будет единицей для обозначения да/нет/пусто

   6. Обязательность может пониматься, как важность наличия тега даже с пустым значением, или как важность заполнения тега в сообщении

      1. Блок может быть разделен на два значения:
         

         1. Обязательность для системы 1 (отправителя)

         2. Обязательность для Системы 2 (получателя)

   7. Комментарий – для указания дополнительной информации, при необходимости

3. Обычно используется два типа сообщений:
   

   1. Запрос (Request) – исходящее сообщение от Системы 1 в Систему 2

   2. Ответ (Response) – входящее сообщение от Системы 2 в Систему 1 в результате полученного запроса (Request).

п. 3.1 Для исходящего сообщения - запрос (Request) характерны несколько блоков сообщения

MessageHeader

Первый блок – заголовок сообщения. Представляет собой массив, включающий в себя адрес или идентификаторы отправителя и получателя. Основная функция – управление сообщением.

Набор тегов в блоке MessageHeader зависит от API смежной системы. Необходимо точно понимать значение каждого из них и быть уверенным, что ваша система обладает этими данными и готова «генерить» их в нужном формате.

Пример заполнения MessageHeader (Request):

MessageBody

Второй блок - тело сообщения, или иными словами - его содержимое. Его объектами могут выступать: строчные, справочные данные, числовые значения, даты и т.д.

Значения могут помещаться в массивы (блоки), если они объединены одним процессом, или описывают одну сущность данных.

Пример заполнения MessageBody (Request):

п. 3.2 Для входящего сообщения - ответ (Response) характерны несколько блоков сообщения:

Ответ (Response) – входящее сообщение от Системы 2 в Систему 1 в результате полученного запроса (Request).

Основное отличие ответа от запроса заключается в том, что он содержит данные об успешности обработки запроса на стороне Системы 2.

Для входящего сообщения также характерны блоки  MessageHeader и MessageBody

MessageBody обязательно должен содержать теги, характеризующие результат обработки запроса на стороне смежной системы:

1. Код результата
   Справочное значение, указывающее на успешность, или на то, с чем связана ошибка.
   Например: в запросе не переданы обязательные данные для смежной системы, данные переданы в неверном формате и не могут быть обработаны смежно системой

2. Описание ошибки
   Текст ошибки также описывается в справочнике кодов ошибок

Справочник ошибок предоставляет Система 2, направляющая ответное сообщение

Пример заполнения MessageHeader и MessageBody (Response):

Понимание технических особенностей интеграции необходимо для качественного определения способа интеграции. На данном этапе проектирования основное участие принимают аналитик и архитектор.

Синхронно или асинхронно?

Так называют способы межсистемного взаимодействия. Ниже я описал основные принципы и примеры применения того или иного способа взаимодействия. На семах ниже представлена обработка не одного, а нескольких сервисов.

Синхронное взаимодействие

Синхронное взаимодействие– это когда каждая операция ожидает окончания предыдущей. SOAP – один из протоколов для организации синхронного взаимодействия.

Недостатки:

Проблема синхронности в том, что удаленный сервис может отвечать не очень быстро даже при прохождении простой операции. Например, на время получения ответа может валять загруженность сетевой инфраструктуры. Блокированные ресурсы могут останавливать работу других экземпляров сервиса по обработке сообщений блокируя весь поток обработки.
Таким образом если в момент обращения к внешнему сервису у нас есть незавершенная транзакция в базе данных, которая блокирует новые вызовы, мы можем получить каскадное распространение блокировок.

Когда «где-то там в середине» процесса по обработке заказа надо получить некое значение от которого зависят дальнейшие действия. Например, узнать вес и бьём товара, для определения способа доставки: курьер или машина (грузовая, легковая и т.д). При выборе синхронного взаимодействия для продолжения процесса нам необходимо получить ответ. и пока он идет, этот процесс держит не только свои ресурсы, но и блокировки, связанные с незавершенной транзакцией.

Асинхронное взаимодействие

Асинхронное взаимодействие– это когда отправляете запрос, который будет обработан «когда-нибудь потом». Взаимодействие происходит через очереди и таким образом ни один из участников не блокируется в ожидании. Обмен сообщениями происходит через очереди сообщений. Именно очереди обеспечивают асинхронную обработку данных. Они дают возможность поместить сообщение в очередь без обработки, позволяя системе обработать сообщение позднее, когда появится возможность.

Чтобы не перегружать всякими системами, приведу самый простой пример.

Условие: Человек собрался на свидание. Надо за 5 часов закончить дела по работе, позвонить и заказать сборку букета, ну и забронировать столик в ресторане.

Первый способ: В случае синхронного взаимодействия, он сидит в офисе, звонит в магазин цветов и делает заказ. Дальше он продолжает сидеть с телефоном возле уха, до тех пор, пока букет не соберут. Он не один кто звонит в цветочный, поэтому на ожидание этого уходит 4 часа, а он «синхронно» сидит с телефоном пока не получит ответ о готовности букета. Затем, потеряв 4 часа, он звонит в ресторан, но там уже все столики забронировали. В этом случае он тоже ждет какое-то время для получения ответа, так как в ресторане тоже работают «синхронно» и кто-то не мог ответить о свободных местах, пока не завершил свое долгое действие.
Результат: Как итог наш «синхронный» чувак, не смог заняться работой, заказал цветы и узнал, что мест в любимом ресторане уже нет.

А вот если он живет в асинхронном мире, то он может заказать букет, попутно с другим действием, потом не ждать ответа о готовности цветов весь период работы флориста, который также собирает множество заказаов своей последовательности. Как следствие совершить звонок в ресторан на 4 часа раньше, когда там еще есть свободные столики. И даже завершить рабочие дела в срок.

Результат: Он все успел.
Будьте асинхронны))

Очереди сообщений

Очереди сообщений это протокол передачи данных. Получатель и отправитель данных сообщений не должны взаимодействовать с очередями сообщений одновременно. Сообщения, хранятся в очереди до тех пор, пока получатель их не получит.

Приведу несколько причин для использования очередей сообщений:

1. Масштабируемость — очереди сообщений дают возможность распределить процессы обработки информации. И как результат - наращивать скорость добавления новых сообщений в очередь и обрабатываться.

2. Эластичность - способность выдерживать высокие нагрузки. Очереди сообщений могут служить буфером для накопления данных в случае высокой нагрузки. Как результат - смягчает нагрузку на систему обработки информации и снижая риски ее отказа.

3. Отказоустойчивость - очереди сообщений позволяют обособить процессы друг от друга. Таким образом, если процесс, который обрабатывает сообщения из очереди падает, то сообщения могут быть добавлены в очередь на обработку позднее, когда система восстановится.

4. Гарантированная доставка - очереди сообщений гарантирует, что сообщение будет доставлено и обработано в любом случае (пока есть хотя бы один обработчик).

Концепция обмена сообщениями

Интеграция в виде обмена сообщениями применяется для передачи информации между несколькими процессами (inter-process communication) и для обмена между несколькими потоками внутри процесса (inter-thread communication)

Представим трубку в которую мы (отправитель) помещаем шарики. Отправленный шарик (сообщение) кто-то получит где-то на другом конце трубки. Таким образом нам очевидно, что:

1. Отправитель не знает кто получит сообщение

2. Отправителю не важно, когда его сообщение будет получено

3. Отправитель может засовывать сколько угодно сообщений с комфортной скоростью

4. Отправителю не важно с какой скоростью получателю комфортно доставать новое сообщение

5. Отправитель и получатель не знают, как каждый из них устроен

6. Оба не знают о нагрузке и вместительности друг друга

7. Оба не знают о расположении другого. В одном здании, комнате, сервере

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

Что такое шина данных?

Шина данных (ESB) выступает прослойкой, связующей различные системы (ПО). Шина дает возможность службам, созданным в различных средах, легко и быстро взаимодействовать между собой. Также она служит для обмена данными с использованием различных протоколов и форматов, позволяя избежать доработок интегрируемых систем. Таким образом, — это промежуточное ПО, которое обеспечивает преобразование сообщений в нужный формат, контроль транзакций, маршрутизацию с учетом смысла, равномерное распределение нагрузки на сервисы и безопасность обмена данными.

Переходим к разработке

В итоге проведенного анализа формируется ряд проектных документов, по которым будет производиться разработка. Первое и самое важное требование, выдвигаемое к документации – четкое описание цели. Или, другими словами – постановка задачи. По мнению аналитика, все может быть описано предельно подробно, но для разработчика постановка была не очевидна. Подобные проблемы «перевода» возникают при недостаточной коммуникации с разработчиком.

На этапе разработки аналитик активно консультирует команду. Как бы полно не была описана документация и постановка задачи, со стороны разработки всегда возникнет масса вопросов, которые они могут просто не задать, посчитав свое понимание единственным и верным. Также аналитик не прекращает коммуникации с заказчиком, не стоит забывать об изменчивости требований.

Переходим к тестированию

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

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

Говоря о тестировании интеграционного взаимодействия, можно выделить несколько этапов:

1. Тестирование на среде разработки (DEV)
   Важно определить способ тестирования. Это может быть моделирование ответов от внешней системы.

2. Тестирование на интеграционной среде (QF,PL etc.)
   Для тестирования на интеграционном стенде рекомендуется подготовить документ, описывающий сценарии, которые необходимо пройти совместно со всеми системами, участвующими в бизнес процессе. Необходимо определить сроки, ответственных и настроить качественную коммуникацию. Все документы и зоны ответственности должны быть четко зафиксированы со всеми заинтересованными лицами.

Nota bene!

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

Вместо заключения

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

 С целью психоэмоциональной разгрузки на рис.1 продемонстрировано изображение отдыхающего котика.