Введение

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

Эта статья — первая часть большого материала об основах интеграции информационных систем. Статья будет полезна системным аналитикам и проектировщикам уровней junior и middle, которые хотят узнать тонкости применения различных способов интеграции и систематизировать свои знания.

В этой статье:

• что такое интеграция и для чего она нужна;

• какие бывают паттерны интеграции;

• подробно о четырех паттернах интеграции, в каких случаях их применять и как спроектировать:

  • файловый обмен;

  • общую базу данных;

  • удалённый вызов процедур: SOAP/REST.

Что такое интеграция и для чего нужно интегрировать системы?

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

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

Интеграции нужны, когда:

• системе А нужны какие-то данные системы Б (например, получить данные о налоговом статусе гражданина из ФНС);

• системе А нужна какая-то функция системы Б (например, проверить действительность документов гражданина).

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

1. При оплате заказа в интернет-магазине можно перейти в любое банковское приложение и оплатить заказ без использования данных карты.

2. Во многих ИС можно авторизоваться через Госуслуги или соцсети.

3. Многие документы можно подписать с помощью электронной подписи прямо с телефона.

Как интегрировать информационные системы?

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

• какими данными должны обмениваться системы? 

• с какой скоростью и в каком объёме системы обмениваются данными? 

• как долго и как часто системы будут обмениваться данными? 

• какие ограничения и особенности есть у интегрируемых систем? 

• сколько временных и финансовых ресурсов есть на интеграцию?

Паттерны интеграции информационных систем

Среди паттернов интеграции ИС выделяют четыре основных.

1. Файловый обмен.

2. Общая база данных.

3. Вызов метода API или удаленный вызов процедур (RPC).

4. Интеграция с помощью внешнего сервиса через брокеры сообщений.

Файловый обмен

Что такое файловый обмен

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

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

Как спроектировать интеграцию через файловый обмен

При проектировании файлового обмена важно определить ряд параметров интеграции.

1. Протокол взаимодействия. Для файлового обмена это могут быть:

   1. FTP (File Transfer Protocol);

   2. FTPS (FTP + SSL);

   3. SFTP (Secure File Transfer Protocol).

2. Настройки подключения к серверу. Это путь, учетные записи для подключения.

3. Условия запуска обмена. Нужно определить, что будет выступать триггером обмена, например, заданное расписание или какое-то событие.

4. Формат и объём передаваемых файлов.

5. Схема передаваемых данных.

6. Порядок удаления файлов с сервера. Будут ли файлы удаляться после передачи? Может быть они будут перемещаться?

7. Логирование событий. Какие события будут записываться в системе-источнике и системе-приёмнике.

8. Правила валидации файлов.

9. Правила обработки ошибок.

Возможности и ограничения файлового обмена

Когда использовать файловый обмен

Файловый обмен хорошо подходит для интеграции ИС, когда:

• нужно передавать файлы больших объёмов;

• нужно передавать агрегированные пакетные данные (например, выгрузка продаж за неделю);

• не нужен обмен данными в реальном времени;

• надёжность системы-приёмника низкая.

Файловый обмен применяется чаще всего для задач:

• массовой загрузки данных в DWH;

• интеграции разных технологических платформ;

• передачи мультимедийных файлов;

• интеграции государственных ИС и Legacy-систем;

• интеграции ИС в условиях отсутствия API.

Аналогия с мостами

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

1. По понтонному мосту могут ехать большие и тяжелые машины. Файловый обмен позволяет ИС обмениваться большими файлами.

2. Машины по понтонному мосту ездят не часто. Файловый обмен не предназначен для потоковой передачи данных в реальном времени.

3. Понтонный мост — быстрое, дешёвое и временное решение с прицелом на то, что когда-нибудь в этом месте построят настоящий большой и красивый мост. Файловый обмен также часто используют как временное решение, потому что файловый обмен просто и дёшево реализуется. 

Общая база данных

Что такое общая база данных

Общая база данных (БД) —  способ интеграции ИС, при котором разные системы обращаются к одному хранилищу данных.

Особенности реализации общей БД

Подключение к общей БД можно организовать по-разному.

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

