Что такое интеграция приложений?
Интеграция приложений — это процесс, который позволяет независимо разработанным приложениям и системам работать вместе. Это может помочь сократить расходы, получить аналитические данные, повысить эффективность и создать больше возможностей для организации.
Определение интеграции приложений
Организации редко полагаются только на одно приложение, но управление несколькими приложениями вместе со всеми их данными может быть трудоемкой, утомительной и сложной работой. Например, типичная крупная организация может иметь тысячи различных типов приложений, таких как наборы приложения, которые покупают клиенты, приложения для локального выполнения или приложения, которые предлагаются в качестве услуги (программное обеспечение как услуга (SaaS)). Клиенты также создают свои собственные приложения в облаке. В результате управление этими различными типами приложений может оказаться сложной задачей, поскольку для них требуются администраторы и ресурсы.
Именно в таких случаях интеграция приложений может изменить ситуацию. Интеграция приложений управляет всеми интеграциями между приложениями в одном месте, контролируя аутентификацию и авторизацию этих интеграций.
Без интеграции приложений перемещение данных между приложениями было бы сложным и чрезвычайно утомительным; это потребовало бы ввода одних и тех же данных несколько раз, а также увеличило бы вероятность человеческой ошибки. Средства сопряжения для интеграции приложений имеют возможность преобразовывать данные в формат, совместимый с существующей ИТ-архитектурой организации, чтобы данные можно было ввести всего один раз и подключить к нескольким приложениям, без необходимости думать о том, сможет ли каждое приложение взаимодействовать друг с другом. Таким образом обеспечивается определенный уровень гибкости, так чтобы организация могла выбирать нужные ей приложения, а не покупать их у конкретного поставщика.
Разница между интеграцией приложений и интеграцией данных
Хотя термины «интеграция приложений» и «интеграция данных» иногда используются как взаимозаменяемые, важно объяснить, чем они отличаются.
Проще говоря, интеграция данных заключается в сборе информации из разрозненных источников с целью создания более единообразного представления о данных в организации. Хотя интеграция данных может происходить в режиме реального времени, она может выполняться и постепенно в течение длительного времени, поскольку при этом происходит сбор большого количества данных, их хранение и последующая пакетная обработка. Это позволяет перемещать и анализировать данные внутри приложений с целью устранения избыточности.
Интеграция приложений обычно более ограничена и привязана к рабочим процессам между приложениями. Например, передача информации о потенциальных клиентах из маркетинговой системы в систему управления продажами. Это также обычно происходит на уровне отдельных транзакций. Интеграция данных обычно происходит на уровне хранилища данных или базы данных — где целые таблицы, каталоги, файлы, потоки или другие типы данных агрегируются и преобразуются по мере необходимости.
Что такое непрерывная интеграция?
Непрерывная интеграция – это практика разработки программного обеспечения DevOps, при которой разработчики регулярно объединяют изменения программного кода в центральном депозитарии, после чего автоматически выполняется сборка и тестирование. Непрерывная интеграция чаще всего относится к этапу сборки или интеграции в процессе выпуска программного обеспечения и подразумевает как компонент автоматизации (например, CI или сервис сборки), так и культурный компонент (например, обучение частой интеграции). Главная задача непрерывной интеграции – быстрее находить и исправлять ошибки, улучшать качество ПО и сокращать временные затраты на проверку и выпуск обновлений ПО.
Зачем нужна непрерывная интеграция?
Раньше разработчики одной команды могли в течение долгого времени работать изолированно и объединяли свои изменения с основной частью проекта только по завершении собственной работы. Это делало слияние кода сложной и трудоемкой задачей, к тому же ошибки накапливались и не исправлялись в течение долгого времени. Такие факторы затрудняли быструю доставку обновлений пользователям.
Как работает непрерывная интеграция?
При непрерывной интеграции разработчики часто подтверждают записи в совместно используемый репозиторий, используя систему контроля версий, например Git. Перед каждым подтверждением записи разработчики могут запускать локальные модульные тесты программного кода в качестве дополнительного уровня проверки перед интеграцией. Сервис непрерывной интеграции автоматически выполняет сборку и запуск модульных тестов для изменений кода, что позволяет моментально выявлять ошибки.
Непрерывная интеграция относится к стадии сборки и поэлементного тестирования процесса выпуска ПО. Каждое подтвержденное изменение кода запускает автоматический процесс сборки и тестирования.
С помощью непрерывной доставки изменения программного кода автоматически проходят сборку, тестируются и подготавливаются к запуску в рабочей среде. Непрерывная доставка расширяет практику непрерывной интеграции за счет того, что все изменения кода после стадии сборки развертываются в тестовой и (или) в рабочей среде.
Методы и подходы к интеграции систем
Интеграция систем в большинстве случаев – мера вынужденная, направленная на повышение эффективности бизнес-процессов компании, в которых используются информационные системы [http://citcity.ru/16663/].
В данном разделе рассмотрены основные подходы к интеграции информационных систем, демонстрирующие возможные способы решения различных проблем компаний, связанных с необходимостью организации взаимодействия систем.
Больше информации по теме
Общие подходы к интеграции систем
1. Нет интеграции между системами
В компании используются три независимые информационные системы: «Складская система» (учет и анализ товародвижений на складе), «CRM-система» (учет и анализ продаж и других взаимоотношений с клиентами) и «Бухгалтерская система» (бухгалтерский учет и финансовый анализ). Между ними нет информационного обмена.
Это приводит к тому, что менеджеры по продажам после выставления счетов клиентам вынуждены печатать их копии и нести в бухгалтерию. В бухгалтерии они регистрируются в бухгалтерской системе. Бухгалтерия регистрирует поступление денег на счет. Менеджеры по продажам, не имея возможность получить оплаты автоматически в CRM-систему, вынуждены ежедневно осведомляться в бухгалтерии о поступлении денег от клиентов. В такой ситуации присутствует большой документооборот между менеджерами, бухгалтерией и складом, а также двойная регистрация действий (один раз в складской системе, второй раз в бухгалтерской).
Если посчитать затраты оплачиваемого компанией времени сотрудников на выполнение дублирующихся процедур в разных системах (выделены красным на схеме), то может получиться ощутимая доля в общих издержках фирмы.
2. Вертикальная интеграция
В соответствии с этим подходом системы интегрируются по принципу функциональных экспертиз. Например, в данном случае выделены две экспертизы: оперативный учет и бухгалтерской учет. При этом бухгалтерский учет находится по вертикали выше оперативного учета. В нашем примере подсистемы оперативного учета поставляют данные подсистеме бухгалтерского учета.
Это позволяет существенно сократить трудозатраты на дублирующиеся и бумажные операции, однако, есть два отягчающих момента.
Во-первых, такую систему крайне трудно расширять функционально. Например, компания может захотеть создать подсистему-экспертизу «Аналитика», которая по вертикали будет расположена над экспертизой «Бухгалтерский учет». Эта экспертиза в значительной степени основана на данных «Оперативного учета». Поэтому, помимо собственно разработки подсистемы «Аналитика» придется дорабатывать подсистему «Бухгалтерский учет» для того, чтобы она получала и хранила для нее из «Оперативного учета» дополнительную информацию.
Во-вторых, остаются значительные возможности по интеграции в рамках одной функциональной экспертизы.
3. Интеграция «многие ко многим» (звезда, спагетти)
В рамках данного подхода каждая из используемых в компании подсистем может при необходимости обращаться к функционалу любой другой подсистемы, при этом каждая из подсистем может также использоваться любой другой подсистемой. Такой тип отношений между элементами называется «многие ко многим».
В этом случаем имеем место с практически неограниченными возможностями интеграции подсистем между собой (естественно, если подсистемы технологически позволяют делать это).
Но, с другой стороны, затраты на поддержку такой интеграционной схемы экспоненциально растут при увеличении числа интегрированных подсистем. Например, если в нашем случае потребуется изменить что-то в бухгалтерской подсистеме (допустим, изменить ее объектную модель), то это может привести к необходимости переработки все остальных подсистем использующих ее, т.к. вызовы старой объектной модели перестанут работать. Для трех взаимодействующих систем это может быт не так критично, а вот для тридцати весьма и весьма.
4. Горизонтальная интеграция
Данный подход заключается в использования специализированного «промежуточного» (middleware) ПО — так называемой корпоративной сервисной шине. Основная задача этого ПО заключается в хранении репозитория функционала корпоративных приложений, подключенных к ней, и обеспечение возможности использования этих функций другими приложениями, также подключенными к этой шине. Взаимодействие между приложениями могут, например, происходить в форме обмена сообщениями или вызова опубликованных функций в виде Веб-сервисов. Подключение системы к шине производится путем создании специального адаптера для каждой системы. После этого «опубликованные» функции системы становятся доступными другим подключенным системам.
Например, CRM-система при подключении к шине публикует свои функции по работе с клиентской базой данных. Шина обеспечивает возможность их использования бухгалтерской и складской системами. В свою очередь CRM-система получает возможность с бухгалтерскими и складскими данными.
Преимуществом данного подхода является то, что сами системы могут заменяться в рамках существующей спецификации опубликованных функций. При этом никаких изменений в других системах не требуется. Кроме того, подключение новой системы в достаточной степени стандартизировано и упрощено. Например, имеется возможность подключить новую систему «Аналитика», которая сразу получит доступ ко всем остальным системам.
5. Отсутствие необходимости в интеграции
Безусловно, самая лучшая интеграция – это отсутствие необходимости в ней. Например, все представленные выше подсистемы могут быть реализованы в виде функциональных модулей одной ERP-системы какого-либо вендора. В этом случае необходимость в интеграции отпадает, т.к. система уже изначально единая, обеспечивающая гораздо большую связность между функциональными модулями чем любой из приведенных выше вариантов интеграции между различными системами.
Объекты и методы интеграции систем
Ранее при описании подходов к интеграции систем мы рассматривали каждую информационную систему как «неделимый» объект. Однако, информационная система представляет из себя совокупность нескольких компонентов, поэтому, говоря об интеграции информационных систем, правильнее говорить об интеграции составляющих их компонентов.
1. Интеграция платформ
Технологии удаленного вызова процедур (в широком смысле под процедурой понимается некоторая функциональность приложения) позволяют опубликовать процедуру и обеспечить возможность ее вызова (передачи входящих параметров и получения выходных результатов) для приложений, работающих на других платформах.
Концепция программного обеспечения промежуточного слоя (framework, среда исполнения, виртуальная машина) состоит в разработке прикладного ПО не с использованием сервисов конкретной операционной системы (например, Windows API), а с использованием сервисов ПО промежуточного слоя. Разработчиками ПО промежуточного слоя создаются ее реализации под различные операционные системы, которые транслируют вызовы соответствующих функций фрэйворка в вызовы соответствующей операционной системы. Типичным примером является технология Java Runtime Environment. Приложения, разработанные для этой технологии работают на любых программно-аппаратных платформах (Windows, Linux и др.) без каких-либо доработок самих приложений. Аналогичные возможности предоставляет среда Microsoft .Net Framework.
Интересной и современной концепцией является «виртуализация». К интеграции платформ она имеет отношение постольку, поскольку позволяет существенно упростить использования различных платформ и, соответственно, использование систем, требующих для своего функционирования наличия конкретных платформ. Если без виртуализации возможно одновременное функционирование N операционных сред на N серверов, то применение технологий виртуализации позволяет обеспечить функционирование N операционных сред на M серверов. Если N > M – это позволяет сократить расходы на аппаратное обеспечение путем его более эффективного использования. Если N < M – это простой путь увеличения производительности систем. Например, виртуализация позволяет развернуть и одновременно использовать на одном физическом сервере несколько операционных систем: Windows, Linux и др. На каждом из таких «виртуальных» серверов могут быть развернуты соответствующие системы, которые будут доступны одновременно. Примеры технологий виртуализации: Microsoft Hyper-V, KVM, OpenVZ, Virtuozzo, VMware, Xen и пр.
2. Интеграция данных
По определению информационная система работает с данными. В подавляющем большинстве случаев система имеет в своем составе базу данных для их хранения. Интеграция на уровне данных предполагает совместное использования данных различных систем. Интеграция данных может оказаться проще, чем интеграция приложений, т.к. промышленные СУБД, в которых обычно хранят данные информационные системы, имеют развитые возможности программного доступа к данным из других приложений. Сами приложения при этом могут иметь весьма ограниченные возможности программного (вне собственного пользовательского интерфейса) использования своей функциональности внешними системами.
Технологии универсального доступа к данным позволяют обеспечить единообразный доступ к данным различных СУБД. Посредником для работы с конкретной СУБД в данном случае является драйвер для соответствующей СУБД. Например, один и тот же SQL-запрос на выборку данных SELECT * FROM TTABLE может быть использован на выборку данных из таблицы TTABLE , хранящейся в различных СУБД. Это позволяет абстрагироваться от специфики конкретных СУБД и легко осуществлять интеграцию данных, хранящихся в различных СУБД. Наиболее распространенные технологии этого класса: ODBC, JDBC, ADO.NET. Кроме того, на сегодняшний день широко распространены технологии объектно-реляционного отображения (ORM), которые также позволяют абстрагироваться от деталей взаимодействия с конкретными СУБД. Примерами таких технологий являются Entity Framework, Hibernate, NHibernate, Flexberry ORM.
Концепция хранилищ данных состоит в создании корпоративного хранилища данных. Хранилище данных – база данных, хранящая в себе данные, собираемые из баз данных различных информационных систем, для целей их дальнейшего анализа. Например, может быть создано единое хранилище данных компании, в которое собрана информация из бухгалтерской, оперативной системы, внешних систем партнеров компаний. Для создания хранилищ данных используются технологии (OLAP), отличные от технологий создания оперативных БД (OLTP). В основном это делается для повышения производительности выполнения сложных аналитических запросов по многим параметрам (многомерные запросы). Подходы к созданию и наполнению хранилищ данных отражены в парадигме ETL (extraction, transformation, loading = извлечение, преобразование и загрузка). Технологии и инструментальные средства анализа больших массивов данных с целью выявления закономерностей предметной области объединяются понятием «Data Mining». Термин для совокупности технологий хранилищ данных и инструментальных средств, обеспечивающих перевод транзакционной деловой информации в человекочитаемую форму, пригодную для бизнес-анализа – «Business Intelligence».
3. Интеграция приложений
Интеграция на уровне приложений подразумевает использование готовых функций приложений другими приложениями. Например, разрабатывая систему электронного документооборота, существует возможность использовать в рамках этой системы в качестве текстового редактора MS Word вместо того, чтобы разрабатывать свой собственный текстовый редактор. Или, например, ПО Call-центра, получив входящий звонок от клиента, имеет возможность обратиться к функции биллинговой системы по проверке баланса (на входе – номер телефона абонента, на выходе – его текущий баланс) и, в зависимости от состояния баланса соединить его с оператором или автоматически проинформировать о необходимости пополнить свой счет. При этом структура база данных биллинговой системы является ее внутренней информацией, публикуются конкретные функции, позволяющие другим системам работать с конкретными данными.
Программный интерфейс конкретной системы представляет собой «опубликованный» функционал этой системы, который может быть использован извне. Функционал может публиковаться в виде набора функций (пример – Windows API) или в виде объектной модели (объекты со свойствами и методами, пример – объектные модели приложений Microsoft Office).
В большинстве случае интеграция нескольких систем заключается в передаче информации между ними, например, в форме запрос-ответ. Если системы функционируют в гетерогенных распределенных средах, то принципиальное значение имеет обеспечение гарантированности, безопасности, управляемости доставки информации между приложениями. Эти и другие принципы реализуются в корпоративных системах обмена сообщениями. В данном случае речь идет об обмене сообщениями между приложениями, а не людьми, как, например, в случае E-mail или мессенджеров. Функциональность этих систем достаточно прозрачна – прием сообщения от одного приложения, транспортировка по заданным правилам и передача этого сообщения другому приложению. При этом может производиться шифрование сообщений (для невозможности прочтения данных в процессе транспортировки), цифровая подпись (для защиты от умышленного изменения данных во время пути сообщения), настройка подписки (для отправки одного сообщения сразу нескольким приложениям), определение метаданных для сообщений (для облегчения использования сообщений со сложной структурой содержимого) и др [https://ru.wikipedia.org/wiki/Сервисная_шина_предприятия].
Цена создания новых приложений на основе существующих Веб-сервисов будет существенно ниже, чем разработка приложений «с нуля» или обширная интеграция с другими системами.
Например, в компании (оператор связи) существует система Service Desk (техническая поддержка абонентов) и биллинговая система (тарификация услуг). Перед компанией стоит задача сделать новую систему «Личный кабинет абонента», в которой абонент мог бы через Интернет просмотреть состояние своего счета и сообщить о неисправности. Для этого компания вместо того, чтобы создавать «Личный кабинет» с собственной базой данных, синхронизируемой с БД биллинговой системы и системы Service Desk, использует готовые Web-сервисы «Карточка абонента» (опубликованный функционал биллинговой системы) и «Создать заявку в техподдержку» (опубликованный функционал системы Service Desk). Очевидно, что вся работа по новому приложению «Личный кабинет» состоит лишь в создании Веб-интерфейса пользователя на сайте компании.
Также часто используется следующий подход – интеграция пользовательских интерфейсов. Например, для создания приложений «одного окна». Простейший пример – фреймы на Веб-странице. Внутри каждого фрейма содержится отдельное Веб-приложение. Благодаря фреймам, все эти приложения отображаются на экране одновременно. Пользовательские интерфейсы Веб-приложений легко интегрируются, однако, существуют возможности интегрировать и «классические» пользовательские интерфейсы и их фрагменты (ActiveX).
4. Интеграция бизнес-процессов
Наиболее целостным подходом к интеграции систем является интеграции на уровне бизнес-процессов. В рамках интеграции бизнес-процессов происходит и интеграция приложений, и интеграция данных и, что не менее важно, людей, вовлеченных в этот бизнес-процесс. Интеграция на уровне бизнес-процессов является наиболее «естественной» для организаций, так как их деятельность состоит, прежде всего, именно из бизнес-процессов, а не приложений, баз данных и платформ.
Что такое интеграция в программировании
Краткий путеводитель по галактике интеграций
для тех, кто уже освоил базовый уровень (или прошел наш интенсив)
Судя по статистики запросов в интернете, понимание интеграции становится одним из базовых знаний для аналитика. Чтобы помочь вам сориентироваться в этой области знания, я предлагаю посмотреть на типы интеграций.
1. Внутренняя и внешняя.
Например, я в Школе системных аналитиков устраиваю интеграцию Тильды (конструктор, на котором сделан сайт школы) и Sendpulse (приложение для рассылок писем). Это две разные системы, которые разработали две разные компании, это внешняя интеграция.
А ещё есть внутренняя. Например, у нас в Аргусе система технического учёта и система CRM были интегрированы между собой, чтобы оператор call-центра мог проверить техническую возможность проведения интернета человеку прямо во время регистрации заявки от него. Обе системы — наша разработка, нам не нужно было подключать каким-то образом третью сторону для этой интеграции.
А когда чуть позже понадобилось оператору карту показывать, то потребовалась внешняя интеграция (со сторонним сервисом — GoogleMap)
2. Простая и сложная (очень условное название)
Интеграция может быть с использованием no-code инструментов (например, я использую Integromat), а может требовать разработчиков и написания кода. Вот тут классная подборка no-code инструментов.
Кстати, можно выделить еще ручную интеграцию. Например, сотрудник склада, переносящий данные из системы 1С:Склад в CRM, занимается интеграцией этих систем.
Интерфейс приложения Integromat
3. Классификация по целям
Интеграция может иметь разные цели. В основном, речь идёт про организацию сквозного бизнес-процесса (процесс заказа продуктов, например, требует работы нескольких систем). Или про организацию хранения данных (MDM-класс систем, DWH-системы и т.п.). Или про представление данных в одном окне (у нас оператор мог видеть dashboard с кучей информации из разных систем): всё это ради экономии времени, денег или предоставлении какой-то новой, ранее невозможной услуги (сервиса) или продукта
4. Интеграция может быть стихийной или плановой
Вам срочно надо объединить две системы, чтобы организовать процесс? Фигачим! О, неплохо бы ещё систему CRM к ним интегрировать? Делаем! И так год за годом. Куча систем, как клубок, наматывается: то там интегрируем, то тут. Плановая, соответственно, возникает, когда есть план)
5. Интеграции могут отличаться по структуре связи
Взаимодействие систем по принципу точка-точка исторически появилось раньше остальных. Подразумевает этот принцип всего лишь ситуацию, когда каждая система попарно интегрируется с другими.
А интегрируется с Б, Б с В и др., т.е. напрямую. Система А знает, как обратиться к системам Б и В, завязана на их интерфейсы, знает адрес сервера приложений.
Звезда — это когда мы добавляем, к примеру, шину (ESB). Какую-то прослойку, которая позволяет всем системам интегрироваться между собой. Это как единая точка. Шина — это тоже ПО. Звезда имеет много плюсов (например, если эта CRM система вам больше не нужна, меняем её на новую — всё не развалится). Но есть и минусы. Например, у вас есть единая точка отказа. Случись что-то с шиной — и не работает вообще всё (весь контур систем, которые интегрируются через эту шину).
Смешанная — это когда у нас на проекте есть шина, общая точка, где системы объединяются. Но и есть попарно интегрированные системы. Так бывает! И это не всегда плохо
6. Синхронная или асинхронная интеграция
Асинхронная интеграция нужна — это как сообщение в почте или чате, ответа мы не ждём сразу. Синхронная — это как общение по телефону: если ты звонишь человеку, то ты общаешься с ним и ждёшь ответа сразу во время разговора. Это большая тема, можно много говорить;
7. Интеграция систем, подсистем, сервисов, микросервисов
Если вы интегрируете свою систему CRM с чужой системой MDM, то это интеграция систем.
Если сервису Яндекс.Кошелек вдруг нужны данные с сервиса Госуслуги, то перед нами интеграция сервисов.
Если наша система построена по SOA, то мы имеем распределенную систему, подсистемы которой интегрируются между собой (например, с помощью шины, о которой будет ниже). Для систем на микросервисах все тоже самое.
8. Паттерны интеграции по типу обмена данными
Речь идет о таких паттернах, как обмен файлами, обмен через общую базу данных, удалённый вызов процедур, обмен сообщениями.
Вот в этой книге можно почитать про все эти паттерны (глава 2)
Самая простая (и исторически возникшая самой первой) — это интеграция по паттерну «общая база данных». Быстро, дешево, небезопасно. Не используйте этот тип интеграции, если у вас есть хоть какая-то альтернатива.
«Обмен файлами» — это простой способ передать файлы. Выкладываете отчет на FTP-сервер как на гугл-диск, а потом другая система его скачивает. Дешево, достаточно безопасно, но сложного взаимодействия не построить (попробуйте впятером работать с одной страницей в гугл-док, не общаясь другими каналами связи.
На основе «удалённый вызов процедур (RPC)» можно построить куда больше взаимодействий. Сейчас это самая популярная тема и по ней пару предложений написать недостаточно. Поэтому просто скажу, что из всего многообразия сейчас максимально популярны gRPC, REST, SOAP, GraphQL(формально не все из этого RPC, но вдаваться в детали мне лень). Если вам нужно построить интеграцию между двумя системами, то скорее всего это REST — вот и все, что стоит пока запомнить.
Паттерн «обмен сообщениями» становится необходим в одном из таких случаев, например
✓ крупный проект, в котором мы хотим иметь единую точку для управления интеграциями (помните п.5 «звезда»?)
✓ асинхронном взаимодействии
✓ больших потоках информации
✓ масштабировании
Вот тогда появляется сервисная шина предприятия или брокер. Это дорого, долго, но порой необходимо.
9. Паттерны по методу интеграции
Никогда не встречала, чтобы кто-то всерьез пользовался этой классификацией, но так как она существует, поделюсь с вами:
• Интеграция систем по данным (data-centric)
• Объектно-центрический (object-centric)
• Функционально-центрический (function-centric) подход
• Интеграция на основе единой понятийной модели предметной области (concept-centric).
Аналитик не выбирает паттерн интеграции (это задача архитектора), но ориентироваться в них весьма желательно.
Если вы столкнулись с новыми терминами в этой статье, выписывайте их в блокнотик и изучайте постепенно. Тема невероятно обширна, и за один присест ее не освоить.