Что такое интеграция в программировании

Интеграция программного обеспечения. Описание процесса от бизнес консультанта

Синерги́я (греч. συνεργία — сотрудничество, содействие, помощь, соучастие, сообщничество; от греч. σύν — вместе, греч. ἔργον — дело, труд, работа, (воз)действие) — суммирующий эффект взаимодействия двух или более факторов, характеризующийся тем, что их действие существенно превосходит эффект каждого отдельного компонента в виде их простой суммы[1], эмерджентность.

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

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

Интеграция – это очень важная часть работы по автоматизации бизнес-процессов, так как требуется она постоянно. В разных ситуациях возникает потребность оперативно обмениваться данными между различными конфигурациями 1С, между программными продуктами 1С и сайтом, между 1С и CAD системами, а также системами биллинга и т.д. Также достаточно часто требуется интегрировать между собой различные веб сервисы, например, интернет-магазин и CRM-систему. В общем, объединить работу различных подразделений компании и автоматизировать рабочий процесс без использования интеграции в большинстве случаев невозможно.

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

Википедия дает нам такое определение:

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

Я считаю, что в данном случае Вики абсолютно права. И дополнить ее можно только одним определением:

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

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

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

Например, если вы объединяете конфигурацию 1С: Торговля с 1С: Бухгалтерией, вам может потребоваться передать данные по всем продажам в бухгалтерию, а обратно получить сведения об оплате по этим продажам.

1. Определяем, какой продукт является источником, какой – приемником.
2. Сопоставляем объекты между источником и приемником.
3. Выбираем протокол для интеграции
4. Проводим постобработку данных (после переноса в одну из сторон)

Важно: при интеграции различных программных решений нужно хорошо понимать их функционал.

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

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

Выбираем источник и приемник

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

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

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

Сопоставление объектов (данных)

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

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

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

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

И здесь возникает проблема: требуются правила сопоставления.

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

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

В результате возникают самые разные казусы. Например, вы используете в качестве ключевого слова для поиска при сопоставлении слово «дилер». Клиент по каким-то причинам меняет его в программе-источнике на слово «дилеры». Казалось бы, мелочь! Но эта мелочь приведет к тому, что поиск в 1С перестанет работать.

1. Обязательно оставляю клиенту подробно описанные правила сопоставления и пояснения, какие параметры и данные менять недопустимо.
2. Предусматриваю варианты оповещения об ошибке. Т.е. не только фиксирую проблему в логе ошибок, но и оповещаю пользователя о сбое каким-то образом: при помощи SMS, письмом на email, всплывающими уведомлениями в 1С. А иногда всеми этими способами сразу.

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

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

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

1. При помощи смс, электронного письма, всплывающих уведомлений в 1С информацию о сбое должен получить человек, который занимается обработкой заказов.
2. Для контроля аналогичное уведомление (чаще всего на email) отправляется руководителю отдела или директору компании.
3. Обязательно ведется лог-файл ошибок для того, чтобы специалист смог просмотреть все подробности.

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

Обмен данными: писать самому или применять типовое решение?

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

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

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

В некоторых случаях, когда типовое решение действительно на 100% удовлетворяет потребности клиента, а скорость работы для него не критична, я также применяю готовые продукты. Например, при выгрузке номенклатуры и фотографий на сайт я не редко использую готовый обмен данными от Битрикс. Но только для выгрузки. Для работы с заказами я применяю самописный обмен.

Метод подключения: REST API, SOAP или прямое подключение к базе приемника

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

Вопросы клиентского доступа: почему не работает обмен?

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

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

• Ограничение доступа по IP.
• Ограничение прав пользователя.
• Ограничение по количеству обращений к источнику или приемнику

В случае работы с CRM-системой ограничения обычно обусловлены оплаченным пакетом услуг. Здесь достаточно оповестить клиента о наличии такого ограничения, и, при необходимости, помочь оплатить и настроить расширенный пакет.

1С идентификаторы и ошибки, связанные с ними

При интеграции с 1С очень часто ошибки обмена данных возникают из-за неверного выбора УИ (уникального идентификатора). Суть проблемы заключается в том, что объекты в 1С имеют два типа УИ: один уникален внутри выбранного типа объектов. Второй используется для работы со всей базой данных.

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

Еще одна проблема: нет возможности привязаться к уникальному идентификатору.

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

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

Я считаю хорошим тоном дублирование этого идентификатора в двух системах. Например, если я делаю выгрузку информации из CRM в 1С, то поле-идентификатор из CRM я копирую в систему 1С. В дальнейшем весь поиск и интеграция производится по этому полю быстро и просто.

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

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

