Из опыта интеграции разных продуктов Microsoft

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

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

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

Процесс сбора данных

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

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

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

Очевидно, что нам понадобится несколько базовых компонентов. Во-первых, это средство проектирования электронных форм. Во вторых, средства доставки форм на клиента. В третьих, механизмы вторичного контроля и консолидации данных. В четвертых, некий набор специализированных компонентов, реализующих специфическую бизнес-логику в каждом конкретном случае. Ну и, наконец, нам нужны хранилища данных. Для наглядности представим архитектуру графически (рис. 1). Здесь может сразу возникнуть вопрос, почему мы используем два хранилища. Это обусловлено двумя основными факторами. Во-первых, в оперативном хранилище могут содержаться неверифицированные данные. К тому же стоит принять во внимание, что над собранными данными будут надстроены механизмы их анализа и обработки, которые в свою очередь могут быть довольно «тяжеловесными». Поэтому имеет смысл вынести проверенные данные в отдельное хранилище, чтобы уменьшить взаимное влияние систем.

Теперь перейдем к описанию конкретной реализации системы сбора на платформе Microsoft. Здесь мы рассмотрим конкретную реализацию системы сбора структурированных данных — решение IBS Monitoring, которое было разработано компанией IBS в рамках новой линейки тиражируемых решений IBS Integrated Solutions. Разложим архитектуру решения, основываясь на семействе продуктов Microsoft. Очень удобным средством для проектирования электронных форм является Microsoft Office InfoPath 2003. Он позволяет визуально проектировать электронные формы, а также создавать правила первичного контроля данных. В качестве средства доставки оформленных данных целесообразно использовать SharePoint Portal Server 2003 (SPS). Во-первых, портал позволит нам обеспечить доступ к формам из любого места через Internet. Во-вторых, SharePoint прозрачно интегрируется с InfoPath и позволяет публиковать разработанные формы. К тому же портал дает нам возможность организовать персонализированные рабочие места и разместить на них специфические компоненты в качестве Web-клиентов. В качестве интеграционного ядра системы мы будем использовать Microsoft Biztalk Server 2004. Это хорошо зарекомендовавший себя продукт для организации сопряжения нескольких систем, а также для организации управляемых бизнес-процессов. Неоспоримым достоинством Biztalk является работа с XML, а значит, поскольку заполненная форма InfoPath является не чем иным, как XML-документом, нам не придется разрабатывать дополнительные механизмы интеграции. В качестве среды разработки под Biztalk будем использовать Microsoft Visual Studio 2003 .NET. В качестве же клиентского программного обеспечения возьмем Microsoft Internet Explorer 6.0 и Microsoft Office InfoPath 2003. Internet Explorer понадобится для взаимодействия с порталом и Web-компонентами, а InfoPath — для заполнения электронных форм. В качестве базы данных будем использовать Microsoft SQL Server 2000. Выбор базы данных довольно очевиден, поскольку и SPS, и Biztalk хранят свои базы данных в SQL Server. Не имеет смысла закупать еще и сторонние базы данных при наличии всех необходимых компонентов у одного поставщика. Стоит отдельно остановиться на интеграции SPS и Biztalk. Поскольку в данный момент в Biztalk нет адаптера для SPS, нам придется применять независимые разработки — WSSLib. WSSLib — это адаптер Biztalk к SPS. Он позволяет получать электронные формы из библиотек форм SharePoint и использовать их внутри оркестровок Biztalk. С выходом Biztalk Server 2006 эта проблема будет устранена, так как в новой версии Biztalk будут встроены средства интеграции с SharePoint.Таким образом, нашу типовую архитектуру можно конкретизировать, как показано на рис. 2.

Реализация

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

  • XSD-схема данных;
  • XSL-преобразование;
  • Manifest.xsn - служебный файл, в котором хранятся настройки формы, например список файлов в форме, источники данных и т. д.
  • Script.js - пользовательские сценарии. Например, функции по обработке событий формы.

Кроме того, при проектировании формы необходимо добавить в шаблон правила первичного контроля введенных данных. Стоит отметить, что для проектирования шаблонов электронных форм InfoPath можно использовать и Visual Studio. В этом случае дополнительная функциональность будет включена в форму в качестве сборки .NET.

Заполненная же форма представляет собой документ XML, в котором в явном виде содержится ссылка на шаблон формы, а также инструкция по обработке (см. экран 1), которая говорит о том, что данный документ XML должен открываться с помощью InfoPath. После создания формы она публикуется в библиотеке форм SharePoint и становится доступной для заполнения через Internet. Заполненные формы InfoPath попадают в соответствующую библиотеку форм в SharePoint. Далее нам надо получить формы из SharePoint, провести процедуру вторичного контроля и отправить данные в итоговое хранилище. Для этого будем использовать сервер Biztalk. Процедуры вторичного контроля и консолидации будут реализованы в качестве оркестровок Biztalk. Дело в том, что правила вторичного контроля могут меняться, как и структура итогового хранилища данных. Поэтому целесообразно реализовать механизмы гибкого управления процессом верификации и консолидации данных. Для получения форм из SharePoint используется соответствующий адаптер к Biztalk — WSSLib. Адаптеру указывается путь к библиотеке форм, а также название представления, из которого следует получать формы (см. экран 2).

Экран 2. Настройка WSSLib

Тонкости

Зачастую структурированные данные перед утверждением должны проходить некий процесс утверждения. В том случае если процессы не очень сложные, можно ограничиться реализацией соответствующей логики в Web-частях SharePoint. Если же процессы довольно сложны или подвержены частым изменениям, возможно, стоит задуматься о внедрении системы документооборота на базе SharePoint. Одним из таких продуктов является Skelta Workflow .NET, которая позволяет визуально создавать процессы документооборота и интегрировать их в SharePoint, как показано на экран 3.

Особое внимание надо уделить стоимости решения. Не всегда у организации есть возможность закупить необходимое количество лицензий на InfoPath. В данный момент пользовательская лицензия на InfoPath стоит в среднем 117 долл. (цены могут варьироваться в зависимости от категории заказчика). В таких ситуациях на помощь приходят продукты независимых поставщиков, такие как InfoView от компании uniqueworld.net. InfoView, — это фактически Web-просмотрщик форм InfoPath. InfoView позволяет преобразовывать формы InfoPath в формы ASP.NET c сохранением практически всей функциональности. Это избавит от необходимости приобретать большое количество пользовательских лицензий на InfoPath.

Итак, перечислим преимущества, которые дает внедрение системы сбора структурированных данных.

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

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

Алексей Берзин - Руководитель группы департамента интеграционных решений компании IBS