OneDrive Entreprise personnalisation dans le modèle de SharePoint de l’entreprise
L’approche que vous prenez pour personnaliser OneDrive Entreprise sites dans le nouveau modèle de SharePoint est différente de celle qu’il était avec le code de confiance totale. Dans un scénario de code de confiance totale/solution de batterie de serveurs classique, les travaux du minuteur SharePoint étaient créés avec le code du modèle objet côté serveur SharePoint, déployés via les solutions de batterie de serveurs et gérés dans le site web Administration centrale de SharePoint. SharePoint gère la planification et l’exécution du travail du minuteur dans ce scénario.
Dans un SharePoint de modèle de module de développement, les travaux du timer sont créés et programmés en dehors des SharePoint. SharePoint n’est pas responsable de la planification ou de l’exécution du travail du minuteur dans ce scénario.
Pourquoi personnaliser les sites OneDrive Entreprise web ?
Il existe de nombreux aspects différents sur l’application de la personnalisation à OneDrive Entreprise sites (OD4B). Vous pouvez certainement personnaliser ces sites, dans la mesure où il s’agit de sites SharePoint, mais en même temps, vous devez toujours prendre en compte l’impact à court et à long terme de la personnalisation.
Conseils importants
En règle générale, nous voulons fournir les instructions de haut niveau suivantes pour la personnalisation des sites OD4B.
- Appliquer la personnalisation de la personnalisation à l’Office 365 thèmes ou SharePoint moteur de thèmes de site
- Si les moteurs de thème ne sont pas suffisants, vous pouvez ajuster certains paramètres CSS à l’aide d’une autre option CSS
- Évitez de personnaliser des sites OD4B à l’aide de pages maîtres personnalisées, car cela vous occasionnera des coûts supplémentaires à long terme et des défis avec les mises à jour futures
- Dans la plupart des cas, vous pouvez réaliser tous les scénarios de branding courants avec des thèmes et d’autres CSS, ce n’est donc pas vraiment ce facteur limitant.
- Si vous avez choisi d’utiliser des pages maîtres personnalisées, soyez prêt à appliquer des modifications aux sites lorsque des mises à jour fonctionnelles majeures sont appliquées à Office 365
- Vous pouvez utiliser l’incorporation de JavaScript pour modifier ou masquer les fonctionnalités dans le site
- Vous pouvez utiliser le modèle CSOM pour contrôler, par exemple, les paramètres linguistiques ou régionaux dans les sites OD4B (voir les nouvelles API).
- Nous déconseillons l’utilisation des types de contenu et des colonnes de site dans les sites OD4B afin d’éviter les difficultés avec les champs requis ou d’autres éléments, ce qui pourrait entraîner des problèmes dans les cas d’utilisation normale avec les sites OD4B.
- Pensez que les sites OD4B sont des données et documents personnels non structurés. Les sites d’équipe et la collaboration sont alors pour les données et les documents de l’entreprise, où vous pouvez certainement utiliser les stratégies et métadonnées de gestion des informations que vous souhaitez.
En résumé, la personnalisation est sans aucun doute prise en charge dans Office 365 et vous pouvez continuer à les utiliser avec des sites OD4B. Nous voulons simplement nous assurer que vous prenez en compte l’impact à court et à long terme de la personnalisation du point de vue opérationnel et de la maintenance. Ce n’est pas vraiment spécifique SharePoint, mais plutôt une règle générale pour toute build de solution it avec n’importe quelle plateforme.
Voici un exemple de site OD4B, qui a été personnalisé à l’aide des instructions ci-dessus. Dans ce cas, le résultat final a été obtenu avec la combinaison de thèmes Office 365, du thème de site et de l’utilisation du modèle d’incorporation javaScript.

Défi représenté par l’application de personnalisations à des sites OneDrive Entreprise
Commençons par définir le défi et les éléments que nous essayons de résoudre ici. Techniquement, chaque site OneDrive Entreprise utilise actuellement une architecture identique à celle utilisée par les sites personnels ou mes sites dans SharePoint version 2007 ou 2010. Cela signifie que techniquement, chaque site OneDrive Entreprise est sa propre collection de sites et que nous n’avons pas d’emplacement centralisé pour appliquer la personnalisation ou toute autre personnalisation.

