OneDrive для бизнеса настройки в модели надстройки SharePoint

Подход, который вы используете для настройки OneDrive для бизнеса сайтов в новой модели надстройки SharePoint, отличается от подхода, используемого в коде полного доверия. В типичном сценарии полного доверия (FTC) или решения фермы задания таймера SharePoint были созданы с помощью кода объектной модели на стороне SharePoint Server, развернутого через решения фермы и управляемого на веб-сайте центра администрирования SharePoint. В этом сценарии SharePoint обрабатывает как планирование, так и выполнение задания таймера.

В сценарии модели надстройки SharePoint задания таймера создаются и планируются за пределами SharePoint. SharePoint не несет ответственности за планирование или выполнение задания таймера в этом сценарии.

Зачем настраивать OneDrive для бизнеса сайты?

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

Руководящие принципы высокого уровня

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

• Применение настройки фирменной символики с помощью Office 365 тем или подсистемы тем сайта SharePoint
• Если обработчиков тем недостаточно, можно настроить некоторые параметры CSS с помощью альтернативного варианта CSS.
• Избегайте настройки сайтов OD4B с помощью пользовательских страниц master, так как это приведет к дополнительным долгосрочным затратам и проблемам при будущих обновлениях
  • В большинстве случаев вы можете достичь всех распространенных сценариев фирменной символики с помощью тем и альтернативных CSS, так что на самом деле это не тот ограничивающий фактор
  • Если вы решили использовать пользовательские страницы master, будьте готовы к применению изменений к сайтам при применении основных функциональных обновлений к Office 365
• Внедрение JavaScript можно использовать для изменения или скрытия функциональных возможностей на сайте.
• CsOM можно использовать для управления, например, языковыми или региональными параметрами на сайтах OD4B (см. новые API)
• Мы не рекомендуем использовать типы контента и столбцы сайта на сайтах OD4B, чтобы избежать проблем с обязательными полями или другими элементами, которые могут вызвать проблемы для обычных вариантов использования с сайтами OD4B.
  • Сайты OD4B считаются личными неструктурированными данными и документами. Сайты групп и группы совместной работы используются для корпоративных данных и документов, где вы, безусловно, можете использовать любые политики управления информацией и метаданные.

Таким образом, настройка определенно поддерживается в Office 365, и вы можете продолжать использовать их с сайтами OD4B. Мы просто действительно хотим, чтобы вы учитывали краткосрочное и долгосрочное влияние настройки с точки зрения эксплуатации и обслуживания. На самом деле это не является конкретным для SharePoint, скорее это правило для любой сборки ИТ-решений с любой платформой.

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

Трудности с применением настроек сайта OneDrive для бизнеса

Начнем с определения проблемы и того, что мы пытаемся решить здесь. Технически каждый сайт OneDrive для бизнеса в настоящее время использует такую же архитектуру, как личные или личные сайты, которые использовались в версии SharePoint 2007 или 2010. Это означает, что технически каждый OneDrive для бизнеса сайт является собственным семейством веб-сайтов, и у нас нет централизованного расположения для применения фирменной символики или любых других настроек.

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

В Office 365 не создается централизованное событие, к которому можно было бы присоединить пользовательский код при создании сайта OD4B. Это означает, что нам нужно подумать об альтернативных решениях, что довольно часто встречается в подходах к модели приложений. Не застряйте на старых моделях, подумайте о том, как достичь того же конечного результата с помощью новых API и технологий. С точки зрения чистого требования на самом деле не имеет значения, как мы применяем настройки к сайтам, если они применяются, так как бизнес-требование заключается не в использовании скрепления функций, а о применении необходимых настроек с использованием любого поддерживаемого технического механизма.

Различные варианты применения настройки

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

1. Параметры уровня набора Office 365 (темы Office 365 и другие параметры)
2. Скрытая часть приложения с контекстом пользователя
3. Предварительное создание и применение конфигурации
4. Удаленное задание таймера на основе обновлений профилей пользователей

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