Формат выгрузки

Для обмена данными используются самые разные форматы. Это может быть JSON, XML, CSV, TXT, прямой доступ к базе и т.д. У меня в этом вопросе нет каких-то определенных предпочтений. Я считаю, что здесь нужно исходить из рациональных требований проекта.

Постобработка

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

• Оповещение менеджера о поступлении заказа, например, при помощи sms
• Уведомление пользователей о поступлении новых заказов или другой актуальной информации по email
• Звуковой сигнал и/или всплывающее окно в 1С с напоминанием о том, что появились новые запросы или заявки

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

Например, это может быть уведомление клиента о том, что его заказ успешно прошел выгрузку и отправлен в обработку. И здесь также может быть использовано sms, электронное письмо или просто изменение статуса заказа в системе.

Тестирование интеграции

С моей точки зрения интеграция – это часть (иногда частный случай) внедрения программного обеспечения. И здесь, как и для любой другой работы по внедрению ПО, потребуется тестирование программистом, потом – лично консультантом, а также различные варианты тестирования вместе с пользователями. Об этом я подробно писал в статье Внедрение программного продукта. Особенности работы бизнес-консультанта. Часть III. Финальная.

Отличие односторонней и двусторонней интеграции

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

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

• интеграция
• интеграция приложений
• интеграция с 1с
• обмен данными

Что такое интеграция приложений?

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

В чем заключаются преимущества интеграции приложений?

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

Повышение производительности

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

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

Поддержание интеграции данных

Одно из самых серьезных препятствий на пути к достижению эффективности – обособленность данных, существующая в различных приложениях во всех типах систем. В рамках корпоративной архитектуры данных бывает крайне сложно объединить данные из разрозненных компонентов. Существуют универсальные корпоративные приложения, в частности системы планирования ресурсов предприятия (ERP), но для многих компаний они могут оказаться слишком дорогими или неэффективными.

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

Повышение привлекательности для клиентов

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

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

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

Снижение затрат на разработку

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

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

Какие существуют варианты использования интеграции приложений?

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

Внутренние приложения

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

Например, системы подбора персонала (HR) могут интегрироваться с платформами обучения сотрудников. А системы управления взаимоотношениями с клиентами (CRM) могут интегрироваться с механизмами коммуникации по электронной почте.

Внешние приложения

Общедоступное или внешнее приложение с интерфейсом интеграции приложений становится более удобным для клиентов или сообщества.

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

Устаревшие приложения

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

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

Каковы распространенные механизмы интеграции приложений?

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

API

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

API можно создавать различными стандартизованными способами. Например, можно выбрать, что использовать: gPRC или REST.

Шины событий

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

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

Протоколы и стандарты обмена сообщениями

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

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

Программное обеспечение для интеграции приложений без кода

Раньше для интеграции двух приложений через их API приходилось нанимать разработчика, который писал код решения. С помощью средств интеграции приложений без кода пользователи, не обладающие техническими знаниями, могут интегрировать два (и даже больше) программных приложения. Кроме того, они могут создавать собственные рабочие процессы взаимодействия программного обеспечения. Эти приложения служат платформой интеграции. Они используют популярные API приложений и отличаются простым в использовании пользовательским интерфейсом.

Как AWS может обеспечить интеграцию приложений?

Amazon Web Services (AWS) предлагает полностью управляемые сервисы интеграции приложений. С помощью интеграции приложений на базе AWS можно обеспечить взаимодействие между изолированными компонентами в микросервисах, распределенных системах и бессерверных приложениях.

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

Ниже представлены сервисы AWS, которые помогают интегрировать приложения.

• API шлюз Amazon помогает разработчикам создавать, публиковать, отслеживать и защищать API-интерфейсы для интеграции приложений.
• Amazon AppFlow – это платформа интеграции без кода, предназначенная для связи между программным обеспечением как услугой (SaaS) и сервисами AWS.
• AWS AppSync помогает разработчикам создавать API для доступа, редактирования и объединения данных из различных источников.
• Amazon EventBridge помогает разработчикам создавать управляемую корпоративную сервисную шину для архитектуры, управляемой событиями.
• Простой сервис уведомлений Amazon (Amazon SNS) – это сервис обмена сообщениями с высокой пропускной способностью для публикации и подписки, предназначенный для интеграции приложений в приложения (A2A).

Создайте аккаунт и начните интеграцию приложений на базе AWS уже сегодня.

Что такое интеграция приложений?

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

Определение интеграции приложений