La solution classique pour appliquer la configuration nécessaire aux sites OneDrive Entreprise (y compris mes sites personnels) était basée sur l’agrafage de fonctionnalités au niveau de la batterie de serveurs. Cela signifie que vous avez déployé la solution de batterie de serveurs sur votre batterie de serveurs SharePoint et utilisé l’infrastructure de fonctionnalités pour associer votre fonctionnalité personnalisée à activer chaque fois qu’un site mon site est lancé, qui était alors responsable de l’application des personnalisations nécessaires. Cette approche similaire ne fonctionne pas dans Office 365, car elle nécessite le déploiement d’une solution de batterie de serveurs, ce qui est tout simplement impossible avec Office 365 sites. Par conséquent, nous devons rechercher d’autres solutions pour appliquer les modifications nécessaires aux sites.
Dans Office 365 il n’existe aucun événement centralisé, auquel nous pourrions attacher notre code personnalisé lors de la création d’un site OD4B. Cela signifie que nous devons réfléchir à d’autres solutions, ce qui est assez courant avec les approches de modèle d’application. Ne restez pas bloqué sur les anciens modèles, réfléchissez à la façon d’obtenir le même résultat final à l’aide de nouvelles API et technologies. Du point de vue de l’exigence pure, peu importe la façon dont nous appliquons les personnalisations aux sites, tant qu’elles sont appliquées, étant donné que l’exigence métier n’est pas d’utiliser l’agrafage de fonctionnalités, il s’agit d’appliquer les personnalisations nécessaires à l’aide de tout mécanisme technique pris en charge.
Différentes options d’application de la personnalisation
En pratique, nous avons quatre mécanismes différents pour appliquer la personnalisation centralisée aux sites OD4B dans le Office 365. Vous pouvez également considérer l’option manuelle comme la cinquième option, mais dans le cas d’avoir des centaines ou des milliers de sites OD4B, l’utilisation d’options manuelles n’est pas vraiment une option réaliste. Voici les différentes options disponibles.
- Paramètres au niveau de la suite Office 365 (thèmes Office 365 et autres paramètres)
- Composant d’application caché avec contexte utilisateur
- Pré-créer et appliquer la configuration
- Travail du minuteur à distance basé sur les mises à jour du profil utilisateur
Chacune des options a des avantages et des inconvénients, et l’option qui s’offre à vous dépend de vos besoins commerciaux détaillés. Certains des paramètres que vous pouvez également appliquer au niveau de la suite Office 365, mais souvent, vous recherchez des informations plus spécifiques, de sorte que des personnalisations réelles sont nécessaires. Il s’agit évidemment d’un ensemble précis d’exigences et d’analyses de cas d’entreprise sur leur impact sur le court et le long terme.
Paramètres au niveau de la suite Office 365
Office 365 est bien plus qu’une simple SharePoint, comme vous le savez. Vous trouverez de plus en plus de services supplémentaires qui ne sont pas basés sur l’architecture SharePoint, comme Delve, Yammer et de nombreux services à venir. Cela signifie que la branding et la configuration de l’entreprise ne consistent pas simplement à contrôler ce que nous avons dans les sites SharePoint, mais plutôt à penser à l’expérience globale de l’utilisateur final et à la façon dont nous fournissons des configurations cohérentes entre les différents services.
L’exemple classique de ces exigences d’entreprise est la branding et, pour cette raison, nous avons déjà introduit Office 365 de ces modèles, qui peuvent être utilisés pour contrôler un certain niveau de branding. Nous avons également d’autres fonctionnalités à venir, qui vous aideront à contrôler la gouvernance de votre site et d’autres paramètres, à partir d’un emplacement centralisé en dehors des paramètres de la collection de sites, comme le centre de conformité à venir pour Office 365, qui est actuellement répertorié dans la feuille de route Office 365.
L’image suivante montre les différents paramètres pour le moment pour Office 365, qui seront ensuite appliqués entre tous les services Office 365 services.

Étant donné que, par défaut, les paramètres de thème Office 365 permettent de contrôler la barre de la suite de sites OD4B, vous utiliserez probablement ces options avec d’autres options pour vous assurer que vous pouvez fournir au moins les éléments de personnalisation qui vous sont nécessaires entre vos sites OD4B. Notez que lorsque vous modifiez, par exemple, Office 365 paramètres de thème dans l’outil d’administration Office 365, l’application des paramètres pour les sites OD4B prend beaucoup de temps, donc soyez patient.
Composant d’application caché avec contexte utilisateur
Il s’agit d’une approche dans laquelle la page d’accueil centralisée est l’emplacement de démarrage du processus de personnalisation nécessaire. Cela signifie que vous devez avoir un emplacement centralisé, comme la page d’accueil intranet de l’entreprise, où les utilisateurs sont toujours à l’arrivée lorsqu’ils ouvrent leur navigateur. Il s’agit d’un processus classique dans les entreprises moyennes et grandes où la page d’accueil de l’entreprise est ensuite contrôlée à l’aide des paramètres de stratégie de groupe dans AD. Cela garantit que les utilisateurs finaux ne peuvent pas remplacer la page d’accueil par défaut des navigateurs joints au domaine de l’entreprise.
Lorsque l’utilisateur arrive sur l’intranet, nous avons masqué le partie d’application dans la page, ce qui démarre le processus de personnalisation. Il peut également être responsable de la création entière du site OD4B, dans la mesure où l’utilisateur doit normalement visiter le site OD4B une seule fois, avant le début du processus de création de site. Le partie d’application masquée héberge en fait une page à partir d’une application hébergée par un fournisseur hébergée dans Azure. Cette page est alors chargée de démarrer le processus de personnalisation.
Examinons de plus près la conception logique de cette approche.

