SharePoint изнутри: Интеграция приложений Office

Службы Microsoft Windows SharePoint Services (WSS) 3.0 и Microsoft Office SharePoint Server (MOSS) 2007 эффективно интегрируются с настольными приложениями в выпуске 2007 системы Microsoft Office, способствуя успешной совместной работе над документами, таблицами, календарями, контактными данными и иным материалами. В сущности, интеграция настолько эффективна, что можно сказать, что выпуск 2007 системы Office является единой платформой для офисных решений.

Это очень существенно для организаций, полагающихся на технологию Microsoft® Office для повышения производительности информационных работников. Однако для организаций с портфелем разнообразных приложений Office подобного уровня стандартной совместимости недостаточно. Выпуск 2007 системы Microsoft Office предоставляет необходимые возможности интеграции, хотя интерфейсы и компоненты работают не во всех случаях и недостаточно подробно документированы. Это затрудняет для сторонних разработчиков интеграцию технологии SharePoint® со своими приложениями, а их клиентам еще более сложно предоставить единое решение информационным работникам.

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

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

Это и представляет сложность. Необходим клиентский компонент, доступный только при развертывании системы Office на рабочих станциях. Но даже если система Office развернута, в зависимости от настройки и топологии узла SharePoint этот компонент может работать ненадежно.

Для решения этой проблемы я создал собственное решение, позволяющее интегрировать любые приложения, такие как Блокнот, Adobe Reader или Autodesk AutoCAD, без необходимости развертывания Office. Это решение также демонстрирует причину ошибки интеграции приложений на основе стандартных компонентов Office в некоторых случаях. Это решение, а также поэтапные указания по развертыванию и настройке приведены в сопроводительном материале к этой статье, доступном в разделе кода для загрузки .com.

Интеграция приложений Office

С точки зрения пользователя меню SharePoint работают так же, как и меню «Пуск» Windows®. Создание нового документа в библиотеке документов осуществляется очень просто. выберите пункт «Создать», затем «Создать документ», после чего запустится Microsoft Office Word 2007. Правка существующих документов также осуществляется просто. Установите указатель на документ, откройте раскрывающееся меню поля правки элементов управления (Edit Control Box – ECB) и выберите «Изменить в Word». Иногда вспоминается, что Word 2007 запущен с веб-страницы через JavaScript, приложение запущено локально, а документ находится в базе данных SQL Server®, и что веб-сервер находится в пределах пути доступа к данным, как показано на рис. 1.

Рис. 1. Работа с документом Word в SharePoint

Несмотря на подобные сложности, работа пользователя на рабочей станции Windows с установленным выпуском 2007 системы Microsoft Office не вызывает затруднений. Работа с документами в библиотеке SharePoint очень сходна с работой с локальными файлами и файлами в общей сетевой папке.

Однако на рабочей станции Windows без установленного выпуска 2007 системы Microsoft Office или Office 2003 пользовательский интерфейс другой. При выборе пункта «Новый документ» или «Изменить в Word» просто появляется диалоговое окно с сообщением о недоступности приложения, совместимого со службами Windows SharePoint.

И это не удивительно. Для предоставления единого интерфейса, с которым так удобно работать пользователям Office, необходима совместная работа нескольких элементов. Для отображения нужных команд в меню «Создать» и ECB службам SharePoint необходимы сведения о типах содержимого библиотеки документов. После выбора этих команд должен быть запущен код JavaScript для запуска соответствующего приложения и передачи пути к документу. Эта часть зависит от настройки рабочей станции, поскольку код JavaScript выполняется локально. Более того, для чтения и возможной записи файлов соответствующее приложение должно взаимодействовать со SharePoint. Для интеграции приложений со SharePoint необходима совместная работа этих элементов.

С другой стороны, взаимодействие SharePoint и сервера баз данных прозрачно для приложения, как и процессы индексирования на веб-сервере, выполняемые для упрощения поиска. По этой причине в данной статье я не будут рассматривать эти аспекты более подробно, но рекомендую ознакомиться с пакетом фильтров Microsoft, описанным в статье «Регистрация пакета фильтров Microsoft в службах Windows SharePoint Services 3.0» базы сведений о разрешении проблем Майкрософт, которая доступна по адресу support.microsoft.com/kb/946338. Теперь рассмотрим добавление команд, реализацию клиентских компонентов и упрощение связи приложения.

Расширение пользовательского интерфейса SharePoint

Доступно множество способов расширения пользовательского интерфейса и возможностей SharePoint. Можно изменить структуру узлов, настроить страницы ASP.NET, разработать веб-компоненты или изменить код JavaScript, включенный в WSS и MOSS, для запуска приложений напрямую.