Параметры на уровне набора Office 365

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

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

На следующем рисунке показаны различные параметры для Office 365 тем, которые затем будут применяться ко всем Office 365 службам.

Так как по умолчанию параметры Office 365 темы предназначены для управления панелью набора сайтов OD4B, вы, скорее всего, будете использовать эти параметры вместе с другими параметрами, чтобы обеспечить по крайней мере правильные элементы фирменной символики на сайтах OD4B. Обратите внимание, что при изменении, например, Office 365 параметров темы в средстве администрирования Office 365, на применение параметров для сайтов OD4B требуется довольно много времени, поэтому будьте терпеливы.

Скрытая часть приложения с контекстом пользователя

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

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

Давайте подробнее рассмотрим логическую структуру этого подхода.

1. Поместите скрытую часть приложения на централизованный сайт, где будут размещаться конечные пользователи. Обычно это начальная страница корпоративной интрасети.
2. Часть приложения размещает страницу из приложения, размещенного поставщиком, где в коде на стороне сервера мы инициируем процесс настройки, добавляя необходимые метаданные в очередь хранилища Azure. Это означает, что эта страница будет получать только запрос на настройку, но фактически не будет применять никаких изменений для поддержания нормального времени обработки.
3. Это фактическая очередь службы хранилища Azure, которая будет получать сообщения для обработки. Таким образом, мы можем асинхронно обрабатывать процесс управления настройкой, чтобы не иметь значения, как долго конечный пользователь будет оставаться на первой странице интрасети. Если процесс настройки будет синхронным, мы будем зависеть от конечного пользователя, чтобы сохранить браузер открытым на главной странице интрасети до завершения выполнения страницы. Это, безусловно, не было бы оптимальным, и это была проблема с оригинальным процессом настройки OD4B, который я блог в то время назад.
4. Веб-задание подключено для следовать очереди хранилища, которая вызывается при добавлении нового элемента в очередь хранилища. Это веб-задание получит необходимые параметры и метаданные из сообщения, помещенного в очередь, для доступа к правому семейству веб-сайтов. Веб-задание использует только маркер приложения и ему предоставлены необходимые разрешения для управления семействами веб-сайтов на уровне клиента.
5. Фактические настройки применяются по отдельности к сайтам пользователей, которые посещают страницу интрасети, чтобы начать процесс.

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

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

Предварительное создание и применение конфигурации

Этот параметр зависит от предварительного создания сайтов OD4B, прежде чем пользователи получат к ним доступ. Этого можно достичь с помощью относительно нового API , который предоставляет нам возможность создавать сайты OD4B для определенных пользователей в пакетном процессе с помощью CSOM или REST. Необходимый код можно инициировать с помощью скрипта PowerShell или путем написания фактического кода, который вызывает удаленные API.

1. Администратор использует ИНТЕРФЕЙСы API удаленного создания для создания сайтов OD4B для пользователей и применяет необходимые настройки к сайтам OD4B в рамках процесса скрипта.
2. Фактические сайты OD4B создаются в Office 365 для конкретных пользователей и связаны с их профилями пользователей.

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

Удаленное задание таймера на основе обновлений профилей пользователей

Этот подход означает сканирование профилей пользователей на предмет того, кому был создан сайт OD4B, а затем применить изменения к сайтам по мере необходимости. Это означает, что запланированное задание выполняется за пределами SharePoint, которое будет периодически проверка состояние и выполнять необходимые настройки. Запланированное задание может выполняться как веб-задание в Azure или как простое, как сценарий PowerShell, запланированный в вашем планировщике Windows. Очевидно, что масштаб развертывания оказывает огромное влияние на выбранный вариант планирования.

1. Инициируется запланированная задача, которая будет обращаться к профилям пользователей для проверки того, у кого подготовлен сайт OD4B.
2. Фактические сайты настраиваются по отдельности на основе бизнес-требований.

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

Расширенная настройка на основе части приложения

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

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

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

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