- Placez le partie d’application masquée sur le site centralisé où les utilisateurs finaux vont se poser. En règle générale, il s’agit de la page d’accueil de l’intranet d’entreprise.
- Le partie d’application héberge une page à partir d’une application hébergée par un fournisseur, où, dans le code côté serveur, nous initions le processus de personnalisation en ajoutant les métadonnées nécessaires à la file d’attente de stockage Azure. Cela signifie que cette page recevra uniquement la demande de personnalisation, mais n’appliquera en réalité aucune modification pour maintenir le temps de traitement normal.
- Il s’agit de la file d’attente de stockage Azure réelle, qui recevra les messages à mettre en file d’attente pour traitement. De cette façon, nous pouvons gérer le processus de contrôle de personnalisation de manière asynchrone afin qu’il n’importe pas vraiment la durée pendant combien de temps l’utilisateur final restera sur la page d’accueil de l’intranet. Si le processus de personnalisation est synchrone, nous dépendons de l’utilisateur final pour que le navigateur reste ouvert sur la page d’accueil intranet jusqu’à ce que l’exécution de la page soit finalisée. Ce n’est absolument pas optimal et c’était le défi du processus de personnalisation OD4Bd’origine, que j’ai enregistré lors de l’opération de retour.
- WebJob raccordé pour suivre la file d’attente de stockage, qui est appelée lorsque le nouvel élément est placé dans la file d’attente de stockage. Cette webjob recevra les paramètres et les métadonnées nécessaires du message en file d’attente pour accéder à la collection de sites appropriée. WebJob utilise uniquement un jeton d’application et a reçu les autorisations nécessaires pour manipuler les collections de sites au niveau du client.
- Les personnalisations réelles sont appliquées une par une aux sites des personnes qui visitent la page d’accueil de l’intranet pour démarrer le processus.
Il s’agit sans aucun doute du processus le plus fiable pour s’assurer qu’il existe des configurations fiables dans les sites OD4B. Vous pouvez facilement ajouter une logique de version de personnalisation au processus, qui applique également les mises à jour nécessaires aux sites OD4B, lorsqu’une mise à jour est nécessaire et que l’utilisateur visite la page d’accueil intranet la prochaine fois. Cette option ne nécessite toutefois pas que vous trouverez cet emplacement centralisé où vos utilisateurs finaux sont en train d’y relocaliser.
Si vous connaissez les modèles de développement SharePoint classiques avec les solutions de batterie de serveurs, il s’agit d’un processus assez similaire à l’exécution de travaux du timer.
Pré-créer et appliquer la configuration
Cette option s’appuie sur la pré-création des sites OD4B avant que les utilisateurs y accèdent. Pour ce faire, vous pouvez utiliser une API relativement nouvelle qui nous permet de créer des sites OD4B pour des utilisateurs spécifiques dans le processus de traitement par lots, à l’aide de CSOM ou REST. Le code nécessaire peut être initié à l’aide d’un script PowerShell ou en écrivant du code réel qui appelle les API distantes.

- L’administrateur utilise les API de création à distance pour créer des sites OD4B pour les utilisateurs et applique les personnalisations nécessaires aux sites OD4B dans le cadre du processus de script.
- Les sites OD4B réels sont créés dans le Office 365 pour des utilisateurs spécifiques et associés à leurs profils utilisateur
Dans un certain sens, il s’agit également d’un processus très fiable, mais vous devez gérer les nouvelles personnes et les mises à jour « manuellement », ce qui peut se faire plus efficacement à l’aide de l’approche de partie d’application masquée. Il s’agit d’une approche absolument valide qui peut être prise et particulièrement utile si vous migrez d’une autre solution de partage de fichiers vers OD4B et que vous souhaitez éviter que les utilisateurs finaux n’accèdent au site OD4B une seule fois, avant le début de la création réelle du site.
Travail du minuteur à distance basé sur les mises à jour du profil utilisateur
Cette approche implique d’analyser les profils utilisateur pour vérifier à qui le site OD4B a été créé, puis d’appliquer les modifications aux sites si nécessaire. Cela signifie qu’un travail programmé s’exécute en dehors du SharePoint, ce qui permet de vérifier régulièrement l’état et d’effectuer les personnalisations nécessaires. Le travail programmé peut être en cours d’exécution en tant que webjob dans Azure ou aussi simple que le script PowerShell programmé dans votre propre programmeur Windows. Évidemment, l’échelle du déploiement a un impact considérable sur l’option de planification choisie.

