Поделиться через

Руководство по агрегации контента для порталов SharePoint Online

  • Статья

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

Примечание.

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

Что не стоит делать

В следующем списке содержатся основные действия, которые не следует выполнять, если нужно создать эффективный интерфейс агрегации контента.

Не рекомендуется:

  • Всегда и везде использовать метод агрегации контента в режиме реального времени.
  • Помещать десятки плохо разработанных элементов управления агрегацией контента на объемной странице портала (например, домашней странице).
  • Использовать объект групповой политики (GPO) для принудительной загрузки браузерами проблемной страницы портала по умолчанию.
  • Отказываться от установки ограничений строк для результатов агрегации контента.
  • Отказываться от кэширования результатов агрегации контента.
  • Выбирать в качестве цели устаревшую веб-службу списков (SOAP). Если передавать ей плохо оформленные запросы CAML, это создаст дополнительные проблемы.

Определение агрегации контента

Важно установить четкое определение агрегации для контекста этой статьи.

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

Агрегация контента не включает контент, созданный на текущей странице.

Агрегация контента в основном предназначена для интерфейсного пользовательского представления портала (в отличие от внутреннего административного представления).

Примеры, где может использоваться агрегация контента:

  • Домашняя страница портала, содержащая элемент управления последними новостями, который отображает список ссылок на последние статьи, опубликованные на портале.
  • Страницы портала, содержащие элементы глобальной структуры навигации, которые отображают навигационные ссылки, управляемые в настраиваемом списке SharePoint.

Требование агрегации контента в режиме реального времени

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

Примеры, где может ожидаться агрегация контента в режиме реального времени:

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

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

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

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

В этом заключается вызов для архитектора портала: уступить этому давлению и создать риск возникновения проблем для производительности портала или убедить группу в обратном и создать портал с высокой производительностью? Мы рекомендуем убедить группу в обратном.

Агрегация контента буквально в режиме реального времени технически невозможна в любой системе публикации. Даже если придерживаться стандартных действий портала публикации, задержки и сбои возникают в различных точках конвейера агрегации или отображения контента. Некоторые из них видны и подвергаются настройке (например, настраиваемый клиентский кэш, серверный выходной кэш и серверный кэш объектов), а некоторые — скрыты и неизменяемы (например, планы запросов базы данных и внутренние кэши приложения).

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

После принятия факта, что агрегацию контента в режиме реального времени нельзя успешно осуществить, остается лишь обсудить следующее:

  • Сколько вы готовы ждать, чтобы увидеть контент?
  • Сколько вы готовы "заплатить", чтобы увидеть контент немного раньше?

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

Примечание.

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

Методы агрегации контента

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

Важно!

Рекомендуется отдать предпочтение агрегации контента на основе поиска, а не агрегации контента на основе CAML.

Агрегация контента на основе CAML

Метод агрегации контента на основе CAML основан на использовании запросов на языке CAML.

Вы можете создать запросы CAML и использовать их для выполнения операций агрегации контента в SharePoint. Запросы выполняются для баз данных контента SharePoint. Запросы CAML встроены в реализованные серверные элементы управления, например готовую веб-часть "Контент по запросу". Запросы CAML также можно использовать непосредственно для различных API обнаружения контента, доступных для настраиваемых клиентских элементов управления JavaScript.

Основное преимущество CAML состоит в максимальном приближении к агрегации контента в режиме реального времени.

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

Путем запрещения развертывания пользовательского кода в SharePoint Online устранена причина снижения производительности SharePoint традиционно относившаяся к единственной наихудшей категории: настраиваемые серверные элементы управления и веб-части, использующие плохо оформленные запросы CAML. Однако по-прежнему имеется возможность неправильного использования CAML с помощью стандартных веб-частей "Контент по запросу", а также настраиваемых клиентских элементов управления JavaScript.

Обратите внимание на следующее:

  • Каждый клиентский запрос CAML приводит к прямому запросу базы данных:

    • Клиентские результаты CAML не кэшируются на сервере.
    • Клиентские запросы CAML поступают на сервер базы данных для выполнения (всегда возникает промах в кэше).

  • Каждый серверный запрос CAML рискует стать прямым запросом базы данных:

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

Важно!

По возможности рекомендуется избегать агрегации контента на основе CAML.

Руководства по использованию агрегации контента на основе CAML

  • Избегайте ее использования на объемных страницах.
  • Ограничьте ее использование определенными классами контента (например, оповещениями).
  • Определите самый простой, наиболее эффективный запрос CAML и проверьте его эффективность.
  • Реализуйте индексированные столбцы для целевых списков.
  • Включите ограничения строк для запроса.
  • Убедитесь, что настраиваемые клиентские элементы управления JavaScript предусматривают ссылку Подробнее для перенаправления пользователей на менее объемную страницу "Просмотреть все".
  • Убедитесь, что настраиваемые клиентские элементы управления JavaScript используют платформу клиентского уровня доступа к данным для кэширования отклика контента. Нет результатов — допустимый ответ, который также должен кэшироваться.
  • Установите для срока действия клиентского кэша значение не менее пяти минут.

Дополнительные сведения о клиентском уровне доступа к данным см. в статье Руководство по оптимизации производительности для порталов SharePoint Online.

Агрегация контента на основе поиска

Способ агрегации контента на основе поиска основан на использовании запросов SharePoint на языке запросов по ключевым словам (KQL).

Вы можете создать поисковые запросы KQL и использовать их для выполнения операций агрегации контента в SharePoint. Запросы выполняются для индекса поиска SharePoint. Поисковые запросы KQL встроены в реализованные серверные элементы управления, например готовую веб-часть "Контент по поиску". Запросы KQL также можно использовать непосредственно для API поиска, доступных для настраиваемых клиентских элементов управления JavaScript.

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

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

Обратите внимание на следующее:

  • Для контента портала должен быть выполнен обход и добавление в индекс поиска, чтобы сделать его доступным для агрегации данных на основе поиска.

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

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

Важно!

Рекомендуется использовать агрегацию контента на основе поиска.

Руководства по использованию агрегации контента на основе поиска

  • Убедитесь, что ваши группы управления контентом понимают необходимость обхода контента перед его агрегацией.

    • Установите ожидания в отношении задержки агрегации контента.

  • Настройте необходимую схему поиска.

    • Выберите соответствующую область (клиент, семейство веб-сайтов или веб-сайт).
    • Запустите автоматическое создание управляемых свойств для обхода.
    • Используйте стандартные управляемые свойства заполнителя (например, RefinableInt01), когда требуется сортировка или уточнение.

  • Разработайте соответствующие источники результатов и запросы.

    • Выберите в качестве цели нужные отдельные списки, веб-части или сайты.
    • Выберите в качестве цели нужные отдельные типы контента.
    • Выберите в качестве цели нужные определенные управляемые свойства (например, столбцы сайта).

  • Выберите нужные элементы управления отображением:

    • Стандартные элементы управления:
      • Используйте веб-части "Контент по поиску".
      • Возвращайте нужное минимальное число строк и столбцов.
      • Разработайте необходимые шаблоны отображения.
      • При желании включите асинхронную клиентскую обработку.
    • Настраиваемые элементы управления:
      • Используйте настраиваемые клиентские элементы управления JavaScript, использующие REST API поиска.
      • Возвращайте нужное минимальное число строк и столбцов.
      • Используйте платформу клиентского уровня доступа к данным для кэширования отклика контента.

Дополнительные сведения о клиентском уровне доступа к данным см. в статье Руководство по оптимизации производительности для порталов SharePoint Online.

См. также