Организации редко полагаются только на одно приложение, но управление несколькими приложениями вместе со всеми их данными может быть трудоемкой, утомительной и сложной работой. Например, типичная крупная организация может иметь тысячи различных типов приложений, таких как наборы приложения, которые покупают клиенты, приложения для локального выполнения или приложения, которые предлагаются в качестве услуги (программное обеспечение как услуга (SaaS)). Клиенты также создают свои собственные приложения в облаке. В результате управление этими различными типами приложений может оказаться сложной задачей, поскольку для них требуются администраторы и ресурсы.

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

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

Разница между интеграцией приложений и интеграцией данных

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

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

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

Интеграция программ и приложений

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

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

Способы интеграции приложений

Мало просто внедрить приложения в систему. Важна правильная интеграция программ между собой. Существует несколько способов взаимодействия приложений:

• Каждый с каждым. Такой тип интеграции работает с малым количеством программ и сегодня используется только в небольших организациях.
• На уровне пользовательских интерфейсов. Этот способ предполагает наличие интерфейсов типа HTML-scraping. Он идентифицирует HTML-компоненты данных одного приложения и позволяет работать с этими данными через другие программы сети.
• На уровне данных. Этот способ считается сегодня одним из самых популярных. Все данные сети хранятся на отдельных серверах. Доступ к этим данным осуществляется с помощью интегрированных в корпоративную сеть приложений.
• На уровне информационных ресурсов. Благодаря ECM-технологии происходит объединение всех приложений, в которых задействованы определенные процессы. Пользователи получают доступ к данным в виде конкретных команд.
• На уровне корпоративных приложений. Этот метод подразумевает пользование данными и приложениями с помощью исполняемого кода. Все данные делятся на компоненты, из которых формируется программное ядро. Его и используют все приложения, интегрированные в систему.
• Web-сервисы. Этой интеграцией сегодня пользуется большинство. Суть метода в предоставлении доступа к программам и данным, которые хранятся на одном сервере.
• С помощью промежуточного ПО. Многие организации не могут отказаться от уже налаженной рабочей сети. Интеграция новых приложений может нарушить рабочий процесс. В этом случае формируется специальный интерфейс, который становится своеобразным мостом между рабочей системой предприятия и новыми необходимыми приложениями.

Методы интеграции

Технически интеграция программ осуществляется 2 способами:

1. точка-точка;
2. сервисная шина.

Метод «точка-точка»

Если в систему планируется интегрировать одно или два приложения, можно использовать метод «точка-точка». Таким образом программы просто объединяются. Ключевой момент при таком методе интеграции – четкое понимание того, как именно системы будут обмениваться данными. Для интегрируемых приложений просто создается общий модуль, через который и будут взаимодействовать программы. Интегрируются программы путем их записи в общую базу данных приложений или через API.

Сервисная шина

Сервисная шина – программное обеспечение, через которое происходит обмен данными между приложениями. У этого метода интеграции существенно больше преимуществ перед «точка-точка»:

• практические неограниченные возможности масштабирования системы;
• гибкость;
• централизация контроля;
• возможность интеграции с другими системами.

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

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

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

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

Взаимодействие интегрированных приложений

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

1. Обмен данными. Существует несколько форматов обмена. Один из самых распространенных – CSV. То есть большинство данных в системе выгружается именно в таком формате, который поддерживают все интегрированные приложения. Если же не все элементы системы готовы распознавать определенный формат, устанавливаются дополнительные утилиты, позволяющие конвертировать данные другого типа в общепринятый.
2. База данных. Здесь все просто – все элементы одной системы при работе используют одну базу данных. Такое взаимодействие с одной стороны кажется максимально простым и удобным. С другой же – могут возникнуть сложности с модернизацией уже внедренного ПО или дополнительной интеграцией приложений. Поэтому такой тип взаимодействия чаще используется для программ одного производителя.
3. Удаленный вызов. Такой тип взаимодействия известен давно и используется не только для приложений. Когда одному элементу необходимы какие-то данные от другого, он просто отправляет ему командный запрос. Однако, чтобы взаимодействие проходило безупречно, важно следить за тем, чтобы все приложения работали исправно и были включены в процесс в конкретный момент времени.
4. Асинхронный обмен. Этот метод считается наиболее продуктивным. Он не требует моментального взаимодействия всех программ внутри системы. Если одному приложению необходимы какие-то данные или действия от другого, первое просто посылает второму запрос. От отвечающей программы не требуется моментальной реакции на полученное сообщение, но она гарантированно его получит.