- La tâche programmée est lancée, qui accède aux profils utilisateur des utilisateurs pour vérifier qui a mis en service le site OD4B
- Les sites réels sont personnalisés un par un en fonction des besoins de l’entreprise
L’un des principaux inconvénients de cette option est qu’il peut clairement y avoir des situations dans lesquelles l’utilisateur peut accéder aux sites OD4B avant que les personnalisations ne soient appliquées. En même temps, cette option est intéressante pour d’autres options pour s’assurer que les utilisateurs finaux n’ont pas modifié les paramètres requis sur les sites ou pour vérifier que le contenu du site OD4B est conforme aux stratégies de l’entreprise.
Personnalisation améliorée basée sur un élément d’application
Voici une description plus détaillée des personnalisations de partie d’application améliorées, qui semblent être l’approche classique pour l’application et la gestion des personnalisations nécessaires aux sites OD4B. Le code source et des détails supplémentaires sur cette solution sont disponibles dans les Office 365 pratiques et modèles de développement.
La conception logique réelle suit l’approche de partie d’application masquée, mentionnée précédemment dans ce billet de blog. Cela signifie que l’on suppose que vous avez centralisé l’intranet dans l’environnement Office 365 où vous pouvez placer le partie d’application nécessaire et que les utilisateurs finaux vont se rendre sur cette page d’accueil lorsqu’ils ouvrent leur navigateur. Il est courant que chaque navigateur d’entreprise a le même ensemble de pages d’accueil à l’aide de stratégies de groupe, afin que les utilisateurs finaux démarrent toujours à partir d’un emplacement centralisé lorsqu’ils ouvrent leur navigateur. Il s’agit de l’emplacement où vous placez le partie d’application, qui peut être définie sur une largeur et une hauteur de 0 pixel. Le point clé ici est que vous utilisez le contexte de l’utilisateur final pour exécuter le partie d’application, qui contient la page à partir du fournisseur hébergé par le add-in.
Considérations sur l’optimisation des performances et la maintenance
Étant donné que ce composant d’application est exécuté chaque fois que l’utilisateur arrive sur la première page de l’intranet, nous devons prendre en compte l’impact sur les performances de ce composant ou comment faire en sorte que le code fonctionne efficacement et n’effectue que des parties clés des exécutions de code lorsque cela est réellement nécessaire. La deuxième considération sur l’optimisation est également l’emplacement des ressources réelles utilisées dans chacun des sites. Ce sont des défis typiques à relever avec les personnalisations. Voici une courte liste des éléments à concentrer dans les implémentations de modèle d’application.
- Emplacement des ressources : solution de réseau de distribution de contenu centralisé (CDN), dans chaque collection de sites ou dans la collection de sites racine ?
- Actualisez la fréquence des ressources ou assurez-vous que, quelle que soit la mise en cache du navigateur côté client, nous pouvons nous assurer que nous exécutons les dernières versions des scripts (JavaScript) ou que nous montrons les dernières versions des images ?
- Exécution réduite du code afin d’éviter toute charge inutile sur azure et Office 365 service
- Personnalisations de version appliquées au site OD4B
Emplacement des biens
Il existe peu de solutions différentes pour cela. Dans l’exemple de code de référence, nous utilisons l’incorporation de Code JavaScript dans chacun des sites OD4B pour fournir un message de stratégie d’entreprise et supprimer la possibilité de créer des sous-sites (ou masquer le lien). Dans cette solution particulière, nous téléchargeons le fichier JavaScript nécessaire vers la collection de sites racine du schéma d’adresses OneDrive Entreprise et nous référons ce fichier directement à partir de cet emplacement dans les sites OD4B individuels. Cela signifie que vous n’avez qu’un seul emplacement pour gérer et mettre à jour le fichier JavaScript, si des modifications sont nécessaires.
Dans cette implémentation de référence, nous actualisons également ce fichier chaque fois que la webjob est exécutée, ce qui n’est certainement pas nécessaire, mais l’exemple de code a été conçu pour fonctionner aussi facilement sans aucune étape supplémentaire et possible. Vous pouvez également charger manuellement le fichier JavaScript dans la collection de sites racine, puis référencer ce fichier à partir de cet emplacement. Une autre solution consisterait également à utiliser un fichier CND pour stocker le fichier nécessaire ou à référencer JavaScript à partir du côté de l’application hébergée par le fournisseur. Tant que vous n’avez qu’une seule copie du fichier, vous aurez :

