Вероятно, имеет смысл пояснить, о чем этот доклад, поскольку название его звучит достаточно странно. Действительно, зачем разрабатывать системы документооборота? На рынке много готовых решений, которые можно легко настроить и внедрить. Может быть, просто слова перепутали? Нет, именно разработка. И ключевое слово здесь "корпорация" - десятки тысяч людей, занятых в многочисленных и разнообразных бизнес-процессах, использующих документы. И в этих условиях настройка готовых продуктов под каждый процесс не всегда является наиболее простым и дешевым решением. Гораздо эффективнее может оказаться разработка и последующее внедрение "типового решения для корпорации". Об опыте реализации такого подхода мы и хотим рассказать.

Введение: Бизнес процессы, использующие документы.

С точки зрения систем документооборота, бизнес-процессы можно разделить на три группы:

• процессы, ориентированные на документ
• процессы, использующие документы (неструктурированные данные).
• процессы, не использующие документы

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

Процессы, попадающие во вторую группу, достаточно разнообразны и разнородны. Рассмотрим некоторые примеры:

• Интернет-магазин, использующий в процессе привлечения клиента изображения продаваемых товаров. В случае успеха, формируется определенный набор документов, связанных с фактом продажи и его доставкой. Некоторые из этих документов (возможно с подписью клиента) должны храниться у продавца в течение определенного законодательством срока.
• Медицинская система, использующая, наряду со структурированными данными, кардиограммы, рентгеновские снимки и результаты других обследований в виде изображения или документа.
• Процессы третьей группы, может быть, вообще не существуют или крайне редки. Документ можно найти практически везде, просто его роль в бизнес-процессе оценивается как "пренебрежимо малая", но эта оценка может измениться. Проиллюстрируем эту мысль на примере. Один из авторов доклада имел повод познакомиться с системой "Мосэнерго", учитывающей потребление и платежи за электроэнергию и работающей исключительно со структурированными данными. Поводом для знакомства была некорректная информация о начальных показаниях нового счетчика, в результате чего оказалось, что потребление электроэнергии возросло на пару порядков по сравнению с предшествующим периодом. Информация эта была введена в систему из документа, хранящегося в некотором (бумажном) архиве. Однако извлечь документ из архива в разумные сроки не удалось. В этой же системе формируются и другие объекты, "похожие на документы", например счета на доплату (формируемые как предопределенный отчет), которые иногда распечатываются и отсылаются клиентам, но не хранятся в системе как документы. И рано или поздно интерес к внедрению систем управления контентом может возникнуть. Причины этого интереса могут быть различны:
• Риск чрезвычайных ситуаций (вспомним 11 сентября)
• Введение нормативных актов, определяющих правила работы с документами в определенных бизнес процессах
• Увеличение числа документов, используемых в бизнес процессах и/или желание повысить их эффективность
• Просто развитие систем документооборота, превратившее их из эксклюзивной технологии в общедоступную, и вызвавшее интерес к ним.

Но во всех случаях возникнет одна и та же проблема - как совместить систему управления контентом с существующими информационными системами?

Решение этой проблемыможет осуществляться разными способами:

• на основе использования систем управления базами данных. Практически все СУБД в настоящее время предоставляют возможность хранения полей типа BLOB и работы с ними, включая возможности поиска по контенту
• на основе использования систем управления контентом, которые используют те же самые СУБД и предоставляют ряд дополнительных возможностей
• на основе совместного использования обеих технологий.

Первый подход выглядит достаточно естественным для систем, работающих со структурированными данными. Действительно, ввел в таблицу "Товар" BLOB для хранения документа, а в таблицу "Заказ" - для счета-фактуры, и все проблемы интернет- магазина решены. Так ли это? Как правило, нет. Если в системе должен храниться подписанный клиентом документ, то потребуется разработка процесса ввода в систему отсканированных документов, если электронный документ хранится в системе в интересах разрешения юридических споров, то способ его хранения должен удовлетворять определенным нормативным требованиям (например, WORM - Write Once Read Many). То есть реальный объем разработки окажется гораздо больше и, что особенно обидно, будут заново разрабатываться решения, уже реализованные и постоянно развиваемые системами управления контентом. СУБД едва ли станут догонять их - использование СУБД в системах управления контентом сделало их партнерами, а не конкурентами.

Второй подход весьма привлекателен для разработки новых систем. Фактически используется та же СУБД с расширенными возможностями, и эти возможности могут быть интересны даже при отсутствии необходимости работы с документами. Достаточно забавный пример такого использования (рассказанный одному из авторов на Cisco Expo представителем EMC) - разработка Call Center с использованием Documentum, с помощью которого был реализован процесс отображения информации о клиенте на экране IP телефона в момент звонка. Забавно, но поучительно - настройка готового решения (в данном случае, Documentum workflow) гораздо привлекательнее собственной разработки.

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

