Представив на рынок в 2003 г. платформу Ensemble, корпорация Intersystems (http://www.intersystems.com) фактически стала одним из пионеров в освоении сферы интеграции корпоративных приложений*. С того момента прошло достаточно времени, чтобы заказчики смогли на реальном опыте убедиться в возможностях и достоинствах этой системы. Более того, нужно отметить, что Ensemble доказала свою жизнеспособность и перспективность в условиях конкуренции, резко выросшей с выходом на рынок интеграции программных решений других ведущих поставщиков ПО.


* О платформе Ensemble см. также статьи "InterSystems Ensemble — платформа для интеграции и разработки приложений" («BYTE/Россия» № 6’2004) и "Мониторинг бизнес-активности и платформа InterSystems Ensemble" («BYTE/Россия» № 9’2005).

В данной статье мы расскажем о двух сильно различающихся по своей природе интеграционных проектах, выполненных с использованием платформы Ensemble, выделив как особенности задач, стоявших перед исполнителями, так и особенности принятых проектных решений. Один из этих проектов, выполненный для администрации Красноярского края, стал победителем конкурса среди субъектов Российской Федерации, цель которого был выбор типовых программно-технических решений для отработки и внедрения в 2007—2008 гг. в рамках ФЦП «Электронная Россия». Важно отметить, что при реализации решений 99% всех работ (кроме создания композитных приложений) было выполнено исключительно в рамках Ensemble, его собственными средствами разработки, что полностью соответствует концепции Ensemble как комплексного инструментального средства, позволяющего решать интеграционные и BPM-задачи различного характера и степени сложности (рис. 1).

Рис. 1. Эволюция интеграции на основе Ensemble.

Интеграция краевого масштаба

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

Рис. 2. Архитектура аналитической информационной системы KrAl.

Непосредственно с помощью Ensemble были решены следующие три задачи, поставленные в рамках краевого конкурса:

  • создана система ведения единых территориальных справочников и классификаторов;
  • создано централизованное хранилище данных и регистр информационных ресурсов Единой краевой информационной системы;
  • усовершенствована краевая система электронного обмена и сбора данных.

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

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

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

Другую типичную проблему интеграции составляет качество самих данных — очевидно, что наивно было бы ожидать полной "заочной" согласованности данных по одним и тем же физическим объектам в разных информационных системах. Встречались и прямые искажения данных, например, в составах некоторых федеральных(!) справочников. Сам факт выполнения интеграционного проекта вскрыл некоторое количество "черных дыр", когда данные об одних объектах в разных системах не соответствовали либо прямо противоречили друг другу.

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

Весьма важным для проекта оказался тот факт, что в систему Ensemble включено ядро высокопроизводительной объектной СУБД Cache', к которой имеют доступ элементы выстраиваемого интеграционного решения, — именно оно было выбрано в качестве технологической платформы организации центрального хранилища данных (ЦХД). СУБД, уже применявшаяся во многих проектах автоматизации крупных структур и организаций, успешно справилась с поставленной задачей. Стержневым элементом создаваемого хранилища выступало понятие композитного объекта — части объективной реальности, которая имела несколько несвязанных друг с другом напрямую образов в информационных системах различных ведомств. Первой задачей, собственно, была организация сбора данных, для чего был использован механизм входящих адаптеров/бизнес-служб Ensemble, в результате работы которых ЦХД наполнялась данными.

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

Для представления накопленной информации потребителям были созданы композитные приложения (в качестве языка реализации была выбрана Java), которые дают пользователям возможность работы с уже готовыми композитными объектами: например, просмотр совокупной информации о некоторой школе позволяет получить как сведения о числе учеников (источник данных — департамент образования), так и характеристики здания, в котором размещается школа (информация относится к ведомству краевого имущества). Точно так же созданный инструментарий поддерживает запросы к ЦХД и обеспечивает просмотр результирующих выборок в привязке к географической информации (одной из интегрируемых систем была ГИС — Банк пространственных данных).

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

В дополнение к работе с композитными объектами потребителям может понадобиться применить OLAP-функционал к собранной информации. На момент первой фазы проекта в качестве OLAP-инструмента использовалось внешнее решение open source, работающее на Java, которое использовало Ensemble как источник данных. В данный момент ведутся работы, которые позволят перенести OLAP-функционал непосредственно на уровень хранилища Ensemble, что позволит отказаться от внешних OLAP-серверов и повысит быстродействие работы аналитической подсистемы в целом.

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

Ориентация на процессы

В 90% случаев интеграция корпоративных приложений — это чистая координация данных, как правило, сводящаяся к типичной ETL-задаче. Однако есть и исключения — присутствующая в Ensemble BPM-функциональность позволяет строить на базе этой платформы решения, основная задача которых состоит в исполнении бизнес-процессов, организации потоков работ (workflow) и мониторинге работы на основе заданных метрик.

Именно таков по своему характеру проект, выполненный совместно в одной из крупных российских ритейловых сетей. Основной акцент в этом случае был сделан не на обеспечении обмена данными между информационными системами, а на отражении в рамках интеграционной платформы бизнес-процессов, протекающих в организации. В данный момент на базе BPM-возможностей Ensemble решены задачи организации в компании Service Desk и документооборота.

Ensemble позволяет очень быстро разрабатывать решения для систем управления потоками работ. Для этого нужно только сделать следующее:

  • создать объектную модель предметной области (документы, организационную структуру, инциденты в service desk и т. д.);
  • создать бизнес-процессы управления потоками работ;
  • настроить Ensemble Workflow Portal, предоставляющий готовый интерфейс для пользователей.

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

Сейчас проект развивается, идет создание Master Data Management — подсистемы, предназначенной для работы с нормативно-справочной документацией.

Промежуточные итоги

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