Défi de mise en cache côté client et comment résoudre ce problème
L’une des difficultés de l’implémentation basée sur JavaScript est la mise en cache côté client. Lorsque les navigateurs téléchargent des fichiers JavaScript utilisés, ils metront en cache ces fichiers pour réduire la quantité de ressources téléchargées pour les demandes suivantes. Cela est idéal du point de vue de l’optimisation des performances, mais pose un problème lorsque nous devons mettre à jour le fichier JavaScript. Dans le pire des scénarios, le fichier JavaScript mis en cache provoquera des exceptions avec d’autres mises à jour introduites avec les versions mises à jour.
Pour supprimer ce problème, nous pouvons commencer à utiliser l’attribut de révision avec la référence d’URL JavaScript. Lorsque nous associeons l’action personnalisée de l’utilisateur au site OD4B, nous incluons l’URL du JavaScript pour avoir un GUID unique dans l’URL. Voici un exemple de référence qui pointe vers le site racine de la collection de sites. Notez le GUID supplémentaire qui a été ajouté après l’attribut rev dans l’URL. Chaque fois que le personnaliste est exécuté pour un site OD4B particulier, cet attribut est mis à jour. En pratique, cela signifie que le fichier JavaScript est mis en cache dans le navigateur jusqu’à ce qu’une nouvelle version soit ajoutée au site OD4B, ce qui modifiera l’URL et par conséquent le navigateur téléchargera la nouvelle version et le mettrea en cache après la prochaine mise à jour.
- /OneDriveCustomization/OneDriveConfiguration.js?rev=4bb89029e7ba470e893170d4cba7de00
Voici le code utilisé pour générer l’URL JavaScript pour l’action personnalisée de l’utilisateur.
/// <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);
}
Exécution réduite du code
Étant donné que ce processus est basé sur le fait d’avoir un partie d’application masquée sur la page d’accueil de l’intranet, cela signifie que le code est exécuté chaque fois que l’utilisateur actualisation son navigateur ou qu’il se déplace vers la page. Étant donné que cette page d’accueil est souvent définie comme page d’accueil du navigateur par défaut pour les utilisateurs de l’entreprise, le code est exécuté chaque fois qu’une session de navigateur est démarrée.
Étant donné que nous ne mettez pas toutefois à jour les personnalisations qui sont appliquées aux sites OD4B souvent, il n’est vraiment pas important de commencer tout le processus de mise à jour de personnalisation. Ce faisant, nous réduisons l’utilisation des files d’attente de stockage et l’exécution du travail web, ce qui réduit directement les coûts associés côté application hébergée par le fournisseur, dans la mesure où nous n’utiliserons pas autant de processeur et d’autres ressources dans notre conception.
Le moyen le plus simple de s’assurer que notre traitement n’est pas effectué dans chaque demande consiste à utiliser l’approche classique des cookies de navigateur, où nous stockerons des cookies spécifiques dans le navigateur client avec une durée de vie spécifique. En vérifiant l’existence de ce cookie, nous pouvons ignorer l’exécution jusqu’à ce que le cookie ait expiré et que nous vérifiions à nouveau l’état de personnalisation réel dans les sites OD4B.
Voici ce que nous avons dans la méthode de chargement de page pour le partie d’application. Cet appel de méthode vérifie l’existence du cookie et si le cookie existe, nous ignorerons le code métier réel jusqu’à ce que l’exécution soit de nouveau nécessaire.
// 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;
L’état et le paramètre réels du cookie sont effectués comme suit.
/// <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;
}
}
Si vous regardez de plus près le code dans la page du partie d’application, vous verrez que, dans chaque appel, nous vérifions les existences du site OD4B pour l’utilisateur final. Étant donné que cela ne peut être effectué qu’en accédant au profil utilisateur, le code aura un impact sur les performances. En utilisant la vérification des cookies ci-dessus, nous pouvons améliorer l’expérience de l’utilisateur final et éviter d’atteindre constamment le service de profil utilisateur sans exigences réelles. Il est également bon de noter que nous avons placé cette vérification des cookies comme première étape de la méthode Page_Load, afin que nous sautions tout le traitement, si nécessaire. Voici un court extrait de la méthode Page_Load de Customizer.aspx pour afficher le processus de code.
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)
{
Personnalisations de version appliquées au site OD4B
Le second niveau d’optimisation de notre traitement du code est effectué par le contrôle de version spécifiquement les personnalisations que nous déployons sur les sites OD4B. Cela signifie que nous stockons la version des personnalisations dans le sac des propriétés du site OD4B et que nous ne mettez à jour les fichiers et les ressources que si nécessaire. Cela signifie que dans l’exécution webjob, nous comparons la version de personnalisation actuelle dans OD4B à la version que nous sommes sur le point de déployer et uniquement si les odes de version de personnalisation n’existent pas dans le site OD4B, nous téléchargeons les ressources nécessaires et appliquons d’autres paramètres.
Cette approche permet également de réduire considérablement les ressources nécessaires de Microsoft Azure, car nous exécutons l’actualisation ou l’exécution du code de personnalisation réel lorsqu’il n’est pas nécessaire. Cela signifie une réduction de l’utilisation du processeur et d’autres ressources dans le Microsoft Azure et moins de demandes vers Office 365.
Toute la logique de personnalisation est stockée dans cet exemple dans la méthode ApplySiteConfiguration de la classe OD4B.Configuration.Async.Common.SiteModificationManager. Cette méthode est également appelée par la webjob avec les paramètres appropriés pour démarrer le processus de personnalisation. Avant d’effectuer des opérations, nous vérifions la valeur du sac des propriétés avec la clé « Contoso_OneDriveVersion » et l’exécution se poursuit uniquement si la version actuelle du site est inférieure à la version que nous prévoyons d’appliquer. Voici le code réel qui utilise Office composant principal PnP pour simplifier le code.
// Check current site configuration status - is it already in right version?
if (ctx.Web.GetPropertyBagValueInt(
SiteModificationManager.OneDriveMarkerBagID, 0)
< SiteModificationManager.BrandingVersion)
{
Lorsque la personnalisation est appliquée au site, nous allons définir la version de personnalisation appliquée sur le sac des propriétés pour l’exécution suivante.
// Save current branding applied indicator to site
ctx.Web.SetPropertyBagValue(SiteModificationManager.OneDriveMarkerBagID, SiteModificationManager.BrandingVersion);
Ce processus est relativement simple, mais réduit considérablement les ressources requises d’Azure et réduit également les opérations distantes inutiles vers Office 365, ce qui aura un impact positif sur les performances.
Configuration nécessaire dans Azure
La principale condition requise pour que cet exemple fonctionne correctement est que vous avez créé stockage Azure Data Service et que vous avez mis à jour les chaînes de connexion de stockage en conséquence pour les projets qui les utilisent. Vous pouvez simplement créer en tant que service de stockage à partir du portail d’administration Azure (manage.windowssazure.com), en sélectionnant New –> Data Services –> Stockage –> Quick Create. Après cela, il vous suffit de définir le nom, l’emplacement et quelques autres paramètres, et vous pouvez y aller.

Une fois le stockage créé, vous devez copier la clé nécessaire pour la chaîne de connexion. Lorsque vous accédez à la page des détailsdu stockage, vous pouvez accéder aux informations clés en cliquant sur « Gérer les touches d’accès rapide » à partir du bas de la page.

Vous devrez mettre à jour App.config pour les projets suivants dans la solution Visual Studio. Chacun des projets est expliqué plus en détail plus loin dans ce billet de blog.
OD4B. Configuration.Async.WebJob OD4B. Le projet WebJob Configuration.Async.Console.SendMessage possède deux clés, qui peuvent être mises à jour pour pointer vers la même connexion et SendMessage n’a qu’une seule clé à mettre à jour.

Structure de la solution de référence
Cette Visual Studio solution se compose d’un certain nombre de solutions, mais chacune d’entre elles a des raisons assez raisonnables d’y être. Voici une présentation de chacun des projets de la solution et de leur raison d’être ou de leur raison d’être.

OD4B.Configuration.Async
Il s’agit du projet SharePoint’application hébergée par le fournisseur, qui présente l’application hébergée par le fournisseur SharePoint et demande les autorisations nécessaires. Notez que même si nous n’effectuez pas réellement d’opérations au niveau du client à partir du partie d’application, nous demandons des autorisations assez élevées pour le add-in. Cela est dû au fait que nous allons utiliser les mêmes ID client et secret de ce fichier d’application dans notre exécution WebJob. Grâce à cette approche, vous n’avez pas besoin d’inscrire manuellement l’ID et la question secrète de l’application dans le SharePoint. Nous utilisons plutôt simplement le même identificateur et la même solution secrète croisée.

Ce projet contient également la définition du partie d’application qui sera ensuite déployée sur le site web hôte.
OD4B.Configuration.Async.Common
Ce projet contient toute la logique métier réelle et le code partagé entre projets, comme la définition de l’objet de données qui est placé dans la file d’attente de stockage et la logique métier réelle pour personnaliser les sites OD4B. Le fait de placer du code ici est simplement pour nous offrir un moyen plus facile de développer et de tester les opérations lors de la création du projet. Comme pour le développement général, vous ne devez pas placer votre code de logique métier directement dans le webjob ou dans le partie d’application, plutôt que de le localiser dans la couche logique métier pour faciliter le test et la réutilisation du code.
Toutes les opérations réelles vers les sites OD4B se trouvent dans la classe OD4B.Configuration.Async.Common.SiteModificationManager.
OD4B. Configuration.Async.Console.Reset
Ce projet est notre projet de test et de débogage pour les personnalisations réelles. Il peut être utilisé pour appliquer manuellement les personnalisations recherchées à n’importe quel site OD4B. Pendant le développement, ce projet était notre projet de test pour tester le processus de personnalisation avant qu’il ne soit raccordé à la webjob. Project permet également de réinitialiser les personnalisations à partir de n’importe quel site OD4B à des fins de démonstration ou de test. Étant donné que la logique métier réelle se trouve dans le projet commun, ce projet utilise la même classe SiteModificationManager que les autres pour appliquer ou réinitialiser les personnalisations à partir des sites.
Lorsque vous testez les personnalisations, vous pouvez simplement modifier le code de la méthode Main entre Appliquer et Réinitialiser pour modifier l’opération recherchée.
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);
}
}
Notez que vous devez vous assurer que l’ID d’application et la question secrète de ce projet dans le app.config correspondent à ceux que vous avez accordés à votre client. Vous pouvez facilement exécuter le projet en cliquant avec le bouton droit sur le projet et en choisissant Déboguer – Démarrer une nouvelle instance, afin de pouvoir parcourir le code réel qui est exécuté ligne par ligne.
OD4B. Configuration.Async.Console.SendMessage
Ce projet a été ajouté à la solution pour tester le mécanisme de file d’attente de stockage avant qu’il ne soit raccordé au partie d’application. Project peut être utilisé en réussissant le processus de partie d’application pour ajouter de nouveaux messages à la file d’attente de stockage. Notez que vous devrez mettre à jour la chaîne de connexion de file d’attente de stockage en conséquence dans le app.config pour que le projet fonctionne correctement.
Vous pouvez facilement exécuter le projet en cliquant avec le bouton droit sur le projet et en choisissant Déboguer – Démarrer une nouvelle instance, afin de pouvoir parcourir le code réel qui est exécuté ligne par ligne.
OD4B. Configuration.Async.WebJob
Il s’agit du projet WebJob réel, qui a été créé à l’aide du modèle de projet WebJob, introduit dans le Visual Studio 2013 Update 4. Ce modèle facilite la création de projets WebJob en ajoutant des références en place et fournit également une automatisation de déploiement agréable avec la prise en charge du clic droit pour le projet. Vous pouvez simplement déployer la version initiale ou la nouvelle version du projet dans Azure en cliquant avec le bouton droit et en sélectionnant Publier en tant que travail web Azure... qui ouvre l’Assistant Publication.

