Remplacer les récepteurs d’événements dans les solutions bac à sable (sandbox)

L’approche que vous prenez pour gérer les événements 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. Dans les solutions précédentes classiques, les récepteurs d’événements étaient créés à l’aide du modèle objet SharePoint Server-Side et déployés via des packages de solutions, qui exécutaient le code sur les serveurs SharePoint.

Dans le modèle SharePoint, toutefois, l’implémentation du récepteur d’événements s’exécute sur le serveur web qui héberge le récepteur d’événements ; ces récepteurs sont appelés récepteurs d’événements distants (RER). Dans de nombreux cas, les récepteurs d’événements peuvent être remplacés par une implémentation de récepteur d’événements distants.

Cet article décrit différentes options et considérations de conception.

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 d’événements

Approche Considérations sur la conception et plus d’informations
Récepteur d’événements distant
  • Nécessite une infrastructure d’hébergement.
  • L’infrastructure d’hébergement doit être hautement disponible.
  • Le point de terminaison du service qui héberge le récepteur d’événements distants doit être configuré pour l’authentification anonyme.
  • Nécessite un certificat tiers approuvé si vous utilisez SharePoint Online.
  • Non destiné aux opérations de longue durée.
  • Les récepteurs d’événements distants qui sont attachés en dehors du contexte des add-ins, attachés à l’aide d’une application console ou de PowerShell, ne recevront pas de jeton de contexte SharePoint lorsqu’ils sont appelés, et vous devez différer les autorisations de module de mise en service uniquement ou utiliser la classe SharePointOnlineCredentials.
  • Il n’existe aucun mécanisme de nouvelle tentative.
Webhooks
  • Nécessite une infrastructure d’hébergement.
  • L’infrastructure d’hébergement doit être hautement disponible.
  • Ne pas prise en charge des événements synchrones.
  • Traiter les modifications une fois que l’événement s’est produit.
  • Non disponible dans SharePoint builds sur site pour le moment.
Travail du timer à distance pour surveiller les modifications
  • Utilise l’objet ChangeQuery pour surveiller les modifications d’un site ou d’une liste. Ce modèle est une alternative aux récepteurs d’événements distants.
  • Nécessite une infrastructure d’hébergement.
  • Traite les modifications après l’événement.
  • Utilise un mécanisme d’interrogation pour traiter les modifications.

Suppression de code bac à sable de votre 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