• Расположение ресурсов — решение для централизованной сети доставки содержимого (CDN) в каждом семействе веб-сайтов или в корневом семействе веб-сайтов?
• Частота обновления ресурсов или как убедиться, что независимо от кэширования браузера на стороне клиента мы можем обеспечить выполнение последних версий скриптов (JavaScript) или отображение последних версий образов?
• Сокращено выполнение кода, чтобы избежать ненужной нагрузки в Azure и службу Office 365
• Настройки версий, применяемые к сайту OD4B

Расположение ресурсов

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

В этой эталонной реализации мы фактически также обновляем этот файл при каждом выполнении веб-задания, что, конечно, не требуется, но пример кода должен был работать так же легко, без каких-либо дополнительных шагов и возможных. Точно так же можно отправить файл JavaScript вручную в корневое семейство веб-сайтов, а затем ссылаться на него. Альтернативным решением также будет использование некоторых CND для хранения необходимого файла или ссылки на JavaScript на стороне размещенного поставщика приложения. Если у вас есть только одна копия файла, у вас будет следующее:

Проблема кэширования на стороне клиента и способы ее решения

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

Чтобы устранить эту проблему, можно начать использовать атрибут revision со ссылкой на URL-адрес JavaScript. При связывании пользовательского действия с сайтом OD4B мы включаем URL-адрес JavaScript, чтобы в URL-адресе был уникальный GUID. Ниже приведен пример ссылки, указывающей на корневой сайт семейства веб-сайтов. Обратите внимание на дополнительный GUID, добавленный после атрибута rev в URL-адресе. Каждый раз, когда настройщик будет выполняться для определенного сайта OD4B, этот атрибут будет обновляться. На практике это означает, что файл JavaScript кэшируется в браузере до тех пор, пока на сайт OD4B не будет добавлена новая версия, которая изменит URL-адрес и, следовательно, браузер загрузит новую версию и будет кэшировать ее после следующего обновления.

• /OneDriveCustomization/OneDriveConfiguration.js?rev=4bb89029e7ba470e893170d4cba7de00

Ниже приведен код, который используется для создания URL-адреса JavaScript для пользовательского действия.

/// <summary>
/// Just to build the JS path which can be then pointed to the OneDrive site.
/// </summary>
/// <returns></returns>
public string BuildJavaScriptUrl(string siteUrl)
{
    // Solve root site collection URL
    Uri url = new Uri(siteUrl);
    string scenarioUrl = String.Format("{0}://{1}:{2}/{3}", 
                            url.Scheme, url.DnsSafeHost, 
                            url.Port, JSLocationFolderName);
    // Unique rev generated each time JS is added, so that we force browsers to 
    // refresh JS file wiht latest version
    string revision = Guid.NewGuid().ToString().Replace("-", "");
    return string.Format("{0}/{1}?rev={2}", scenarioUrl, JSFileName, revision);
}

Сокращенное выполнение кода

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

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

Самый простой способ убедиться, что обработка не выполняется в каждом запросе, — использовать классический подход к файлам cookie браузера, при котором мы будем хранить определенные файлы cookie в клиентском браузере с определенным временем жизни. Проверив наличие этого файла cookie, мы можем пропустить выполнение, пока срок действия файла cookie не истек, а затем мы повторно проверка фактическое состояние настройки на сайтах OD4B.

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

// Check if we should skip this check. We do this only once per hour to avoid 
// perf issues and there's really no point even hitting the user profile 
// in every request.
if (CookieCheckSkip())
    return;

Фактическое состояние файла cookie и настройка файла cookie выполняются следующим образом.