Третий подход, состоит в том, что в помощь существующим бизнес-системам, работающим со структурированными данными, создаются системы для работы с документами в определенном бизнес процессе (или группе процессов) и интегрируются с ними. Такие системы мы будем называть бизнес ориентированными системами документооборота (БОСДО). Подход достаточно естественный, и на рынке есть даже готовые решения для интеграции систем документооборота с системами класса ERP или CRM. Но готовые решения разрабатываются, как правило, для наиболее распространенных систем (например, SAP R3, PeopleSoft) или для систем, используемых достаточно крупным клиентом, и не покрывают, да и не могут покрыть, всего разнообразия информационных систем, используемых в корпорации. И реализация такого подхода, в большинстве случаев, предполагает собственную или заказную разработку систем документооборота для различных бизнес процессов. Если речь идет об одном или двух бизнес процессах, то проблем нет. А если их десятки, то придется разрабатывать десятки систем, настроенных на разные бизнес процессы? Не обязательно. Можно разработать типовую БОСДО для данной корпорации. Об опыте реализации такого подхода мы и расскажем в этом докладе.

Типовое решение. А это возможно?

Да, если называть типовым решение, покрывающее основные потребности определенного класса бизнес процессов, а не универсальное решение на все случаи жизни. Вопрос скорее состоит в том, насколько представителен этот класс и какой процент потребностей это решение покрывает. Обратимся к рассмотренным выше примерам. Несмотря на внешнее разнообразие самих процессов, роль документов в этих процессах описывается одной и той же моделью. Для автоматизации некого бизнес процесса разработана система, работающая со структурированными данными (назовем ее "родительской"). Бизнес процесс порождает или использует документы, причем эти документы всегда связаны с определенными бизнес объектами, участвующими в процессе: "Заказом" в Интернет-магазине, "Пациентом" или "Заболеванием" в медицинской системе, "Клиентом" "Мосэнерго"... И во всех случаях от БОСДО требуется, в первую очередь, возможность сохранять сами документы (связав их с бизнес объектами "родительской системы"), находить и получать документы в процессе работы с этими объектами, а также выполнять редактирование, управление версиями документа и другие стандартные действия над документами. Звучит достаточно обнадеживающе, а с учетом "единства места" (корпорация, имеющая определенные корпоративные стандарты) и подавно. Начнем разработку...

Разработка БОСДО

Основными требованиями, предъявляемыми к БОСДО является малое время разработки и внедрения системы для очередного бизнес процесса, а также малые затраты, связанные с сопровожением системы и ее последующим развитием в соответствии с потребностями бизнес процесса. В силу специфики бизнес процессов достаточно трудно рассчитывать на то, что ни в одной из созданных в корпорации систем не придется реализовывать дополнительную функциональность, и эффективность типового решения определяется тем, какой процент функциональности предоставляется "из коробки". Итак, что же может быть общим?

Платформа документооборота (Система управления контентом), используемая в корпорации. В нашем случае такой платформой был Documentum.

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

Архитектура приложения, определяемая с учетом информационной стратегии корпорации. Мы разрабатывали многоуровневое Java Enterprise решение, состоящее из двух приложений: сервера бизнес логики (реализованного как поставщик Web Сервисов -WSS) и презентационного сервера:

• Сервер бизнес логики реализован в виде Java Enterprise Web Service Application, выполняющего роль поставщика данных для презентационному серверу и реализующего всю бизнес логику, оформленную в виде Java Classes. WSS взаимодействует с eContent сервером Documentum. Компоненты в архитектуре WSS реализованы в слоях. Компоненты в каждом слое взаимодействуют с компонентами из соседними слоев, общим environment, и общими объектами для всех слоев. Существует стандартные интерфейсы, определенный для всех слоев. Каждый компонент слоя должен реализовать один из доступных интерфейсов. Данная архитектура позволяет свободно расширять систему, базируясь на доступных интерфейсах и создавать компоненты, реализующих бизнес логику проекта на всех уровнях систем.
• Презентационный сервер реализован как Web приложение построенное на основе Struts Framework. Презентационный сервер взаимодействует по SOAP протоколу с WSS Server, формируя запросы на получение и обработку данных. Кроме того, на презентационный сервер возложено взаимодействие с eContent сервером Documentum в процессе получения и загрузки контента. Для реализации презентационного сервера были созданы тавлицы стилей, а также библиотеки JSP тэгов, которые поддерживают стандарт графического интерфейса корпорации и обеспечивают стандартную реализацию таблиц, форм ввода и других низкоуровневых компонентов (календари, выпадающие списки и т.д.). Все модули, реализованные в системе, оформлены как слабосвязанные компоненты с независимой портальной и Struts конфигурацией, своим набором ресурсов. Это позволяет с легкостью строить приложение из библиотеки модулей по списку требований. Это же позволяет снижать затраты на сопровождение систем - в большинстве случаев расширение функциональности обеспечивается поставкой нового модуля в те системы, где он необходим.

