Механизм хранения

При определении домашней страницы SharePoint считывает свойство vti_welcomepage корневой папки сайта. Используя следующий PowerShell, можно посмотреть значение для сайта:

Если значение этого свойства не задано, то страницей по умолчанию считается default.aspx.

Изменение домашней страницы

Изменить домашнюю страницу сайта можно несколькими способами.

Способ 1: Параметры сайта

Домашнюю страницу можно изменить в разделе Страница приветствия параметров сайта:

Можно воспользоваться кнопкой Обзор. для удобного выбора домашней страницы сайта.

Способ 2: SharePoint Designer

Чтобы задать страницу приветствия с помощью SharePoint Designer достаточно в контекстном меню файла выбрать Set as a Home Page:

Способ 3: PowerShell

Того же результата можно достичь, используя PowerShell:

Допустимые значения

Изменение домашней страницы с помощью параметров сайта и SharePoint Designer ограничено из-за использование интерфейса. С помощью PowerShell можно достичь большей гибкости.

Ограничения, накладываемые SharePoint при задании домашней страницы:

• Путь должен быть относительным по отношению к корневой папке сайта;
• Путь не должен содержать двух точек.

В противном случае будет выдано соответствующее исключение:

На этом ограничения заканчиваются.

Любой файл на сайте

Начальной страницей может быть не только страница, но и любой файл на сайте. Указав в качестве домашней страницы ссылку на изображение в библиотеке, мы получим редирект с сайта на указанный файл:

Дочерний сайт

Можно указать в качестве домашней страницы ссылку на дочерний сайт.

Если, например, есть сайт http://portal и дочерний сайт http://portal/subsite, то для родительского сайта можно указать дочерний сайт в качестве домашней страницы (адрес должен быть относительным, т.е. без / вначале):

Список

Аналогично можно указать ссылку на представление списка или библиотеки документов. При открытии сайта пользователь будет автоматически перенаправлен на список:

QueryString, Hash

Также в адресе домашней страницы можно использовать QueryString и/или Hash. В следующем примере домашней страницей будет форма просмотра элемента списка с идентификатором, равным 1. Дополнительно в адрес передается hash:

И результат в Developer Tools:

Примеры работают в SharePoint 2010/2013/2016 и SharePoint Online.

Корпоративный портал в Интернете

Цель лекции. Показать, как создаются веб-узлы SharePoint в локальной сети и в Интернете , а также описать, как можно быстро организовать в Интернете связку «общедоступный веб-узел — внутренний корпоративный портал». Рассматривается создание узлов верхнего уровня, дочерних узлов и содержимого SharePoint.

1.1. Создание веб-узла на собственном сервере

Рассмотрим, как, пользуясь возможностями служб SharePoint, можно быстро создать корпоративный сайт , отвечающий типичным запросам российской компании. В качестве конкретного примера используем сайт ЗАО Полибук Мультимедиа авторов этого курса.

Техническое задание

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

• Лента новостей
• Календарь (для планирования ключевых дат, например, сдачи баланса, корпоративных праздников и т.д.)
• Форум сотрудников
• Блог руководителя
• Несколько библиотек документов (договора, первичная бухгалтерская отчетность ) с настроенным электронным документооборотом
• Дочерние веб-сайты (второго уровня) отделов и личные страницы сотрудников
• Вики-библиотека

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

Этот раздел будет посвящен решению «глобальных» задач — созданию и администрированию родительского и дочерних веб-узлов , а, собственно, выполнение технического задания будет вынесено в лабораторные работы и последующие лекции. В качестве первого этапа станем разрабатывать веб-сайт, размещенный на сервере компании (либо в локальной сети, либо в Интернете — на выделенном сервере хостинг-провайдера для организации удаленной работы сотрудников), имея в виду, что на втором этапе он может быть без труда перенесен на другое место в сети Интернет .

Создание веб-узла верхнего уровня (на сервере)

Приведем описание процесса организации корпоративного портала с самого начала, т.е. с создания нового семейства веб-узлов SharePoint на сервере , которое будет, по определению, веб-сайтом (или, что то же самое веб-узлом ) SharePoint верхнего уровня. Эта часть работы должна осуществляться на сервере сетевым администратором, обладающим соответствующими правами на администрирование служб SharePoint.

Для того, чтобы создать новый веб-узел верхнего уровня , выполните следующее.

