Создаем портал в Sharepoint. Часть 1

Если вы работаете с Sharepoint то скорее всего эта тема вам хорошо знакома. Любой бизнес имеет специфичные правила и процедуры, которые не покрываются стандартным возможностями Sharepoint-а. В этом случае мы разрабатываем новое решение либо кастомизируем существующую функциональность для удовлетворения бизнеса потребностей. С этим постом я начну серию статей где постараюсь описать одну из важных и востребованных тем: создание специализированных (custom) сайтов и порталов в Sharepoint. Сразу оговорюсь, что я рассмотрю процесс создания сайтов в основном с точки зрения разработчиков. Технически это значит, что в статье будет рассмотрен процесс кастомизации с использованием определений сайтов (site definitions) в Visual Studio, т.е. работа с сайтами с использованием например Sharepoint Designer вне скопа данной статьи.

Предположим, наш заказчик – это компания, имеющая много филиалов по всему миру. Мы должны создать для нее портал на Sharepoint, который бы содержал подсайты для каждого филиала. Для простоты будем полагать, что нам достаточно одной сайт коллекции для всей компании (с корневым сайтом скажем http://www.contoso.com). Филиалы будут иметь собственные подсайты(http://www.contoso.com/usa, http://www.contoso.com/europe, и т.д.), которые имеют более менее одинаковую структуру (т.е. собственные подсайты, библиотеки документов, страницы, веб парты, и т.д.) и настройки (настройки доступа, навигация, базовый look and feel, и т.д.). Положим, что нам надо реализовать следующую топологию:

www.contoso.com
 |
 |----USA
 |    |
 |    |----Sales
 |    |----IT
 |    |----HR
 |
 |----Europe
 |    |
 |    |----Sales
 |    |----IT
 |    |----HR
...

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

Как я уже упомянул в начале статьи, есть несколько способов кастомизации сайтов в Sharepoint. Для решения указанной задачи, вы например можете создать сайт, используя стандартное определение сайта, добавить в него нужную функциональность (веб парты, страницы и т.п.), сохранить сайт как шаблон (файл .stp) и создать новый сайт, на основе этого шаблона. Также вы можете использовать команды export и import утилиты stsadm для создания сайта и последующим изменением его с помощью Sharepoint Designer-а. Указанные подходы не требуют участия разработчика и выполняются администратором. Эти решения подходят для случаев, когда не так много сайтов нужно создавать по одинаковым шаблонам, либо когда количество изменений базового шаблона невелико. Но для больших компаний, имеющих множество филиалов, для которых необходим отдельный сайт с уникальными настройками, задаваемыми при создании, автоматизация данного процесса имеет критическое значение. В этом случае лучшим, на мой взгляд, средством решения указанной задачи является одна из точек расширения (extensibility point) Sharepoint-а: специализированные определения сайтов. Если вы не знакомы с определениями сайтов, либо вас смущают термины “определение сайта” и “шаблон сайта”, я рекомендую ознакомится со следующей статьей в msdn: Working with Site Templates and Definitions. Для нас достаточно запомнить, что шаблон – это .stp файл созданный на основе существующего сайта (также термин шаблон будет использоваться как элемент внутри xml-артефактов описания сайтов – о них речь пойдет ниже). Этот .stp файл, будучи созданным однажды, не модифицируется (я не рассматриваю случаи ручной распаковки, изменения, и обратной упаковки с изменением расширения с .stp на .cab – хотя иногда приходится делать и такое. Однако, этот способ не является официальным способом работы с сайтам от MS 🙂 ). С другой стороны, определение сайта – это полностью изменяемое определение возможностей сайта, которое хранится в файлах onet.xml в подпапках 12/Template/SiteTemplates (далее я расскажу об этом более подробно).

Мы пойдем дальше большинства примеров по данной теме, и не будем ограничиваться лишь созданием своего собственного определения сайта. Мы реализуем специализированный процесс создания сайтов. Имея определение сайта (кастомное или стандартное), единственное, что мы можем – это использовать стандартную страницу создания сайтов (12/Templates/Layouts/newsbweb.aspx) и выбрать нужный шаблон в элементе управления template picker (либо передать параметр командной строки ID – в этом случае template picker будет содержать лишь одно значение, которое соответствует переданному ID). Но что есть нам нужно указывать свои собственные (специфичные для бизнеса) параметры при создании нового сайта (кроме стандартных заголовка, описания, языка, URL-а и т.п.)? Для этого нам потребуется реализовать свою собственную страницу создания сайтов, взяв за основу стандартную newsbweb.aspx. Но обо всем по порядку.

Начнем создавать необходимы артефакты для сайтов филиалов. Прежде всего необходимо понять что нам нужно сделать в терминах MOSS-а. В описанном примере с Contoso это не просто сайт, т.к. для каждого филиала есть собственные подсайты (Sales, IT, HR). Используя терминологию MOSS-а нам нужно создать портал для филиала с корневым сайтом (который и будет считаться “сайтом филиала”) и тремя упомянутыми подсайтами. Не запутайтесь в терминах. С точки зрения обычных пользователей есть только один основной портал верхнего уровня http://www.contoso.com, который имеет множество подсайтов для каждого филиала. Но мы также знаем, что каждый такой подсайт филиала в свою очередь также является порталом в терминах MOSS-а.

Хорошо, теперь, когда мы более менее разобрались, что нам нужно делать, надо выбрать: создавать определение сайтов портала с нуля, либо использовать существующее стандартное определение Sharepoint-а. В данном цикле статей будет рассмотрен второй вариант. Мы будем использовать OTB определение “Сайт публикации” (Publishing Site), т.к. это наиболее функциональное и часто используемое определения для подобных задач, но вместе с тем и наиболее сложное.

Для создания портала необходимо создать webtemp файл в папке 12/Template/{lcid}/XML, где {lcid} – это placeholder обозначающий поддерживаемую локаль. Т.е. если нам нужно иметь возможность создавать порталы филиалов на английском и шведском языках, надо создать 2 webtemp файла в следующих папках:

  • 12/Template/1033/XML – для английской локали;
  • 12/Template/1053/XML – для шведской.

    Вы можете прочитать больше про файлы webtemp в следующей статье: Portal Site Template File. Давайте назовем наш файл webtempContosoBranchSite.xml. В нашем случае он будет иметь следующее содержимое:

    <?xml version="1.0" encoding="utf-8" ?>
    <Templates>
      <Template Name="ContosoBranchSitePortal" ID="10001">
        <Configuration ID="0"
          Title="Contoso Branch"
          Description=""
          ProvisionAssembly="Contoso.Branches, Version=1.0.0.0, Culture=neutral, PublicKeyToken=a91ac4533350b8ae"
          ProvisionClass="Contoso.Branches.BranchSitePortalProvisioningProvider"
          ProvisionData="SiteTemplates\\ContosoBranchSitePortal\\ContosoBranchSitePortalWebManifest.xml"
          RootWebOnly="FALSE"
          Hidden="FALSE"
          ImageUrl="/_layouts/images/stsprev.png"
          DisplayCategory="Contoso" />
      </Template>
    </Templates>
    

    Я не буду повторять содержимое статей msdn и technet, описывая все аттрибуты – вы можете ознакомиться с ними по ссылке, которой я привел выше. Сейчас для нас важно следующее – мы определили шаблон (template) для портала под названием ContosoBranchSitePortal с идентификатором ID = 10001. Теперь если вы скопируете этот файл в 12 hive и перезапустите IIS, то на странице создания сайта вы увидите указанный шаблон (если вы укажете идентификатор шаблона в командной строке, то template picker будет содержать только ваш шаблон в категории Contoso):

    01

    Хочу обратить особое внимание на 2 атрибута в файле webtempContosoBranchSite.xml: ProvisionAssembly и ProvisionClass. Как во многих других местах в Sharepoint-е (напр. при определении feature receiver-ов) в них содержатся полное имя сборки и класса, которые будут использованы при провиженинге. Если вы используете Сайт публикации в качестве базового для портала, вам необходимо использовать стандартный класс PortalProvisioningProvider из сборки Microsoft.SharePoint.Publishing.dll. Но в нашем случае – это специализированный провайдер провиженинга BranchSitePortalProvisioningProvider. Я выбрал этот вариант специально, т.к. в данной статье хочу показать как можно больше возможностей для кастомизации. Это достаточно мощная техника, позволяющая вам исполнять свой код до и после провиженинга. К сожалению класс PortalProvisioningProvider является изолированным, т.е. вы не можете напрямую унаследовать его в вашем классе. Но его можно агрегировать так, как это показано в следующем коде:

    namespace Contoso.Branches
    {
        public class BranchSitePortalProvisioningProvider : SPWebProvisioningProvider
        {
            public override void Provision(SPWebProvisioningProperties props)
            {
                // todo: add code which will run before provisioining
                var publishingPortalProvisioningProvider = new PortalProvisioningProvider();
                publishingPortalProvisioningProvider.Provision(props);
                // todo: add code which will run after provisioning
            }
        }
    }
    

    Как показано в примере, вы можете исполнять свой код до (когда подсайты портала еще не созданы) и после провиженинга (когда вся структура готова). Но где и как определяется эта структура? Это делается в специальном файле – веб манифесте портала, который мы указали в атрибуте ProvisionData в файле webtempContosoBranchSite.xml:

    ProvisionData=»SiteTemplates\\ContosoBranchSitePortal\\ContosoBranchSitePortalWebManifest.xml

    Я уже упоминал, что в папке 12\Template\SiteTemplates находятся файлы onet.xml с определениями сайтов (см. эту статью в msdn для описания содержимого файлов onet.xml). Коротко, файл onet.xml – это ключевой элемент в процессе провиженга сайтов в Sharepoint-е. В нем содержатся фичи, шаблоны документов, экземпляры списков (хотя списки лучше создавать в отдельных фичах – на то есть несколько технических причин) и другие артефакты, которые будут запровиженены на сайт, созданный на основе конфигурации из данного onet.xml. Но если вы создаете портал, а не единственный сайт, то вместо onet.xml вы должны создать веб манифест портала, содержащий структуру портала со ссылками на существующие определения сайтов. В нашем случае файл ContosoBranchSitePortalWebManifest.xml выглядит следующим образом:

    <?xml version="1.0" encoding="utf-8" ?>
    <!-- _lcid="1033" _version="12.0.4518" _dal="1" -->
    <!-- _LocalBinding -->
    <portal xmlns="PortalTemplate.xsd">
      <web name="Home" siteDefinition="ContosoBranchSite#0" displayName="$Resources:ContosoBranch,Site_Home_DisplayName;" description="">
        <webs>
          <web name="Sales" siteDefinition="ContosoBranchSite#1" displayName="$Resources:ContosoBranch,Site_Sales_DisplayName;" description="" />
          <web name="IT" siteDefinition="ContosoBranchSite#2" displayName="$Resources:ContosoBranch,Site_IT_DisplayName;" description="" />
          <web name="HR" siteDefinition="ContosoBranchSite#3" displayName="$Resources:ContosoBranch,Site_HR_DisplayName;" description="" />
        </webs>
      </web>
    </portal>
    

    В веб манифесте мы определили корневой сайт (Home) и 3 подсайта (Sales, IT и HR). Атрибут Name будет использован в качестве URL-ов подсайтов (кроме корневого сайта портала, для которого URL указывается на странице создания сайта), а атрибут displayName содержит локализованные заголовки сайтов (файл ресурсов ContosoBranch.resx должен находится в папке 12/Resources также, как и его языковые версии, напр. ContosoBranch.en-us.resx. Также важно понимать, что заголовки сайтов – это так называемые ресурсы провиженинга. В MOSS-е они “раскрываются” в реальные значения в момент провиженинга и в content базу данных записываются именно эти конечные значения. Т.е. если вы потом поменяете значение ресурсной строки в resx файле – это будет иметь действие только для новых сайтов, в то время как существующие сайты это изменение не затронет). Наиболее важный атрибут – это siteDefinition. Он говорит Sharepoint-у какое именно определение сайта должно использоваться для каждого сайта портала. Например, для подсайта Sales MOSS будет использовать определение ContosoBranchSite#1.

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

  • Реклама

    Об авторе sadomovalex

    Старший инженер, team lead, консультант. Работаю в стеке .Net. Последние несколько лет занимаюсь разработкой enterprise приложений под Sharepoint, чему и будет в основном посвящена тематика этого блога. Также активно использую и интересуюсь ASP.Net MVC, DDD, TDD, Agile. Активно участвую в жизни многих профессиональных сообществ, SPb .Net UG, SPb ALT.Net, rsdn, Finland SP UG и др.
    Запись опубликована в рубрике Sharepoint. Добавьте в закладки постоянную ссылку.

    Добавить комментарий

    Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

    Логотип WordPress.com

    Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

    Фотография Twitter

    Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

    Фотография Facebook

    Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

    Google+ photo

    Для комментария используется ваша учётная запись Google+. Выход / Изменить )

    Connecting to %s