Данная архитектура согласуется с архитектурой хранилищ данных WSS (один или кластер) размещается в том же географическом регионе, где хранятся метаданные, а презентационные сервера - в тех регионах, где размещены хранилища контента.

Реализации WSS и презентационного сервера включают в себя помимо системных компонент бизнеснезависимые функциональные компоненты и поставляются, соответственно, в виде EAR и WAR архивов.

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

Способы и технологии получения контента, используемые в корпорации:

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

Для них разрабатываются стандартные технологии и функциональные компоненты платформы.

Таким образом, разработка и внедрение каждого последующего приложения может использовать в готовом виде достаточно много системных и бизнеснезависимых компонент. Но ведь БОСДО должна быть настроена на определенный бизнес процесс, в котором используются специфические для этого процесса бизнес объекты. Что дальше - ручная разработка?

Настройка БОСДО для бизнес процесса.

У ручной разработки есть альтернатива, существующая достаточно давно.. Называется она Model driven architecture (MDA) и состоит в автоматической генерации программного кода по модели (метамодели) приложения. Однако используется она достаточно редко, и связано это, в основном с тем, что

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

В силу этого MDA используется либо в "коробочных" продуктах), либо для "мелкооптовой" разработки информационных систем ([1]-[3]), т.е. для задачи, которую мы решаем.

Для реализации MDA (как и вм цитируемых работах) был выбран подход основанный на использовании шаблонов. Суть его состоит в следующем:

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

На основе кода бизнесзависимых компонент создаются шаблоны. При этом, шаблонами могут быть любые ресурсы (XML, Java, JSP, JS, HTML файлы и т.д.) в которые внедрены синтаксические структуры кодогенератора. Кодогенератор использует структуры в шаблонах как директивы, а модель, как параметры для обработки файлов шаблонов. В результате создаются готовые приложения на основе метаданных конкретного бизнес проекта. В зависимости от требований проекта, а точнее их соответствия требованиям БОСДО, созданные приложения могут либо совсем не требовать дальнейшей доработки, либо дополняются компонентами, реализующими редко используемую фунциональность. Последнее не исключает того, что разработанный при этом образец не будет когда-нибудь превращен в шаблон.

Релизация БОСДО как набора слабосзвязанных модулей и кодогенерация позволяют очень гибко настраивать систему под нужды заказчика. Например, есть возможность указать какой вид интеграции с системой сканирования и почты будет использована: персональная, групповая или совместная. Имеет ли проект функцию одобрения контента и метаданных в workflow документа и т.д.

Совместное использование контента различными бизнес процессами.

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

Начнем с примера. Недавно один из авторов завершил длившийся почти два года процесс перерегистрации земельного участка. Суть этого процесса состояла в посещении различных учреждений, в каждое из которых предоставлялся определенный набор документов или их копий, на основе которого создавались новые документы для хранения и передачи копий в следующую инстанцию. Некоторые из этих документов создавались заново, но, в большинстве случаев, это были уже существовавшие документы, например, кадастровый план всего поселка, который копировался, а потом подшивался в "папку" каждого собственника. Давайте помечтаем, и предположим, что в каждом из этих учреждений создана система документооборота. А как организовать обмен документами между ними - системы разные, ведомства разные, документы разные… Но работают они с одним и тем же набором бизнес объектов ("Собственник", "Строение", "Участок", "Поселок") и требуются им определенные типы документов ("Подтверждение права собственности", "План БТИ", "План участка", "Кадастровый план")., связанных с определенными экземплярами этих бизнес объектов ("участок, расположенный по адресу…"). И каждый тип документов может проверяться и храниться в электронном виде в единственной системе. Все остальные могут получать его по запросу, содержащему перечисленные выше параметры:

• Тип бизнес объекта
• Информацию, идентифицирующую экземпляр бизнес объекта
• Тип документа

