Partager via

Remplacer les récepteurs de fonctionnalités dans les solutions de bac à sable

  • Article

Les récepteurs de fonctionnalités sont généralement utilisés pour appliquer différents types de configurations ou de paramètres aux sites SharePoint lorsque la fonctionnalité est activée ou lorsque le site est créé (si la fonctionnalité est associée à un modèle de site ou à un modèle web). Les récepteurs de fonctionnalités ont été déployés à l’aide de solutions de bac à sable dans SharePoint Online ; Toutefois, étant donné que les personnalisations basées sur le code ne peuvent plus être utilisées, vous devez utiliser une autre conception.

L’approche que vous utilisez pour gérer les récepteurs de fonctionnalités dans SharePoint est légèrement différente dans le modèle de complément SharePoint qu’avec le code de confiance totale ou dans les solutions de bac à sable codé. Vous devez reconcevoir la solution de manière à utiliser des API distantes (CSOM/REST) pour appliquer les configurations nécessaires à vos sites.

Remarque

L’utilisation des solutions bac à sable basées sur un code est déconseillée depuis 2014 et, dans SharePoint Online, cette fonctionnalité est sur le point d’être totalement supprimée. Les solutions bac à sable basées sur un code sont également déconseillées dans SharePoint 2013 et SharePoint 2016.

Options de remplacement des récepteurs de fonctionnalités

Approche Considérations relatives à la conception et plus d’informations
Personnalisation basée sur PowerShell
  • Utilise des scripts PowerShell pour provisionner de nouvelles collections de sites (et potentiellement des sous-sites) là où les personnalisations nécessaires sont appliquées à l’aide d’API distantes. En règle générale, cela s’effectue en utilisant CSOM/REST directement dans les scripts PowerShell ou en utilisant des commandes PowerShell PnP, ce qui permet de modifier facilement les sites et le contenu à distance.
  • Fonctionne bien si votre modèle d’approvisionnement de site est basé sur des actions d’administration.
  • Nécessite l’exécution d’un script qui applique les personnalisations nécessaires aux sites créés.
  • Peut être combiné avec le processus de création de site, s’il est effectué en tant qu’opération d’administration.
  • Ne nécessite pas d’infrastructure d’hébergement.
  • Ne peut pas être combiné automatiquement dans le cadre du processus de création du sous-site.
Personnalisation basée sur le code
  • Applique les personnalisations nécessaires à l’aide de code managé avec des API distantes. Cela signifie que vous les appliquez dans le cadre de l’opération d’administration lors de la création du site ou que vous les appliquez à SharePoint, qui fait partie de votre code pour faire partie des éléments d’interface utilisateur.
  • Peut nécessiter une infrastructure d’hébergement si elle est combinée avec des opérations de l’utilisateur final.
  • Peut utiliser du code managé exécuté n’importe où à l’aide des API CSOM/REST pour les opérations nécessaires.
  • Peut être utilisé pour intégrer à SharePoint en remplaçant le lien de création de sous-site.
  • Peut automatiser la collection de sites et l’approvisionnement de sous-site à l’aide d’API distantes.

Remarque

Si vous souhaitez fournir un moyen automatique d’appliquer le code distant nécessaire dans le cadre de la logique de création de sous-site, vous devez remplacer le lien de sous-site à l’aide d’actions personnalisées de l’utilisateur. Cette option est disponible uniquement pour les sites qui utilisent le modèle classique pour les bibliothèques et les listes.

Application de personnalisations aux sites

Utiliser PowerShell

Voici un script simple qui utilise PnP PowerShell pour charger un fichier de couleur de thème à partir d’un ordinateur vers SharePoint Online, puis activer le fichier sur le site SharePoint.

Cet exemple utilise PnP PowerShell, qui fournit plus de 150 applets de commande PowerShell supplémentaires destinées à la configuration du site et à la gestion des ressources.

Connect-SPOnline –Url https://yoursite.sharepoint.com/ –Credentials (Get-Credential)
Add-SPOFile -Path c:\temp\company.spcolor -Folder /_catalogs/theme/15/
Set-SPOTheme -ColorPaletteUrl /_catalogs/theme/15/company.spcolor

Remarque

PnP PowerShell est une solution open source pour laquelle un support est assuré par la communauté active. Il n’existe pas de contrat SLA Microsoft pour le support technique relatif à cet outil open source.

Utilisation du code

Voici un exemple de code simple qui utilise le modèle CSOM SharePoint Online pour activer un thème personnalisé en chargeant d’abord les ressources sur un site SharePoint, puis en activant le thème personnalisé.

Cet exemple utilise le composant principal CSOM PnP, qui étend les opérations prêtes à l’emploi natives en introduisant un ensemble supplémentaire de méthodes d’extension pour les opérations courantes. Vous pouvez effectuer des opérations similaires à l’aide du modèle CSOM natif, mais le code serait beaucoup plus complexe.


// Upload assets to theme folder.
clientContext.Site.RootWeb.UploadThemeFile(
        HostingEnvironment.MapPath(string.Format("~/{0}", "Resources/Themes/SPC/SPCTheme.spcolor")));
clientContext.Site.RootWeb.UploadThemeFile(
        HostingEnvironment.MapPath(string.Format("~/{0}", "Resources/Themes/SPC/SPCbg.jpg")));

Web web = clientContext.Web;
// Loading RootWeb.ServerRelativeUrl property.
clientContext.Load(clientContext.Site, w => w.RootWeb.ServerRelativeUrl); 
clientContext.ExecuteQuery();
// Let's first upload the contoso theme to host web, if it does not exist there.
web.CreateComposedLookByUrl("Contoso",
                clientContext.Site.RootWeb.ServerRelativeUrl + "/_catalogs/theme/15/SPCTheme.spcolor",
                null,
                clientContext.Site.RootWeb.ServerRelativeUrl + "/_catalogs/theme/15/SPCbg.jpg",
                string.Empty);

// Setting the Contoos theme to host web.
web.SetComposedLookByUrl("Green");

Conseil

Lorsque vous utilisez des approches basées sur du code, nous vous recommandons d’utiliser le moteur de provisionnement PnP pour la gestion des modèles, ce qui simplifie considérablement l’effort de développement.

Suppression d’une solution de bac à sable contenant du code de récepteur de fonctionnalités de votre site

Si votre solution de bac à sable contient une logique de récepteurs de fonctionnalités pour la désactivation des fonctionnalités et qu’il est important qu’ils soient exécutés, vous devez vous assurer que ces fonctionnalités sont désactivées avant que la prise en charge basée sur le code ne soit désactivée à partir de SharePoint Online.

Vous pouvez désinstaller des solutions de bac à sable de SharePoint Online une fois la prise en charge basée sur le code désactivée, mais votre code de récepteur de fonctionnalité ne sera pas exécuté même si les fonctionnalités sont déplacées à partir du site.

Lorsque vous désactivez votre solution de bac à sable existante de vos sites, les ressources ou fichiers déployés à l’aide d’options déclaratives ne sont pas supprimés. Toutefois, les fonctionnalités de la solution de bac à sable sont automatiquement désactivées et le récepteur d’événements est supprimé.

Voir aussi