Всегда можно открыть файл Ows.js в текстовом редакторе (файл находится в папке COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Layouts\1033 интерфейсных серверов SharePoint) и изменить работу функций createNewDocumentWithProgIDCore, editDocumentWithProgIDNoUI и DispDocItem. Но существует лучший способ, не требующий изменения базы кода WSS неподдерживаемыми способами: использование сопоставлений типов документов и типов содержимого.

В моей статье «Стандартизация управления данными с помощью пользовательских типов содержимого» (см. выпуск журнала TechNet Magazine за февраль 2008 г., technet.microsoft.com/magazine/cc194408.aspx) я рассматривал создание типов содержимого конкретных узлов и глобальных типов содержимого для управления документами и другим содержимым списков и библиотек документов SharePoint. Кроме того, можно ознакомиться с документом Text Content Type.pdf, входящим в состав сопроводительного материала для этой статьи, в котором описано создание нового типа содержимого для файлов .text и сопоставление данного типа содержимого с библиотекой документов. В результате в меню «Создать» становится доступной команда «Текстовое содержимое», подобная команде «Документ» для документов Word (см. рис. 2).

Рис. 2. Пользовательский тип содержимого в интерфейсе пользователя SharePoint

Меню ECB также может быть расширено. Вы могли рассчитывать на то, что меню ECB будет учитывать тип содержимого, но в текущей версии WSS это меню реализовано иначе. Вместо этого тип документов необходимо зарегистрировать в файле Docicon.xml, находящемся в папке %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Xml всех интерфейсных серверов SharePoint.

Например, при добавлении к разделу <ByExtension> файла Docicon.xml следующего сопоставления типа документа в SharePoint появится команда «Изменить в блокноте» (подробные указания приведены в файле Text Content Type.pdf):

<Mapping Key="text" Value="ictxt.gif"    
 EditText="Notepad"   
 OpenControl="SharePoint.OpenDocuments"/>

Параметр Key определяет расширение имени файла, параметр Value – значок документа для отображения в пользовательском интерфейсе, параметр EditText – строку, добавляемую SharePoint к команде «Изменить в», а параметр OpenControl – код ProgID клиентского компонента COM. Это код ProgID, передаваемый функциями JavaScript SharePoint вызову ActiveXObject (см. Ows.js для получения дополнительных сведений) для создания экземпляра объекта COM, который может быть приложением или вспомогательным элементом управления, запускающим приложение на основе соответствующего типа файла.

Веб-узел «Продукты и технологии SharePoint»

• Веб-узел «Продукты и технологии SharePoint»
• Технический центр служб Windows SharePoint
• Центр разработчиков для служб Windows SharePoint
• Блог группы «Продукты и технологии Microsoft SharePoint»

Необходимо иметь в виду, что параметр OpenControl с именем SharePoint.OpenDocuments ссылается на элемент управления ActiveX®, который выходит в состав последних версий Office (%PROGRAMFILES%\Microsoft Office\Office12\Owssupp.dll). Если этот файл существует на ваших рабочих станциях, и указанный значок документа (параметр Value) находится в папке %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Images серверов SharePoint, возможно, большая часть необходимой работы по интеграции уже выполнена.

В составе пакета SDK для служб Windows SharePoint 3.0 имеются определенные сведения о клиентских интерфейсах API, входящих в состав выпуска 2007 системы Microsoft Office, в том числе об элементе управления OpenDocuments. См. раздел «Справочник по клиентским интерфейсам API» по адресу msdn2.microsoft.com/ms440037.

Использование элемента управления OpenDocuments

Элемент управления OpenDocuments предназначен для решения наиболее важных задач интеграции приложений, но для него необходим выпуск 2007 системы Microsoft Office или Office 2003, и его возможности несколько ограничены. Команды меню «Создать» могут работать не всегда, и иногда отображаемые ими сведения могут вводить пользователей в заблуждение.

Как показано на рис. 3, элемент управления OpenDocuments информирует пользователя о том, что необходимое приложение установлено неправильно или невозможно открыть файл шаблона, хотя оба утверждения неверны. Функция «Изменить в» также имеет проблемы. Часто появляется второе сообщение об ошибке, показанное на рис. 3 на переднем плане. Это мое излюбленное сообщение, поскольку сбивает с толку даже специалистов по SharePoint, но оно будет рассмотрено подробнее чуть позже.

Рис. 3. Дезориентирующие сообщения об ошибке элемента управления OpenDocuments