Правда, для этого все должны знать, где какие документы должны (или могут) храниться. А зачем все? Разве покупатель на бирже знает, кто собирается продать интересующие его акции? Нет, он просто обращается к брокеру и получает акции.

Именно так мы и осуществили интеграцию систем документооборота корпорации.

При этом мы стремились удовлетворить следующим требованиям:

• Возможность поиска документов, хранящихся в разных приложениях, вне зависимости от используемых в каждом конкретном приложении систем управления контентом (content management systems), операционных систем, технологий и языков программирования.
• Возможность управления доступом к контенту в соответствии с моделью безопасности собственника контента.
• Высокий уровень масштабируемости, высокая производительность, легкость в администрировании.
• механизм интеграции должен быть построен на основе промышленных стандартов.
• Интеграция не должна требовать внесения серьезных изменений в интегрируемые приложения.
• использование платформенных компонент, созданных на этапе разработки бизнес ориентированных систем документооборота.

Интеграция бизнес ориентированных систем документооборота.

Для интеграции бизнес ориентированных систем документооборота была выбрана архитектура Hub-and-Spokes. В архитектуре Hub-and-Spokes центральное место занимает сервер (hub), к которому посредством адаптеров (adapters) присоединены интегрируемые приложения (spokes). Приложения взаимодействуют друг с другом не напрямую, а посредством центрального сервера. Интеграция нового приложения в данной архитектуре означает присоедение приложения к центральному серверу с помощью соответствующего адаптера. Центральный сервер-hub зачастую называют интеграционным брокером (Itegration Broker), или просто брокером. Требуемая надежность обеспечивается за счет кластеризации брокера.

В качестве протокола взаимодействия между приложениями и брокерами был выбран SOAP with Attachments over HTTP. Выбор был обусловлен следующими соображениями: данный протокол является промышленным стандартом, основой SOA (Services Oriented Architecture) и de-facto наиболее используемым в настоящее время протоколом для интеграции систем.

Для внешнего мира (потребителей документов) Брокер предоставляет два сервиса:

• предоставление списка документов заданных типов, связанных с указанным экземпляром бизнес объекта определенного типа. Для формирования этого списка Брокер рассылает запросы Адаптерам всех известных ему систем документооборота, хранящих документы заданного типа, связанные с требуемым типом бизнес объекта. Например, Брокер медицинских документов может разослать запросы на кардиограмму пациента (идентифицируемого по номеру паспорта или полиса ОМС) ко всем медицинским системам.
• Предоставление документа (из списка). Этот запрос Брокер адресует только Адаптеру приложения, владеющего документом.

Для упрощения взаимодействия между приложениями и кластером Брокеров, было принято решение не хранить состояние взаимодействия (state) на Брокере. Таким образом, Брокер выполнен как stateless компонент интеграционной модели. Все состояния (включая результаты поиска документов) хранятся Адаптерами интегрируемых приложений. На Брокере (в базе данных кластера) хранится только реестр Владельцев документов:

• Список Владельцев
• Бизнес объекты, с которыми работает Владелец
• Типы документов, которыми может располагать Владелец по каждому бизнес объекту
• адреса Адаптеров.

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

Для интеграции приложения-потребителя с брокером, предоставляются две возможности:

• По протоколу SOAP посредством универсального Адартера Потребителя (клиентских Java-библиотек). Этот механизм предназначен для Java-приложений
• По протоколу HTTP/HTPS. В этом случае запрос посылается к Презентационному серверу Брокера (Presentation Servers) - для любых приложений. Презентационный сервер представляет из себя веб-приложение взаимодействующее с Брокером по протоколу SOAP. Презентационный сервер представляет из себя особый вид приложения-потребителя, которое может выступать в виде прокси для других приложений-потребителей. Кроме того, презентационный сервер представляет собой реализацию графического интерфейса по умолчанию для пользователей, а так же реализацует административную консоль Брокера.

При построении Брокера и Адаптера Владельца использовалась реализация сервера Web сервисов, разработанная для создания бизнес ориентированных систем документооборота. А для Презентационного сервера Брокера - презентационный сервер бизнес ориентированных систем документооборота.

Общий вид архитектуры интеграционной платформы представлен на рисунке.

Ссылки

[1] назад	Особенности разработки интернет приложений масштаба предприятия. Николай Приезжий, Алексей Закис, Ирина Борисова, Михаил Лужецкий (Компания HRS)
[2] назад	Системы сквозного проектирования А. Закис, Н. Приезжий, DataX/FLORIN
[3] назад	Технология быстрой разработки приложений на основе CASE-средств фирмы CADRE. А.Закис, М.Макаров, Н.Приезжий, DataX/FLORIN