1. На сервере , на котором развернуты службы SharePoint , выберите в главном меню Пуск команду Администрирование / Центр Администрирования служб SharePoint 3.0.
2. В открывшемся окне браузера со страницей Центра Администрирования на вкладке Управление приложениями щелкните ссылку Создание семейства веб-узлов (рис. 1.1).
3. На одноименной странице (рис. 1.2) введите в соответствующие поля название, краткое описание веб-узла (оно потом появится на домашней странице) и окончание его URL-адреса, которое, добавившись к идентификатору сервера в локальной сети, станет адресом домашней страницы веб-узла (в примере, показанном на рис. 1.2, это будет адрес — http://win-a848da7q7wv/sites/polybook).

В принципе, уже сейчас (после всего пары минут установки!) сайт вполне можно использовать для коллективной работы предприятия. Если затратить еще несколько минут, то, не выходя из браузера, несложно настроить разрешения для пользователей и добавить дополнительные фрагменты сайта (например, библиотеки рисунков и форм, дочерние веб-узлы страничек сотрудников и т.п.), выполнив полностью (или почти полностью) наше нехитрое техническое задание. Заметим попутно, что обратившись к сайту Майкрософт, либо к возможностям, предоставляемым Вашим SharePoint-хостинг-провайдером, несложно отыскать шаблоны узлов , подходящих для более специфических задач (организация call-центра, вики-библиотеки и т.д. и т.п.).

Однако, мы пойдем по несколько другому пути, обратившись, вместо браузера, к специальному средству редактирования веб-сайтов SharePoint — программой Microsoft Office SharePoint Designer .

Доступ к веб-узлу для его редактирования (на компьютерах клиентов)

После того, как сайт верхнего уровня (мы будем также использовать термин портал ) создан на сервере , его разрешается редактировать с клиентских компьютеров, подключенных к локальной сети. (Конечно, подключаться к сайту необходимо, пользуясь учетными записями, для которых администратором настроены соответствующие разрешения).

Для того, чтобы открыть в SharePoint Designer некоторый веб-узел (например, только что созданный в браузере), выполните следующее.

1. Введите команду Файл / Открыть узел.
2. В диалоговом окне Открытие веб-узла отыщите желаемый узел в списке папок, либо (что, возможно, будет проще) введите его непосредственно в поле Имя узла (рис. 1.4).

В результате узел будет загружен в SharePoint Designer , а для открытия его домашней страницы (рис. 1.5) следует дважды щелкнуть на ее названии — default.aspx — на панели Список папок.

Здесь стоит напомнить, что, веб-страница на узле SharePoint, формируется путем объединения:

• мастер-страницы (или, по-другому, главной страницы узла) — файла-шаблона (с расширением .master), включающего общие элементы для всех страниц узла SharePoint (рис. 1.6);
• страницы содержимого ( контента ) — файла с расширением .aspx, содержащего уникальное наполнение страницы (рис. 1.5).

И master-, и aspx-страницы редактируются по одинаковым правилам в SharePoint Designer , что позволяет разделить разработку, соответственно, общего дизайна сайта, и наполнения его конкретных веб-страниц.

Сайт коллекции SharePoint, управляемые пути, а можно субдомены?

Сильно не буду влезать в теорию, т.к. она очевидна тем специалистам, которым может быть интересен итоговый тезис статьи.

Речь пойдет о ссылках, по которым могут быть размещены сайт коллекции SharePoint.

Без минимума теории было бы тоже неправильно.

Если взглянуть на логическую архитектуру сайтов SharePoint, то мы увидим следующую картину:

Во главе стола — IIS и веб-приложения, в рамках веб-приложений размещаются сайт коллекции, а в них, в свою очередь, набор сайтов.

С точки зрения адресации, веб-приложение определяет Host Header и порт, которые, кстати, легко могут быть переопределены альтернативным доступом (AAM) или расширением веб-приложения.

В рамках примера, пусть у нас будет следующее веб-приложение:

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

При этом сайт коллекция всегда содержит корневой сайт.

У сайтов может быть иерархия подсайтов.

Адреса подсайтов формируются следующим образом:

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

Управляемые пути бывают двух типов:

• Явные (Explicit)
  • В случае с явными путями сайт коллекция будет располагаться в корне управляемого пути, на таком пути, логично предположить, сможет существовать только одна сайт коллекция.
  • Продолжим пример, допустим у нас создан управляемый путь «spdemo» с типом Explicit.
  • Ссылка созданной сайт коллекции будет следующией: http://sharepoint2013.arvosys.ru/spdemo/
• Подстановки (Wildcard)
  • Подстановки созданы, чтобы на них можно было располагать множество сайт коллекций, при этом для каждой сайт коллекии добавлется «папка» в пути адреса.
  • По умолчанию создан управляемый путь «sites».
  • При создании сайт коллекции «spdemo» ссылка будет следующией: http://sharepoint2013.arvosys.ru/sites/spdemo/

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

Давайте представим ситуацию, что нам нужно:

• нашу ферму вывести конечным пользователям с использованием субдоменов, вот такое оно функциональное требование: CRM должен быть по адресу http://crm.company.org, управление проектами — http://epm.company.org, документооборот на http://ecm.company.org и так далее и никак иначе,
• т.е., все адреса должны быть на 80-м порту,
• количество субдоменов для разных функциональных случаев не ограничено.

Вроде как приходит мысль создавать разные веб-приложения по разным субдоменам, но не стоит так делать, если создание отдельных веб-приложений не обусловлено политикой безопасности или еще какими либо вескими причинами.

Кстати, вопрос: может ли быть несколько веб-приложений на одном порту? Ответ: да, конечно могут, если будут с разными Host Header’ами.

Так что же делать, спросите Вы, если не создавать отдельные веб-приложения? Как быть?

И вот ради этого ответа весь этот пост. Сайт коллекции могут быть и на субдомене, отличном от Host Header веб-приложения.

Создавать такие сайт коллекции можно только через PowerShell.

Add-PSSnapin Microsoft.SharePoint.PowerShell-ErrorAction SilentlyContinue;

-Name «SPDemo» ` -OwnerAlias «CIBSPAdmin» `

New-WebBinding -Name «http://sharepoint2013.arvosys.ru» `

Add-PSSnapin — добавление снапина объектной модели SharePoint, хороший тон, чтобы он присутствовал.

New-SPSite — командлет создания сайт коллекции.

• В передаваемом идентификатора надо указать ссылку на субдомене и оно будет работать.
• В параметр HostHeaderWebApplication указываем наше веб-приложение.
• Name — наименование сайт коллекции.
• OwnerAlias — владелец сайт коллекции, второго можно не указывать.
• Template — идентификатор шаблона сайт коллекции. «STS#0» — идентификатор TeamSite. Параметр можно пропустить, тогда при первой навигации к сайт коллекции можно будет выбрать нужный шаблон в визуальном интерфейсе.

New-WebBinding — одно из составляющих чуда. Непосредственно к SharePoint отношения не имеет. Данный командлет выставляет настройку IIS, а именно прописывает связь с нужным Host Header.

Последнее составляющее «чуда» — добавить запись в DNS.

В итоге в одном веб-приложении, на одном порту, на разных субдоменах, у нас заводятся и работают сайт коллекции SharePoint.

Многоликий SharePoint

Я часто консультирую людей по поводу SharePoint, и каждый раз я слышу примерно одно и то же: “мы планируемразрабатываемвнедряемиспользуемхотим_выкинуть портал на SharePoint”. Такое ощущение, что единственное для чего предназначен SharePoint – делать порталы. Как битрикс или, не дай бог, друпал. Ситуацию еще подогревают HRы, которые хотят “интранеты” (имея ввиду ровно тоже, что и порталы).

Если же попадается грамотный заказчик,который понимает проблемы за пределами фразы “корпоративный портал”, то подрядчик зачастую пытается впарить свое “портальное решение”. Это “решение” должно закрывать все потребности заказчика одним махом.

Конечно порталы каждый раз разные, но в них очень много общего.

Типовой корпоративный портал на SharePoint

Обычно на портал возлагаются следующие задачи:

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

Самое странное, что многие цели противоречат друг другу, но это никого не смущает. Например документооборот крайне плохо сочетается с уникальным дизайном. Никому в голову не придет делать уникальный дизайн в Documentum или DocsVision, а в SharePoint это нормально. Хранилище активов требует разграничения доступа в соответствии с организационной структурой, а совместная работа и улучшение коммуникаций, наоборот, требует преодоления рамок организационной структуры. Весь feature soup, который предлагается в качестве полезного функционала, вообще ни как не коррелирует с заявленными целями и присутствует, в основном, “для галочки”. И это еще не самое страшное…

Самое страшное начинается когда этот портал пытаются реально использовать. Ведь бизнес динамичен, постоянно требуется что-то поменять, подкрутить, дать доступ, создать сайт, изменить страницу. Но универсальное “портальное решение” больше напоминает не гибкую систему, а изваяние из гранита, которое даже передвинуть нельзя, не то что как-то поменять.

Приспособить “портал” под конкретные задачи пользователей оказывается сложно, а без этого adoption становится низкий и вложения не окупаются. Гигантский набор фич на портале используется от силы на 20% и, зачастую, страдает от проблем масштабирования.

Почему так происходит

Ситуация описанная выше повторяется чуть менее, чем всегда. Казалось бы зачем покупать порталы, когда они приводят к неудовлетворительному результату. Но проблема в том, что все продают “корпоративные порталы”. Все это не только Microsoft и партнеры, это в том числе те, кто внедряет другие технологии, от вики движков, до битриксов и WebSphere. Тут работает принцип социального доказательства: “если все остальные покупают корпоративные порталы, то чем мы хуже”.

Сам термин корпоративный портал является ментальным шорткатом, который избавляет продавца и покупателя от необходимости выяснения потребностей. Кроме того, для продавца продать «корпоративный портал” – это хороший способ продать проект допиливания портала под конкретные нужды.

Я думаю для многих не секрет, что некоторые вендоры “корпоративных порталов” по факту не имеют портала как продукта (распространяющегося без программистов).

Как сделать правильное решение

Для создания хорошего решения на SharePoint необходимо:

1. Сосредоточиться на целях
2. Поставить измеримые KPI
3. Планировать информационную архитектуру
4. Создавать самые простые решения

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

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

Примеры решений на SharePoint

Корпоративный поиск

Цель – уменьшить время на поиск информации.
KPI – количество успешных запросов (с кликом на результат) и количество неуспешных (без результатов или без клика на результат). На основании этих величин можно получить экономический эффект и вычислить целевые значения.
Архитектура – искать “везде” обычно плохо работает. Смотрите на поисковую выдачу интернет-поисковиков. Там есть разные типы информации, поиск по разным источникам, продвигаемые результаты,actionable результаты. Адаптируйте к своим источникам и внедряйте.
Решение – стандартный поиск SharePoint 2013. После внедрения поисковая аналитика и “тюнинг” поиска.

Рабочие области команд и проектов

Цель – увеличить эффективность совместной работы.
KPI – количество пересылаемых по электронной почте документов. Взять baseline до запуска системы, уменьшить на 30%-50%-80% по вкусу.
Архитектура – необходимо сделать максимально простой процедуру создания сайтов с библиотекой и списками для совместной работы. Без заявок в ИТ и согласований.
Решение – стандартные сайты команд SharePoint, плоские разрешения, контролируемый жизненный цикл. Обучение пользователей возможностям платформы.

Корпоративный сайт

Цель – сделать единую точку входа для информационных ресурсов компании.
KPI – Количество просмотренных страниц сайта (новостей, событий, фотовидео материалов), количество опубликованных, процент сотрудников, ответивших на опросы. Каждая новость, опубликованная на сайте, должна быть прочитана значительным количеством сотрудников (30% и более), при определенном темпе публикации можно получить довольно точные количественные характеристики.
Архитектура – фиксированные типы информации, малое количество редакторов, простая система разрешений. Участие пользователей – лайки и комментарии, ответы на опросы.
Решение – отдельная коллекция сайтов с режимом публикации, кастомный дизайн, фиксированная структура. Обязательное обучение авторов контента.

Документооборот

Цель – уменьшить время согласования.
KPI – Время согласования документов (по типам). Можно взять baseline с текущей ситуации, уменьшить на 30%-50%-80% по вкусу.
Архитектура – фиксированные маршруты, роли, типы документов. Это очень важный момент. Если в согласовании может принимать участие произвольное количество людей, то считать KPI становится невозможным. Если документы нельзя разделить по типам, то тоже вызывает проблемы расчета KPI.
Решение – Отдельный сайт или коллекция, типы контента, шаблоны, workflow. Предусмотреть вычисление количества днейчасовминут на согласование. Ну и без обучения, скорее всего, никуда.

Специализированные варианты решений:

• Enterprise Content Management Электронный Архив
• Автоматизация заявок
• Базы знаний
• Системы оценки персонала
• Системы внутренних вакансий

Попробуйте на досуге продумать конкретные цели и KPI таких систем.

Самое важное – все это разные системы. Нет смысла все валить в одну кучу и называть “корпоративным порталом”, так достичь KPI не получится.