Partager via

Transformer des solutions bac à sable (sandbox) en modèle de complément SharePoint

  • Article

Transformer vos solutions bac à sable en modèle de complément SharePoint implique d’analyser vos extensions existantes, de concevoir et développer votre nouveau complément SharePoint, puis de tester et déployer celui-ci dans votre environnement de production.

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.

Solutions bac à sable basées sur un code dans SharePoint

Les solutions bac à sable sont des packages de personnalisation utilisables pour déployer les personnalisations dans SharePoint au niveau collection de sites. Si une solution bac à sable contient du code, elle est exécutée dans un processus isolé spécial, avec un ensemble limité d’API pour accéder au contenu et aux services SharePoint.

Il existe deux types de solutions bac à sable :

  • Les solutions bac à sable basées sur un code qui contiennent un assembly personnalisé dans le package.
  • Les solutions bac à sable déclaratives qui contiennent uniquement des configurations basées sur XML et des éléments associés.

Les solutions bac à sable déclaratives (basées sur XML) peuvent être classées en différents types selon leurs cas d’utilisation, à savoir :

  • Modèle de site : solution générée à l’aide de la fonctionnalité « Enregistrer le site en tant que modèle » à partir d’un site existant.
  • Package de conception : solution générée à l’aide du Gestionnaire de conception à partir du site de publication.
  • Solution bac à sable personnalisée : créée dans Visual Studio, par exemple, pour la personnalisation d’éléments et ne contenant pas d’assembly.

Les solutions bac à sable basées sur un code peuvent être classées en différents types selon leurs cas d’utilisation, à savoir :

  • Solution bac à sable déclarative avec assembly vide
  • Solution bac à sable contenant un formulaire InfoPath avec du code
  • Solutions bac à sable basées sur un code avec des personnalisations telles que des composants WebPart, des récepteurs d’événements ou des récepteurs de fonctionnalité
  • Solutions bac à sable avec action de workflow personnalisée

Lorsque vous prévoyez de vous écarter des solutions bac à sable, vous devez évaluer les exigences fonctionnelles et opérationnelles d’une solution spécifique et déterminer l’orientation future de la conception sur cette base.

Planification du processus de transformation

Lorsque vous transformez vos solutions bac à sable en modèle de complément SharePoint, vous devez vous assurer que l’impact sur vos utilisateurs sera minimal. Analysez soigneusement vos solutions bac à sable actuelles, puis concevez votre nouveau complément SharePoint de telle sorte qu’il répondre aux besoins de votre o/rganisation. Pour garantir la réussite de la transformation, nous vous recommandons de suivre le processus ci-après.

Préparation

Pour en savoir plus, approfondissez les sujets suivants :

Évaluation de la solution

Analysez les besoins fonctionnels et opérationnels comme suit :

  • Identifiez les solutions bac à sable déployées dans votre environnement actuel pour lesquelles vous pouvez utiliser les outils suivants fournis en open source par l’équipe Pratiques et modèles de SharePoint :

  • Examinez les exigences avec vos utilisateurs. Les utilisateurs peuvent montrer comment ils utilisent les solutions bac à sable existantes pour accomplir leur travail quotidien.

  • Identifiez, documentez et concevez de nouvelles fonctionnalités à inclure dans le nouveau complément SharePoint. Songez à consulter votre liste de nouvelles demandes de fonctionnalité des utilisateurs pour obtenir des idées supplémentaires.

  • Identification des fonctionnalités inutilisées et otention de l’agrément des utilisateurs pour omettre cette fonctionnalité dans le nouveau complément SharePoint.

  • Pour chaque solution, déterminez s’il faut la remplacer par un complément SharePoint ou l’implémenter à l’aide de fonctionnalités prêtes à l’emploi ou d’une autre solution.

Planification de la solution

Concevoir la nouvelle application en utilisant le modèle de complément SharePoint basé sur :

  • Les exigences collectées lors de l’ étape d’évaluation de la solution.

  • Votre analyse du code existant. Pendant l’analyse du code, vous pouvez identifier les parties du code qui peut être abandonnées (par exemple, le code n’est plus utilisé, ou les exigences ont changé).

Développer et tester la version du modèle de complément SharePoint de votre application

Il s’agit généralement de l’étape qui exige le plus de temps dans le processus de transformation.

Déployer votre nouveau complément

Vérifiez que votre déploiement est stable et envoyez des communications appropriées à vos utilisateurs.

Remplacement de personnalisations de solutions bac à sable

Voici des personnalisations courantes incluses dans les solutions bac à sable et les options de transformation potentielles. Nous envisageons d’ajouter des informations pour chacun des types de personnalisations afin que vous disposiez d’exemples concrets des options de transformation.

