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

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 en bac à sable dans SharePoint Online ; Toutefois, étant donné que les personnalisations basées sur du code ne peuvent plus être utilisées, vous devez utiliser une autre conception.

L’approche que vous prenez pour gérer les récepteurs de fonctionnalités dans SharePoint est légèrement différente dans le modèle de SharePoint Add-in par rapport au code de confiance totale ou dans les solutions bac à sable codées. Vous devez reconçre la solution d’une manière qui utilise des API distantes (CSOM/REST) pour appliquer les configurations nécessaires à vos sites.

Notes

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 sur la conception et plus d’informations
Personnalisation basée sur PowerShell
  • Utilise des scripts PowerShell pour mettre en service de nouvelles collections de sites (et potentiellement des sous-sites) lorsque les personnalisations nécessaires sont appliquées à l’aide d’API distantes. En règle générale, cela s’fait à l’aide de CSOM/REST directement dans les scripts PowerShell ou à l’aide de commandes PowerShell PnP, ce qui permet de modifier facilement des sites et du contenu à distance.
  • Fonctionne bien si votre modèle de mise en service de site est basé sur des actions administratives.
  • Nécessite l’exécution d’un script qui applique les personnalisations nécessaires aux sites créés.
  • Peut être combiné au processus de création de site, s’il est effectué en tant qu’opération administrative.
  • Ne nécessite pas d’infrastructure d’hébergement.
  • Impossible de les combiner automatiquement dans le cadre du processus de création de sous-site.
Personnalisation basée sur le code
  • Applique les personnalisations nécessaires à l’aide de code géré avec des API distantes. Cela signifie que vous les appliquez dans le cadre de l’opération administrative lors de la création du site ou que vous les appliquez à SharePoint, qui raccorde 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 les opérations de l’utilisateur final.
  • Peut utiliser du code géré exécuté n’importe où à l’aide des API CSOM/REST pour les opérations nécessaires.
  • Peut être utilisé pour s’intégrer à SharePoint en remplacement du lien de création de sous-site.
  • Peut automatiser la mise en service des collections de sites et des sous-sites à l’aide d’API distantes.

Notes

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 par 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 à des sites

Utiliser PowerShell

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

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

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

Notes

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 de code

Voici un exemple de code simple qui utilise SharePoint Online CSOM pour activer un thème personnalisé en télé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 natives pré-terrain 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 d’approvisionnement PnP pour la gestion des modèles, ce qui simplifie considérablement l’effort de développement.

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

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

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

Lorsque vous désactivez votre solution 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 bac à sable sont automatiquement désactivées et le récepteur d’événements est supprimé.

Voir aussi