2. Подключение к БД через DBC (Database Connectivity) API — интерфейс для подключения и выполнения запросов к базе данных. Бывает двух видов: JDBC — специфичный для языка программирования Java и ODBC — универсальный интерфейс от Microsoft.

Подход, при котором внешние ИС имеют прямой доступ на чтение и запись ко всем таблицам в общей БД на практике практически не применяется, потому что не является безопасным. Чаще доступ внешним ИС даётся не к самим таблицам, а к представлениям. 

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

Получение данных из материализованного представления происходит быстрее, чем из обычного, но данные в материализованных хранилищах необходимо постоянно обновлять.

Чтобы реализовать интеграцию через представления нужно выполнить несколько шагов:

• создать схему данных — определить в каких структурах будут храниться данные;

• создать представления — создать объекты в БД и написать запросы для наполнения представлений;

• создать роль и пользователя — выделить для обращения внешней ИС отдельного пользователя;

• выдать права — предоставить этому пользователю ограниченные права только на чтение определённых представлений.

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

Как спроектировать интеграцию через общую БД

При проектировании интеграции через общую БД важно определить ряд параметров.

1. Способ взаимодействия с БД. Нативное подключение или с использованием DBC API (JDBC или ODBC)?

2. Объекты БД для обращения. Будут ли внешние приложения обращаться напрямую к таблицам или к представлениям?

3. Роль для доступа. Под какой ролью должны обращаться в БД внешние системы? Под каким пользователем?

4. Права доступа к БД. Будет ли внешним системам доступно только чтение? Будет ли доступна запись? 

5. Предотвращение опасных операций. Нужно ли повесить триггеры на какие-то запросы или действия, например, удаление или запись?

6. Предотвращение SQL-инъекций и неверной типизации в коде приложения. Как защититься от встраивания в запрос вредоносного кода? Как реагировать на попытку записи данных с неверным типом? 

Возможности и ограничения прямого доступа

Когда использовать общую БД

Общая БД хорошо подходит для интеграции ИС, когда:

• все интегрируемые ИС внутренние;

• интегрируемые ИС относятся к одной доменной области и оперируют одинаковыми данными;

• обмен данными происходит по расписанию или эпизодически, обмен частый и в реальном времени;

• объём данных не слишком большой (не крупные файлы);

• необходимо сразу видеть изменения, происходящие в ИС.

Общую БД как способ интеграции чаще всего используют для решения задач:

• интеграции разных подсистем одной корпоративной платформы (например, ERP, CRM, СЭД и т.д.);

• интеграция Legacy-систем или самописных ИС.

Аналогия с мостами

Вернемся к аналогии с мостами. Интеграцию с помощью общей БД можно сравнить с переходом между зданиями.

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

2. Люди по мосту могут ходить часто и с небольшой скоростью, также как и данные между системами, интегрируемыми через общую БД.

3. По такому переходу обычно не ходят случайные люди «с улицы», доступ есть только у доверенных людей: у жильцов или сотрудников. Через общую БД тоже обычно интегрируются ИС внутри одной компании.

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

Удалённый вызов процедур

Что такое удалённый вызов процедур

Удалённый вызов процедур — это способ интеграции ИС, при котором клиент удалённо вызывает функцию или процедуру на сервере по определённому протоколу (набору правил). Сервер в свою очередь выполняет какой-то процесс или формирует набор данных и передаёт ответ клиенту. 

Все что мы называем сейчас вызовом по веб-API является на самом деле удалённым вызовом процедуры.

API (Application Programming Interface, программный интерфейс приложения) — набор правил, по которым сервисы и приложения взаимодействуют друг с другом. 

Несмотря на то, что изначально «Удалённый вызов процедур» — наименование конкретной прикладной технологии RPC (Remote Call Procedure), под этим термином можно объединить  различные технологии и подходы:

• RPC — Remote Procedure Call;

• CORBA  — Common Object Request Broker Architecture;

• SOAP  — Simple Object Access Protocol

• REST — Representational State Transfer 

• GraphQL — Graph Query Language

• gRPC — Google Remote Procedure Calling

SOAP

Что такое SOAP