Cette webjob est créée en tant que webjob continue, qui est nécessaire pour le traitement basé sur la file d’attente. Cela signifie que dans la méthode Main, nous avons uniquement définie le processus pour qu’il s’exécute en continu comme suit.
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();
}
}
Le traitement réel de la file d’attente est très simple avec les webjobs. La seule chose que nous devons faire est de définir les attributs de la méthode et de s’assurer que les chaînes de connexion de stockage Azure dans la config de l’application sont mises à jour en conséquence et en correspondance avec les files d’attente de stockage que vous avez créées pour Microsoft Azure. Voici la méthode ProcessQueueMessage de la classe functions.cs. Notez que nous utilisons le modèle de jeton Application uniquement pour accéder au SharePoint à partir de la webjob. Pour que cela fonctionne, vous devez vous assurer que vous avez copié l’ID et la question secrète de l’application dans le app.config du projet. La logique métier réelle se trouve dans la classe SiteModificationManager, donc nous appelons simplement cela avec le contexte client et les paramètres appropriés.
// 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);
}
}
Il est également important de noter que vous devez vous assurer que vous avez bien définie la propriété Copy Local pour la propriété de références d’assembly CSOM SharePoint pour le projet, afin que tous les assemblys dépendants soient correctement copiés dans Azure lorsque vous déployez la tâche web. Cela est simplement dû au fait que ces assemblys ne se trouvent pas dans le site web Azure normal par défaut. Ainsi, si vous avez la valeur True, vous vous assurerez que les assemblys référencés sont également copiés dans le cloud.
OD4B. Configuration.AsyncWeb
Il s’agit de l’application hébergée par le fournisseur réelle qui est hébergée dans Microsoft Azure. Il contient la page mise en page vers le partie d’application, qui est placée sur la première page de l’intranet. La page Default.aspx de cette application ne contient pas réellement d’opérations. Elle fournit des détails sur l’utilisation de l’application.
Remarque. Si vous êtes confronté à des problèmes d’autorisation refusés avec l’accès WebJob ou application uniquement en général, assurez-vous que vous avez mis à jour l’ID client et la question secrète de l’application dans le app.config pour qu’ils correspondent aux valeurs de l'web.config de ce projet. Visual Studio peut modifier ces valeurs dans certains scénarios.
Traitement de file d’attente dans WebJob
L’utilisation des files d’attente de stockage est très simple avec les API disponibles dans Azure. Le moyen le plus simple de commencer consiste à utiliser le package Nuget «Windows stockage Azure» qui associera toutes les API nécessaires et d’autres packages à votre projet. Une fois que vous avez ajouté ce package Nuget, vous pouvez simplement commencer à utiliser les API de file d’attente de stockage pour le traitement. L’extrait de code suivant est extrait du projet OD4B.Configuration.Async.Common (méthode AddConfigRequestToQueue dans la classe SiteModificationManager), qui contient le code de gestion des messages de file d’attente réel et est utilisé à partir de nombreux projets (pour faciliter le débogage du temps de développement).
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)));
}
Dans ce cas, le traitement réel de la file d’attente a été effectué avec le projet WebJob. Dans le cas de WebJob, nous pouvons simplement utiliser des attributs spécifiques pour automatiser la gestion des files d’attente. Nous devons seulement nous assurer que nous utilisons la même chaîne de connexion de stockage et le même nom de file d’attente dans les parties d’envoi et de réception.
// 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);
Ce n’est vraiment pas plus simple que cela. Notez que nous utilisons SiteModificationManager.StorageQueueName des deux côtés pour nous assurer que le nom de file d’attente correspond.
Appliquer des configurations réelles au site
Dans ces implémentations de référence, nous suivons les personnalisations pour chacun des sites OD4B.
- Ajouter un message de stratégie d’entreprise qui s’affiche tout le temps sur les sites OD4B
- Masquer l’option créer un lien de sous-site à partir de la page de contenu du site
- Appliquer un thème personnalisé au site OD4B pour correspondre à la personnalisation de l’entreprise
La stratégie de l’entreprise et le masquage du lien de création de sous-site sont obtenus à l’aide du modèle d’incorporation JavaScript appelé « javascript embedding » dans lequel nous ajoutons une action utilisateur personnalisée au niveau du site avec référence à un fichier JavaScript spécifique, qui est ensuite exécuté dans chaque demande de page. Cela signifie que nous pouvons contrôler le traitement des pages à l’aide des technologies côté client en ajoutant, supprimant ou mettant à jour n’importe quel élément dans n’importe quelle page. À l’aide de cette approche, nous n’avons pas besoin d’introduire une page maître personnalisée, ce qui pourrait nous occasionner des coûts de maintenance à long terme plus importants, en particulier si les modifications nécessaires sont assez minimes.
La deuxième opération avec les thèmes personnalisés nécessite de télécharger des fichiers supplémentaires sur le site, puis de les définir comme paramètres de thème. Nous utilisons strictement le CSOM pour télécharger tous les fichiers nécessaires sur les sites afin d’éviter toute complication ultérieure avec les associations d’éléments d’infrastructure de fonctionnalité. Étant donné que le téléchargement d’un fichier vers le SharePoint à l’aide du modèle CSOM est très simple, il s’agit certainement du moyen le plus simple d’effectuer l’automatisation et vous n’avez pas besoin de vous soucier de la dépendance des configurations spécifiques xml aux solutions en bac à sable. Voici la méthode de configuration de site réelle de la classe OD4B.Configuration.Async.Common.SiteModificationManager. Notez que nous utilisons le Office 365 principal PnP développeur pour simplifier certaines opérations nécessaires.
Il est également bon de noter que nous téléchargeons effectivement une nouvelle version du JS vers la collection de sites racine chaque fois que nous personnalisations un site OD4B personnel. Cette solution n’est absolument pas optimale, mais elle est plutôt là à des fins de simplicité pour cette solution de référence. Vous pouvez envisager d’ajouter cette opération de chargement de fichier JavaScript à l’événement Installed de l’application, afin qu’elle ne soit effectuée qu’une seule fois lors de l’installation de l’application, mais dans ce cas, vous devez travailler davantage avec les mises à jour de ce fichier 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);
}
}
Évidemment, les opérations nécessaires dépendent fortement des besoins de votre entreprise. Vous pouvez trouver plusieurs modèles et approches différents avec les opérations basées sur CSOM à partir des pratiques et modèles Office 365 développeur.
Remarques supplémentaires sur les solutions WebJob
Voici quelques remarques supplémentaires relatives au développement WebJob dans Azure. Il s’agit d’une technique extrêmement puissante qui sera certainement utilisée largement Office 365 personnalisations. Vous verrez certainement des solutions nouvelles et améliorées basées sur la technologie WebJob être ajoutées au programme Office 365 Developer Patterns & Practices.
Débogage du processus de personnalisation et webjob
L’une des bonnes pratiques pour votre code en général consiste à localiser les opérations réelles en dehors du processus d’exécution final réel, afin que vous pouvez d’abord vous concentrer sur le test du code nécessaire simplement à l’aide de l’application console ou, par exemple, avec des projets de test dans le Visual Studio. Ainsi, vous pouvez vous assurer que la logique métier réelle est entièrement fonctionnel avant de l’raccorder au processus final, dans ce cas, c’est-à-dire la webjob. Dans ce cas de solution de référence, nous avons placé tout le code métier à la classe OD4B.Configuration.Async.Common.SiteModificationManager et nous l’appelons à partir de nombreux emplacements.
Cela signifie que pendant le développement, nous pouvons utiliser OD4B. Application console Configuration.Async.Console.Reset pour tester et réinitialiser les personnalisations autant de fois que nécessaire à partir des sites afin de garantir une logique métier complète. Cela n’a vraiment rien à voir avec le modèle de SharePoint ou le développement Azure, plutôt pratiques pratiques, quelle que soit la technologie que vous utilisez. Lorsque j’ai été haut-parleur dans le MCM pour une formation de certification SharePoint, je l’ai référent comme méthode NKOTB,mais il ne s’agit pas vraiment d’une terminologie standard du secteur : -)
L’une des grandes améliorations du point de vue du débogage pour les webjobs a été introduite dans la Visual Studio 2014 Update 4. Avec les nouvelles connexions Azure et les modèles de projet, vous pouvez réellement faire le débogage à distance avec WebJob s’exécutant côté Azure. Vous devrez déployer la webjob sur Azure et, après cela, vous pouvez démarrer la session de débogage en cliquant avec le bouton droit sur l’instance WebJob à partir de l’Explorateur de serveurs, puis choisir Joindre le déboguer dans le menu contextiqué.