Успешная интеграция программного обеспечения во многом зависит от выбранного метода взаимодействия приложений друг с другом. Именно поэтому следует особое внимание уделить этому вопросу. Кроме этого неверно подобранный способ взаимодействия очень сложно перенастроить в уже работающей системе.

Выбор приложений и технологий для интеграции

Многие крупные компании предпочитают потратиться на разработку собственного программного обеспечения. Это позволяет охватить все поставленные перед интеграцией задачи и дополнительно обезопасить бизнес от несанкционированного доступа. Вместе с тем наиболее популярна сегодня SaaS-интеграция – услуги сторонних организаций по предоставлению ПО.

Современные поставщики программного обеспечения готовы предоставить приложения для любых целей и в любом объеме. Это делает SaaS-интеграцию востребованной как у представителей крупного бизнеса, так и для небольших предприятий. SaaS – облачные приложения. То есть нет необходимости внедрять программы в сеть, используя при этом ее полезное пространство.

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

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

При выборе подходящего онлайн-сервиса следует обратить внимание на следующие критерии:

• Платформы, с которыми можно работать с помощью данного сервиса. Например, небольшим предприятиям будет достаточно интеграции простой CRM для взаимодействия с клиентами. Организации более высокого уровня бизнеса захотят дополнительно подключить почтовые клиенты, телефонию, платёжные сервисы и т. д.
• Набор инструментов. Если одним будет достаточно просто иметь доступ к данным, то другим необходимы инструменты для анализа этих данных.
• Удобство пользования. Понятный интерфейс и множество автоматизированных процессов значительно упрощают работу с платформой и экономят время.
• Безопасность. Всегда важно быть уверенным в том, что данные находятся под защитой. Особенно, когда речь идет об онлайн-сервисах. Интеграция единого входа, шифрование, управление доступом, надежность связи – лишь несколько важных аспектов безопасного хранения данных.
• Своевременная техническая поддержка позволяет оперативно устранять проблемы и решать вопросы, что важно как для любого типа бизнеса.
• Стоимость и пробный доступ. Цена всегда имеет значение, а бесплатный пробный период позволит утвердиться в принятом решении.

Для интеграции приложений чаще всего используют 2 технологии.

RPA

Robotic process automation – технология, позволяющая управлять процессами интеграции с помощью программного робота. Главное преимущество RPA – скорость. Кроме того, использование этой технологии существенно дешевле остальных.

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

API

Application Programming Interface – технология, в процессе которой создается определенный пользовательский интерфейс для конкретных задач. В данном случае интерфейс необходим для обеспечения взаимодействия интегрированных приложений. Главное преимущество API перед другими технологиями – более высокая скорость. Среднее время одной операции менее секунды.

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

Независимо от преимуществ и недостатков каждой из технологий выбор стоит делать с учетом совершенно других параметров. Например, в крупных компаниях вероятнее всего есть огромное количество необходимых, но устаревших приложений. Синхронизировать их через API и интегрировать может оказаться большой проблемой. Придется создать не одну сотню новых кодов, что повлечет за собой не только существенную нагрузку на ИТ-отдел, но и высокую вероятность критических ошибок. Именно поэтому для наследуемых приложений предпочтительнее RPA-технология.

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

Возможные проблемы интеграции приложений

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

• Недостаточная поддержка и инициатива со стороны руководства. Зачастую инициатором внедрения дополнительного ПО являются не руководящие чины, а рядовые сотрудники или ИТ-отдел. Не осознавая в полной мере преимуществ интеграции программного обеспечения, руководство выбирает ПО, исходя из его цены или решения отдельных задач. В результате, например, внедряются отдельные элементы, которые не могут полноценно работать без других приложений и цель интеграции оказывается недостигнутой. Именно поэтому важно донести до принимающих решения лиц всю важность планируемой интеграции, начиная от самых мелких преимуществ до решения крупных задач предприятия.
• Ошибочная стратегия. Очень многие, особенно некомпетентные в вопросах ИТ, руководители рассматривают интеграцию дополнительных приложений как дополнительные инструменты. В итоге внедряются отдельные приложения, которые работают автономно. Важно понимать, что итогом интеграции должна стать работающая и выполняющая общие задачи система, а не набор нескольких приложений, которые будут работать отдельно друг от друга.
• Недостаточный контроль. Интеграция программного обеспечения – это не только внедрение приложений. Важно уделить достаточно внимания обслуживанию нового ПО, мониторингу и оценке эффективности работы как отдельных элементов, так и всей системы в общем, обучению и контролю сотрудников, которые будут задействованы в работе с новыми приложениями.

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

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

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