Personnalisation Options de transformation
Solution déclarative avec assembly vide

Vous pouvez contrôler la création d’assembly à partir de propriétés de projet de solution Visual Studio. Pour plus d’informations, voir Suppression de la référence d’assembly de votre solution bac à sable (sandbox) créée dans Visual Studio.



Important : lorsque vous utilisez le scanneur de solution bac à sable SharePoint, celui-ci répertorie les solutions contenant un assembly vide et crée des packages de solution bac à sable mis à jour pour vous dans lesquels l’assembly est supprimé. Vous pouvez ensuite remplacer simplement la solution bac à sable existante par celle mise à jour.
Formulaire InfoPath contenant du code

Si vous avez publié à partir du client InfoPath un formulaire contenant du code, celui-ci est publié sur SharePoint en tant que solution bac à sable. Cela signifie que le code de formulaire est en réalité exécuté par le moteur de bac à sable dans SharePoint.

L’éloignement des formulaires InfoPath basés sur un code dépend du cas d’utilisation réel. Plusieurs options sont disponibles, de la génération d’une interface utilisateur personnalisée en tant que complément à l’utilisation d’autres techniques de formulaire.

Pour plus d’informations, voir Corriger les formulaires InfoPath dans les solutions bac à sable.
Composant WebPart

Les composants WebPart sont généralement convertis en composants de complément, ou implémentés avec des technologies entièrement côté client en utilisant le modèle d’incorporation JavaScript.

Pour plus d’informations, consultez l’article suivant :
Composant WebPart visuel

Les composants WebPart visuels sont transformés de la même façon que des composants WebPart normaux. Les contrôles utilisateur utilisés dans les composants WebPart visuels doivent être remplacés car, dans les solutions bac à sable, ils sont inclus dans l’assembly.
Récepteurs d’événements

Il est souvent possible de remplacer des récepteurs d’événements par l’implémentation du récepteur d’événements distant. Cependant, les récepteurs d’événements distants doivent être hébergés sur une plateforme, généralement sur des compléments hébergés par un fournisseur spécifique.

Pour plus d’informations, consultez l’article suivant :
Récepteur de fonctionnalité

Les récepteurs de fonctionnalité sont généralement remplacés par une opération basée sur une API distante, telle que l’utilisation de CSOM ou de REST pour appliquer la personnalisation ou la configuration requises au niveau du site. S’il manque une API nécessaire parmi les API distantes (CSOM/REST), signalez-le via SharePoint UserVoice.

Des récepteurs de fonctionnalité sont utilisés, par exemple, pour définir une page maître personnalisée ou un thème pour un site quand ils sont activés. Il est facile de remplacer ces types d’opérations par des solutions distantes basées sur un code ou en utilisant les pratiques et modèles PowerShell qui fournissent des commandes simples pour contrôler la configuration du site.
Action de workflow personnalisée

Le chemin de migration de code classique pour ces sortes de personnalisations consiste à utiliser des flux de travail SharePoint ou d’autres solutions telles que Microsoft Flow ou des solutions tierces.

Suppression de code bac à sable de votre site

Lorsque vous désactivez votre solution bac à sable d’un site, les éléments ou fichiers déployés à l’aide d’options déclaratives ne sont pas supprimés. Si vous avez utilisé des solutions bac à sable pour introduire de nouveaux composants WebPart basés sur un code, ces fonctionnalités sont désactivées des sites. Cela signifie que les pages sont toujours restituées normalement et que la désactivation de la solution n’a aucune incidence directe sur l’utilisateur final, à l’exception de la suppression des fonctionnalités basées sur un code telles que les composants WebPart.

Suppression de la prise en charge de solutions bac à sable basées sur un code

La prise en charge des solutions bac à sable basées sur un code sera supprimée de SharePoint Online en désactivant les opérations basées sur un code qui s’exécutent à partir d’un code basé sur une solution bac à sable. Cela signifie que vos solutions bac à sable ne sont pas explicitement désactivées de la banque de solutions, mais que les opérations basées sur un code ne seront plus effectuées. Les solutions bac à sable restent à l’état activé dans la galerie de solutions. Les fonctionnalités déployées à l’aide de solutions bac à sable ne sont pas automatiquement désactivées. Autrement dit, le code éventuel associé aux gestionnaires de désactivation ou de désinstallation des fonctionnalités n’est pas exécuté.

Toutes les définitions déclaratives dans la solution bac à sable continuent de fonctionner une fois cette modification appliquée dans SharePoint Online.

Contenu de cette section

Voir aussi