SOAP (Simple Object Access Protocol) — протокол взаимодействия веб-сервисов. Протокол имеет набор жёстких правил, без соответствия которым взаимодействие по SOAP невозможно. 

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

Обмен данными с помощью SOAP реализуется в следующем порядке.

1. Клиент формирует запрос и направляет HTTP-запрос на сервер. Чаще всего это POST-запрос (даже на получение данных), так как исторически SOAP поддерживал только их (новые версии протокола поддерживают и GET). В теле запроса передаётся набор данных в формате XML: SOAP поддерживает только этот формат данных. Запрос всегда выполняется к одному ресурсу — название конкретной функции передаётся в теле запроса.

2. Данные запроса обрабатываются на веб-сервере по правилам, закреплённым в XSD-схеме.

3. Веб-сервер осуществляет вызов удаленной процедуры на сервере приложений.

4. Веб-сервер получает ответ от сервера приложений и возвращает его клиенту. 

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

Как спроектировать интеграцию через SOAP

При проектировании SOAP API важно определить ряд параметров интеграции.

1. Перечень функций на сервере и их названия нужно закрепить в WSDL-схеме.

2. Структуру и содержимое XML-сообщений запросов, включая типы данных, нужно закрепить в XSD-схеме, которая будет использоваться для валидации запросов.

3. Методы аутентификации клиента. Будет ли это базовая аутентификация или с использованием токена? Параметры для аутентификации передаются в заголовке запроса.

4. Перечень статусов ответов сервера, в том числе для ошибок. Статусы ответов передаются в заголовке ответа.

5. Структуру и содержимое XML-сообщений ответов, включая типы данных, нужно закрепить в XSD-схеме, которая будет использоваться для валидации ответов.

Возможности и ограничения SOAP

Когда использовать SOAP

SOAP хорошо подходит для интеграции ИС, когда:

• надёжность и безопасность важнее скорости;

• строгие контракты важнее высокой частоты изменений;

• логика удаленных процедур сложна;

• нужны транзакционные операции.

SOAP как способ интеграции чаще всего используют для решения задач, в которых цена ошибки высока:

• финтех-проекты;

• государственные системы;

• медицинские системы.

Аналогия с мостами

Вернемся к аналогии с мостами. SOAP можно сравнить с железнодорожным мостом.

1. Железнодорожный мост строится по строгим стандартам, от которых нельзя отклониться, что обеспечивает поезду надёжность и безопасность. Аналогично SOAP реализуется на основе строгого протокола, без выполнения которого взаимодействия не получится.

2. Железнодорожный мост рассчитан на долгую эксплуатацию и высокие нагрузки. SOAP-сервис также предназначен для долговременного использования с низкой вероятностью изменений.

3. Размеры и конструкции рельсов и поездов ограничены стандартами. Структура запросов и ответов строго определена и закреплена в XSD-схеме.

4. Поезд следует из одной точки (вокзал) по разным заранее определенным маршрутам. SOAP-запрос всегда направляется на один ресурс, а конкретная функция указана в полезной нагрузке запроса.

5. И железнодорожный мост и SOAP-сервис долго и дорого проектировать и реализовывать.

REST

Что такое REST

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

Существует 6 принципов стиля REST:

1. Клиент-серверная архитектура

2. Stateless

3. Кэширование

4. Единообразие интерфейса

5. Layered system

6. Code on demand

Если сервис соответствует всем этим принципам, то такой сервис называют RESTful.

Приложение, спроектированное в стиле REST работает следующим образом.

1. Клиент (как правило из веб-браузера) направляет HTTP-запрос на веб-сервер.

2. Веб-сервер направляет запрос к веб-приложению.

3. Веб-приложение выполняет какое-то действие или формирует набор данных из БД и возвращает ответ клиенту через веб-сервер.

В качестве транспортного протокола REST-сервисы используют HTTP/HTTPS. Обмен данными производится чаще всего в формате JSON, но можно использовать любой формат: XML, TXT, CSV, Protobuf.