/// <summary>
/// Checks if we need to execute the code customization code again. 
/// Timer set to 60 minutes to avoid constant execution of the code for nothing.
/// </summary>
/// <returns></returns>
private bool CookieCheckSkip()
{
    // Get cookie from the current request.
    HttpCookie cookie = Request.Cookies.Get("OneDriveCustomizerCheck");

    // Check if cookie exists in the current request.
    if (cookie == null)
    {
        // Create cookie.
        cookie = new HttpCookie("OneDriveCustomizerCheck");
        // Set value of cookie to current date time.
        cookie.Value = DateTime.Now.ToString();
        // Set cookie to expire in 60 minutes.
        cookie.Expires = DateTime.Now.AddMinutes(60);
        // Insert the cookie in the current HttpResponse.
        Response.Cookies.Add(cookie);
        // Output debugging information
        WriteDebugInformationIfNeeded(
            string.Format(@"Cookie did not exist, adding new cookie with {0} 
                            as expiration. Execute code.",
                            cookie.Expires));
        // Since cookie did not existed, let's execute the code, 
        // so skip is false.
        return false;
    }
    else
    {
        // Output debugging information
        WriteDebugInformationIfNeeded(string.Format(@"Cookie did existed, 
                                    with {0} as expiration. Skipping code.", 
                                    cookie.Expires));
        //  Since cookie did existed, let's skip the code
        return true;
    }
}

Если вы внимательно изучите код на странице части приложения, вы увидите, что при каждом вызове мы проверка существования сайта OD4B для конечного пользователя. Так как это можно сделать только путем доступа к профилю пользователя, код будет влиять на производительность. Используя приведенный выше проверка файлов cookie, мы можем улучшить взаимодействие с конечными пользователями, и мы избегаем постоянного попадания в службу профилей пользователей без фактических требований. Также приятно отметить, что мы разместили этот файл cookie проверка в качестве первого шага в методе Page_Load, чтобы при необходимости пропустить всю обработку. Ниже приведен краткий фрагмент из метода Page_Loadиз Customizer.aspx для отображения процесса кода.

