Расширение интеграционного сценария
Уровень интеграции обеспечивает централизацию ключевых функций, совместно используемых приложениями, а это открывает более широкие возможности, чем интеграция пользовательских интерфейсов. Средства интеграции данных, информации и процессов способствуют сокращению расходов на интеграцию (или даже разработку) каждого последующего приложения. Как показывает опыт, применение уровня интеграции со временем приносит все большую экономию и, кроме того, позволяет создавать совершенно новые приложения, выходящие за рамки первоначального сценария интеграции.
Например, если системы биллинга, обработки жалоб клиентов (troubleticketing), управления клиентами и ERP интегрированы пользовательским интерфейсом CRM, то, поскольку эти системы уже связаны, вы можете создавать простые решения для самопомощи через Интернет (Web self-help solutions), а в дальнейшем расширять их до систем заказов через Интернет и решений для канальной дистрибуции между предприятиями (B2B channel). Если вы приобретете какое-то новое приложение вроде системы управления сетью поставщиков, интеграция этого приложения в такую среду все равно окажется нетривиальным процессом. Однако эта задача заметно упростится при наличии уровня интеграции, так как интегрировать данные будет легче за счет того, что единый набор известных интерфейсов включается в уровень интеграции, а не в каждое приложение.
Табл. 2. Технические требования к уровню данных
|
Требования |
Описание |
|
Возможность соединений |
Это возможность передачи информации с применением самых разных протоколов и методов, в том числе интерфейса Web-сервисов. Сюда также следует отнести специфические протоколы, необходимые в конкретных сценариях (в каждой организации может быть своя специфика). Например, во многих организациях, где в качестве основных бизнес-систем по-прежнему используются мэйнфреймы, нужны IBM WebSphere MQ и/или SNA-подключения с применением Microsoft Host Integration Server (HIS). В других системах могут понадобиться интерфейсы COM+ или даже HTTP, низкоуровневые сокеты (raw sockets) или FTP. Все протоколы должны выполняться через общий интерфейс с возможностью подключения специфических реализаций для конкретных сценариев. Все специфические технические требования конкретных протоколов или методов должны удовлетворяться подключаемой реализацией, и во внешних системах не должно быть логики обработки специфических случаев |
|
Трансформация |
Это преобразование данных из одной структуры в другую на основе правил. Ядро трансформации должно быть размещено на уровне данных |
Рабочие процессы — основная часть любого решения в области интеграции. Они используются в управлении бизнес-процессами и играют центральную роль в выполнении процессов, обеспечивающих связывание систем. Это две разные задачи, но обе прекрасно решаются с применением средств управления рабочими процессами. Рабочий процесс, применяемый для интеграции систем, может включать такие операции, как получение данных от каждой системы и их агрегацию, проверка информации, вводимой пользователями, и обновление информации в системах при ее изменении или при вводе новых данных.
Табл. 3. Технические требованию к информационному уровню
|
Требования |
Описание |
|
Агрегация данных |
Сервисы, служащие оболочкой вызовов от разных систем, обеспечивают агрегацию данных. Очень важно рассматривать агрегацию данных как отдельное требование и уделять большее внимание организации данных и бизнес-правилам, которые позволят именно агрегировать данные, а не просто накапливать их |
|
Бизнес-правила |
Будьте очень внимательны при разработке бизнес-правил в интеграционном сценарии: правила, составляющие часть каждого приложения, должны находиться в этом приложении, а правила, относящиеся к интеграции приложений, должны быть инкапсулированы на информационном уровне. Такой подход обеспечивает эффективное повторное использование правил, упрощает сопровождение приложений и позволяет создать единую, централизованную точку разработки и применения правил |
|
Управление транзакциями |
Это обязательное и в то же время сложное в реализации требование, выдвигаемое при интеграции приложений. Обязательно оно потому, что существует потребность в фиксации или откате транзакции между любыми приложениями, включенными в эту транзакцию. А сложно в реализации из-за того, что откат транзакции для множества систем может потребовать создания обратимых записей (reversing entries) или применения какого-то другого программного способа. Это, кстати, идеальный пример, наглядно демонстрирующий потребность в централизации сложной логики |
|
Управление справочными данными |
Справочные данные обычно применяются при выводе через UI списков, где пользователь что-то выбирает, или при проверке данных на допустимость. Как правило, справочные данные являются общими для всех приложений (например, списки стран, почтовых индексов, продуктов, адресов офисов и т. д.). Доступ к справочным данным из общей точки на этом уровне повышает производительность, дает согласованные результаты и упрощает разработку |
|
Управление сеансом |
Гарантирует, что во всех системах, охваченных интеграционным сценарием, известно, кто обращается к данным, и что текущие операции синхронизированы между системами. Полноценное управление сеансом позволяет получать представление о сеансе из одной точки доступа, например при обращении клиента к порталу в Интернете, и повторно использовать его в другой точке, скажем, чтобы консультант мог корректировать заказ от клиента |
|
Средства мониторинга и протоколирования |
По аналогии с управлением справочными данными централизация средств мониторинга и протоколирования на этом уровне вполне логична, так как позволяет сосредоточить весь код, отвечающий за мониторинг и протоколирование, в одном месте Обработка ошибок Обработка ошибок на этом уровне позволяет централизовать код, отвечающий за обработку ошибок, и единообразно реагировать на ошибки |
|
Управление конфигурациями |
Управление конфигурациями в такой среде, как рассматриваемой нами, — дело сложное и заслуживает отдельного обсуждения. Однако оно должно обеспечить создание единой точки, откуда можно было бы изменять адреса систем, контролировать доступ к системам и где можно было бы хранить параметры конфигурации, при необходимости загружаемые общим диспетчером конфигурации
|
Применение средств управления рабочими процессами — идеальный способ выполнения таких операций, гораздо более эффективный, чем написание соответствующего кода. Эти средства могут принести существенные выгоды бизнесу при использовании уровня интеграции, особенно если учесть, что:
- работа с несколькими системами естественным образом строится на основе процессов, при этом задачи выполняются поэтапно, и на каждом этапе поддерживаются точки принятия решений, ветвление по условию и другие базовые возможности рабочих процессов;
- рабочие процессы, связанные с интеграцией систем, выполняются централизованно и размещаются между приложениями, поэтому на них чаще влияют изменения в интеграционной среде (при условии, что каждое изменение в каждой системе отражается на уровне интеграции). Средства управления рабочими процессами делают их понятными более широкому кругу людей (а не только разработчикам), так как рабочие процессы представляются в графическом виде. Эти процессы легче и быстрее модифицировать, их отладка проще по сравнению с отладкой кода;
- схематическое представление, формируемое средствами управления рабочими процессами, облегчает понимание бизнес-процессов, и их модификацию можно разрешить не только группе разработчиков, но даже бизнес-аналитикам и основным бизнес-пользователям.
Табл. 4. Бизнес-требования к информационному уровню
|
Требования |
Описание |
|
Информационная модель
|
Чем больше приложений интегрируется, тем больше объемы доступных данных. Это позволяет приступить к созданию информационной модели, охватывающей все вовлеченные системы. При должной реализации информационная модель, размещаемая на уровне интеграции, способна предоставить единую точку получения ключевых сущностей данных. Например, она позволяет тут же выяснить адреса всех систем, используемые продукты, историю заказов и технической поддержки по конкретным заказчикам. Два распространенных способа создания единой точки получения информации — использование одной ключевой системы и ее синхронизация с остальными системами или применение базы данных, обновляемой согласованно с изменениями в нескольких системах. Общая информационная модель на уровне интеграции особенно эффективна и полезна благодаря тому, что она объединяет данные из множества источников, не оказывая влияния ни на данные, ни на код в этих источниках
|
Табл. 5. Бизнес-требования к уровню процессов
|
Требования |
Описание |
|
Рабочие процессы |
Системы рабочих процессов (workflow systems) можно реализовать как управляемые пользователем или системой. В обоих случаях их можно задействовать на уровне интеграции; однако важно различать эти случаи. Рабочий процесс, управляемый системой (system-driven workflow), требует выполнения ряда операций, связанных с взаимодействием с различными системами в интеграционной среде |
|
Комплексные бизнес-правила |
Эти бизнес-правила придают дополнительную ценность уровню интеграции, так как они позволяют предоставлять новую или расширенную функциональность, выходящую за рамки одной лишь интеграции систем |
|
Моделирование бизнес-процессов |
Системы рабочих процессов можно использовать и для автоматизации существующих процессов, пока выполняемых с участием людей. Уровень интеграции — идеальное место для среды, моделирующей бизнес-процессы. Применение средств управления рабочими процессами позволяет документировать существующие процессы и представлять их в графической форме. Эти же средства упрощают доступ к нескольким приложениям, особенно при реализации информационной модели, поддержке транзакций и т. д. Моделирование бизнес-процессов открывает простор для таких усовершенствований, которые в ином случае были бы просто невозможны |
|
Business Activity Monitoring (BAM) |
Business Activity Monitoring (BAM) — это комплексная система отслеживания транзакций, позволяющая выявлять узкие места, ухудшение производительности, проблемы с конкретными транзакциями и др. Возможности BAM очень велики, но зависят от средств, предоставляемых информационным уровнем |
Заключение
Располагать каким-то инструментом и правильно пользоваться им — две разные вещи, и в этой статье я пытался обрисовать, как изменить свое мышление, чтобы добиться действительно успешной интеграции. Какой бы подход вы ни выбрали, помните, что интеграция в масштабах всего предприятия принесет гораздо больше выгод для бизнеса, что сама по себе интеграция — задача нетривиальная и ее следует рассматривать в контексте всей организации, а также что начинать реализацию решения можно и даже нужно с одного проекта.
Получить представление об интеграции уровня целого предприятия необходимо как можно раньше. Хотя в каких-то областях можно остановиться на интеграции по типу «точка-точка», более эффективная интеграционная среда, поддерживающая рабочие процессы и другие возможности, даст существенные преимущества при увеличении количества систем и появлении необходимости в более тесной их интеграции.
Принимая любые решения по архитектуре, как всегда, учитывайте факторы, влияющие на бизнес, расходы, возможности и т. д. Подход к интеграционной архитектуре, предлагаемый в этой статье, хорошо соответствует возможностям нынешних средств интеграции и современным архитектурным концепциям. Надеюсь, что моя статья поможет вам в осмыслении некоторых решений, которые могут быть приняты в этой области.
Источник: http://msdn2.microsoft.com/en-us/arcjournal/default.aspx |