Для того, чтобы обратиться к веб-серверу, необходимо направить запрос по определённому маршруту, используя один из HTTP-методов (GET, POST, PUT, PATCH). Таким образом, маршрут указывает на то, с каким ресурсом (объектом) нужно работать — это может быть любой объект предметной области: пользователь, заказ, товар и т.д. Важно, что сам по себе HTTP-метод не выполняет никаких действий с ресурсом. REST не обязывает реализовывать конечные точки каким-то конкретным образом, например, удаление ресурса можно реализовать методом GET и наоборот. Несмотря на это использование методов с учетом их семантики является рекомендацией стиля REST и правильной практикой для правильного понимания пользователей вашего API. 

Как спроектировать интеграцию с использованием REST

При проектировании REST API важно определить ряд параметров интеграции.

1. Набор конечных точек: маршрутов и HTTP-запросов к ним. Часто конечные точки еще называют эндпоинтами (endpoint) или «ручками».

2. Формат, структуру и содержимое полезной нагрузки запроса для каждой конечной точки.

3. Аутентификация клиента для каждой конечной точки. 

4. Статусы ответа сервера для каждой конечной точки

5. Формат, структура и содержимое полезной нагрузки ответа для каждой конечной точки. 

Для документирования REST API принято использовать спецификацию OpenAPI. 

Возможности и ограничения REST

Когда использовать REST

REST хорошо подходит для интеграции ИС, когда:

• нужно сделать быстро и просто;

• скорость важнее надёжности и безопасности;

• нужно часто вносить изменения в контракты взаимодействия;

• бизнес-логика не очень сложная и операции над бизнес-сущностями ограничены набором CRUD-операций (Create, Read, Update, Delete);

• экономия трафика не важна.

REST как архитектурный стиль интеграции чаще всего используют для:

• веб-приложений;

• мобильных приложений.

Аналогия с мостами

REST API можно сравнить с лифтом. 

1. Просто реализуется. 

2. Клиент изолирован от сложности сервера. Пассажир лифта не знает о том, как лифт устроен внутри, а просто нажимает кнопку этажа. Также и клиент не знает о том, как работает логика сервера.

3. Универсальность. Лифты бывают разные: скоростные, грузовые, пассажирские, горизонтальные, вертикальные. Для RESTful сервисов можно использовать любой удобный формат обмена данными.

4. Типовые подходы к реализации.

Резюме

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

2. Существует несколько подходов к интеграции ИС:

• файловый обмен;

• общая база данных;

• удаленный вызов процедур;

• брокеры сообщений.

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

• какими данными должны обмениваться системы?

• с какой скоростью и в каком объёме системы обмениваются данными?

• как долго и как часто системы будут обмениваться данными?

• какие ограничения и особенности есть у интегрируемых систем?

• сколько временных и финансовых ресурсов есть на интеграцию?

4. Файловый обмен как способ интеграции подходит для решения задач, в которых нужно передавать файлы больших объёмов и обмен данными в реальном времени не нужен.5. Общая БД как способ интеграции применяется, когда все интегрируемые ИС внутренние; когда обмен данными происходит по расписанию или эпизодически, обмен частый и в реальном времени; когда объем данных не слишком большой (небольшие файлы); когда нужно видеть изменения, происходящие в ИС, сразу.6. Удаленный вызов процедуры объединяет несколько технологий, самые известные из которых RPC, SOAP, REST, GraphQL, gRPC.

• SOAP хорош для интеграции, когда надёжность и безопасность важнее скорости, нужно реализовать сложную бизнес-логику, не предвидятся частые изменения контрактов взаимодействия;

• REST как архитектурный стиль лучше применять в задачах, которые нужно сделать быстро и просто, а скорость важнее надёжности и безопасности.

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

Вопросы и ответы

Допускается ли доступ к общей БД через промежуточный слой?

В качестве прослойки между приложением и БД могут выступать:

• DBC, о которых сказано в статье, позволяют сделать универсальный коннектор, умеющий работать с различными СУБД;

• ORM (Object–relational mapping) — технология, позволяющая повысить уровень абстракции и оперировать в коде приложения не сущностями реляционной БД, а классами объектно-ориентированного подхода. На практике использование ORM может порождать проблемы с производительностью приложения в долгоживущих системах.

Автор статьи — Анна Вичугова