protected void Page_Load(object sender, EventArgs e)
{
    // Check if we should skip this check. We do this only once per hour to avoid 
    // perf issues and there's really no point even hitting the user profile 
    // in every request.
    if (CookieCheckSkip())
        return;
  
    var spContext = 
        SharePointContextProvider.Current.GetSharePointContext(Context);
    using (ClientContext clientContext = 
        spContext.CreateUserClientContextForSPHost())
    {
        // Get user profile
        ProfileLoader loader = ProfileLoader.GetProfileLoader(clientContext);
        UserProfile profile = loader.GetUserProfile();
        Microsoft.SharePoint.Client.Site personalSite = profile.PersonalSite;

        clientContext.Load(profile, prof => prof.AccountName);
        clientContext.Load(personalSite);
        clientContext.ExecuteQuery();

        // Let's check if the site already exists
        if (personalSite.ServerObjectIsNull.Value)
        {

Настройки версий, применяемые к сайту OD4B

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

Этот подход также значительно сократит необходимые ресурсы из Microsoft Azure, так как мы избегаем обновления или выполнения фактического кода настройки, когда он не нужен. Это означает сокращение использования ЦП и других ресурсов в Microsoft Azure и уменьшение количества запросов к Office 365.

Вся логика настройки, хранящейся в этом примере, находится в методе ApplySiteConfiguration в OD4B. Класс Configuration.Async.Common.SiteModificationManager . Этот метод также вызывается веб-заданием с правильными параметрами для запуска процесса настройки. Перед фактическим выполнением каких-либо операций мы проверяем значение контейнера свойств с помощью ключа "Contoso_OneDriveVersion" и выполнение будет продолжаться только в том случае, если текущая версия на сайте ниже версии, которую мы планируем применить. Ниже приведен фактический код, который использует компонент Office PnP Core для упрощения кода.

// Check current site configuration status - is it already in right version?
if (ctx.Web.GetPropertyBagValueInt(
    SiteModificationManager.OneDriveMarkerBagID, 0) 
    < SiteModificationManager.BrandingVersion)
{

При применении настройки к сайту мы задаем примененную версию настройки в контейнер свойств для следующего выполнения.

// Save current branding applied indicator to site
ctx.Web.SetPropertyBagValue(SiteModificationManager.OneDriveMarkerBagID, SiteModificationManager.BrandingVersion);

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

Необходимая конфигурация в Azure

Ключевое требование для правильной работы этого примера заключается в том, что вы создали службу данных службы хранилища Azure и соответствующим образом обновили строки подключения к хранилищу для проектов, которые их используют. Вы можете просто создать службу хранилища на портале администрирования Azure (manage.windowssazure.com), выбрав Создать — Службы данных —>> Хранилище —> Быстрый Create. После этого вам нужно будет просто определить имя, расположение и несколько других параметров, и вы можете пойти.

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

Вам потребуется обновить файл App.config для следующих проектов в решении Visual Studio. Каждый из проектов более подробно описан далее в этой записи блога.

OD4B. Configuration.Async.WebJob OD4B. Проект Веб-задания Configuration.Async.Console.SendMessage имеет два ключа, которые можно обновить, чтобы указать на одно и то же подключение, а sendMessage — только один ключ для обновления.

Структура эталонного решения

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

OD4B.Configuration.Async

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

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

OD4B. Configuration.Async.Common

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

Все фактические операции с сайтами OD4B находятся в OD4B. Класс Configuration.Async.Common.SiteModificationManager .

OD4B. Configuration.Async.Console.Reset

Этот проект является нашим проектом тестирования и отладки для фактических настроек. Его можно использовать для ручного применения нужных настроек к любому сайту OD4B. Во время разработки этот проект был нашим тестируемым проектом для тестирования процесса настройки, прежде чем он был подключен к веб-заданию. Project также можно использовать для сброса настроек с любого сайта OD4B в целях демонстрации или тестирования. Так как фактическая бизнес-логика находится в общем проекте, этот проект будет использовать тот же класс SiteModificationManager , что и другие, для применения или сброса настроек с сайтов.

При тестировании настроек можно просто изменить код в методе Main между Apply и Reset, чтобы изменить желаемую операцию.

static void Main(string[] args)
{
  
    Uri url = 
        new Uri("https://vesaj-my.sharepoint.com/personal/vesaj_veskuonline_com");
  
        //get the new site collection
    string realm = TokenHelper.GetRealmFromTargetUrl(url);
    var token = TokenHelper.GetAppOnlyAccessToken(
                    TokenHelper.SharePointPrincipal, 
                    url.Authority, realm).AccessToken;
    using (var ctx = 
        TokenHelper.GetClientContextWithAccessToken(url.ToString(), 
        token))
    {
        // Uncomment the one you need for testing/reset
        // Apply(ctx, url);
        Reset(ctx);
    }
}

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

OD4B. Configuration.Async.Console.SendMessage

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

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

OD4B. Configuration.Async.WebJob

Это фактический проект веб-задания, который был создан с помощью шаблона проекта веб-задания, представленного в обновление 4 для Visual Studio 2013. Этот шаблон упрощает создание проектов веб-заданий, добавляя нужные ссылки на месте, а также обеспечивает удобную автоматизацию развертывания с поддержкой правой кнопки мыши для проекта. Вы можете просто развернуть начальную или новую версию проекта в Azure, щелкнув правой кнопкой мыши и выбрав Опубликовать как веб-задание Azure... откроется мастер публикации.

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

class Program
{
    // Please set the following connection strings in app.config for this 
    // WebJob to run: AzureWebJobsDashboard and AzureWebJobsStorage
    static void Main()
    {
        var host = new JobHost();
        // The following code ensures that the WebJob will be 
        // running continuously
        host.RunAndBlock();
    }
}

Фактическая обработка очереди очень проста с помощью веб-заданий. Единственное, что нам нужно сделать, это задать правильные атрибуты для метода и убедиться, что строки подключения к хранилищу Azure в конфигурации приложения обновляются соответствующим образом и соответствуют очереди хранилища, созданной в Microsoft Azure. Ниже приведен метод ProcessQueueMessage из класса functions.cs. Обратите внимание, что для доступа к SharePoint из веб-задания используется модель маркеров только для приложений. Чтобы сделать это, необходимо убедиться, что вы скопировали правильный идентификатор приложения и секрет в app.config проекта. Фактическая бизнес-логика находится в классе SiteModificationManager , поэтому мы просто вызываем ее с правильным контекстом и параметрами клиента.

// This function will get triggered/executed when a new message is written 
// on an Azure Queue called queue.
public static void ProcessQueueMessage(
    [QueueTrigger(SiteModificationManager.StorageQueueName)] 
    SiteModificationData request, TextWriter log)
{
    Uri url = new Uri(request.SiteUrl);
  
    //Connect to the OD4B site sing App Only access
    string realm = TokenHelper.GetRealmFromTargetUrl(url);
    var token = TokenHelper.GetAppOnlyAccessToken(
        TokenHelper.SharePointPrincipal, url.Authority, realm).AccessToken;

    using (var ctx = TokenHelper.GetClientContextWithAccessToken(
        url.ToString(), token))
    {
        // Set configuration object properly for setting the config
        SiteModificationConfig config = new SiteModificationConfig()
        {
            SiteUrl = url.ToString(),
            JSFile = Path.Combine(Environment.GetEnvironmentVariable
                ("WEBROOT_PATH"), "Resources\\OneDriveConfiguration.js"),
            ThemeName = "Garage",
            ThemeColorFile = Path.Combine(Environment.GetEnvironmentVariable
                ("WEBROOT_PATH"), "Resources\\Themes\\Garage\\garagewhite.spcolor"),
            ThemeBGFile = Path.Combine(Environment.GetEnvironmentVariable
                ("WEBROOT_PATH"), "Resources\\Themes\\Garage\\garagebg.jpg"),
            ThemeFontFile = "" // Ignored in this case, but could be also obviously set
        };

        new SiteModificationManager().ApplySiteConfiguration(ctx, config);
    }
}

Также стоит отметить, что необходимо убедиться, что вы задали свойство Copy Local для свойства ссылок на сборки CSOM SharePoint для проекта, чтобы все зависимые сборки правильно копировались в Azure при развертывании веб-задания. Это просто потому, что эти сборки по умолчанию не находятся на обычном веб-сайте Azure, поэтому, задав это свойство True, вы также убедитесь, что указанные сборки будут скопированы в облако.

OD4B. Configuration.AsyncWeb

Это фактическое приложение, размещенное поставщиком, которое размещено в Microsoft Azure. Он содержит страницу, вложенную в часть приложения, которая размещается на первой странице интрасети. Default.aspx страница этого приложения фактически не содержит никаких операций, на ней отображаются сведения об использовании приложения.

Примечание. Если вы столкнетесь с проблемами с отказом в разрешении, связанными с веб-заданием или доступом только к приложению в целом, убедитесь, что в app.config обновлены идентификатор клиента приложения и секрет, чтобы они соответствовали значениям в web.config этого проекта. Visual Studio может изменить эти значения в определенных сценариях.

Обработка очереди в веб-задании

Использование очередей хранилища очень просто с API, доступных в Azure. Самый простой способ приступить к работе — использовать пакет Nuget службы хранилища Windows Azure, который свяжет все необходимые API и другие пакеты с проектом. После добавления этого пакета Nuget можно просто приступить к использованию API очереди хранилища для обработки. Ниже приведен фрагмент из OD4B. Проект Configuration.Async.Common (метод AddConfigRequestToQueue в классе SiteModificationManager), который содержит фактический код обработки сообщений очереди и используется из многочисленных проектов (при упрощении отладки).

public void AddConfigRequestToQueue(
            string account, string siteUrl, string storageConnectionString)
{
    CloudStorageAccount storageAccount = 
                        CloudStorageAccount.Parse(storageConnectionString);
  
    // Get queue... create if does not exist.
    CloudQueueClient queueClient = storageAccount.CreateCloudQueueClient();
    CloudQueue queue = 
        queueClient.GetQueueReference(SiteModificationManager.StorageQueueName);
    queue.CreateIfNotExists();

    // Pass in data for modification
    var newSiteConfigRequest = new SiteModificationData()
    {
        AccountId = account,
        SiteUrl = siteUrl
    };

    // Add entry to queue
    queue.AddMessage(
        new CloudQueueMessage(
            JsonConvert.SerializeObject(newSiteConfigRequest)));
}

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

// This function will get triggered/executed when a new message is written 
// on an Azure Queue called queue.
public static void ProcessQueueMessage(
    [QueueTrigger(SiteModificationManager.StorageQueueName)] 
    SiteModificationData request, TextWriter log)
{
    Uri url = new Uri(request.SiteUrl);

Это действительно не легче, чем это. Обратите внимание, что мы используем SiteModificationManager.StorageQueueName с обеих сторон, чтобы убедиться, что имя очереди совпадает.

Применение фактических конфигураций к сайту

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

• Добавление сообщения политики компании, которое постоянно отображается на сайтах OD4B
• Скрыть параметр "Создать ссылку на вложенный сайт" на странице содержимого сайта
• Применение пользовательской темы к сайту OD4B для сопоставления фирменной символики компании

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

Вторая операция с пользовательскими темами требует, чтобы мы отправили на сайт несколько дополнительных файлов, а затем задали их для использования в качестве параметров темы. Мы используем строго CSOM для отправки всех необходимых файлов на сайты, чтобы избежать любых будущих осложнений с сопоставлениями элементов платформы признаков. Так как отправка файла в SharePoint с помощью CSOM очень проста, это, безусловно, самый простой способ автоматизации, и вам не нужно беспокоиться о зависимости xml-конфигураций в решениях песочницы. Ниже приведен фактический метод конфигурации сайта из OD4B. Класс Configuration.Async.Common.SiteModificationManager. Обратите внимание, что мы используем основной компонент PnP для разработчика Office 365 для упрощения некоторых необходимых операций.

Также приятно отметить, что мы действительно загружаем новую версию JS в корневое семейство веб-сайтов каждый раз, когда настраиваем личный сайт OD4B. Это определенно не оптимальное решение, оно скорее существует для простоты для этого эталонного решения. Вы можете добавить эту операцию отправки файла JavaScript в событие Установлено приложение, чтобы она выполнялось только один раз при установке приложения, но в этом случае вам придется выполнить некоторые дополнительные действия с любыми обновлениями в этом JS-файле.

// This function will get triggered/executed when a new message is written 
// on an Azure Queue called queue.
public static void ProcessQueueMessage(
    [QueueTrigger(SiteModificationManager.StorageQueueName)] 
    SiteModificationData request, TextWriter log)
{
    Uri url = new Uri(request.SiteUrl);
  
    //Connect to the OD4B site using App Only token
    string realm = TokenHelper.GetRealmFromTargetUrl(url);
    var token = TokenHelper.GetAppOnlyAccessToken(
        TokenHelper.SharePointPrincipal, url.Authority, realm).AccessToken;

    using (var ctx = TokenHelper.GetClientContextWithAccessToken(
        url.ToString(), token))
    {
        // Set configuration object properly for setting the config
        SiteModificationConfig config = new SiteModificationConfig()
        {
            SiteUrl = url.ToString(),
            JSFile = Path.Combine(Environment.GetEnvironmentVariable
                ("WEBROOT_PATH"), "Resources\\OneDriveConfiguration.js"),
            ThemeName = "Garage",
            ThemeColorFile = 
                Path.Combine(Environment.GetEnvironmentVariable
                ("WEBROOT_PATH"), "Resources\\Themes\\Garage\\garagewhite.spcolor"),
            ThemeBGFile = 
                Path.Combine(Environment.GetEnvironmentVariable
                ("WEBROOT_PATH"), "Resources\\Themes\\Garage\\garagebg.jpg"),
            ThemeFontFile = "" // Ignored in this case, but could be also set
        };

        new SiteModificationManager().ApplySiteConfiguration(ctx, config);
    }
}

Очевидно, что необходимые операции в значительной степени зависят от бизнес-требований. Вы можете найти несколько различных шаблонов и подходов с операциями на основе CSOM из Office 365 шаблоны и методики разработчика.

Дополнительные заметки о решениях на основе веб-заданий

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

Отладка веб-задания и процесс настройки

Один из рекомендуемых методов для кода в целом заключается в поиске фактических операций за пределами фактического окончательного процесса выполнения, чтобы можно было сначала сосредоточиться на тестировании необходимого кода просто с помощью консольного приложения или, например, с тестовых проектов в Visual Studio. Таким образом, вы можете убедиться, что фактическая бизнес-логика полностью функциональность, прежде чем фактически подключить ее к конечному процессу, в данном случае это означает веб-задание. В этом примере мы поместили весь бизнес-код в OD4B. Класс Configuration.Async.Common.SiteModificationManager и мы называем его из множества расположений.

Это означало, что во время разработки мы могли использовать OD4B. Консольное приложение Configuration.Async.Console.Reset для тестирования и сброса настроек на сайтах столько раз, сколько необходимо, чтобы убедиться, что бизнес-логика полностью надежна. Это действительно не имеет ничего общего с моделью надстройки SharePoint или разработкой в Azure. Это практические пошаговые методики разработки независимо от используемой технологии. Во времена, когда я был докладчиком в обучении сертификации MCM для SharePoint, я называл это методом NKOTB, но это не совсем стандартная терминология отрасли :-)

Одно из важных улучшений с точки зрения отладки для веб-заданий появилось в Visual Studio 2014 с обновлением 4. Благодаря недавно представленным подключениям Azure и шаблонам проектов вы можете выполнять удаленную отладку с помощью веб-задания, запущенного на стороне Azure. Необходимо развернуть веб-задание в Azure, после чего можно запустить сеанс отладки, щелкнув правой кнопкой мыши экземпляр веб-задания в Обозреватель сервера и выбрав в контекстном меню команду Подключить отладчик.

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

Переменные среды веб-задания

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

В этом случае у нас есть один файл JavaScript и несколько файлов для пользовательской темы, которые были развернуты на веб-сайте Azure, чтобы их можно было отправить на сайты SharePoint по мере необходимости. Эти файлы можно увидеть в Azure, если расширить ветвь "Файлы" на определенном веб-сайте.

Как правило, на веб-сайтах Azure можно ссылаться на эти файлы в следующем формате.

string path = HostingEnvironment.MapPath(
    string.Format("~/{0}", "Resources/OneDriveConfiguration.js"));

Так как веб-задания выполняются в другом расположении, а не в контексте IIS, приведенная выше ссылка на файл не будет работать, так как сопоставление завершится ошибкой из контекста процесса веб-задания. Здесь могут помочь переменные среды для конкретных веб-заданий. В примере эталонного решения мы использовали переменную среды webJob WEBROOT_PATH для получения доступа к связанной папке веб-сайта.

string jsFile = Path.Combine(
    Environment.GetEnvironmentVariable("WEBROOT_PATH"), 
    "Resources\\OneDriveConfiguration.js");

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

Видео, демонстрирующее решение и действия

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

См. также

• Настройка сайтов OneDrive для бизнеса
• Статьи руководства на https://aka.ms/OfficeDevPnPGuidance
• Ссылки в MSDN на https://aka.ms/OfficeDevPnPMSDN
• Видео на https://aka.ms/OfficeDevPnPVideos

Образцы PnP

• OD4B. Configuration.Async (пример O365 PnP)
• Provisioning.OneDriveProvisioning (пример PnP O365)
• Основной компонент Office PnP
• Примеры и содержимое в Microsoft 365 Patterns and Practices (PnP)

Область применения

• Office 365 Multi Tenant (MT)
• Office 365 Dedicated (D) частично
• Локальная среда SharePoint 2013 — частично

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