Il existe même un testeur pour envoyer des messages correctement mis en forme à la file d’attente dans la solution de référence. OD4B. Le projet Configuration.Async.Console.SendMessage a été créé simplement pour pouvoir déboguer le processus WebJob sans être obligé de déployer le partie d’application n’importe où. Cela est revenu lors du débogage et du test pas à pas de l’ensemble du processus.
Variables d’environnement WebJob
L’un des points intéressants des webjobs est qu’ils s’exécutent sous un site web Azure, mais leur emplacement d’exécution est légèrement différent de celui des sites web normaux dans Azure. Cela signifie que si vous déployez des fichiers ou des ressources supplémentaires avec la webjob dans Azure, vous pouvez être confronté à des difficultés si vous supposez que vous pouvez référencer ces ressources directement à l’aide de chemins d’accès relatifs classiques dans le code WebJob.
Dans ce cas, nous avons eu un fichier JavaScript et quelques fichiers pour le thème personnalisé, qui ont été déployés sur le site web Azure, afin qu’ils soient chargés sur les sites SharePoint si nécessaire. Vous pouvez voir ces fichiers dans Azure si vous étendez la branche Fichiers sous un site web spécifique.

En règle générale, dans les sites web Azure, vous pouvez faire référence à ces fichiers en utilisant le format suivant
string path = HostingEnvironment.MapPath(
string.Format("~/{0}", "Resources/OneDriveConfiguration.js"));
Étant donné que les webjobs sont toutefois exécutés à un emplacement différent et non dans le contexte d’IIS, la référence ci-dessus au fichier ne fonctionnerait pas, car le mappage échouerait à partir du contexte du processus WebJob. C’est là que les variables d’environnement propres à WebJob peuvent vous aider. Dans le cas d’une solution de référence, nous avons utilisé des variables d’environnement spécifiques de la WEBROOT_PATH WebJob pour accéder au dossier du site web associé.
string jsFile = Path.Combine(
Environment.GetEnvironmentVariable("WEBROOT_PATH"),
"Resources\\OneDriveConfiguration.js");
Il existe également quelques autres variables d’environnement pour les webjobs, ce qui peut vous aider. Vous pouvez vérifier les différentes variables d’environnement à l’aide de code et il existe de GitHub références à ce sujet.
Vidéo illustrant la solution et les actions
Voici une vidéo montrant la solution en pratique, y compris une explication des structures de la solution et de la façon dont vous l’utiliseriez dans votre environnement Office 365 pour modifier les sites OneDrive Entreprise sites.
Liens connexes
- Personnaliser des sites OneDrive Entreprise
- Articles de référence sur la page https://aka.ms/OfficeDevPnPGuidance
- Références dans MSDN sur la page https://aka.ms/OfficeDevPnPMSDN
- Vidéos sur la page https://aka.ms/OfficeDevPnPVideos
Exemples PnP
- OD4B. Configuration.Async (exemple PnP O365)
- Provisioning.OneDriveProvisioning (exemple PnP O365)
- Office Composant principal PnP
- Exemples et contenu dans Microsoft 365 et pratiques PnP (Patterns and Practices)
S’applique à
- Office 365 multi-locataire (MT).
- Office 365 dédiés (D) partiellement
- SharePoint 2013 en local : partiellement
Les modèles pour les versions dédiées et en local sont identiques au complément SharePoint technique du modèle, mais il existe des différences sur les technologies qui peuvent être utilisées.