Тем не менее, элемент управления OpenDocuments полезен в средах, на всех рабочих станциях которых установлены последние версии Office. Помимо прочего, можно скрыть типы содержимого в меню «Создать» (откройте параметры библиотеки документов, выберите «Изменение порядка новых кнопок и типа содержимого по умолчанию» и снимите флажок «Видимый» для соответствующих типов содержимого), чтобы у пользователей не появлялось первое сообщение об ошибке. Также можно упростить топологию узла, чтобы избежать неполадок связи WebDAV (Web-Based Distributed Authoring and Versioning); это позволит избежать появления второго сообщения об ошибке.

Обмен данными со SharePoint

Пока что мне удалось расширить пользовательский интерфейс SharePoint и, возможно, запустить приложение с помощью элемента управления OpenDocuments, но для приложения по-прежнему необходим способ связи со SharePoint для доступа к данным. Как обычно, SharePoint поддерживает несколько способов достижения этого, например, серверные расширения Microsoft Office FrontPage®, удаленные вызовы процедур (RPC) WSS, WebDAV и веб-службы. В сущности, приложения Office, например, Word 2007, могут использовать любые способы связи или сразу все в зависимости от способа доступа к документу, например, через веб-папки, подключенные сетевые диски или пользовательский интерфейс SharePoint.

Все способы связи клиента и сервера SharePoint основаны на протоколе HTTP. Например, удаленные вызовы процедур (RPC) FrontPage и WSS будут использовать запросы HTTP POST и HTTP GET, направляемые расширениям ISAPI на серверах SharePoint в папке %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\ISAPI и всех ее подпапках.

Одним из наиболее важных расширений ISAPI является библиотека Owssvr.dll, реализующая, помимо прочего, функциональные возможности для работы со списками и библиотеками документов. На рис. 4 показано диалоговое окно SharePoint Save в Word 2007 (слева) и в обозревателе (справа), открытое непосредственно через запрос по URL-адресу http://sharepoint/HR/Administration/_vti_bin/owssvr.dll?dialogview=FileSave&location=Shared%20Documents&FileDialogFilterValue=*.docx. Сходства двух снимков экрана очевидны.

Рис. 4. Диалоговое окно «Сохранить» SharePoint в Word 2007 и Internet Explorer

Другими важными расширениями ISAPI являются следующие библиотеки: Author.dll, реализующая удаленные вызовы процедур (RPC) FrontPage и WSS для клиентских операций правки, таких как загрузка, переименование и удаление документов; Admin.dll для управления узлами и выполнения ряда административных задач; и Shtml.dll для поддержки отправки форм HTML.

Как правило, поддержку удаленных вызовов процедур (RPC) FrontPage и WSS невозможно добавить к существующим приложениям, таким как «Блокнот» или Adobe Reader, без доступа к исходному коду. Но необходимые возможности связи можно предоставить с помощью функции веб-клиента Windows.

SharePoint также поддерживает WebDAV через библиотеку расширения Httpext.dll, которая находится в папке %WINDIR%\System32\Inetsrv\, но давайте останемся на стороне клиента. На компьютерах под управлением Windows Server® 2008 и Windows Vista® функция веб-клиента установлена по умолчанию. Служба WebClient доступна в средстве «Службы», находящемся в разделе «Администрирование» на панели управления. В операционных системах Windows XP и Windows Server 2003 необходимо установить веб-клиент. В любом случае убедитесь, что служба WebClient запущена и для нее установлен тип запуска «Авто».

На рис. 5 показана архитектура веб-клиента. Служба WebClient реализована в виде библиотеки DLL режима пользователя (Webclnt.dll), загружаемой диспетчером служб в размещающий процесс Svchost.exe. Webclnt.dll предоставляет интерфейс доступа к сети для операций, отличных от ввода-вывода (таких как проверка подлинности пользователя для доступа WebDAV; подключение узлов SharePoint в качестве сетевых дисков; перечисление узлов, списков и библиотек документов SharePoint как сетевых ресурсов; и отключение смонтированных дисков).

Figure 5 Архитектура перенаправителей клиентов WebDAV

Для выполнения этой задачи Webclnt.dll связывается с драйвером файловой системы в режиме ядра, который в действительности предоставляет функции перенаправителя. Драйвер перенаправителя клиентов WebDAV (Mrxdav.sys) основан на подсистеме RDBSS (Redirected Drive Buffering Subsystem), которая интегрируется с диспетчером ввода-вывода и другими компонентами ядра для предоставления служб удаленной файловой системы. Mrxdav.sys реализует возможности связи WebDAV для поддержки доступа к узлам и библиотекам документов SharePoint на уровне файловой системы.

