Office Business Applications
Ключевые сценарии и типовые подходы к реализации. Часть 3
Типовые подходы к реализации Office Business Applications
Приложение как канал поставки информации
Композитный интерфейс пользователя
Дополнения для Document Workflow
Задачи и нотификации, генерируемые приложениями
«Разумная» генерация задач и нотификаций
Задачи и нотификации на базе форм
Ресурсы по бизнес-вопросам, связанным с OBA
Ресурсы по техническим вопросам, связанным с OBA
В предыдущих частях нашего обзора мы узнали, что такое Office Business Applications, ознакомились с основными задачами, решаемыми с помощью OBA, обсудили возможные уровни таких приложений и рассмотрели ключевые сценарии и основные шаги по созданию Office Business Applications. Мы также изучили архитектуру Office Business Aplications и ключевые компоненты приложений. В этой части мы остановимся на типовых подходах к реализации бинзес-приложений на основе Office — так называемого Office Business Applications Patterns.
Типовые подходы к реализации Office Business Applications
Можно выделить семь основных категорий типовых сценариев, используемых при создании бизнес-приложений на основе Microsoft Office: приложение как канал поставки информации, интеграция документов, композитный интерфейс пользователя, дополнения для Document Workflow, навигация по данным, совместная работа и задачи и нотификации, генерируемые приложениями (рис. 1).
Рис. 1. Основные категории типовых сценариев
Каждый типовой сценарий содержит несколько вариантов реализации, которые мы рассмотрим далее. Основные категории типовых сценариев показаны в таблице.
Основные категории типовых сценариев
Категория |
Описание |
Приложение как канал поставки информации |
Расширение доступа к функциональности бизнес-приложений на пользователей Office |
Интеграция документов |
Генерация документов Office из бизнес-приложений. Позволяет встраивать бизнес-данные в документы и обрабатывать документы на сервере |
Композитный интерфейс пользователя |
Позволяет объединить интерфейсы к нескольким бизнес-приложениям на уровне документа или страницы SharePoint |
Дополнения для Document Workflow |
Обеспечивает контроль и мониторинг процессов работы с документами. Возможность расширения существующих бизнес-процессов |
Навигация по данным |
Предлагает более естественный способ использования бизнес-данных — поиск данных по различным бизнес-приложениям и выполнение действий над данными |
Совместная работа |
Объединение структурированных бизнес-процессов с неструктурированной совместной работой |
Задачи и нотификации, генерируемые приложениями |
Использование Outlook как единого интерфейса для получения задач и нотификаций от бизнес-приложений |
Рассмотрим каждую категорию сценариев более подробно, обсудив задачу, решаемую тем или иным сценарием, возможные варианты реализации сценария, а также технологии, которые используются для реализации этих сценариев.
Приложение как канал поставки информации
Данный сценарий обеспечивает доступ к бизнес-приложениям пользователям, работающим с Microsoft Office. Возможны два варианта реализации такого сценария: через прямую интеграцию и через так называемую опосредованную интеграцию. Для воплощения и того и другого сценария можно использовать средства разработки, включенные в состав Visual Studio Tools for Office, портальные технологии на уровне Microsoft Office SharePoint Server, а также технологию Business Data Catalog — в случае реализации опосредованной интеграции (рис. 2).
Рис. 2. Приложение как канал поставки информации
Рассмотрим сценарии, относящиеся к группе «Приложение как канал поставки информации», более подробно. Как мы помним, есть два варианта реализации этих сценариев: прямая интеграция и опосредованная интеграция.
Прямая интеграция
В случае прямой интеграции клиентские приложения Microsoft Office предоставляют непосредственный доступ к функциональности бизнес-приложений. В данном сценарии интерфейс к бизнес-приложению напрямую проецируется на интерфейс клиентского приложения Microsoft Office или портала на базе Office SharePoint Server. Несколько сценариев, которые мы рассмотрим далее, базируются на сценарии прямой интеграции. Бизнес-приложение остается неизмененным, или в него вносятся минимальные изменения, позволяющие реализовать данный сценарий. Средства, включенные в состав Visual Studio Tools for Office, позволяют реализовать интеграцию с клиентскими приложениями Office, необходимую для данного сценария. В случае использования Office SharePoint Server можно создать дополнительные web-компоненты для доступа к бизнес-приложению — этот подход является альтернативой применению опосредованной интеграции, которую мы рассмотрим далее. Использование web-компонентов может оказаться более удобным, например, в тех случаях, когда требуется обратиться к сервис-ориентированной инфраструктуре, уже существующей на уровне бизнес-приложения (рис. 3).
Рис. 3. Прямая интеграция
Опосредованная интеграция
Прямая интеграция лучше всего подходит для тех сценариев, когда необходимо использовать существующую сервис-ориентированную архитектуру, построенную вокруг бизнес-приложений. Несмотря на то что прямая интеграция реализуется достаточно быстро, она требует написания больших объемов кода, не позволяет обнаруживать существующие сервисы и не способствует созданию или повторному применению составных или композитных элементов решения на основе Microsoft Office. Подход, основанный на использовании метаданных, который лежит в основе опосредованной интеграции, позволяет создавать слабосвязанные решения, компоненты которых могут повторно применяться для реализации различных композитных решений. Microsoft впервые осуществила такой подход в технологии Information Bridge Framework (IBF). Несмотря на то что IBF успешно использовалась корпоративными разработчиками и компаниями, производящими программное обеспечение, для реализации большинства сценариев требовалась более простая и более гибкая технология. В состав Office System 2007 входит технология Business Data Catalog (BDC), которая поддерживает большую часть функциональности IBF, позволяет задавать бизнес-объекты и связанные с ними сервисы, управлять ими через web-сервисы и источники данных на уровне ADO .NET и создавать на их основе интеграционные решения для Office SharePoint Server.
Вариант опосредованной интеграции — это расширение сценария прямой интеграции за счет применения хранилищ метаданных, например предоставляемых BDC, для реализации уровня абстракции поверх прямой интеграции. В случае использования Business Data Catalog появляется возможность создания представлений на уровне только чтения для различных компонентов SharePoint без необходимости написания интеграционного кода. Различные композиционные сценарии с применением компонентов SharePoint, связанных с бизнес-объектами и данными через BDC, также могут быть реализованы без написания кода.
При необходимости функциональность BDC можно расширить дополнительным кодом, что может потребоваться в тех сценариях, когда необходимо вносить изменения в бизнес-данные и передавать эти изменения в бизнес-приложения. Помимо использования интерфейсов на базе web-сервисов, Business Data Catalog поддерживает систему безопасности на уровне signle sign-on, реализованную на основе отображения учетных записей (credentials mapping) — рис. 4.
Рис. 4. Опосредованная интеграция
Интеграция документов
Данный сценарий позволяет реализовать генерацию документов Office из бизнес-приложений, а также встраивать бизнес-данные в документы и обрабатывать документы на сервере. Возможные варианты реализации данного сценария — непосредственная генерация документов и создание так называемых разумных документов: встраивание бизнес-информации в документы, встраивание шаблонов документов и распознавание бизнес-данных. Для реализации этих сценариев применяются новые форматы файлов офисных документов (Open XML), средства разработки, включенные в состав Visual Studio Tools for Office, технология Business Data Catalog, а также разметка документов (рис. 5).
Рис. 5. Интеграция документов
Рассмотрим варианты реализации сценариев интеграции документов более подробно. Как мы помним, существует несколько таких сценариев: генерация документов приложениями и создание разумных документов, в том числе встраивание бизнес-информации в документы, встраивание шаблонов документов и распознавание бизнес-данных.
В современном мире огромный объем информации, порождаемой и потребляемой в компаниях, располагается в различных документах. Исследования показали, что структурированное хранилище данных, используемое бизнес-приложениями, содержит только 30% корпоративной информации. Остальные данные находятся в документах, хранимых на компьютерах пользователей, причем зачастую эти данные дублируют те, что хранятся в бизнес-приложениях. С появлением Office System 2007 и нового формата офисных документов Open XML разработчики получили возможность создавать документы, которые содержат данные, экспортируемые из бизнес-приложений, а также извлекать данные из документов и при необходимости экспортировать их в бизнес-приложения.
Генерация документов приложениями
Генерация документов приложениями — наиболее часто применяемый сценарий для интеграции Office в бизнес-приложения. В этом сценарии бизнес-данные внедряются в офисный документ — обычно это происходит в пакетном режиме на сервере, хотя в ряде случаев возможна реализация такого сценария и на клиенте. Примерами этого сценария являются экспорт данных в электронные таблицы Excel, генерация отчетов в Microsoft Word и т.п. (рис. 6).
Рис. 6. Генерация документов приложениями
До появления Office System 2007 существовали определенные проблемы с масштабируемостью данного сценария, поскольку в большинстве случаев в серверной реализации использовалось однопоточное клиентское приложение семейства Office для генерации необходимых документов. В Office System 2007 поддерживается формат хранения документов Open XML, а следовательно, не требуется запускать на сервере клиентские приложения Office для того, чтобы сгенерировать необходимый документ, — достаточно написать код, например на Microsoft .NET Framework, применяющий Open XML SDK для создания офисных документов и заполнения их данными из бизнес-приложений на лету.
Напомним, что Open XML является стандартом уровня ECMA — более подробно об этом можно узнать на сайте http://www.openxmldeveloper.org и из наших обзоров, опубликованных в № 6’2006 (Office 2007 Open XML Format) и № 8’2007 (Microsoft Office 2007 Open XML. Часть 2).
Группа сценариев, называемых «разумные документы», включает сценарии встраивания бизнес-информации в документы, встраивания шаблонов документов и распознавания бизнес-данных, находящихся в документах. Все они базируются на предположении, что визуализация бизнес-данных, манипуляция подобными данными и их анализ часто выполняются из офисных приложений, более знакомых обычным пользователям, а документы, содержащие бизнес-данные, намного проще партнерам и клиентам передать, чем предоставлять им доступ к части функциональности бизнес-приложения. Помимо этого сценарии разумных документов подразумевают, что бизнес-данные, располагаемые в них, являются динамическими и транзакционными — то есть структурированное содержание, сохраняемое в документах, может использоваться для обновления бизнес-приложений, вызова сервисов, запуска бизнес-процессов и т.п. Расширяемая схема на основе Open XML поддерживает встраивание в документ практически любых бизнес-данных. Подмножество информации из бизнес-приложения перемещается вместе с документом, превращая такой документ в контейнер с данными, над которыми можно выполнять те или иные действия с помощью как клиентской, так и серверной логики. Расширенные средства поиска могут применяться для обработки информации, хранимой в документах и, таким образом, расширять сценарии работы с документами.
Встраивание бизнес-информации в документы
В данном сценарии информация из бизнес-приложений встраивается в офисные документы Word или Excel. Панель задач (Task Pane) офисных приложений может служить в качестве основы для пользовательского интерфейса поверх сценариев прямой или опосредованной интеграции. С помощью формата Open XML можно встраивать в документ структурированные данные и процессы — пользователи могут просматривать или выполнять поиск бизнес-данных по каким-либо критериям и выбирать подмножество данных для встраивания в документ (рис. 7).
Рис. 7. Встраивание бизнес-информации в документы
Данные могут присутствовать в документе либо непосредственно, либо в виде встроенной XML-части. В случае использования документов Word 2007 данные в XML-частях могут отображаться в документе с помощью компонентов, называемых Word Content Controls. Такой подход обеспечивает абстракцию между данными и приложением, что обеспечивает ему приоритет по сравнению с непосредственным встраиванием данных в документ.
Другой подход — применение возможностей SharePoint Server для вклеивания в документ в виде его свойств пар данных «имя-значение» — такой сценарий не требует написания кода. Данные, извлекаемые из бизнес-приложений средствами Business Data Catalog, могут быть отображены в списках SharePoint Server и других хранилищах документов на портале. Бизнес-данные, отображенные на компоненты SharePoint, будут унаследованы документами, созданными на основе соответствующих шаблонов или сохраненными в соответствующих хранилищах. Следовательно, такой сценарий может использоваться для автоматического заполнения свойств документов и обеспечения их синхронизации с данными, хранимыми в бизнес-приложениях. Кроме того, свойства документов могут быть связаны с компонентами Word 2007, что позволяет встраивать бизнес-данные в документы Word и обеспечивать их синхронизацию средствами Business Data Catalog.
Встраивание шаблонов документов
Более комплексный сценарий генерации документов с внедренными в них бизнес-данными состоит в применении шаблонов документов, на основе которых генерируются сами документы. Подобные шаблоны могут включать метаданные из бизнес-приложений, а также элементы разметки документов: Content Controls, схемы XML, закладки, именованные диапазоны данных и т.п. Эти элементы разметки будут использоваться для связи документа с бизнес-данными. Создание шаблона может быть реализовано с помощью панели задач — так же, как и в предыдущем сценарии, но вместо просмотра и отбора бизнес-данных в нашем сценарии пользователям должна быть предоставлена возможность отбора метаданных для включения в состав шаблона. Эти метаданные служат для разметки схемы документа и последующего включения в него данных, извлекаемых из бизнес-приложения. Такой сценарий позволяет конечным пользователям создавать шаблоны документов разной сложности и автоматически заполнять их данными, не прибегая к помощи разработчиков (рис. 8).
Рис. 8. Встраивание шаблонов документов
Объединение двух рассмотренных сценариев — генерации шаблонов документов и генерации документов на основе шаблонов — может существенно расширить сферу применения решений, требующих включения бизнес-данных в документы.
Распознавание бизнес-данных
Еще один сценарий, относящийся к группе разумных документов, — это распознавание бизнес-данных, включенных в состав офисного документа. Предположим, что фрагмент документа содержит семантически осмысленную информацию в контексте бизнес-приложения. Распознавание такой информации может быть реализовано на уровне метаданных и разметки документа (как мы обсудили в предыдущем сценарии) средствами Content Controls, XML-схемы, закладок, именованных диапазонов и прочего или с помощью технологии Smart Tags, поддерживаемой в приложениях Microsoft Office. После того как мы распознали информацию, мы можем выполнить над ней какие-либо осмысленные действия. В серверном сценарии такая информация может быть извлечена и использована для обновления данных в бизнес-приложениях или для запуска бизнес-процессов; в клиентских сценариях распознанная информация может служить в качестве контекста для отображения дополнительных данных в панели задач или для переключения вкладок в интерфейсном элементе «лента».
Композитный интерфейс пользователя
Данный сценарий позволяет объединить интерфейсы к нескольким бизнес-приложениям на уровне документа или страницы SharePoint (рис. 9).
Рис. 9. Композитный интерфейс пользователя
К возможным способам реализации такого сценария отнесем интерфейс, управляемый контекстом, композитный интерфейс на основе компонентов, композицию RSS и Web Services, а также отображение аналитики в бизнес-приложениях. Для реализации этих сценариев применяются web-компоненты (Parts), средства разработки, включенные в состав Visual Studio Tools for Office, для создания новых элементов «ленты» и панелей задач, технология Business Data Catalog, сервисы Excel и компоненты для отображения данных на портале.
Пользователям довольно часто требуется обращаться к данным, хранимым в разных бизнес-приложениях, и объединять извлеченные данные в рамках документов. Помимо этого информация о той или иной бизнес-сущности может храниться в различных системах. Эффективное извлечение подобной информации требует реализации составного, композитного интерфейса. Рассматриваемые в этом разделе сценарии создания композитных интерфейсов позволяют независимым разработчикам подготавливать свои приложения к включению в состав композитного интерфейса, который может быть реализован как на уровне офисных документов, так и на уровне портала на базе SharePoint Server.
Интерфейс, управляемый контекстом
В данном сценарии используется контекстная информация для динамического изменения интерфейса. Контекстная информация может быть статической (например, на уровне конфигурационного файла) или динамической (например, отображение/сокрытие элементов «ленты» в зависимости от контекста, полученного с помощью рассмотренного выше сценария распознавания бизнес-данных).
Поскольку такой сценарий предполагает использование разных бизнес-приложений, в конкретный момент композиции могут быть составлены из интерфейсов к различным приложениям, актуальным для данного контекста.
Для клиентских приложений Microsoft Office различные модули дополнений могут быть либо статически сконфигурированы, либо динамически загружены и активированы на основе распознанной информации. Этот сценарий может быть реализован как на уровне панелей задач (в этом случае отдельная панель задач создается для каждого бизнес-приложения), так и на уровне элементов «ленты» — вкладки, группы, элементы внутри групп. Когда пользователь инициирует какие-либо действия с бизнес-приложением через элементы «ленты», активизируется соответствующая панель задач, в которой отображаются данные и возможные действия над ними, актуальные для этого контекста.
В случае применения расширенных элементов «ленты» и дополнительных панелей задач рекомендуется использовать стандартные подходы к реализации интерфейсов — панель должна активироваться только в результате действий пользователя, например при нажатии соответствующей кнопки; пользователь, в свою очередь, тоже должен иметь возможность деактивировать и скрыть панель задач — осуществлять автоматическую активацию/деактивацию дополнительных панелей задач не рекомендуется (рис. 10).
Рис. 10. Интерфейс, управляемый контекстом
Рассмотренный выше сценарий может быть объединен со сценарием разумных документов для обеспечения контекста для переключения элементов составного интерфейса. В этом варианте, когда пользователь выбирает содержимое документа и оно распознается как содержащее ассоциированные с бизнес-приложением данные, соответствующие интерфейсные элементы — на уровне «ленты» и на уровне панели задач — становятся активными. В этом сценарии также могут использоваться контекстные меню и контекстные вкладки для отображения набора действий над данными, актуальных в контексте того или иного бизнес-приложения.
Рассматриваемый нами сценарий тоже может быть реализован через представления в SharePoint Server. Например, дополнительные результаты поиска могут быть интегрированы в Search Center в виде дополнительных вкладок, отображающих данные, полученные для того или иного контекста (рис. 11).
Рис. 11. Реализация составного интерфейса, управляемого контекстом
Композитный интерфейс на основе компонентов
В данном сценарии мы создаем представление, которое собирает компоненты одного или нескольких бизнес-приложений, которые взаимодействуют между собой для расширения функциональности и предоставления дополнительных сервисов. Например, в момент загрузки представления компонент, который отображает список клиентов, полученный из CRM-системы, может подключаться к полученной из ERP-системы информации о заказах, размещенных клиентами. При выборе определенного клиента в списке возникает событие, обработчик которого обновляет информацию в списке заказов — обращается к ERP-системе для получения детальной информации о заказах для выбранного клиента (рис. 12).
Рис. 12. Композитный интерфейс на основе компонентов
В Microsoft Office SharePoint Server инфраструктура web-компонентов основана на библиотеке web-компонентов ASP .NET 2.0, которую можно использовать для создания компонентов, отображающих данные из различных бизнес-приложений на одной странице портала. В состав SharePoint Server входят web-компоненты Business Data Catalog, Excel Services, компоненты для фильтрации данных, а также ряд других компонентов, которые могут применяться для решения конкретной задачи. Кроме того, можно создать собственные компоненты, которые будут использовать сценарии прямой или опосредованной интеграции с применением Business Data Catalog для доступа к данным в бизнес-приложениях. Конечные пользователи могут создавать настраиваемые страницы портала, выбирая необходимые им компоненты из галереи доступных web-компонентов. После того как два компонента будут связаны между собой, они смогут обмениваться данными и задавать контекст, который сможет влиять на отображение данных. Один компонент может посылать данные нескольким компонентам — таким образом, появляется возможность динамического изменения содержимого компонентов, управляемого контекстом.
Композиция RSS и Web Services
Данный сценарий представляет собой расширение сценария использования компонентов для создания составного интерфейса. В данном случае бизнес-приложение применяет RSS-канал или web-сервисы для поставки информации. Компонент Data View, входящий в состав Windows SharePoint Services v3, служит для форматирования и отображения полученных таким способом данных. Сценарий композиции на основе RSS и web-сервисов особенно интересен для реализации обмена данными между компаниями (business-to-business, B2B) с использованием платформы Office Live. Рассмотрим следующий пример. Предположим, существует крупная компания-производитель, пользующаяся услугами нескольких небольших поставщиков. Для управления цепочкой поставок компания-производитель применяет SCM-систему, поддерживающую программные интерфейсы на уровне web-сервисов для доступа к информации о запасах и прогнозах на спрос. Производители публикуют спецификации продуктов в виде RSS-потока. Большинство производителей использует Office Live для упрощения управления операциями. Поскольку Office Live базируется на Windows SharePoint Services v3, поставщик может создать информационную панель с тремя компонентами Data View: один из них будет служить для отображения текущего списка запасов на складе, второй — для отображения прогнозов на спрос, а третий — для отображения спецификации продуктов, полученных из RSS-потока (рис. 13).
Рис. 13. Композиция RSS и Web Services
Поставщики управляют состоянием запасов через простые списки SharePoint типа каталога и склада. Эти списки также могут отображаться в панели с помощью компонентов Data View. После того как компонент, отображающий каталог продуктов, соединен с другими компонентами в панели через идентификатор продукта, конечный пользователь получает возможность выбрать продукт из каталога, посмотреть состояние склада у поставщика и у производителя, получить представление о спросе и детальную информацию спецификации на выбранный продукт.
Отображение аналитики
Сценарий отображения аналитики является частным случаем сценария применения компонентов для создания составного интерфейса. В этом сценарии пользователи получают средства анализа данных — для реализации используются Excel Services и соответствующие компоненты, входящие в состав Microsoft Office SharePoint Server. Как известно, Excel Services позволяют отображать электронные таблицы Excel в web-браузере. Пользователи, выполняющие роли финансовых аналитиков, планировщиков бизнеса, инженеров и других, активно применяют Excel для анализа и визуализации данных. Они могут создавать «книги» Excel с помощью формул, простых и сводных таблиц, графиков и т.п., а также подсоединяться к бизнес-системам для получения необходимых данных. Созданные таким образом «книги» Excel могут быть опубликованы на портале SharePoint Server и отображены с помощью компонентов Excel Service. Последние могут быть соединены с другими компонентами, например с фильтрами, компонентами BDC и компонентами, разработанными на основе ASP .NET, для решения специфических задач (рис. 14).
Рис. 14. Отображение аналитики
Другим важным компонентом, входящим в состав Microsoft Office SharePoint Server, является компонент для отображения ключевых индикаторов — Key Performance Indicator (KPI) Web Part, который позволяет задавать ключевые индикаторы на основе данных в любом списке SharePoint, в том числе в списке Business Data Catalog.
Дополнения для Document Workflow
Данный сценарий позволяет обеспечить контроль и мониторинг процессов работы с документами, а также реализовать возможность расширения существующих бизнес-процессов. Возможны два варианта реализации данного сценария: в первом бизнес-приложение инициирует Document Workflow, а во втором реализуется кооперация между Document Workflow. Для реализации этих сценариев используются Windows Workflow Foundation, хранилище на уровне SharePoint, а также технология Business Data Catalog (рис. 15).
Рис. 15. Дополнения для Document Workflow
Инициация Document Workflow бизнес-приложением
Компании часто применяют данные из бизнес-приложений для создания документов, которые должны пройти этапы обсуждения, редактирования и утверждения. Например, отчеты должны проверяться на соответствие стандартам — они могут быть опубликованы в хранилище SharePoint для отслеживания прохождения проверки. Механизмы управления документами в SharePoint будут отслеживать прохождение документа и уведомлять все заинтересованные стороны о наступлении сроков проверки или перехода документа на следующий этап. Одним из способов получения большего контроля над документами является генерация документа из бизнес-приложения непосредственно в библиотеку документов SharePoint, с которой ассоциированы соответствующие процедуры проверки (рис. 16).
Рис. 16. Инициация Document Workflow бизнес-приложением
В качестве альтернативы документ определенного типа, например форма InfoPath, может быть ассоциирован как тип по умолчанию для данной библиотеки документов. В этом случае процедура инициируется простым добавлением документа в библиотеку документов (рис. 17).
Рис. 17. Инициация Document Workflow
бизнес-приложением (вариант 2)
Кооперация между Document Workflow
В более комплексных сценариях может быть несколько взаимодействий между документами и бизнес-прилоложениями. Например, в процессе проводки документа на каждом этапе может быть доступно только подмножество действий над документом или не все данные могут быть собраны при начальной публикации документа. Для реализации таких сценариев можно использовать кооперацию между несколькими Document Workflow. Можно выделить два способа реализации. В первом случае мы применяем рассмотренный выше сценарий инициации Document Workflow бизнес-приложением, объединенный со сценарием создания разумных документов. В этом составном сценарии документ содержит данные из бизнес-приложения, модуль расширения клиентского приложения Office (Word или Excel) взаимодействует с бизнес-приложением с помощью данных, находящихся внутри документа (рис. 18).
Рис. 18. Кооперация между Document Workflow (вариант 1)
Workflow предоставляет логику проводки документа, а сам документ обеспечивает взаимодействие с бизнес-приложением в рамках того или иного контекста. Недостатком такого подхода является то, что невозможно полноценно отследить состояние всего процесса, так как оно разделено между взаимодействиями с документом на клиенте и состоянием workflow на сервере.
Второй вариант реализации данного сценария предполагает создание workflow для решения специфической задачи и включение этого workflow в библиотеку активностей в SharePoint Server (рис. 19).
Рис. 19. Кооперация между Document Workflow (вариант 2)
Отметим, что не вся необходимая для полноценного управления документом функциональность может быть реализована только на сервере. Таким образом, в зависимости от конкретной задачи рекомендуется использовать лучший из двух описанных вариантов реализации сценариев кооперации между Document Workflow.
Навигация по данным
Такой сценарий позволяет реализовать естественный способ применения бизнес-данных — поиск данных по различным бизнес-приложениям и выполнение действий над данными. Этот сценарий не подразумевает несколько вариантов реализации и может быть создан средствами поиска, интегрированными в платформу Microsoft Office SharePoint Services, а также средствами технологии Business Data Catalog (рис. 20).
Рис. 20. Навигация по данным
Механизмы поиска существенно облегчают и упрощают работу с бизнес-данными. Не случайно поисковые механизмы в Microsoft Office SharePoint Server for Search включают возможность индексации бизнес-сущностей и бизнес-данных. Обеспечена возможность ассоциации каких-либо действий над бизнес-сущностями, полученными в результате работы поисковой системы. Когда набор бизнес-сущностей отображается в интерфейсе конечного пользователя, отображаются и механизмы воздействия на сущности, при этом пользователи могут активировать их для выполнения каких-либо действий на стороне бизнес-приложения. Реализация такого сценария позволяет расширить спектр возможностей пользователей в рамках одного интерфейса на базе Microsoft Office (рис. 21).
Рис. 21. Навигация по данным. Шаг 1
Для навигации по данным необходимо выполнить два основных действия. Во-первых, интегрировать содержимое бизнес-приложения в SharePoint, для чего используются механизмы, предоставляемые технологией Business Data Catalog, которые позволяют интегрировать данные и проиндексировать их на уровне SharePoint. Портальные технологии SharePoint также поддерживают инкрементную индексацию (рис. 21).
Во-вторых, после того как данные проиндексированы, выполнение поиска может привести к нахождению данных из бизнес-приложений, а навигация по данным и обращение к самим приложениям могут быть интегрированы в страницу, отображающую результаты поиска. Дополнительные вкладки на странице Search Center также могут использоваться для категоризации результатов поиска (рис. 22).
Рис. 22. Навигация по данным. Шаг 2
За счет применения свойств на уровне результатов поиска одна бизнес-сущность может быть ассоциирована с несколькими бизнес-системами.
Совместная работа
В задачу этого сценария входит объединение структурированных бизнес-процессов с неструктурированной совместной работой. Данный сценарий не подразумевает нескольких вариантов реализации и может быть создан посредством Windows SharePoint Services и сервисов на базе форм InfoPath (рис. 23).
Рис. 23. Совместная работа
Традиционные бизнес-приложения классов CRM, ERP, PLM, SCM и прочие отлично справляются с выполнением структурированных бизнес-процессов над данными, но, когда требуется неструктурированная работа пользователей, приходится искать подходы для обеспечения совместной работы над бизнес-данными. В большинстве случаев неструктурированная совместная работа требует участия пользователей, которые не применяют бизнес-приложения и даже не имеют доступа к ним.
Традиционно такие совместные действия выполняются через электронную почту. Но по мере роста числа участников, объема информации, времени, требуемого на сбор данных, и ряда других факторов применение электронной почты становится неэффективным и приводит к задержкам и ошибкам. Для решения этих проблем можно использовать описанный далее сценарий совместной работы.
В состав Microsoft Office SharePoint Server входит шаблон web-сайта под названием Team Site, который может применяться для совместной работы над какой-либо бизнес-задачей. Командный сайт содержит библиотеку документов, список дискуссий, список задач, общий календарь, механизмы управления проектами и ряд других компонентов, позволяющих реализовать совместную работу. Данный сайт может быть защищен от доступа к нему не членов команды.
В нашем сценарии можно создавать командные сайты для отдельных бизнес-сущностей или бизнес-процессов, например запрос на оказание услуг, бюджетирование, анализ, прогнозирование и т.п. Контекст бизнес-сущности может служить для заполнения соответствующих разделов необходимыми бизнес-данными. Связь между бизнес-сущностью и сайтом осуществляется таким образом, что пользователь может перейти из интерфейса бизнес-приложения непосредственно на сайт. Как вариант расширения данного сценария можно рассмотреть возможность встраивания интерфейса к командному сайту в интерфейс бизнес-приложения — таким образом мы сможем реализовать совместную работу, полностью управляемую контекстом. Пользователи, не имеющие доступа к бизнес-приложениям, могут участвовать в совместной работе через web-интерфейс. Для этого им может потребоваться определенный контекст в рамках бизнес-сущностей. В таком случае для отображения бизнес-данных можно использовать web-компоненты, которые будут задействовать сценарии прямой или опосредованной интеграции для получения даных из бизнес-приложений.
Задачи и нотификации, генерируемые приложениями
В задачу данного сценария входит возможность применения Outlook как единого интерфейса для получения задач и нотификаций от бизнес-приложений. Существует несколько вариантов реализации данного сценария: от простой доставки задач и нотификаций до прямой и опосредованной синхронизации задач, «разумной» генерации задач и нотификаций, а также генерации задач и нотификаций на базе форм. Для реализации этих сценариев можно использовать механизмы интеграции Outlook 2007 и SharePoint, средства разработки, включенные в состав Visual Studio Tools for Office, а также сервисы на базе форм InfoPath (рис. 24).
Рис. 24. Задачи и нотификации, генерируемые приложениями
Многие бизнес-приложения поддерживают механизмы раздачи заданий и рассылки уведомлений пользователям. Эти задания и уведомления видны только при обращении пользователей к бизнес-приложению. Поскольку в организациях обычно применяется несколько бизнес-приложений, управление заданиями и уведомлениями становится комплексным, что приводит к неэффективному управлению заданиями и задержкам в получении уведомлений и реакции на них. Эта проблема может быть решена переадресацией задач и уведомлений в единую точку, в качестве которой может выступать инструмент, ставший практически стандартным для всех офисных работников, — Microsoft Outlook. Далее мы рассмотрим несколько сценариев, связанных с переадресацией задач и уведомлений.
Простая доставка задач и нотификаций
В этом сценарии бизнес-приложение доставляет пользователям задания и уведомления в виде заданий и электронных сообщений Outlook. В таком сценарии поддерживается однонаправленная передача информации: изменения, внесенные пользователем в Microsoft Outlook, не поступают обратно в бизнес-приложение. Детали о задании и уведомлении передаются в теле электронного сообщения. Язык гипертекстовой разметки HTML может использоваться для форматирования сообщений, включать ссылки на элементы бизнес-приложений, где пользователь сможет получить дополнительную информацию о задании или уведомлении. В варианте Push бизнес-приложение доставляет задания и уведомления на сервер Microsoft Exchange Server. Пользователи могут получать данные через Outlook, Outlook Web Access (OWA) или Pocket Outlook (Smart Phone/Pocket PC — рис. 25).
Рис. 25. Простая доставка заданий и уведомлений (вариант Push)
В варианте Pull модуль расширения для Outlook обращается к бизнес-приложению для получения списка заданий и уведомлений и на основе полученной информации создает задания в Outlook. В качестве альтернативы бизнес-приложение может поставлять через RSS-канал информацию о заданиях и уведомлениях, на которую могут быть подписаны пользователи Outlook 2007. Данный вариант может оказаться подходящим для реализации поставки уведомлений, но может и вызвать сложности с поставкой расширенной информации о заданиях (дата исполнения, приоритет, статус и т.п. в рамках RSS-потока — рис. 26).
Рис. 26. Простая доставка заданий и уведомлений (вариант Pull)
Синхронизация задач
В этом сценарии бизнес-приложение посылает пользователям задания через Exchange или Outlook и они синхронизируются. Таким образом, бизнес-приложение может посылать обновления заданий, которые уже помещены в почтовый ящик пользователя, а пользователь может обновлять задания в Outlook и эти обновления будут переданы обратно в бизнес-приложение.
Существует два варианта реализации данного сценария в зависимости от выбранного способа синхронизации. В первом варианте, называемом прямой синхронизацией, задания синхронизируются с помощью дополнительного модуля, созданного для Outlook. Задача данного модуля — синхронизция заданий в бизнес-приложении и в Outlook. Модуль расширения обращается к бизнес-приложению для получения заданий и либо создает новое задание в Outlook, либо обновляет уже существующее. Тот же модуль следит за изменениями в Outlook и передает их обратно в бизнес-приложения. Корректно спроектированный модуль расширения должен также уметь отслеживать конфиликты при синхронизации и работать в отсоединенном режиме, при котором пользователь вносит обновления в задания в Outlook, но бизнес-приложение ему недоступно.
Второй вариант синхронизации называется опосредованной синхронизацией — в этом случае Microsoft Office SharePoint Server 2007 служит посредником между бизнес-приложением и Outlook и обеспечивает синхронизацию заданий. В этом сценарии применяются две ключевые функции SharePoint Server, позволяющие упростить логику синхронизации: возможность синхронизации списка заданий SharePoint Server (Task List) с заданиями Outlook 2007 и событийный механизм, который может вызывать код при изменении содержимого списка заданий. В нашем случае бизнес-приложение публикует задания в список Task List, расположенный на портале, а поскольку этот список доступен всем пользователям, бизнес-приложение должно корректно заполнять поле Assigned To для того, чтобы задание нашло своего адресата (рис. 27).
Рис. 27. Синхронизация задач
В качестве альтернативы бизнес-приложение может публиковать задания на индивидуальных страницах пользователей. Список заданий SharePoint Server (Task List) реплицируется в Outlook 2007 и поддерживается в синхронном состоянии через штатные механизмы, встроенные в платформу. Когда пользователь обновляет задание в Outlook 2007, изменения автоматически публикуются в Task List на портале. В этом случае возникает событие, связанное с изменением содержимого списка, и код обработчика данного события может внести изменения в бизнес-приложение. Таким образом, Microsoft Office SharePoint Server 2007 обеспечивает синхронизацию заданий, разрешение конфликтов, которые могут возникнуть при синхронизации, и работу в отсоединенном режиме. Задача разработчика — реализовать логику публикации заданий из бизнес-приложения и механизм обновления бизнес-приложения в ответ на возникновение события, связанного с изменением содержимого списка Task List на портале.
«Разумная» генерация задач и нотификаций
Для выполнения каких-либо действий над задачами и уведомлениями, посылаемыми бизнес-приложениями пользователям, обычно требуется подключение к приложению, поиск необходимой информации и ее обновление. Этот сценарий может быть оптимизирован за счет того, что пользователи выполняют все необходимые действия в Outlook в контексте задания или электронного сообщения. Ключевой концепцией данного сценария является распознавание контекста и данных, включенных в задание или в электронную почту. Такое распознавание может быть реализовано на уровне дополнительных свойств, Smart Tags, синтаксического разбора текста или посредством регулярных выражений. После того как контекст и встроенные данные распознаны, соответствующие действия могут быть отображены в панели задач Outlook или в дополнительных элементах меню.
Задачи и нотификации на базе форм
Данный сценарий является вариантом описанного выше сценария «разумной» генерации заданий и нотификаций. В таком случае бизнес-приложение заполняет шаблон формы InfoPath и отправляет ее пользователю по электронной почте. Пользователь открывает письмо и заполняет форму. InfoPath облегчает проверку вводимых данных, поддерживает вычисления и логику. Помимо этого панель задач в InfoPath может содержать дополнительные данные, извлеченные из бизнес-приложения. Пользователь отсылает заполненную форму через вызов web-сервиса. Реализация данного сценария возможна путем интеграции между Outlook 2007 и InfoPath 2007 — форма может быть отослана по электронной почте без развертывания отдельного шаблона, поскольку шаблон уже находится в теле письма. С присоединенной к письму формой можно ознакомиться в панели предварительного просмотра в Outlook.
Вариант реализации данного сценария может использовать InfoPath Forms Services — сервисы, реализованные в Office SharePoint Server 2007 и позволяющие заполнять формы непосредственно из web-браузера. В этом случае форма помещается в библиотеку форм на портале и ссылка на форму отсылается пользователю.
Заключение
В данном обзоре мы познакомились с различными аспектами создания бизнес-приложений на основе Microsoft Office System 2007. Мы узнали, что такое Office Business Applications, ознакомились с основными задачами, решаемыми с помощью OBA, обсудили возможные уровни таких приложений и рассмотрели ключевые сценарии и основные шаги по созданию Office Business Applications. Мы также изучили архитектуру Office Business Aplications и ключевые компоненты таких приложений. Наш обзор мы завершли подробным рассмотрением более 20 ключевых сценариев реализации различных задач в рамках Office Business Applications. Ниже перечислены основные ресурсы, которые помогут вам в более глубоком изучении OBA.
Ресурсы по бизнес-вопросам, связанным с OBA
Office Business Applications — http://office.microsoft.com/en-us/products/FX102204261033.aspx?pid=CL100796341033
Microsoft Office Business Applications Central — https://www.obacentral.com/
O2 OBA Challenge — http://www.o2obachallenge.com/
Office Solution Showcase — http://microsoft.com/offce/showcase
Office Business Applications FAQ — http://office.microsoft.com/en-us/products/HA102200721033.aspx
Innovate On Microsoft Office System 2007 — http://InnovateOnOffice2007.com
Ресурсы по техническим вопросам, связанным с OBA
Office Developer Center — http://msdn2.microsoft.com/en-us/office
OBA Developer Portal — http://msdn2.microsoft.com/en-us/office/aa905528.aspx
Microsoft Architecture site — http://msdn.microsoft.com/architecture
Office Business Applications: Building Composite Applications Using the Microsoft Platform — http://msdn2.microsoft.com/en-us/architecture/bb220800.aspx
Building Office Business Applications — http://msdn2.microsoft.com/en-us/library/bb266337.aspx
Создание приложений на основе Office Business Applications — http://www.microsoft.com/rus/msdn/publish/articles/bb266337.mspx