SharePoint 2007 делает возможным стандартизацию
многих аспектов содержимого и характеристик жизненного цикла
посредством типов содержимого. Типы содержимого веб-узлов являются
определениями метаданных, которые можно установить независимо от
любого веб-узла, семейства веб-узлов, списка или библиотеки
документов. Это позволяет последовательно устанавливать свойства,
затрагивающие всю компанию, рабочие потоки, политики управления
информацией и другие элементы, позволяя при этом каждому отделу или
владельцу веб-узла настраивать типы содержимого для конкретных
целей.
В этой статье я продемонстрирую, как использовать
новую модель содержимого SharePoint, представленную службами
Windows® SharePoint Services (WSS) 3.0 и
Microsoft Office SharePoint Server (MOSS) 2007 для создания иерархий
информационного содержимого предприятия, основанных на общих
характеристиках. Эти иерархии содержимого делают возможным
единообразное применение метаданных рабочих потоков и политик
управления информацией на глобальном уровне, в то же время
предоставляя гибкое удовлетворение уникальных потребностей в
управлении содержимым на уровне семейств веб-узлов, веб-узлов,
библиотек документов и списков.
Чтобы проиллюстрировать некоторые из
низкоуровневых аспектов типов содержания SharePoint, я включил в
сопровождающий статью файл ряд специальных средств, а также их
исходный код на случай необходимости расширить эти средства в
соответствии с теми или иными нуждами. Но помните, что эти средства
не протестированы тщательно, и их не стоит использовать в
производственной среде. Код можно загрузить с веб-узла журнала
TechNet Magazine на technetmagazine.com/code08.aspx.
Жизненный цикл содержимого и
определения типов содержимого
При управлении документами и прочим содержимым в
организации необходимо помнить о множестве деталей. Помимо прочего,
необходимо определять, какие действия следует выполнять каким
сотрудникам или процессам в ходе создания, публикации, архивации и
удаления содержимого. Для организации также часто необходимо
разрабатывать специальные шаблоны создания содержимого, определять
роли с целью назначения обязанностей и прав доступа к пользователям,
обеспечивать контроль версий, отслеживать соответствие, сохранять и
архивировать, определять метаданные и так далее.
Насколько бы сложным ни был жизненный цикл
определенного содержимого, модель содержимого SharePoint опознает
некоторые общие характеристики и типичные фазы, определяющие, как
следует обрабатывать отдельные элементы содержимого. Например, можно
структурировать создание содержимого через шаблоны и формы ввода, а
его отображение и поиск через метаданные. Можно также использовать
правку, одобрение и другие требования рабочего потока, требования
архивирования, графики истечения срока годности и подходящие
политики управления информацией для различения отдельных частей
содержимого. Некоторое содержимое может не требовать никаких
специальных шаблонов или не может быть заархивировано, но даже это
является характеристиками жизненного цикла, выделяющими такие
элементы.
Модель содержимого SharePoint позволяет
определять индивидуальные типы содержимого и устанавливать
иерархические отношения. В иерархическом отношении дочерние типы
содержимого наследуют общие характеристики родительских, добавляя
специальные характеристики по мере надобности.
Лучшей иллюстрацией к этому являются встроенные
типы содержимого SharePoint. В состав WSS 3.0 и MOSS 2007 входит
некоторое количество предварительно определенных типов содержимого
для типичных элементов, которые можно сохранять в библиотеке или
списке документов, включая документы и задачи. Определения этих
стандартных типов содержимого можно найти на сервере SharePoint в
папке %CommonProgramFiles%\Microsoft Shared\Web Server
Extensions\12\Template\Features\Ctypes. Там можно найти файл
манифеста, именуемый feature.xml. Взглянув на этот файл, можно
понять, что SharePoint применяет стандартные типы содержимого как
скрытую возможность (Hidden="TRUE"), в масштабе семейства веб-узлов
(Scope="Site") и что файл манифеста элемента, содержащий собственно
элементы типов содержимого – ctypeswss.xml (<ElementManifest
Location="ctypeswss.xml" />).
Тем, кто хочет поближе познакомиться с функциями
SharePoint, я рекомендуют прочесть выпуск рубрики Теда Паттинсона
(Ted Pattison) «Пространство Office» в журнале MSDN® Magazine, озаглавленный «Функции для
SharePoint» и доступный на msdnmagazine.com/issues/07/05/OfficeSpace.
Давайте теперь откроем файл ctypeswss.xml в
блокноте, чтобы изучить стандартные типы содержимого вне зависимости
от их видимости в интерфейсе пользователя SharePoint. Изменять
ctypeswss.xml не следует. Если есть мысли о правке ctypeswss.xml с
целью добавления новых полей к стандартным типам содержимого или
превращения скрытых типов содержимого в видимые, чтобы пользователи
SharePoint могли использовать их для вывода новых типов содержимого,
обратите внимание, что обычно в этом нет необходимости. Вдобавок,
это ведет к неподдерживаемым настройкам, а при последующей установке
пакетов обновления эти изменения могут быть перезаписаны, и решения
для управления содержимым будут разрушены.
Гораздо лучшим подходом является копирование
всего, что нужно, в новый файл манифеста элемента, внесение
изменений по мере необходимости и развертывание
индивидуализированных типов содержимого как новой функции в масштабе
семейства веб-узлов, чтобы они были доступны всем узлам в
семействе.
Определение типа содержимого System («Системный»)
на основе языка CAML, указанное в ctypeswss.xml, раскрывается
здесь:
<ContentType ID="0x"
Name=$Resources:System
Group="Hidden"
Sealed="True"
Version="0">
<FieldRefs>
<FieldRef ID="{c042a256-787d-4a6f-8a8a-cf6ab767f12d}" Name="ContentType"/>
</FieldRefs>
</ContentType>
Атрибуты Group («Групповой») и Sealed
(«Заблокированный») показывают, что тип содержимого System скрыт и
заблокирован, так что нельзя изменить в интерфейсе пользователя
SharePoint. Тип содержимого System обладает только одним элементом
FieldRef, ссылающимся на встроенный столбец узла, именуемый
ContentType. Это высший уровень абстракции. Все прочие типы
содержимого SharePoint наследуют это свойство от типа содержимого
System. Таким образом, SharePoint обеспечивает, чтобы все элементы
содержимого, хранящиеся в любой из библиотек или списков документов,
использовали это свойство совместно.
На рис. 1 показан веб-компонент
ContentTypeHierarchy, входящий в материал, сопровождающий данную
статью; этот веб-компонент дает более интуитивную иллюстрацию
иерархий. System является корнем всех прочих типов содержимого, за
которым следует Item («Элемент») и так далее. В частности, тип
содержимого Item устанавливает следующий уровень детализации. Если
проверить ctypeswss.xml, то можно убедиться, что Item определяет
единственное поле метаданных, ссылающееся на столбец веб-узла под
названием Title («Заголовок»). Таким образом, у всех встроенных
типов содержимого на нижних уровнях имеется свойство Title.
Рис.
1 Встроенная иерархия типов
содержимого WSS 3.0
Удалить наследуемое поле также возможно, как
показывает определение типа содержимого Document в ctypeswss.xml.
Тип содержимого Document включает несколько соответствующих
элементов RemoveFieldRef, однако поле Title может потребоваться
оставить на месте в собственноручно созданных типах содержимого,
поскольку столбец Title предоставляет доступ к раскрывающемуся меню
окна правки элементов управления (Edit Control Box – ECB) в
библиотеке документов SharePoint и отображениях списков.
Хорошим примером, показывающим, как
переименовывать наследуемые поля, является тип содержимого Far East
Contact в ctypeswss.xml. Проведите поиск 0x0116 (соответствующий ему
идентификатор типа содержимого) и затем проверьте элемент FieldRef с
атрибутом Name="Title", чтобы увидеть, как можно использовать
атрибут DisplayName для переименования поля в интерфейсе
пользователя. В данном конкретном случае, атрибут DisplayName
изменяет имя поля Title в интерфейсе пользователя локализованным
значением данных, на которое ссылается
"$Resources:core,Last_Name;".
Если приглядеться к Рис.
1, можно увидеть, что атрибут идентификатора элемента
ContentType уникальным образом идентифицирует тип содержимого и
устанавливает иерархическое отношение. Все идентификаторы начинаются
с идентификатора родительского типа содержимого, к которому
добавлены дополнительные шестнадцатеричные значения. К стандартным
типам содержимого обычно добавляется два дополнительных
шестнадцатеричных значения для создания нового уникального
идентификатора для дочернего типа содержимого. Другой прием –
добавить "00" и шестнадцатеричный идентификатор GUID. В частности,
именно этим способом типы содержимого Office Data Connection File и
Universal Data Connection File выводятся из типа содержимого
Document.
Пользователю важно помнить, что атрибут ID
(«Идентификатор») элемента ContentType не может превышать 1024. Это
может стать проблемой в крупной иерархии, если все типы содержимого
используют шестнадцатеричный прием адресации идентификаторов GUID.
Однако начинать с более короткого приема – не лучший вариант,
поскольку такие идентификаторы могут оказаться неуникальными.
Чтобы гарантировать уникальность, используйте
прием идентификаторов GUID для основания глобального пространства
имен своих корпоративных типов содержимого и переключитесь на более
короткий прием внутри этого пространства. Подробные сведения об
атрибуте ID и других элементах определений типов содержимого
приведены в разделе "Content Type Definition Schema" («Схема
определений типов содержимого») в SDK для WSS 3.0.
Зависимости типа
содержимого
Теперь стоит обратиться к вопросу использования
типов содержимого SharePoint для структуризации управления типами
содержимого. Необходимо подумать о нескольких зависимостях, таких
как взаимозависимости между библиотеками и списками документов,
типами содержимого, столбцами веб-узла и типами полей. Библиотеки и
списки ссылаются на типы содержимого, которые ссылаются на столбцы
веб-узла, которые, в свою очередь, ссылаются на типы полей (такие
как стандартные типы полей WSS – текст, заметка, выбор, номер,
валюта и так далее), которые, в свою очередь, пребывают в сборках
Microsoft .NET Framework, таких как центральная сборка WSS
Microsoft.SharePoint.dll.
Для примера давайте вернемся к типу содержимого
System, как он проиллюстрирован выше в определении CAML записи в
файле манифеста о типе содержимого System. Как можно было увидеть,
этот тип содержимого содержит элемент FieldRef, ссылающийся на
встроенный столбец узла, именуемый ContentType. Обратите внимание,
что определение типа содержимого не определяет собственно столбец
веб-узла ContentType. ContentType – поле типа Text, определенное в
манифесте элементов fieldswss.xml, находящемся в папке
%CommonProgramFiles%\Microsoft Shared\Web Server
Extensions\12\Template\Features\Fields. Тип поля Text, в свою
очередь, определен в fldtypes.xml, а этот файл можно найти в
%CommonProgramFiles%\Microsoft Shared\Web Server
Extensions\12\Template\XML. Важный вывод, который следует сделать из
этого дерева зависимостей, – необходимость обеспечить доступность
всех ресурсов на серверах SharePoint.
Типы содержимого, которые надо использовать,
должны быть созданы на уровне библиотек и списков документов не ниже
в иерархии, чем уровень веб-узла. Аналогично, поля метаданных типов
содержимого должны ссылаться на существующие столбцы веб-узла. Можно
добавлять к своим типам содержимого стандартные или
индивидуализированные столбцы веб-узла, основанные на стандартных
или индивидуализированных типах полей, но необходимо убедиться, что
эти столбцы существуют на локальном веб-узле. Вдобавок, если
необходимо использовать индивидуализированные типы полей, необходимо
обеспечить развертывание базовых сборок .NET на своих серверах
SharePoint.
Аналогичные зависимости существуют для типов
содержимого, ссылающихся на шаблоны документов, приемники
нестандартных событий, рабочие процессы и иные компоненты. Например,
определение типа содержимого может содержать элемент
DocumentTemplate, указывающий на шаблон документов, связанный с этим
типом содержимого. Определение типа содержимого может также
содержать элемент XmlDocuments с одним или несколькими дочерними
элементами XmlDocument, определяющими дополнительные характеристики
типа содержимого, такие как определения пространств имен,
определения областей сведений о документах или любую нестандартную
информацию.
Создание
глобальных типов содержимого
Пользователи с полномочиями на разработку могут
создавать новые типы содержимого и столбцы веб-узлов прямо в
интерфейсе пользователя SharePoint, но типы содержимого после этого
будут доступны только на локальном веб-узле и веб-узлах ниже его в
иерархии. Нестандартные столбцы веб-узла доступны только на
локальном веб-узле. Этого недостаточно для создания глобальных типов
содержимого. Необходимо обеспечить доступность глобальных типов
содержимого на всех семействах веб-узлов в среде. Тут-то функции
SharePoint и могут пригодиться. Установка и активация функций
SharePoint на нескольких семействах веб-узлов с целью
последовательного применения соответствующих столбцов веб-узлов и
определений типа содержимого довольно проста.
В составе сопровождающего материала для этой
статьи есть пример функции, именуемой AdventureWorks, которая
демонстрирует установку глобального типа содержимого. Эта функция
определяет общий тип содержимого, именуемый Customer Documentation
(«Клиентская документация»), который можно использовать для создания
любых типов клиентских материалов, таких как предложения и письма с
предложениями о продажах. Разумно предположить, что все эти типы
документов должны быть связаны с информацией о клиентах, такой как
имя компании, контактные сведения и адрес. Я специально создал новое
поле, именуемое Customer Name («Имя клиента») для своего типа
содержимого и добавил некоторые встроенные поля, такие как
Department («Отдел») и Primary Phone («Основной телефон»). Тип
содержимого и поля можно изменить, изменяя файл ContentTypes.xml, а
ссылки полей – изменяя файл SiteColumns.xml в сопровождающем
материале.
Если развернуть эту функцию согласно указаниям
файла readme.htm, ее можно последовательно активировать на
нескольких семействах веб-узлов. Тогда тип содержимого Customer
Documentation будет доступен глобально. Это позволит различным
отделам создавать специальную клиентскую документацию посредством
производных типов содержимого, связанных с целевыми шаблонами
документов. В составе сопровождающего материала имеются примеры
шаблонов документов, которые можно использовать при продажах и
консультациях. На Рис. 2 показаны
получающиеся типы содержимого.
Рис.
2 Родительские и дочерние типы
содержимого для клиентской документации
При создании функций для собственноручно
созданных столбцов веб-узлов и типов содержимого вWSS 3.0 и MOSS
2007 можно воспользоваться одним из нескольких вариантов. Можно
изучить комплект SDK для WSS 3.0 и писать файлы XML с нуля. Можно
также выбрать использование SharePoint Designer для экспорта списка
в персональный веб-пакет, переименовать получившийся файл .fwp в
файл CAB, извлечь файл manifest.xml из файла CAB и найти определения
ContentType в файле manifest.xml. К несчастью, оба подхода неудобны
и подвержены ошибкам.
Напротив, создавать индивидуализированные столбцы
и типы содержимого в интерфейсе пользователя SharePoint
примечательно просто, однако интерфейс не предоставляет возможностей
по правке файлов XML функции. Функции являются эффективным путем
подготовки ресурсов SharePoint, но после предоставления ресурсы
существуют только в базе данных содержимого . Может быть, в будущую
версию WSS будет входить возможность экспортировать столбцы узлов и
типы содержимого в файлы XML через интерфейс SharePoint, подобно
экспорту веб-компонентов. Пока же приходится работать с тем, что
есть.
В сопровождающем материале имеется веб-компонент,
именуемый ContentTypeSchema, который может стать отправной точкой. В
нем используется объектная модель SharePoint для извлечения свойства
SchemaXML из выбранного типа содержимого. Через преобразования на
основе XSLT веб-компонент извлекает определения Field или
определения ContentType в зависимости от варианта, выбранного в
интерфейсе пользователя перед нажатием на кнопку Display
(«Отобразить»).
На рисунке 3 показана работа этого
веб-компонента. Он отображает тип содержимого Active Directory® Documentation, который я основал на типе
содержимого Customer Documentation. Тип содержимого Active Directory
Documentation связан с нестандартным шаблоном Microsoft Word (Active
Directory Template.dot). Отметьте, что у этого типа содержимого нет
дополнительных полей. Все поля наследуются от родительского типа
содержимого.
Если есть планы использовать веб-компонент
ContentTypeSchema в собственной среде, имейте в виду, что этот
веб-компонент не протестирована тщательно. В моем веб-компоненте
используется сравнительно сложное преобразование XSL для создания
разности между свойством SchemaXML выбранного в настоящий момент
типа содержимого и его родительским типом содержимого. Но XSLT 1.0
все же не создан для преобразований сложных документов XML. В нем
нет встроенной функции сравнения узлов XML. Кроме того, пространства
имен XML, также как и разделы CDATA, являются препятствиями, которые
XSLT 1.0 не может эффективно преодолеть.
SharePoint сохраняет определение столбцов
веб-узлов и типов содержимого веб-узлов, созданное путем
использования интерфейса пользователя или объектной модели
SharePoint, в базе данных содержимого в таблице, именуемой
ContentTypes. На Рис. 3 можно посмотреть
на идентификатор моего типа содержимого. Соответственно,
нижеследующий оператор T-SQL предоставит точные результаты: SELECT
Definition FROM ContentTypes WHERE ContentTypeId = <content type
ID>.
Рис.
3 Определение типа содержимого,
созданного пользователем в ContentTypeSchema Веб-часть Какой подход ни выбери, создание функций для
типов содержимого в масштабе компании после получения столбца
веб-узла и определений типов содержимого будет весьма простым. Я
рекомендую использовать единую функцию для всех глобальных столбцов
веб-узлов и типов содержимого отдела или компании. Таким образом,
будет понятно, куда добавлять новые столбцы веб-узлов и определения
типов содержимого.
Поиск созданных пользователями метаданных в
масштабах предприятия
Непосредственным преимуществом иерархий типа
содержимого является наследование полей метаданных родительского
типа всеми дочерними типами. Поскольку у всех типов содержимого есть
общие поля метаданных, пользователям довольно просто создавать
собственные представления и фильтры в библиотеках документов.
Пример функции AdventureWorks показывает это
весьма интуитивным способом. Вне зависимости от содержимого,
создаваемого консультантом или продавцом, сохранение получающегося
документа Word 2007 в библиотеке документов требует указания
Customer Name, поскольку родительский тип содержимого Customer
Documentation устанавливает необходимость этого поля метаданных.
Группируя или фильтруя элементы в представлении библиотеки
документов в соответствии с Customer Name, консультанты и продавцы
могут быстро и с удобством найти всю существующую документацию по
клиенту, как показано на Рис. 4.
Рис.
4 Группировка различных документов
в библиотеке на основе общих метаданных
Общие метаданные также делают несложным поиск
содержимого по нескольким библиотекам документов и веб-узлам, путем
использования поисковых возможностей WSS 3.0 и MOSS 2007. WSS
поддерживает поиск по библиотекам, спискам и веб-узлам внутри одного
семейства веб-узлов. MOSS 2007 выходит за пределы этих базовых
возможностей, позволяя реализовать центр поиска в масштабах компании
и управлять пользовательскими метаданными в пользовательском
интерфейсе центральной администрации SharePoint 3.0. По этой
причине, нижеследующее объяснение фокусируется на MOSS 2007.
При настройке поставщика общих служб (Shared
Service Provider – SSP) в MOSS 2007 и обходе веб-узлов SharePoint
MOSS 2007 может автоматически обнаруживать нестандартные поля
метаданных, использованные в источниках содержимого. Соответственно,
эти поля можно найти в списке обойденных свойств.
Поля метаданных, определенные в функциях
SharePoint, обычно подпадают под категорию SharePoint. Чтобы найти
ее положение в центральной администрации SharePoint Central
Administration, в меню «Быстрый запуск», под пунктом
«Администрирование общих служб», щелкните ссылку на SSP, затем
параметры поиска, затем сопоставление свойств метаданных, затем
обойденные свойства в меню «Быстрый запуск», а затем откройте
категорию SharePoint.
Вот пример всего этого в действии. Поле
метаданных, именуемое Customer Name, превращается в обойденное
свойство, именуемое ows_Customer_x0020_Name. SharePoint снабжает
обойденные свойства префиксами "ows_" и "_x0020_" в закодированной
версии единого пространства. В случае отображения подробностей об
обойденном свойстве можно обнаружить, что оно включено в индекс
поиска по умолчанию, так что пользователи могут использовать его
значения для выполнения поисков содержимого. Однако для повышения
точности поиска может возникнуть желание не сопоставлять обойденное
свойство с управляемым свойством, чтобы пользователи однозначно
могли искать содержимое по имени клиента.
При сопоставлении обойденных свойств с
управляемыми есть две возможности. Можно автоматически создавать по
управляемому свойству на каждое обойденное свойство или их можно
сопоставлять вручную. Первый вариант доступен при отображении
параметров желаемого обойденного свойства (при отображении таких
свойств в категории, вроде категории SharePoint, выберите пункт
«Изменить категорию» в меню быстрого запуска). В области «Параметры
свойств, используемых при обходе содержимого» необходимо установить
флажок «Автоматически создавать новое управляемое свойство для
каждого обойденного свойства, обнаруженного в этой категории».
Однако SharePoint снабжает автоматически созданные управляемые
свойства префиксами "ows" и избегает пробелов с помощью "x0020".
Управляемое свойство для обойденного свойства
ows_Customer_x0020_Name будет выглядеть как owsCustomerx0020Name.
Однако это не очень удобное для пользователя имя свойства.
Возможно, лучшей стратегией будет сопоставление
обойденных свойств с управляемыми свойствами вручную после
развертывания типов содержимого масштаба предприятия. Обойденное
свойство можно сопоставить с одним или несколькими управляемыми. Для
создания нового управляемого свойства в центральной администрации
SharePoint Central Administration, в меню «Быстрый запуск», под
пунктом «Администрирование общих служб», щелкните ссылку на ваш SSP,
затем Параметры поиска, затем Сопоставления свойств метаданных,
затем выберите «Новое управляемое свойство» для указания необходимой
информации и привязки его к нужному обойденному свойству.
Затем пользователи могут обнаруживать нужные
элементы содержимого используя управляемые свойства либо в
синтаксисе property:, либо в расширенном поиске. Например, если
сопоставить обойденное свойство ows_Customer_x0020_Name с
управляемым свойством, именуемым Customer, пользователи смогут
искать все документы клиента просто указывая Customer: <Имя
клиента> в стандартном окне поиска, например Customer:
Contoso.
Хорошей мыслью также является включение
управляемых свойств для наиболее важных полей метаданных ваших типов
содержимого в список свойств на странице расширенного поиска. Чтобы
выполнить это, отобразите страницу расширенного поиска, выберите
действия на узле и затем команду правки страницы. Теперь можно
нажать кнопку правки в окне расширенного поиска, чтобы выбрать
вариант изменения общего веб-компонента. При расширении категории
Properties и помещении курсора в соответствующее текстовое поле
можно нажать на кнопку для правки документа XML Properties.
Необходимо добавить определение свойств к элементу
<PropertyDefs>, скажем <PropertyDef Name="Customer"
DataType="text" DisplayName="Customer Name"/>, а также необходимо
добавить ссылку на определение свойств под элементом ResultType
(например, элементом <ResultType DisplayName="All Results"
Name="default">), скажем <PropertyRef Name="Customer" />.
На Рис 5a показан получившийся интерфейс
расширенного поиска. На рис. 5б показаны
результаты поиска.
Рис.
5a Поиск документации по
ИТ-инфраструктуре на основе имени клиента
Рис.
5б Результаты поиска имени клиента
Обеспечение согласованности
информации
К этому моменту я успешно стандартизировал
наиболее важные поля метаданных и типы содержимого, а также расширил
возможности поиска по семействам веб-узлов в моей компании,
основываясь на MOSS 2007. Теперь настало время обеспечить ввод
пользователями верной информации в поля метаданных.
Сделать это можно двумя способами. Во-первых,
можно заменить стандартную область сведений о документах в шаблонах
документов на специально созданную форму InfoPath®, дающую пользователям заранее определенный
набор вариантов ввода, подобный присутствующему в окне списка.
Во-вторых, можно привязать получатель события к типу содержимого и
затем проверять верность метаданных и прочей информации каждый раз,
когда пользователи создают, изменяют или удаляют соответствующие
элементы содержимого.
Эти варианты дополняют друг друга. Форма
InfoPath, в первую очередь, предоставляет удобный способ правки типа
содержимого SharePoint, тогда как получатель событий может
обеспечить верность метаданных, даже если пользователи правят
свойства типа содержимого вне формы InfoPath. Обработчики событий
можно привязывать к определенному типу содержимого, что позволяет
указывать события и их ответы на все документы, связанные с
определенным типом содержимого во всех семействах веб-узлов вне
зависимости от библиотеки документов. Дополнительные сведения о
разработке и развертывании обработчиков событий можно найти на msdn2.microsoft.com/ms453149.
Вероятно, простейшим методом связывания типа
содержимого с нестандартной областью сведений о документе является
отображение параметров области сведений о документе типа содержимого
в интерфейсе пользователя SharePoint на компьютере, где установлен
InfoPath 2007. После этого можно щелкнуть ссылку "Создать новый
пользовательский шаблон" в шаблоне области сведений о документе,
чтобы запустить InfoPath 2007 в режиме создания. Однако, если в
состав содержимого веб-узла входят столбцы без явного атрибута
SourceID, можно столкнуться с ситуацией, при которой InfoPath не в
состоянии создать верную схему XSD для формы области сведений о
документе. Например, в тип содержимого Customer Documentation,
представленный ранее, входят несколько специфических для каждого
контакта столбцов, таких как Department, Office и адрес электронной
почты, которые могут вызвать эту проблему, как показано на рис. 6.
Рис.
6 Несовместимости схемы XSD в
InfoPath 2007
На этом этапе при наличии данной проблемы есть
два варианта. Можно либо удалить ссылки на столбцы веб-узла без
явного атрибута SourceID из определения типа содержимого, либо
заменить встроенные столбцы веб-узла, вызвавшие проблему, на
измененные столбцы веб-узла, совместимые с InfoPath 2007. Помните,
что невозможно изменить ссылки на поля в типе содержимого,
основанном на CAML, после того, как он был предоставлен в базу
данных содержимого, особенно если уже были созданы дочерние типы
содержимого. Файл основанного на CAML определения типа содержимого
больше нельзя обновить, а также нельзя свалить изменения на дочерние
типы содержимого, посколькуWindows SharePoint Services не
отслеживают изменения в определении родительского типа
содержимого.
Чтобы свалить изменения, необходимо изменить
родительский тип через интерфейс пользователя или объектную модель
SharePoint, либо надо определить новый тип, порожденный от
существующего. Последний прием позволяет удалять критические поля и
добавлять столбцы. Пользователи затем могут выводить типы
содержимого из нового типа. Чтобы пользователи не могли выбрать
неверный тип, добавьте предыдущий тип содержимого к группе типов
содержимого _Hidden.
Как я уже сказал, типы содержимого на основе CAML
нельзя обновлять после их развертывания и активации. Поэтому очень
важно тестировать глобальные типы содержимого перед развертыванием.
Дополнительные сведения см. в статье MSDN "Updating Content Types"
(«Обновление типов содержимого») на msdn2.microsoft.com/aa543504.
После того, как тип содержимого с верными
ссылками на поля создан, можно создать индивидуализированную область
информации о документе в InfoPath 2007. Лучшая стратегия состоит в
том, чтобы позволить владельцам веб-узлов создавать такие области
для их дочерних типов содержимого. InfoPath 2007 предоставляет
возможность публикации таких областей прямо в выбранный тип
содержимого, что облегчает вариант развертывания. Но также возможно
публиковать формы InfoPath из центральной точки, такой как
библиотека документов, включая ссылку на область сведений о
документе в тип содержимого. Такой вариант является лучшим, если
планируется предоставить индивидуализированную область информации о
документе вместе со своими типами содержимого CAML. На Рис. 7 показана архитектура реализации.
Рис.
7 Применение файла XSN из
центрального местоположении в MOSS 2007
В состав файла для загрузки, сопровождающего эту
статью, входит функция AdventureWorks_Update, расширяющая предыдущую
функцию AdventureWorks путем добавления дополнительных столбцов
веб-узлов, работающих с InfoPath 2007. Функция AdventureWorks_Update
помечает оригинальный тип содержимого Customer Documentation как
скрытый и производит новый тип содержимого Customer Docs, где
унаследованные встроенные поля заменены специально созданной
областью информации о документе.
Новый тип содержимого Customer Docs включает
элемент XmlDocument, предоставляющий информацию о панели сведений о
документе. Точнее говоря, элемент xsnLocation указывает на форму
InfoPath http://companyresources/DIPs/customerDIP.xsn, которая
применяет эту область. Подробные указания по применению функции
AdventureWorks_Update приведены. в файле readme.htm папки
AdventureWorks_Update.
Заключение
Типы содержимого SharePoint 2007 можно
использовать для создания политик метаданных и их согласованного
использования в масштабах компании. Иерархия типов содержимого
позволяет стандартизировать характеристики, относящиеся к среде в
целом, и применять из единообразно ко всем узлам путем
наследования.
Среди прочего возможно расширить встроенные
возможности поиска MOSS 2007, чтобы пользователи могли быстрее и с
большим удобством обнаруживать конкретное содержимое. Также возможно
применять информационную согласованность в области метаданных и
создавать централизованные политики управления информацией. Лучшей
стратегией является стандартизация глобальных типов содержимого на
наиболее абстрактных характеристиках метаданных, чтобы свести к
минимуму потребность в последующих изменениях. Основанные на
тщательно разработанной модели содержимого типы данных SharePoint
могут предоставлять новые возможности стандартизации жизненного
цикла содержимого в компаниях и организациях.
