Интеграция приложений на разных уровнях
Существует четыре различных уровня методов интеграции приложений. На уровне представления интеграция может быть достигнута путем представления нескольких различных приложений в виде единого представления приложения с общим пользовательским интерфейсом (UI). Этот старый метод интеграции также называется «очисткой экрана», в котором используется технология промежуточного программного обеспечения для сбора информации, вводимой пользователями на веб-страницах или других пользовательских интерфейсах. В прошлом люди использовали методы интеграции на уровне презентации для интеграции приложений, которые невозможно было соединить. Но сегодня технологии интеграции приложений развиваются и становятся более сложными, что делает этот подход менее распространенным.
Посредством интеграции бизнес-процессов компании сопоставляют логические процессы, необходимые для ведения бизнеса, со своими ИТ-активами, которые обычно расположены в различных частях внутренней ИТ-среды компании, а с развитием облачных вычислений все больше и больше размещается в облаке. Идентифицируя различные операции в бизнес-процессе и позиционируя свои ИТ-активы как метасистему (систему о системе), предприятия могут использовать методы интеграции приложений, чтобы определить, как каждое приложение должно взаимодействовать для достижения ключевого Автоматизация бизнес-процессов ускоряет доставку товаров и услуг для клиентов, снижает вероятность человеческой ошибки и снижает эксплуатационные расходы.
Помимо интеграции бизнес-процессов, для интеграции приложений также необходимы возможности интеграции данных. Если приложение не может обмениваться данными из других приложений и точно понимать их, могут возникнуть несоответствия, которые снизят эффективность бизнес-процессов. Возможности интеграции данных могут быть достигнуты одним из следующих двух методов: 1) написать код, чтобы каждое приложение понимало данные из других приложений на предприятии, 2) использовать приложения отправителя и получателя, которые могут анализировать Единый формат обмена данными. Последний метод лучше, чем первый, поскольку он более масштабируемый по мере роста размера и сложности корпоративных систем. Согласно двум вышеупомянутым методам, доступ к данным, анализ и преобразование являются важными возможностями, которые могут успешно обеспечить интеграцию данных. В традиционной технологической системе SOA формат данных XML обычно используется как унифицированный формат обмена и обработки данных, описанный выше. На платформе управления API нового поколения и интеграции приложений компании Lingchang Technology мы применяем более легкий и эффективный формат данных JSON, который легко анализировать, обрабатывать и преобразовывать, и можем использовать различные эффективные инструменты обработки данных в богатой экосистеме JavaScript для непосредственного Манипуляция данными помогает эффективно завершить интеграцию данных между различными приложениями.
Ниже уровня интеграции бизнес-процессов и данных находится интеграция уровня связи. Это относится к тому, как различные приложения внутри предприятия взаимодействуют друг с другом с помощью таких методов, как передача файлов, методы запроса / возврата или обмен сообщениями. Во многих случаях приложения не предназначены для взаимодействия друг с другом, поэтому на уровне связи необходимо применять технологии, которые могут помочь реализовать обмен данными между приложениями. Эти технологии включают интерфейсы прикладного программирования (API), определяющие способ вызова приложений, а также носители, которые действуют как соединители между приложениями
На уровне связи также важно учитывать архитектуру взаимодействия между приложениями. Для реализации архитектуры взаимодействия приложений на уровне связи можно использовать такие технологии, как двухточечная модель, модель концентратора и звезды или служебная шина предприятия (ESB)
Российская специфика
По данным Merrill Lynch, к 2002 году рынок корпоративных
информационных порталов достигнет 14,8 млрд. долл. Аналитики Meta Group
считают, что к 2002 году 70% компаний из списка Global 2000 (крупнейшие
компании мира по величине оборота) внедрят или начнут внедрять у себя
корпоративные порталы. К 2003 году 60% компаний из Fortune 500 будут
использовать корпоративный портал в качестве инструмента поддержки принятия
решений, совершенствования информационных потоков и развития электронной
коммерции типа B2B.
Как соотносятся ситуации на рынке Internet-приложений на
Западе и в России? Подавляющее большинство отечественных организаций пока не
может позволить себе внедрять дорогостоящие решения. Если на Западе
развертывание системы ERP на среднем предприятии стоит порядка 1 млн. долл.,
российские компании, даже достаточно успешные, не готовы тратить на интеграцию
данных и приложений более 100-150 тыс. долл. При этом требования к срокам
внедрения у отечественных компаний выше; здесь гораздо реже разрабатываются
долгосрочные, стратегические планы развития информационной системы. Еще одна
особенность отечественных компаний — широкое использование приложений,
написанных собственными силами.
Еще сильнее отличаются задачи, стоящие перед ИТ-отделами.
Широкое применение информационных технологий в корпоративном секторе на Западе
началось еще в 60-е годы. В результате, компании накопили огромные массивы
информации, связанной с их хозяйственной деятельностью, а также множество
приложений, в том числе и для мэйнфреймов; все это вынуждает искать пути
эффективного использования имеющихся ресурсов. В России к уже перечисленным
проблемам добавляется еще и разрозненность корпоративных приложений, которую
часто характеризуют выражением «островки информатизации». В некоторых
подразделениях компании могут использоваться бизнес-приложения, в других их
нет; более того, в различных подразделениях одной организации могут применяться
разные приложения. Это приводит к тому, что в компании может просто не
существовать сводных показателей о ее деятельности.
В России решения в области Web-интеграции могут быть
интересны среднему и крупному бизнесу, с уже внедренными и работающими
приложениями CRM, ERP и им подобными. Таким компаниям необходима единая
платформа для ведения электронного бизнеса, взаимодействия между сотрудниками и
отдельными подразделениями внутри компании, а также с заказчиками, каналами
сбыта, партнерами и поставщиками, причем при сохранении уже имеющейся
информационной инфраструктуры.
Понимается под Web-интеграцией определенная форма, методы обработки
и представления информационных ресурсов организации при помощи Web-технологий
Семь принципов Web-интеграции
1. Интеграция данных и приложений (финансовые, системы CRM,
ERP и унаследованные) в корпоративный портал.
2. Визуализация информации при помощи Web-браузера,
благодаря чему исчезает необходимость в установке и поддержке «тяжелых»
клиентских приложений.
3. Гибкость, масштабируемость и открытость создаваемых
решений, которые достигаются благодаря использованию XML/XSL и Java; быстрое и
легкое внедрение, оптимизация и персонификация.
4. Единый и настраиваемый интерфейс работы с данными и
приложениями, возможный благодаря созданию корпоративного портала; возможность
входа в портал из различных систем, в том числе территориально удаленных.
5. Реализация системы на основе технологий Java и XML, что
обеспечивает переносимость и независимость приложений от операционных систем
сервера и клиента. Хранение и передача данных происходит с помощью языка XML,
специально созданного для организации взаимодействия с различными приложениями.
Формат данных в XML не зависит от способа его дальнейшей визуализации — за это
отвечают хранимые отдельно файлы таблицы стилей XSL, которые преобразуют файлы
XML для их представления в виде Web-страницы.
6. Создание в процессе интеграции пользовательских
Web-интерфейсов к корпоративным приложениям. При дальнейшем развитии системы
обеспечивается не только доступ для чтения данных, но и полноценный
документооборот.
7. Безопасность и защита информации обеспечиваются единой
точкой входа, каталога и разделением прав доступа. База описаний пользователей
также хранится в едином кросс-платформенном каталоге, что создает
унифицированную систему безопасности для всех приложений.
Зачем нужна интеграция API?
Возможность подключения к API помогает приложениям обмениваться данными и взаимодействовать друг с другом без вмешательства человека. Вы обеспечиваете связь между двумя веб-инструментами или приложениями через их API. Это позволяет организациям автоматизировать системы, улучшить беспрепятственный обмен данными и интегрировать текущие приложения.
Предприятия не могут игнорировать важность интеграции API в современном мире. После стремительного роста количества облачных продуктов и приложений организациям необходимо создать подключенную систему, в которой данные будут автоматически передаваться между различными программными инструментами
Интеграция API делает это возможным, поскольку позволяет обмениваться данными процессов и предприятия между приложениями в данной экосистеме.
Это открывает новый уровень гибкости предоставления информации и услуг. Это также упрощает встраивание контента с разных сайтов и приложений. API действует как интерфейс, позволяющий интегрировать два приложения.
Для чего нужен корпоративный портал
Внедрение и использование корпоративного информационного
портала дает компании целый ряд преимуществ:
Повышение производительности. Легкий доступ к
персонализированной информации из корпоративных и внешних источников повышает
производительность труда сотрудников. На базе портала возможна организация
документооборота — получение данных из приложений и их ввод, создание и
редактирование документов в едином Web-интерфейсе.
Повышение конкурентоспособности. Поскольку портал
представляет собой единую точку входа в корпоративную информационную систему и
позволяет получать весь объем необходимой информации, он дает возможность
снизить затраты и повысить эффективность работы всех систем организации.
Web-интеграция открывает новые возможности анализа деловой информации,
сегментирования рынка и позиционирования, планирования и прогнозирования,
выполнения ряда иных функций.
Улучшение корпоративного взаимодействия. Портал
играет роль центрального информационного ресурса для сотрудников компании,
заказчиков, руководства, поставщиков, дистрибьюторов, партнеров и акционеров.
Своевременный обмен необходимой информацией обеспечивает более тесную связь
между всеми группами сотрудников и подразделениями. В то время как большинство
существующих на рынке систем документооборота позволяет только отслеживать
процесс прохождения документов внутри организации, корпоративный портал
обеспечивает и ряд других функций: хранение всех версий документа, определение
прав доступа ему, оповещение пользователей об изменении существующего документа
или появлении нового, публикация документов.
Повышение отдачи от инвестиций. Портал — это
интегрированное приложение, которое можно достаточно быстро внедрить, легко
поддерживать, затрачивая при этом сравнительно скромные ресурсы по сравнению с
системами со сходными функциями, но построенными на основе других концепций.
Все это снижает издержки и повышает отдачу от вложений в корпоративную
информационную систему
Использование «тонкого клиента» — браузера — для
визуализации информации позволяет, с одной стороны, экономить на обучении
персонала, а с другой, что особенно важно, дает возможность не устанавливать
клиентские приложения на множестве компьютеров. Сокращение затрат на
приобретение и обслуживание клиентского ПО и оборудования — один из основных
ресурсов снижения издержек при использовании корпоративного портала
Важно
упомянуть и о минимизации затрат на аренду Internet-канала за счет того, что
большая часть информации уже размещена в портале.
Единая платформа для ведения электронного бизнеса. Внедрение
корпоративного портала и обеспечение доступа к нему внешних пользователей
способствует укреплению деловых связей с заказчиками, партнерами, поставщиками
и повышает качество обслуживания заказчиков и партнеров за счет предоставления
им дополнительных возможностей и услуг.
Стили взаимодействия
В приложениях на базе микросервисов можно использовать разные стили внутреннего взаимодействия модулей. Например:
-
если взаимодействие выполняется за пределами узла Docker или кластера микросервиса, то лучше подойдет механизм синхронных запросов и ответов;
-
если взаимодействие выполняется в пределах узла Docker или кластера, подойдет комбинированный формат взаимодействия или асинхронное взаимодействие на базе сообщений (например, AMQP).
Кроме того, можно использовать и нестандартный комбинированный метод, но такой вариант подойдет только для внутреннего взаимодействия на узле или кластере — сервисы с таким форматом лучше не публиковать.
Операция «запрос-ответ» с использованием HTTP и REST
При использовании взаимодействия типа «запрос-ответ», клиентский запрос поступает к службе, которая обрабатывает его и возвращает ответ. Такой тип взаимодействия — лучший вариант для запроса данных от клиентских приложений, поэтому он чаще применяется в архитектуре микросервисов.
Пример использования взаимодействия типа «запрос-ответ». Источник
Один из распространенных стилей архитектуры при подобном типе взаимодействия — REST. Подход основан на HTTP-протоколе и позволяет работать с HTTP-командами. Кроме того, сервисы REST подходят для разработки сервисов веб-API ASP.NET Core.
Push-уведомления и связь по протоколу HTTP
Еще один метод — асинхронное взаимодействие в формате «один ко многим» в режиме реального времени с платформами высшего уровня.
При таком варианте взаимодействия серверный код способен автономно отправлять доступные данные клиентам, а не дожидаться, пока он их запросит.
Пример асинхронного взаимодействия в формате «один ко многим». Источник
Один из популярный инструментов для выстраивания подобного взаимодействия для быстрой передачи данных с сервера клиентам — SignalR. При этом обработку выполняет протокол WebSockets с множеством подключенных WebSockets на стороне клиентов (один клиент — один WebSockets). Например, такой метод применяют в спортивных приложениях, когда нужно всем пользователям передать данные об изменении счета в матче.
Переходим к тестированию
На этом этапе разработанный функционал передаётся в команду тестирования
Важно помнить, что тестировать интеграционное взаимодействие не легче, чем его проектировать и разрабатывать
Аналитик должен качественно ориентироваться в бизнес процессах, системе и функционале. Поскольку аналитик лучше других участников команды разбирается в требованиях заказчика, то на этапе проектирования необходимо уделить время описанию тестовых сценариев.
Говоря о тестировании интеграционного взаимодействия, можно выделить несколько этапов:
Тестирование на среде разработки (DEV)Важно определить способ тестирования. Это может быть моделирование ответов от внешней системы.
Тестирование на интеграционной среде (QF,PL etc.)Для тестирования на интеграционном стенде рекомендуется подготовить документ, описывающий сценарии, которые необходимо пройти совместно со всеми системами, участвующими в бизнес процессе
Необходимо определить сроки, ответственных и настроить качественную коммуникацию. Все документы и зоны ответственности должны быть четко зафиксированы со всеми заинтересованными лицами.
Nota bene!
Фактически аналитик никаким образом не контролирует работу смежной системы. Он должен публично фиксировать все договорённости, согласования и сроки на каждом этапе, в котором требуется участие смежной системы или заказчика.
Расширение интеграционного сценария
Уровень интеграции
обеспечивает централизацию ключевых функций, совместно используемых
приложениями, а это открывает более широкие возможности, чем интеграция
пользовательских интерфейсов. Средства интеграции данных, информации и
процессов способствуют сокращению расходов на интеграцию (или даже разработку)
каждого последующего приложения. Как показывает опыт, применение уровня интеграции
со временем приносит все большую экономию и, кроме того, позволяет создавать
совершенно новые приложения, выходящие за рамки первоначального сценария
интеграции.
|
Инфраструктуры для |
Например, если
системы биллинга, обработки жалоб клиентов (troubleticketing), управления
клиентами и ERP интегрированы пользовательским интерфейсом CRM, то, поскольку
эти системы уже связаны, вы можете создавать простые решения для самопомощи через
Интернет (Web self-help solutions), а в дальнейшем расширять их до систем
заказов через Интернет и решений для канальной дистрибуции между предприятиями
(B2B channel). Если вы приобретете какое-то новое приложение вроде системы
управления сетью поставщиков, интеграция этого приложения в такую среду все
равно окажется нетривиальным процессом. Однако эта задача заметно упростится
при наличии уровня интеграции, так как интегрировать данные будет легче за счет
того, что единый набор известных интерфейсов включается в уровень интеграции, а
не в каждое приложение.
Рабочие
процессы — основная часть любого решения в области интеграции. Они используются
в управлении бизнес-процессами и играют центральную роль в выполнении
процессов, обеспечивающих связывание систем. Это две разные задачи, но обе
прекрасно решаются с применением средств управления рабочими процессами.
Рабочий процесс, применяемый для интеграции систем, может включать такие операции,
как получение данных от каждой системы и их агрегацию, проверка информации, вводимой
пользователями, и обновление информации в системах при ее изменении или при
вводе новых данных.
Применение
средств управления рабочими процессами — идеальный
способ
выполнения таких операций, гораздо более эффективный, чем написание
соответствующего кода. Эти средства могут принести существенные выгоды бизнесу
при использовании уровня интеграции, особенно если учесть, что:
● работа с несколькими системами естественным
образом строится на основе процессов, при этом задачи выполняются поэтапно, и
на каждом этапе поддерживаются точки принятия решений, ветвление по условию и
другие базовые возможности рабочих процессов;
● рабочие процессы, связанные с интеграцией
систем, выполняются централизованно и размещаются между приложениями, поэтому
на них чаще влияют изменения в интеграционной среде (при условии, что каждое
изменение в каждой системе отражается на уровне интеграции). Средства
управления рабочими процессами делают их понятными более широкому кругу людей
(а не только разработчикам), так как рабочие процессы представляются в графическом
виде. Эти процессы легче и быстрее модифицировать, их отладка проще по
сравнению с отладкой кода;
● схематическое представление, формируемое
средствами управления рабочими процессами, облегчает понимание
бизнес-процессов, и их модификацию можно разрешить не только группе
разработчиков, но даже бизнес-аналитикам и основным бизнес-пользователям.
Асинхронная интеграция как способ обеспечения автономности микросервисов
При создании приложений с микросервисной архитектурой важно правильно реализовать способ интеграции — в идеале, чтобы внутренние микросервисы взаимодействовали между собой минимально, а взаимодействие было асинхронным.
Следует понимать, что использование синхронного взаимодействие между несколькими микросервисами не лучший вариант — каждый микросервис должен быть автономным и доступным клиенту, даже если другие сервисы отключены или недоступны. Если это не реализовать, архитектура будет неустойчива к сбоям — при недоступности одного сервиса будет недоступно все приложение.
Кроме того, наличие зависимостей HTTP между микросервисами влияет не только на их автономность, но и на быстродействие — чем меньше синхронных зависимостей, тем выше скорость отклика в клиентском приложении.
Паттерны взаимодействия между микросервисами. Источник
Преимущество асинхронного типа связи в том, что запрос клиента обрабатывается сразу, в то время, как при синхронной модели вся обработка выполняется одновременно. Поэтому синхронный способ взаимодействия лучше не использовать в рамках исходной операции «запрос-ответ».
Асинхронный тип связи можно использовать, даже если исходному микросервису нужны данные из другого микросервиса. В такой ситуации отказаться от синхронных запросов можно, делая реплики данных в базу данных — это допустимо.
Исходя из этого, главное что нужно понимать — не используйте синхронные зависимости между микросервисами.
Портал и управляемость компании
Исследование, проведенное компанией RewardsPlus, показало,
что организации начали инвестировать большие средства в создание корпоративных
порталов для улучшения внутри корпоративных коммуникаций, аутсорсинга трудовых
ресурсов, а также для социализации сотрудников компании и укрепления у них
чувства самоидентификации с ней. По мнению аналитиков, портал должен не только
обеспечивать выполнение корпоративных функций, но и помочь сотрудникам
сбалансировать свои производственные обязанности и личные потребности.
Руководители должны иметь в виду, что, поскольку рабочее место становится все
более виртуальным, корпоративный портал будет основным средством общения внутри
компании. Для руководителей портал — это канал взаимодействия с сотрудниками,
ресурс укрепления организационной морали; для сотрудников — лучший способ
решать повседневные проблемы.
В чем состоят резервы повышения управляемости организации
при внедрении корпоративного информационного портала? Как известно,
деятельность менеджеров любого уровня отличает необходимость принимать решения
в условиях недостатка информации или при наличии противоречивых данных. Умение
работать в условиях неопределенности, принимать правильные решения всегда может
считаться одним из главных критериев эффективности деятельности управленца. С
точки зрения налаживания коммуникаций корпоративный портал решает ряд задач:
● прохождение
информационных потоков между подразделениями;
● устранение
различия в «языке» между отдельными подразделениями и отдельными сотрудниками
благодаря использованию единых форматов распространения информации;
● фильтрация
потоков информации благодаря возможности настраивать профили пользователя;
● минимизация
искажений информации при ее прохождении по многочисленным вертикальным и
горизонтальным каналам внутри организации;
● упрощение
процесса обучения сотрудников;
● обеспечение
своевременного доступа к корпоративной информации.
Все это позволяет рассматривать корпоративный портал как
систему управления знаниями, охватывающую большую часть корпоративной
информации.
Переходим к разработке
В итоге проведенного анализа формируется ряд проектных документов, по которым будет производиться разработка
Первое и самое важное требование, выдвигаемое к документации – четкое описание цели. Или, другими словами – постановка задачи
По мнению аналитика, все может быть описано предельно подробно, но для разработчика постановка была не очевидна. Подобные проблемы «перевода» возникают при недостаточной коммуникации с разработчиком.
На этапе разработки аналитик активно консультирует команду. Как бы полно не была описана документация и постановка задачи, со стороны разработки всегда возникнет масса вопросов, которые они могут просто не задать, посчитав свое понимание единственным и верным. Также аналитик не прекращает коммуникации с заказчиком, не стоит забывать об изменчивости требований.
Интеграция приложений SimpleOne
Продукты SimpleOne легко интегрируются с любыми программами поддержки коллективной работы, ERP-системами и средами виртуализации, программным обеспечением для аутентификации и инструментами повышения производительности.
В SimpleOne для интеграции используется REST API, которое позволяет настраивать как входящее соединение, так и исходящее. Для этого есть два способа.
RESTful API используется для уведомлений в корпоративных приложениях о событиях во внутренней системе. Во внешней системе создаётся бот, который может отправлять сообщения. Во внутренней системе также необходимо провести настройку, определить условия, при которых бот уведомляет пользователей о каких-либо событиях.
Например, вот так могут выглядеть оповещения об инцидентах в Slack:
Пример интеграции со Slack
JavaScript API используется для настройки определённого поведения на какие-то события во внешней системе. Например, система мониторинга сообщает, что перестал быть доступен инстанс. Автоматически система отправляет запрос на сервер, и создаётся уведомление о проблеме с сервером.
Возможность интеграции корпоративных приложений — важная особенность, которая должна присутствовать в любой современной ESM-системе. SimpleOne может выступать единой сервисной шиной для корпоративных систем, поддерживающих REST API, в этом случае SimpleOne будет являться единой точкой агрегации информации из различных корпоративных систем, предоставляя удобные инструменты ее анализа.
Свежее по теме
Счетная палата подвела итоги цифровизации школ за пять лет
Factory5 стала официальным партнером группы «Борлас»
«Ростелеком» помог «ТЭК СПб» автоматизировать сбор показаний с узлов учета энергоресурсов
Ленэнерго заплатит за систему финансов больше полумиллиарда рублей
Интересные ссылки
- Softline Ecommerce разработал для «Лаборатории Касперского» инструмент автоматизации продления заказов
- ICL Services разработали бота для классификации электронных писем
- ВТБ Лизинг провел автоматизацию контакт-центра для повышения качества обслуживания клиентов
- Эксперты компании «Системы компьютерного зрения» расскажут об автоматизации подсчета древесины на конференции WoodTech
- Softline помогла компании ОМА повысить качество внутренних и внешних коммуникаций
Техническая документация
Какой бы не была задача: создание новой интеграции, доработка или реинжениринг, все начинается с документации (ТЗ, ЧТЗ, СТП, API). И писать ее именно вам. Главная задача документации – максимально точно описать то, что хотят от итогового функционала.
Тут можно выделить сложность, связанную с массивностью требований. Например при описании знакомой системы будет четче определен набор требований (близкий и понятный вашему глазу и сердцу). А вот в случае с интеграцией потребуется работать с незнакомой системой, которую создали другие специалисты, по которой чаще нет документации, а сотрудники давно сменились. Что же, тогда может потребоваться анализировать все с нуля, проводить изучение процесса, выявлять источник данных и т.д.
