Что такое интеграция в программировании
Интеграцией называется элемент процесса разработки программного обеспечения, в ходе которого отдельные компоненты программного продукта объединяются в единое целое. Интеграция осуществляется на нескольких уровнях и этапах реализации:
В RUP применяется пошаговый подход к интеграции программного обеспечения. Пошаговая интеграция заключается в том, что код разрабатывается и тестируется малыми компонентами, которые затем постепенно собираются в единое целое.
Противоположный подход к интеграции называется поэтапной интеграцией. Принцип поэтапной интеграции заключается в одновременной интеграции нескольких (новых и измененных) компонентов. Основной недостаток поэтапной интеграции заключается в том, что в нее вовлечено много переменных, и это затрудняет поиск ошибок. Это происходит в первую очередь за счет того, что ошибка может находиться в любом из новых компонентов, во взаимодействии новых компонентов с ярдом системы и во взаимодействии между новыми компонентами.
Преимущества пошаговой интеграции:
Важно понимать, что интеграция осуществляется, по меньшей мере, один раз в каждой итерации. План итерации должен содержать сведения о том, какие варианты использования должны быть спроектированы и какие классы должны быть реализованы. Основное внимание в стратегии интеграции должно уделяться последовательности реализации и объединения классов.
© Copyright IBM Corp. 1987, 2006. Все права защищены..
Интеграция программного обеспечения. Описание процесса от бизнес консультанта
Синерги́я (греч. συνεργία — сотрудничество, содействие, помощь, соучастие, сообщничество; от греч. σύν — вместе, греч. ἔργον — дело, труд, работа, (воз)действие) — суммирующий эффект взаимодействия двух или более факторов, характеризующийся тем, что их действие существенно превосходит эффект каждого отдельного компонента в виде их простой суммы[1], эмерджентность. Википедия.
В процессе работы бизнес консультантом, для увеличения эффективности работы систем предприятия, я почти всегда предлагаю провести интеграцию между различным ПО заказчика. Потому что интегрировав различные системы возможно добиться эффекта синергии. Мне постоянно приходится сталкиваться с одними и теми же проблемами и решениями многие из которых приходится пояснять в каждом новом проекте заказчикам, некоторые – программистам. А потому я считаю, что о процессе интеграции стоит поговорить подробно. В большинстве примеров я выбрал различные случаи интеграции 1С и CRM, так как сегодня именно этот вопрос, как показывает моя практика, наиболее актуален. Хотя данная статья подойдет при интеграции практически любого программного обеспечения. Итак начнем. Интеграция – это очень важная часть работы по автоматизации бизнес-процессов, так как требуется она постоянно. В разных ситуациях возникает потребность оперативно обмениваться данными между различными конфигурациями 1С, между программными продуктами 1С и сайтом, между 1С и CAD системами, а также системами биллинга и т.д. Также достаточно часто требуется интегрировать между собой различные веб сервисы, например, интернет-магазин и CRM-систему. В общем, объединить работу различных подразделений компании и автоматизировать рабочий процесс без использования интеграции в большинстве случаев невозможно.
Что такое интеграция?
Википедия дает нам такое определение:
Интегра́ция (от лат. integratio — «соединение») — процесс объединения частей в целое. В зависимости от контекста может подразумеваться: Веб-интеграция — объединение разнородных веб-приложений и систем в единую среду на базе веб. Интеграция данных — объединение данных, находящихся в различных источниках и предоставление данных пользователям в унифицированном виде.
Я считаю, что в данном случае Вики абсолютно права. И дополнить ее можно только одним определением: Интеграция программных систем и продуктов — это обмен данными между системами с возможной последующей их обработкой. Смысл интеграции заключается в том, чтобы данные, которые пользователь вводит в одну систему, автоматически переносились в другую. Продукт, в который пользователь вводит данные, называется источник. А получатель данных, соответственно, приемник. Достаточно часто данные переносят в обе стороны, например, после преобразования в системе-приемнике результаты отправляются обратно в источник. А потому интеграция бывает как односторонней, так и двухсторонней. Например, если вы объединяете конфигурацию 1С: Торговля с 1С: Бухгалтерией, вам может потребоваться передать данные по всем продажам в бухгалтерию, а обратно получить сведения об оплате по этим продажам. Лично я делю процесс интеграции на такие этапы:
Я всегда придерживаюсь этой последовательности при планировании работ по интеграции. Это помогает работать системно, не упустить ни одного важного момента и провести интеграцию таким образом, чтобы клиенту было удобно работать в объединенной системе. Важно: при интеграции различных программных решений нужно хорошо понимать их функционал. Когда-то я и сам совершал такую ошибку, и брался за интеграцию программных продуктов, которые я недостаточно хорошо знал. А потому могу сказать точно: изучать программный продукт в процессе интеграции – это не совсем корректно. При таком подходе чаще всего возникает множество ошибок и проблем, например, перенос не тех данных или сбои в работе. Рекомендую сначала хорошо изучить программный продукт, понять, что он может, каким образом в нем реализованы те или иные функции, и только потом заниматься интеграцией. В принципе, в процессе интеграции вам может потребоваться и более сложный обмен, и придется вводить, например, трех- или четырехстороннюю интеграцию. Но, по сути, эти процессы ничем не отличаются от обычного одно- или двухстороннего процесса. А потому я буду говорить об интеграции односторонней. А в конце скажу пару слов об особенностях двухсторонней. Все остальные направления вы всегда сможете выстроить по аналогии.
Выбираем источник и приемник
Для каждого случая интеграции данных важно четко определить, какая система будет источником, а какая – приемником. Например, у вас есть система CRM и программа 1С: Торговля. В обеих системах существует такое понятие, как контактное лицо. В принципе, вводить его вы можете и с одной, и с другой стороны. В данном случае, очевидно, что источником стоит назначить CRM, так как этого требует логика работы с любой CRM-системой. Аналогично и в других случаях. Нужно понимать, в какой системе пользователь будет вводить данные, а какая станет получателем этих данных через интеграцию. Это обязательно согласовывается с клиентом (пользователем), кроме случаев, когда источник очевиден. при этом обязательно нужно поставить в известность клиента, что данные определенного типа следует вводить именно через систему-источник.
Сопоставление объектов (данных)
Каждый раз при работе с данными нужно очень хорошо понимать, что именно вы выгружаете, в каком виде, а также, куда вы будете выгружать эти данные. В некоторых случаях в источнике у вас будет строковая переменная, а в приемнике – два или более объектов. В других важно просто правильно выбрать объект-приемник. Например, практически в любой CRM контактное лицо и клиент – это одно и то же. С другой стороны в 1С контактное лицо может быть клиентом, партнером, поставщиком. И очень важно понимать, куда именно записывать данные этого контактного лица. Также важно сопоставлять все данные до того, как начнется работа непосредственно с кодом. Для этого прекрасно подойдут таблицы или блок-схемы. Когда-то я так же, как и многие, пренебрегал этим этапом работы. Сейчас я знаю, что эти действия позволят избежать огромного количества ошибок. На какой бы стороне ни работал программист – на стороне программы-источника или приемника, такая табличка очень помогает в работе. Программист должен четко понимать, какие данные будут брать из источника, куда их нужно переносить, и как они будут обрабатываться. Например, при выгрузке контактного лица из CRM нужно четко сопоставить этот контакт партнеру или покупателю. Также очень важно понимать, какие преобразования потребуются для выгружаемых данных. Например, нужные для интеграции данные в источнике хранятся в качестве перечисления в виде текста. А в приемнике (пусть это будет 1С) аналогичное перечисление имеет ссылочный тип. Следовательно, вам потребуется преобразовать текст в ссылку, и уже ссылку передать в документ. И здесь возникает проблема: требуются правила сопоставления. Вы должны четко продумать и прописать правила сопоставления. Более того, об этих правилах необходимо оповестить ваших клиентов. Важно понимать, что клиент не видит логику работы обмена данными, он не понимает особенностей интеграции. Конечно, вы обязательно введете ограничение прав доступа, добавите другие варианты защиты. Но, как показывает практика, это не гарантирует от того, что пользователь совершит ошибку, из-за которой интеграция перестанет работать или будет работать не корректно. Это может быть кто-то из сотрудников, обладающий правами администратора, или приглашенный специалист, который дорабатывает, например, печатную форму документа, но при этом не осведомлен об особенностях интеграции. В результате возникают самые разные казусы. Например, вы используете в качестве ключевого слова для поиска при сопоставлении слово «дилер». Клиент по каким-то причинам меняет его в программе-источнике на слово «дилеры». Казалось бы, мелочь! Но эта мелочь приведет к тому, что поиск в 1С перестанет работать. Я решил эту проблему таким образом:
Почему я пришел к такому варианту работы? Интеграция – процесс сложный, и проблемы из-за человеческого фактора возникают достаточно часто, защититься от них практически не реально. Также бывают и программные сбои, особенно это касается таких сложных систем с большим числом багов, как программные продукты 1С. А для бизнеса очень важно, чтобы обмен данными проходил своевременно, а если возникла проблема также важно ее оперативно устранить. Например, в моей практике была ситуация, когда я провел интеграцию 1С и Oracle, причем, последний являлся программой-источником. Далее на стороне Oracle изменили одно из полей. В результате заказы перестали загружаться в 1С вообще, при этом сервер не выдавал уведомление об ошибке. Обнаружили проблему через неделю. С одной стороны, это явная недоработка отдела продаж моего клиента, так как неделю не получать ни одного заказа и не волноваться по этому поводу, мягко говоря, странно. С другой – отсутствие уведомления об ошибке я считаю собственной недоработкой. Конечно, в результате ошибки были исправлены, система дальше работала без сбоев, но теперь я всегда добавляю несколько вариантов уведомления об ошибке при передаче данных. Самые распространенные решения:
В некоторых случаях также стоит добавлять уведомление о сбое другим лицам, этот вопрос решается с заказчиком индивидуально. Также стоит лог-файл ошибок вести максимально подробно и как можно дольше хранить историю. Не забывайте, что вы имеете дело с данными, которые имеются в одной базе данных, но отсутствуют в другой. И без подробного отчета вам будет очень сложно понять, что именно произошло в процессе передачи данных.
Обмен данными: писать самому или применять типовое решение?
Лично я предпочитаю всегда разрабатывать решение под заказчика. Здесь можно спорить, можно обсуждать различные варианты, но есть факт: типовые обмены данными всегда сильно перегружены возможностями, которые вашему клиенту не нужны. В результате процесс обмена значительно замедляется, а число возможных ошибок вырастает в разы. Кроме того, при выборе типового программного решения вы очень сильно зависите от поставщика программного обеспечения. Для любого исправления бага вам придется ждать выпуск очередной версии программы. Также придется подстраиваться при обновлениях под все изменения в работе, который внес разработчик. А потому при выборе между самостоятельным написанием обмена данными и типовым решением, которое не на 100% подходит для данной ситуации, лучше писать обмен самому. В некоторых случаях, когда типовое решение действительно на 100% удовлетворяет потребности клиента, а скорость работы для него не критична, я также применяю готовые продукты. Например, при выгрузке номенклатуры и фотографий на сайт я не редко использую готовый обмен данными от Битрикс. Но только для выгрузки. Для работы с заказами я применяю самописный обмен.
Метод подключения: REST API, SOAP или прямое подключение к базе приемника
Выбор протокола обмена данными в большинстве случаев напрямую зависит от системы, которую вы интегрируете. В большинстве случаев программисту приходится учитывать требования обеих систем, а потому выбора как такового не существует. В тех случаях, когда система может работать с несколькими протоколами, выбирайте тот, который вам удобнее. По моему опыту, для малых и средних предприятий этот вопрос не принципиален.
Вопросы клиентского доступа: почему не работает обмен?
Я считаю, что обо всех возможных ограничениях в доступе нужно узнать на начальном этапе интеграции. Таким образом, вы гарантированно избежите очень распространенной проблемы: Вы внедрили интеграцию, все проверили, протестировали, убедились, что система работает. После чего пользователь обнаруживает, что обмен данными не происходит. Самые распространенные ситуации:
В первых двух случаях ограничения обычно связаны с политикой информационной безопасности предприятия, и решаются они на административном уровне. Для пользователей, которым потребуется работа с обменом данных, системный администратор настроит перечисленные вами права. Аналогично для ограничения по IP. В случае работы с CRM-системой ограничения обычно обусловлены оплаченным пакетом услуг. Здесь достаточно оповестить клиента о наличии такого ограничения, и, при необходимости, помочь оплатить и настроить расширенный пакет.
1С идентификаторы и ошибки, связанные с ними
При интеграции с 1С очень часто ошибки обмена данных возникают из-за неверного выбора УИ (уникального идентификатора). Суть проблемы заключается в том, что объекты в 1С имеют два типа УИ: один уникален внутри выбранного типа объектов. Второй используется для работы со всей базой данных. Если вы будете проводить поиск по всему справочнику с использованием идентификатора, который предназначен для работы внутри определенного типа данных, возникнет ошибка. Объект может быть вообще не найдет, либо система найдет сразу несколько разных объектов. К этой особенности 1С нужно относиться очень внимательно. Еще одна проблема: нет возможности привязаться к уникальному идентификатору. Например, системой-источником является сайт, и на нем не предусмотрено отдельное поле для информации о клиенте, она идет в общем тексте заказа. В этом случае придется выбрать какой-то другой вариант идентификации, например, по email. При интеграции очень важно выбрать в источнике одно из полей, которое и станет уникальным идентификатором. Я считаю хорошим тоном дублирование этого идентификатора в двух системах. Например, если я делаю выгрузку информации из CRM в 1С, то поле-идентификатор из CRM я копирую в систему 1С. В дальнейшем весь поиск и интеграция производится по этому полю быстро и просто. В принципе, это не обязательное действие. Более того, вы будете хранить даже избыточные данные, так как у вас есть нужная информация в одной из систем, но такое дублирование повышает надежность работы обеих программ и является удобным решением для интеграции и последующей обработки данных. Например, по идентификатору, который идентичен источнику, поиск будет производиться проще и быстрее, так как он не будет требовать дополнительной обработки. Кроме того, если что-то случится с базой данных одной из систем, благодаря дублирующимся идентификаторам сопоставить данные будет намного проще.
Формат выгрузки
Для обмена данными используются самые разные форматы. Это может быть JSON, XML, CSV, TXT, прямой доступ к базе и т.д. У меня в этом вопросе нет каких-то определенных предпочтений. Я считаю, что здесь нужно исходить из рациональных требований проекта.
Постобработка
Итак, обмен данными прошел успешно. Что дальше? Я считаю, что это еще не финал интеграции, так как пользователю мало того, что данные появились в системе. Обычно ему требуется, чтобы с этими данными выполнялись какие-то действия. Что именно нужно клиенту, следует уточнить у него. Но всегда надо помнить о том, что вы работаете для пользователя, для того, чтобы ему было удобно. Для интернет магазинов при интеграции чаще всего требуются:
Постобработка требуется, прежде всего, для того, чтобы полученные данные прошли полный жизненный цикл, а, следовательно, приняли участие в каких-то последующих бизнес-процессах. А потому после загрузки должны запускаться оповещения или какие-то определенные процессы, например, обработка заказа. Кроме действий, которые нужно выполнить в приемнике, также часто требуется после завершения успешной передачи данных выполнить определенные действия в источнике. Что именно потребуется, вам также расскажет пользователь. Например, это может быть уведомление клиента о том, что его заказ успешно прошел выгрузку и отправлен в обработку. И здесь также может быть использовано sms, электронное письмо или просто изменение статуса заказа в системе.
Тестирование интеграции
С моей точки зрения интеграция – это часть (иногда частный случай) внедрения программного обеспечения. И здесь, как и для любой другой работы по внедрению ПО, потребуется тестирование программистом, потом – лично консультантом, а также различные варианты тестирования вместе с пользователями. Об этом я подробно писал в статье «Внедрение программного продукта. Особенности работы бизнес-консультанта. Часть III. Финальная».
Отличие односторонней и двусторонней интеграции
На самом деле, принципиальных отличий у односторонней, двусторонней или многосторонней интеграции не существует. Суть процесса остается прежней, просто в разные моменты времени приемник и источник меняются ролями. Единственное важное правило, которое я ввел для себя и вам также советую: при двухстороннем обмене необходимо хранить уникальный идентификатор для всех систем, которые участвуют в интеграции. И я считаю, что его также стоит дублировать в обеих системах. Сегодня я постарался кратко рассказать об особенностях процесса интеграции, с которыми я лично сталкиваюсь на практике. Я надеюсь, что статья оказалась для вас полезной, а если возникнут какие-то вопросы, я, как и всегда, готов на них ответить.
Что такое интеграция по API
Раньше фраза «интеграция по API» была известна только определенному кругу людей, непосредственно работающих с программным интерфейсом приложений. Сейчас же, когда информационно-коммуникационные технологии, такие как виртуальная IP-телефония, системы CRM и многие другие, коснулись практически всех ниш бизнеса, данная аббревиатура все чаще на слуху у офисных работников и их руководителей, чья специализация напрямую не связана с программированием.
Что же такое API, где используется и для чего нужен такой интерфейс? Более детально в этих вопросах постараемся разобраться в данной статье. Приведем примеры, которые даже «чайникам» помогут понять суть работы и взаимодействие с API.
Определение и принцип работы
API или Application Programming Interface (программный интерфейс приложения) представляет собой описание способов взаимодействия между компьютерными программами. Например, позволяет программисту сделать так, чтобы приложение установленное на смартфоне, будь то Twitter, Facebook или ВКонтакте, могло «соединятся» с соответствующим ему сервером: позволяло выполнять различные действия или просматривать определенную информацию на сайте посредством клиента. Для этого разработчики пишут специальные коды, содержащие описание типа данных, процедуры, функции, структуры, константы, которые помогают программам, говоря простыми словами, понимать друг друга.
Примеры использования
Чаще всего API используют для взаимодействия программ и приложений с операционными системами или Web сайтами. Остановимся более детально на каждом из этих примеров.
Взаимодействие приложений с операционными системами
Большинство современных операционных систем обладают встроенным API. Это позволяет разработчикам создавать софт, который будет взаимодействовать с конкретной ОС. Мало того, применение API к графическим интерфейсам, дает возможность использовать программы с однотипным пользовательским интерфейсом и значительно упрощает освоение новых.
В то же время, API различных операционных систем имеют отличия, которые существенно затрудняют перенос готового приложения с одной платформы на другую. В таких случаях приходится прибегать к некоторым методам обхода в программировании:
К тому же, программисту зачастую доступно несколько разных API, с помощью которых можно добиться одного и того же результата.
Применение в Web
Использование API для взаимодействия программ, сервисов, клиентов с Web сайтами очень распространено в последнее время, поэтому примеров такого использования достаточно много. Рассмотрим некоторые из них.
Импорт и экспорт данных
Используют API при экспорте или импорте данных с онлайн-сервисов в десктопные программы, приложения для смартфонов или другие облачные сервисы. Например, по API возможна интеграция виртуальной АТС с CRM-системами или такими приложениями, как 1С, Google Sheets, позволяет автоматически получать и сохранять различные данные по звонкам клиентов: записывать телефонные разговоры, их длительность, время звонка и многое другое.
Маркетинговые исследования
С помощью API программисты могут связать, быстро набирающий популярность в интернет-маркетинге, инструмент call-tracking с CRM, сервисами Яндекс.Метрика и Google Analytics, с платформами для таргетированной рекламы другими системами. То есть, можно четко указать сервису, какую именно информацию необходимо отслеживать, собирать и передавать, куда сохранять данные, и какие действия с ними выполнять.
Платежи
Не в новинку взаимодействие мобильных клиентов и различных онлайн-сервисов для оплаты с банковскими системами. Подобное “взаимопонимание” между такими разными системами осуществляется за счет все того же API.
Поиск товаров и услуг
Очень удобно в интернете пользоваться различными онлайн-сервисами по поиску товаров, услуг, цен на них. Подобные интернет-ресурсы “подтягивают” нужную информацию о продуктах с первоисточников. Например можно найти и купить билеты на авиарейс, не заходя при этом непосредственно на сайт определенной авиакомпании. Онлайн-ресурс по поиску авиабилетов с помощью API взаимодействует с сайтами различных авиалиний, и на основе требуемой информации пользователя, о времени, месте отправления и назначения, выдает все возможные предложения непосредственно на страницу онлайн-ресурса.
Социальные сети и SIP-телефония
Уже давно используется интерфейс API для связи мобильных приложений с социальными сетями, как писалось в начале статьи. Ведь достаточно удобно выполнить вход, оставить комментарий в Facebook, ВКонтакте, Twitter, воспользовавшись приложением на смартфоне, а не через сам сайт.
Также популярно использование на смартфонах, компьютерах и ноутбуках SIP-клиентов. Взаимодействие последних с серверами, на которых происходит регистрация, соединение с SIP-клиентами и другие процессы, в какой-то степени осуществляется за счет того же API.
Что общего между API и современным бизнесом?
Казалось бы, какая связь между коммерческой деятельностью и программным интерфейсом приложений. Прямой связи нет, но непосредственное использование API для интеграции различных приложений, программ, Web сайтов и т.д., в ведении бизнеса дает ряд преимуществ, таких как:
Интеграция приложений: методы взаимодействия, топология, инструменты
Вопросы интеграции приложений предприятия активно обсуждаются сегодня компьютерным сообществом. Однако в стороне нередко остается ряд моментов, способствующих рождению преувеличенных надежд, возлагаемых на ряд «модных» средств и технологий интеграции. Не существует информационных систем, которые в одиночку могли бы покрыть потребности современного предприятия. Средние и крупные организации обычно эксплуатируют как минимум десяток многопользовательских систем, а иногда счет идет на сотни и тысячи. В этих системах часто обрабатываются одинаковые данные — начиная со справочников и классификаторов.
Вопросы интеграции приложений предприятия активно обсуждаются сегодня компьютерным сообществом. Однако в стороне нередко остается ряд моментов, способствующих рождению преувеличенных надежд, возлагаемых на ряд «модных» средств и технологий интеграции.
Не существует информационных систем, которые в одиночку могли бы покрыть потребности современного предприятия. Средние и крупные организации обычно эксплуатируют как минимум десяток многопользовательских систем, а иногда счет идет на сотни и тысячи. В этих системах часто обрабатываются одинаковые данные — начиная со справочников и классификаторов. Обычны ситуации, когда в рамках одного бизнес-процесса задействованы разные информационные системы. Многие информационные системы изначально ориентированы на получение информации из других приложений и баз данных (например, системы формирования сводной и корпоративной отчетности, системы управления и мониторинга). Поэтому ни одно корпоративное приложение не может рассматриваться как нечто автономное, а всегда является частью большого механизма под названием «информационная система предприятия».
Следствиями отсутствие должного решения проблемы интеграции являются:
Это определяет цели интеграции приложений предприятия.
Цели интеграции
Общие цели интеграции приложений можно сформулировать следующим образом:
В качестве целей конкретных интеграционных проектов обычно фигурируют более четкие формулировки. Например: «обеспечить формирование финансовой отчетности предприятия в срок не более одной недели после завершения финансового периода»; «уменьшить время оформления продажи с одного часа до 15 минут»; «уменьшить количество персонала, задействованного для поддержания в актуальном состоянии справочников и классификаторов, с 20 до пяти человек». Но обычно все, в конце концов, сводится к общим целям, которые можно сформулировать в еще более общем виде — уменьшить операционные расходы предприятия или организации. Поэтому интеграционные проекты часто оказываются в выигрышном положении с точки зрения обоснования перед людьми, принимающими решение о финансировании проектов: расчет показателей возврата инвестиций для таких проектов может выглядеть достаточно привлекательным.
Успешная интеграция корпоративных систем позволяет достичь и дополнительных целей — обеспечить автоматизированный контроль прохождения основных бизнес-процессов на предприятии, информационную безопасность при реализации бизнес-процессов и т.д.
Кто должен инициировать и стимулировать интеграционные проекты — бизнес или ИТ? Автор, выступая в качестве исполнителя работ, сталкивался с разными вариантами «спонсорства» таких проектов. Для любого ИТ-проекта чем сильнее заинтересованность в нем со стороны бизнес-подразделения, тем лучше. Однако для интеграционных проектов такая заинтересованность жизненно необходима. Дело в том, что подобрыне проекты обычно затрагивают интересы многих подразделений, каждое из которых видит только свою часть бизнес-процессов — одни готовят документацию, вторые оформляют накладные, третьи занимаются финансовыми операциями и т.д. Согласование и формализация требований разных подразделений становится очень трудной задачей; отсутствие среди «идеологических лидеров» проекта человека, которому подотчетны все задействованные подразделения, обычно означает провал проекта. Представители ИТ-служб в большинстве случаев не обладают необходимым уровнем влияния.
Не надо забывать, что основная цель интеграционных проектов — снижение издержек, равно как и предпосылки к проектам лежат в бизнес-области даже если проект относится сугубо к ИТ. К примеру, задача развертывания систем управления и мониторинга возникает, если бизнес озабочен снижением затрат на эксплуатацию ИТ-инфраструктуры. Мало того, интеграционные проекты в какой-то степени являются перекладыванием проблем с бизнес-подразделений на ИТ-службу. Рассмотрим, к примеру, типичную ситуацию, когда формированием отчетов «в стиле Excel» для руководства занимается группа в составе финансового департамента. От ИТ-подразделения при этом требуется лишь поддержание в работоспособном состоянии корпоративных информационных систем. В случае же внедрения системы, автоматически формирующей эту отчетность, за все — в том числе и за ошибки в данных — будет отвечать ИТ-служба. Действительно, по мере увеличения степени интегрированности и взаимосвязанности информационных систем возрастает ответственность, роль и статус ИТ-службы, увеличивается зависимость основных показателей работы всей организации от надежности и эффективности интегрированной информационной системы предприятия.
Взаимодействие интегрированных приложений
Для взаимодействия приложений обычно используются такие методы, как обмен файлами, общая база данных, удаленный вызов и асинхронный обмен сообщениями. В этом списке нет прямого обмена данными между базами данных приложений: этот метод ближе не к интеграции приложений, а к перемещению данных. С точки зрения интеграции приложений важна возможность в процессе обмена данными выполнять какую-то содержательную обработку (например, при загрузке накладных пересчитывать товарные остатки). Прямой обмен данными, который обычно выполняется средствами класса ETL (extract, transfer, load) или самодельными утилитами, обычно такой возможности не предоставляет.
Обмен файлами
Обмен файлами пожалуй, самый распространенный подход к организации взаимодействия. Это связано с относительной простотой реализации, а также существованием стандартных (или «почти» стандартных) форматов обмена. Например, большая часть корпоративных информационных систем позволяет загружать и выгружать файлы, например, в формате CSV (Comma-Separated Values — «поля, разделенные запятыми»). Но у этого подхода есть и недостатки; если необходимо оперировать сложными структурами, то простые форматы обмена уже не пригодны. Возникающие в таких случаях специализированные форматы файлов должны «понимать» взаимодействующие системы, что ведет к жесткой зависимости систем друг от друга. Этот недостаток обычно преодолевают всевозможными утилитами конвертации данных. Кроме того, обычно обмен файлами подразумевает участие человека — кто-то должен выгрузить файл, скопировать его на другой компьютер, загрузить. Однако если интегрируемые методом обмена файлами системы имеют возможность автоматической загрузки/выгрузки (например, по расписанию), то данный подход позволяет построить полностью автоматизированное решение, которое вследствие своей простоты обладает высокой надежностью и пропускной способностью.
Общая база данных
Данный подход концептуально очень прост — несколько информационных систем или приложений используют одну базу данных. Главный его недостаток — связь между интегрированными приложениями настолько тесная, что иногда невозможно заметить границу между ними (обычно так интегрируются продукты одного производителя). Примером такого подхода могут служить большинство ERP-систем, где различные модули системы используют одну базу. Однако слишком тесная связь превращает конгломерат интегрированных приложений в монолит, в «суперсистему», отдельные части которой с трудом поддаются самостоятельной модернизации и замене. С этим борются, используя механизмы серверов баз данных (представления данных, промежуточные таблицы и т.п.), но далеко не всегда эффективно.
Удаленный вызов
Стандарты на удаленный вызов процедур возникли два десятка лет назад, позволяя программному коду, который выполняется на одном компьютере, вызывать код на другом. Стандарты появлялись, развивались и угасали: RPC, CORBA, DCOM, RMI… последним в этом ряду стал протокол SOAP, основа современных Web-сервисов. Собственно в подходе к интеграции с использованием удаленных вызовов за эти годы ничего принципиально не изменилось — если приложению А что-то нужно от приложения Б, то А одним из перечисленных способов вызывает функцию приложения Б.
Основной недостаток удаленного вызова — требование работоспособности всех задействованных приложений в момент взаимодействия. Представьте себе систему ведения справочников, изменения из которой каждую ночь распространяются в десятки корпоративных систем. Вероятность того, что, скажем, в два часа ночи все корпоративные системы находятся в состоянии полной боеготовности, невелика. На этом «погорели» и мы, реализовав с помощью технологий Web-сервисов распространение справочников по корпоративным системам; все пришлось переписать.
Опыт показывает, что подход, основанный на удаленном вызове, приемлем только в тех случаях, когда взаимодействие приложений инициируется пользователем, который сам контролирует результат. Для автоматического взаимодействия без участия человека данный подход практически неприменим. В этом нет ничего удивительного: удаленные вызовы изначально были придуманы не для интеграции разных приложений, а для создания распределенных систем, когда компоненты одной системы могут работать на разных компьютерах.
Асинхронный обмен сообщениями
Это, пожалуй, единственный из перечисленных подходов, который создавался специально для интеграции информационных систем. Идея концептуально проста и напоминает работу электронной почты. Когда приложению А необходимо вызвать какое-то действие в приложении Б, оно формирует соответствующее сообщение с данными и инструкциями и отправляет его посредством системы доставки сообщений. Слово «асинхронный» означает, что приложение А не должно ждать, пока сообщение дойдет до Б, будет обработано, сформирован ответ и т.п. Сообщение гарантированно доставляется благодаря механизму очередей сообщений, которые снимают с взаимодействующих систем заботу о надежности сети передачи данных, работоспособности взаимодействующих систем в конкретные моменты времени и т.д.
Недостаток данного подхода — высокая цена. Система гарантированной доставки на основе очередей сообщений обычно сама по себе недешева; единственным известным мне исключением является Microsoft Message Queue (MSMQ), компонент серверных операционных систем семейства Windows. Правда, есть и свободно распространяемые бесплатные (например, ActiveMQ), которые, тем не менее, нужно развернуть, обучить специалистов, поддерживать, написать адаптеры между системой доставки и приложениями и т.д.
Топология
Существует два подхода к организации маршрутов взаимодействия интегрируемых системы. Первый — прямое взаимодействие интегрированных систем по принципу «каждая с каждой», или «точка-точка». Второй — взаимодействие через центральный узел; подобную звездообразную архитектуру обычно называемую «хаб + спицы». Топология не зависит от физической архитектуры информационной системы, а определяет логические маршруты взаимодействия и передачи данных между интегрированными системами.
Точка-точка
При данном подходе интегрированные системы взаимодействуют напрямую. Преимущества подхода — простота, прозрачность и отсутствие необходимости в дополнительном программном обеспечении. Однако, есть и недостатки. Во-первых, интегрированные приложения должны общаться с использованием одинаковых методов взаимодействия и форматов вызовов/данных. При изменении одного из приложений (если оно повлекло за собой изменение интерфейса взаимодействия данного приложения) приходится модифицировать или как минимум перенастраивать все интегрированные с ним системы. Во-вторых, в информационной системе предприятия появляется слишком много связей, каждую из которых нужно контролировать и поддерживать в работоспособном состоянии.
Если взаимодействующих приложений много, стоимость сопровождения интегрированной таким образом информационной системы предприятия становится неприемлемо высокой. Тем не менее подход «точка-точка» широко используется. Это происходит, как правило, в тех случаях, когда при взаимодействии конкретных приложений необходимо передавать большие объемы данных или обеспечивать нормированное время взаимодействия, а также если эксплуатируемые на предприятии приложения имеют встроенные средства взаимодействия (это часто случается при внедрении нескольких систем от одного поставщика, а также если при разработке заказных программных систем или внедрении новых к ним изначально предъявляется требование по взаимодействию с уже имеющимися системами).
Здесь, однако, таится опасность «ползучей» интеграции, которая делает возможной ситуации, когда при необходимости поменять систему XYZ неожиданно обнаруживается, что сделать этого нельзя, поскольку справочник оргструктуры и сотрудников вашего предприятия, исторически ведущийся в XYZ, каждую ночь реплицируется еще в десяток систем.
Хаб + спицы
Взаимодействие по типу «точка-точка» создает в инфраструктуре предприятия слишком много связей и требует согласования интерфейсов и форматов данных между взаимодействующими приложениями. Эти недостатки призвана решить архитектура взаимодействия, в которой все приложения непосредственно соединены только с центральным узлом, решающим следующие задачи:
Благодаря введению промежуточного звена, уменьшается число связей между приложениями, устраняются прямые связи, а система интеграции становится более гибкой и дешевой в эксплуатации. Если меняется одно из интегрированных приложений, то — при условии правильно спроектированной системы интеграции — нужно будет модифицировать только одну связь, между данным приложением и хабом.
Недостатком топологии «хаб + спицы» является высокая стоимость приобретения и сложность программного инструментария, играющего роль хаба, а также нехватка специалистов, имеющих опыт применения подобных программных средств.
Выбор средств интеграции
Готовых инструментов интеграции на рынке немало. Так, только корпорация IBM в разделе программного обеспечения интеграции приложений предлагает пару десятков групп продуктов и еще много интеграционных продуктов в других категориях. Сложность выбора состоит в том, что среди представленных средств есть и узко ориентированные (например, IBM Message Broker), и позиционируемые как «универсальные» (скажем, Microsoft BizTalk). Однако выбор того или иного инструментария определяется не тем, что о нем говорит производитель, а конкретным составом «зоопарка» аппаратно-программных решений в организации, которые необходимо заставить работать совместно.
Советы общего плана
Перед выбором программных средств интеграции необходимо четко определить все системы, нуждающиеся в координации или в обмене данными с другими системами; документировать все возможные протоколы взаимодействия, требования по объему данных, расписанию обмена и т.д. Ключевым моментом также является необходимость участия человека в процессе взаимодействия информационных систем. Часто это диктует выбор решений, не имеющих, на первый взгляд, отношения к интеграции.
Собрав и документировав информацию о будущей картине взаимодействия приложений, необходимо отобрать минимальный набор приложений, дающих все варианты методов взаимодействия, протоколов и т.п. Возможны разные требования по объему и видам передаваемых данных, по стилям интеграции и так далее — нужно сформировать минимальную по объему репрезентативную выборку, и на ее основе выбирать комплект продуктов для интеграции и запускать пилотный проект.
Совет конкретный
До завершения пилотного проекта нет необходимости приобретать интеграционное программное обеспечение — всегда есть возможность получить временные лицензии и все проверить. При этом партнеры поставщиков таких решений, как правило, решают вопросы проверки оперативнее самих поставщиков, и, самое главное, могут обеспечить техническую поддержку еще до покупки лицензий.
Отдельно про Web-сервисы
Сегодня технология Web-сервисов позиционируется как удобное средство интеграции приложений, поскольку позволяет реализовывать, развертывать, и обеспечить простое межплатформное взаимодействие. К сожалению, наш опыт говорит о практической неприменимости современных технологий Web-сервисов для интеграции приложений как общего подхода. Действительно, пока Web-сервисы оказываются непригодны для обработки больших объемов информации; в них отсутствуют средства поддержки транзакций; взаимодействующие системы должны находиться в работоспособном состоянии на момент взаимодействия.
Непригодность к обработке больших объемов — врожденный недостаток, который связан с XML-природой Web-сервисов. Все данные и параметры вызовов Web-сервисов преобразуются в формат XML, что во много раз увеличивает объем данных со всеми вытекающими из этого последствиями в виде растущей потребности в оперативной памяти и нагрузки на процессоры. К сожалению, речь идет не о гигабайтах передаваемой информации: Web-сервисы «захлебываются», когда за одно взаимодействие между интегрированными системами нужно передавать уже сотню килобайт. (Правда, существует стандарт WS-Attachments, описывающий механизм подсоединения к вызовам Web-сервисов любых данных без перекодирования в XML, однако ведущие поставщики этот стандарт не поддерживают.)
Далее представьте, что в процессе взаимодействия множества информационных систем необходимо провести согласованные изменения в некоторых из них, то есть выполнить логическую транзакцию, затрагивающую несколько систем. Если для интеграции используются Web-сервисы, то такой возможности нет: в своем «исходном» варианте Web-сервисы не поддерживают заключение в рамки одной транзакции несколько вызовов методов одного или нескольких сервисов. Поставщики интеграционного программного обеспечения в этом случае обычно предлагают использовать так называемые «компенсационные операции» (на каждую операцию предусмотреть отменяющую ее операцию). Скажем, если из трех участвующих в логической транзакции приложений два смогли выполнить какую-то операцию, а одно — нет, то в двух системах нужно выполнить действия отката, отменяющие результат успешно выполненных операций. В теории подход хорош, но, во-первых, никто не гарантирует успех компенсационной операции, а во-вторых, некоторые системы (например, финансовые) не допускают удаления данных, внесенных в базу.
Но самое печальное в ситуации с Web-сервисами — не отсутствие реализаций стандартов, сдерживающих их применение для интеграции приложений. Плохо то, что после реализации всех необходимых стандартов Web-сервисы рискуют потерять то, благодаря чему они стали столь популярны, — простоту создания, развертывания, поддержки. Поддержка WS-Transactions, WS-Attachments и других стандартов, расширяющих возможности Web-сервисов, может резко усложнить их создание, отладку и развертывание.
Немного о ESB и SOA
Вернемся теперь на пять лет назад, когда основной платформой интеграции приложений были транспорты на основе очередей сообщений и программное обеспечение промежуточного слоя, ориентированное на обработку сообщений, которое играло роль «хаба» в рассмотренной ранее архитектуре «хаб + спицы».
Подобный инструментарий промежуточного слоя стоил слишком дорого, а специалисты по нему — еще дороже. Когда появился новый метод межплатформного взаимодействия, Web-сервисы, родился и новый подход к организации основы для интеграции — сервисная шина предприятия (Enterprise Service Bus, ESB). Реальным отличием ESB от шины сообщений предприятия стала поддержка дополнительных методов взаимодействия между приложениями и хабом, прежде всего, протокола SOAP. Основанный на ESB подход подавался как более дешевая, простая в реализации альтернатива предыдущей концепции.
Что же получилось в действительности? Появились новые продукты, поддерживающие SOAP, в старые продукты такая поддержка была добавлена, однако они не стали дешевле, а значит, доступнее своих предшественников. Означает ли это конец еще одной красивой сказки? Вовсе нет. Если отбросить пропаганду, то поддержка «хабом» интеграционной системы широкого спектра методов взаимодействия и протоколов облегчает и удешевляет интеграцию. Но не в разы, а на проценты — что уже неплохо с учетом стоимости интеграционных проектов.
Вокруг архитектуры, ориентированной на сервисы (Service-Oriented Architecture, SOA), также очень много маркетинговой шумихи. На мой взгляд, SOA — это не конкретные продукты и даже не технология, а лишь концепция построения информационных систем путем представления их в виде сервисов, доступных для «наружного» использования, в том числе путем их интеграции с другими приложениями. Это означает, что для пользователей ничего не изменится, пока ведущие поставщики программного обеспечения (и прежде всего, производители бизнес-приложений наподобие ERP, CRM, EAM и т.д.) не модифицируют свои системы в соответствии с SOA. Только тогда можно получить реальный выигрыш; пока же популярные бизнес-приложения — это замкнутые системы с очень «узким» внешним интерфейсом.
Однако ведущим поставщикам программного обеспечения это не так уж и нужно — хотя бы по той причине, что SOA даст теоретическую возможность клиентам выбирать компоненты от разных поставщиков по принципу «лучший в классе» и объединять их в информационную систему предприятия. При этом производителям, скорее всего, потребуется переписать свои системы. Вместе с тем, в настоящее время поддержка SOA является одним из тех немногих «крючков», которые могут побудить имеющихся клиентов переходить на новые версии бизнес-систем, а также способствовать правильной — с точки зрения поставщика — ориентации новых клиентов. Так или иначе, следующие несколько лет покажут, насколько жизнеспособна концепция SOA.
Алексей Добровольский (ADobrovolsky@croc.ru) — директор по разработке программного обеспечения компании КРОК (Москва).
Поделитесь материалом с коллегами и друзьями