Возможность доступа к узлам и библиотекам документов SharePoint через сетевой перенаправитель устраняет необходимость поддержки удаленного вызова процедур (RPC) FrontPage и WSS RPC в пользовательском приложении. Сетевые диски можно сопоставить с библиотеками документов (например, net use x: http://wss/doclib/Shared%20Documents), а доступ к ресурсам SharePoint также может осуществляться через пути в формате UNC.

URL-адрес http://wss/doclib/Shared%20Documents соответствует \\wss\doclib\Shared%20Documents. Поэтому доступны несколько способов открытия документа в приложении. Например, можно открыть документ в программе «Блокнот», используя путь HTTP http://wss/doclib/Shared%20Documents/New%20Text%20Document.txt или путь UNC \\wss\doclib\Shared%20Documents\New%20Text%20Document.txt.

К сожалению, функция веб-клиента имеет ряд ограничений. Доступ к пользовательским свойствам и веб-приложениям, использующим пользовательские порты TCP, невозможен. Сбой веб-клиента, входящего в состав Windows Vista, также происходит в случае, если у пользователя отсутствует доступ к родительскому узлу в иерархии, как показано в файле WebDAV Access.pdf (см. сопровождающие материалы).

В путь http://sharepoint/HR/Administration/Shared%20Documents/ входит несуществующий корневой узел (это http://sharepoint), однако без доступа к корню веб-клиент не может определить возможности веб-сервера. Веб-сервер отвергает запрос OPTIONS веб-клиента с кодом состояния 401, что означает, что доступ несанкционирован, и поэтому веб-клиент продолжает запрашивать учетные данные пользователя, как показано на рис. 6, даже если пользователь имеет административный доступ к семейству веб-узлов sharepoint/HR и всем входящим в него узлам.

Рис. 6. Ошибка доступа WebDAV

Если при использовании элемента управления OpenDocuments веб-клиент не может открыть документ, появляется сообщение об ошибке, показанное на рис. 3. Приложение доступно, а сопоставление типа документа правильное. Это документ, доступ к которому через перенаправитель WebDAV невозможен.

Реализация собственного решения OpenControl

Вообще, недостатки веб-клиента можно исправить двумя способами. Можно дождаться выпуска обновленной версии веб-клиента корпорацией Майкрософт или реализовать пользовательское решение OpenControl, успешное разрешающее текущую ситуацию. Реализация пользовательского решения OpenControl – нетривиальная задача, но оно устраняет необходимость установки Office на рабочих станциях, позволяет успешно совместно использовать команды «Создать» и «Изменить» и разрешать ситуации сбоя веб-клиента.

Если что-либо из перечисленного вам необходимо, взгляните на исходный код AppStart, входящий в материал, сопровождающий данную статью. В этом коде продемонстрировано предоставление интерфейсов COM OpenControl в сборке Microsoft .NET Framework, которые могут быть вызваны из кода JavaScript SharePoint. В исходном коде AppStart также показан один из возможных способов проверки доступности файла и его загрузки на локальный компьютер через HTTP, если прямой доступ через WebDAV невозможен. Наконец, исходный код AppStart реагирует на команду «Создать», загружая на локальный компьютер шаблон, соответствующий типу содержимого, чтобы пользователь мог начать работу с документом. В таблицах Text Content Type.pdf и Adobe Reader Support.pdf описано развертывание этого решения OpenControl.

На схеме, показанной на рис. 7, показана архитектура AppStart. Мой собственный компонент OpenControl (с именем Biblioso.dll) предоставляет два одинаковых интерфейса COM, вызываемые кодом JavaScript SharePoint для создания новых документов или открытия существующих документов для внесения изменений (Biblioso.AppStart.2 и Biblioso.AppStart.3).

Рис. 7. Архитектура AppStart

Если документ открыт для изменения, Biblioso.dll проверяет существования файла и открывает соответствующее приложение вместе с путем к документу, если файл доступен напрямую через WebDAV. Если файл недоступен, Biblioso.dll запускает внепроцессный сервер COM, который в свою очередь загружает OpenDocsUtility.dll для загрузки файла через HTTP и открытия приложения вместе с путем к загруженному документу.

Внепроцессный сервер COM позволяет решению выйти из процесса Internet Explorer®, ограничивающего загрузку папкой временных файлов Интернета в защищенном режиме. Пользователи должны иметь возможность загрузки файлов без ограничений защищенного режима, которую предоставляет внепроцессный сервер COM, работающий в качестве приложения-посредника.

Разработка внепроцессных серверов COM в .NET не поддерживается, поэтому для выполнения этой задачи я переключился на C/C++. На языке C++ я создал только минимально необходимое диалоговое окно «Сохранить как». Для обеспечения максимальной простоты решения и минимальных усилий по разработке я поместил действительный код загрузки в сборку .NET (OpenDocsUtility.dll), который затем вызывается через другой интерфейс COM.

Для упрощения развертывания я добавил к решению проект Setup. Помимо прочего, процедура установки регистрирует все компоненты COM и записывает относящиеся к приложению параметры в HKEY_LOCAL_MACHINE\SOFTWARE\Biblioso\AppStart. Наиболее важные параметры – AllowedApps и AllowedFileTypes. Решение AppStart работает только с приложениями и типами файлов, явно указанными в этих параметрах.

Процедура установки также создает политику повышения прав для внепроцессного сервера COM, чтобы интерфейс Biblioso.dll в процессе Internet Explorer мог запустить AppBrokerEngine.exe без появления предупреждений безопасности. Тем, кто хочет поближе познакомиться с защищенным режимом Internet Explorer и работе с ним при разработке приложений, я рекомендую статью Марка Силби и Питера Брандретта «Знакомство с принципами защищенного режима обозревателя Internet Explorer и работа в нем», доступную по адресу msdn2.microsoft.com/bb250462.

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

Это решение следует использовать на свой страх и риск. Если вы хотите изучить исходный код для создания собственного решения, начните с файла AppStart.cs проекта кода Biblioso. В этом файле реализуется интерфейс COM OpenControl и точки входа для вызовов JavaScript из Ows.js.

Заключение

WSS 3.0 и MOSS 2007 предоставляют богатые возможности интеграции приложений для улучшения работы пользователей с документами и другими элементами списков и библиотек документов SharePoint. Настольные приложения выпуска 2007 системы Microsoft Office весьма наглядно демонстрируют это, кроме того, можно добиться такого же уровня интеграции и удобства работы и для других приложений.

В основе архитектуры интеграции приложений лежат компоненты COM, используемые функциями JavaScript SharePoint вместе с путем к документу для запуска приложения. В выпуске 2007 системы Microsoft Office предоставлено нескольких уровней таких компонентов COM, оптимизированных для конкретных потребностей приложений Office; кроме того, элемент управления OpenDocuments Office можно повторно использовать для интеграции приложений сторонних производителей. Элемент управления OpenDocuments удовлетворяет большинство основных потребностей. В случае с более сложными требованиями к интеграции приложений возможна реализация пользовательского элемента управления.

Полная интеграции приложения со SharePoint влечет за собой не только установку компонентов IFilter и значков документов для расширения возможностей поиска и отображения, но также и создание собственных типов содержимого и сопоставлений типов документов на серверах SharePoint для включения соответствующих команд «Создать» и «Изменить» в пользовательский интерфейс SharePoint. Эти команды вызывают функции JavaScript, которые в свою очередь вызывают методы, предоставляемые компонентом OpenControl. Компонент OpenControl также должен быть доступен на рабочей станции.

Другая важная часть головоломки – веб-клиент, по умолчанию включенный и установленный в операционной системе Windows Vista. Веб-клиент реализует драйвер удаленной файловой системы и перенаправитель WebDAV для обеспечения доступа любых приложений к ресурсам списков и библиотек документов SharePoint, так же как и общим файловым ресурсам в сети. Хотя веб-клиент, входящий в состав Windows Vista, имеет недостатки, это важная часть истории интеграции приложения.

Поддержка WebDAV также ликвидирует разрыв между SharePoint и приложениями, работающими на рабочих станциях под управлением операционных систем, отличных от Windows. Как правило, в этих операционных системах недоступны технология COM и элементы управления ActiveX, что делает невозможным использование компонентов OpenControl для автоматического запуска приложений, но в состав большинства операционных систем входят перенаправители WebDAV, предоставляющие пользователям доступ к документам непосредственно в библиотеках документов без необходимости загрузки файлов на локальные рабочие станции.

WSS 3.0 и MOSS 2007 лежат в основе истории успеха выпуска 2007 системы Microsot Office, а пользователи приложений на основе Office производства сторонних разработчиков могут аналогичным образом использовать преимущества SharePoint. Возможности интеграции выходят далеко за пределы Office. Используя все преимущества SharePoint, можно создать единую платформу решений Office, предоставляющую подобное удобство работы с Office и программным обеспечением других производителей, и в результате повысить производительности информационных работников.