Gestion des événements dans les compléments pour SharePoint
Votre code personnalisé peut gérer trois catégories d’événements dans les compléments hébergés par un fournisseur :
- Événements de liste, comme l’ajout ou la suppression d’une liste sur un site web.
- Événements d’élément de liste, comme la modification d’un élément dans une liste.
- Événements d’application, comme l’installation d’une application.
Les compléments SharePoint hébergés par SharePoint ne prennent pas en charge la gestion des événements, mais vous pouvez transformer un flux de travail en gestionnaire d’événements de liste ou d’élément de liste en configurant un événement pour qu’il déclenche le flux de travail. Pour en savoir plus, consultez l’article Flux de travail dans SharePoint. Les événements de complément ne peuvent pas déclencher les flux de travail. C’est pourquoi un complément hébergé par SharePoint ne peut pas gérer les événements de complément.
Remarque
Les événements de site web et de collection de sites ne sont pas pris en charge dans les compléments SharePoint.
Il existe deux types d’événements :
Les événements antérieurs sont déclenchés avant que l’infrastructure SharePoint réalise sa propre gestion de l’événement (y compris avant de valider les modifications apportées à la base de données de contenu). Dans SharePoint, les gestionnaires d’événements antérieurs personnalisés sont toujours exécutés de façon synchrone. Ils peuvent être utilisés, entre autres, pour annuler l’événement. Par exemple, si un complément dispose d’une fonction de suppression de liste, le gestionnaire de l’événement de suppression de liste peut annuler la suppression si certaines conditions ne sont pas remplies. Si l’événement fait partie d’une séquence d’événements, son annulation empêche les événements ultérieurs de survenir. Par exemple, si le gestionnaire de l’événement ItemAdding annule cet événement, l’événement ItemAdded, qui se produit normalement plus tard, n’est pas déclenché.
Les événements postérieurs sont déclenchés après que l’infrastructure SharePoint réalise sa propre gestion de l’événement. Dans SharePoint, les gestionnaires d’événements postérieurs distants de liste et d’élément de liste sont toujours exécutés de façon asynchrone. (Les événements d’application représentent une exception.) Ils peuvent être utilisés, entre autres, pour consigner les événements.
Gestion des événements d’élément de liste et de liste
Pour gérer les événements de liste et d’élément de liste, vous créez des récepteurs d’événements distants (RER), qui sont des services web qui s’exécutent en externe sur la batterie de serveurs SharePoint ou SharePoint Online. L’URL du service RER est inscrite pour les événements qu’il gère. Il existe deux façons d’inscrire un gestionnaire :
Les événements du site web hôte sont inscrits via un programme avec le modèle CSOM ou l’API REST SharePoint. Cette tâche est généralement effectuée dans la logique « Première exécution » dans le complément ou dans un gestionnaire d’événements de complément. (Vous retrouverez tous les événements de complément dans la section Gérer des événements de complément plus loin dans cet article.) Pour obtenir un exemple de code qui inscrit un événement de liste via un programme, consultez l’article SharePoint/PnP/Samples/Core.EventReceivers.
Les événements de site web de complément sont généralement inscrits dans une fonctionnalité du site web de complément via des balises XML simples. Pour en savoir plus sur la création des balises et du service, consultez l’article Créer un récepteur d’événements distant dans des compléments pour SharePoint. Il est également possible d’inscrire des événements de site web de complément via un programme.
Remarque
Les récepteurs d’événements distants ont le même objectif que les récepteurs d’événements des solutions de batterie de serveurs. Toutefois, les récepteurs d’événements ont un code personnalisé qui s’exécute sur les serveurs SharePoint, c’est pourquoi ils ne peuvent pas être utilisés dans les compléments SharePoint.
Votre complément peut gérer les événements de bibliothèque de documents et de liste suivants. Les événements se terminant par « ing » sont des événements antérieurs (synchrones) et ceux se terminant par « ed » sont des événements postérieurs (asynchrones).
| Événements antérieurs (synchrones) | Événements postérieurs (asynchrones) |
|---|---|
| ListAdding | ListAdded |
| ListDeleting | ListDeleted |
| FieldAdding | FieldAdded |
| FieldDeleting | FieldDeleted |
| FieldUpdating | FieldUpdated |
Les événements de mise à jour de champ consistent à modifier les propriétés d’un champ (colonne) dans une liste, par exemple s’il est triable, et non à modifier les données dans le champ.
Votre complément peut gérer les événements d’élément de liste suivants.
| Événements antérieurs (synchrones) | Événements postérieurs (asynchrones) |
|---|---|
| ItemAdding | ItemAdded |
| ItemUpdating | ItemUpdated |
| ItemDeleting | ItemDeleted |
| ItemCheckingOut | ItemCheckedOut |
| ItemCheckingIn | ItemCheckedIn |
| ItemUncheckingOut | ItemUncheckedOut |
| ItemAttachmentAdding | ItemAttachmentAdded |
| ItemAttachmentDeleting | ItemAttachmentDeleted |
| ItemFileMoving | ItemFileMoved |
| ItemVersionDeleting* | ItemVersionDeleted* |
| ItemFileConverted |
Remarque
*Ces deux nouveaux événements peuvent ne pas être disponibles dans l’interface utilisateur de Visual Studio. Dans ce cas, sélectionnez les événements ItemDeleting ou ItemDeleted, puis renommez-les manuellement.
Lorsque vous travaillez dans Visual Studio et que vous ajoutez un RER à un projet de complément SharePoint, les outils de développement Office pour Visual Studio réalisent les opérations suivantes :
Un fichier de service web, tel que RemoteEventReceiver1.svc, est ajouté à l’application web pour gérer les événements que vous avez spécifiés lorsque vous avez ajouté le récepteur d’événements distants au complément SharePoint. Le service web contient un fichier de code destiné à gérer les événements distants.
Après avoir créé le récepteur d’événements distants, ajoutez un code au fichier de code du service d’application web pour gérer les événements. Par défaut, le fichier de code contient deux méthodes auxquelles vous pouvez ajouter votre code de gestion :
ProcessEvent()gère les événements « antérieurs » (tels que ceux apparaissant dans les colonnes de gauche ci-dessus) et renvoie un objet à SharePoint qui indique si l’événement doit être annulé ou poursuivi.ProcessOneWayEvent()gère les événements « after ». Il s’exécute de manière asynchrone et ne renvoie rien à SharePoint.
Quand un événement inscrit se produit, SharePoint appelle la méthode appropriée dans votre service et transmet un objet qui fournit des informations de contexte pour votre code. Par exemple, le type d’événement (d’un des deux tableaux ci-dessus) est identifié pour que votre code puisse ajouter une branche à la logique correspondant à l’événement.
Un élément de projet pour le récepteur d’événements distants est ajouté au projet de complément SharePoint. Le fichier Elements.xml pour le récepteur d’événements distants référence le service web dans l’application web et les événements distants que vous avez spécifiés. L’exemple suivant présente un fichier Elements.xml qui gère l’ajout ou la suppression d’un élément de liste :
<?xml version="1.0" encoding="utf-8"?> <Elements xmlns="http://schemas.microsoft.com/sharepoint/"> <Receivers ListTemplateId="104"> <Receiver> <Name>RemoteEventReceiver1ItemAdding</Name> <Type>ItemAdding</Type> <SequenceNumber>10000</SequenceNumber> <Url>~remoteAppUrl/RemoteEventReceiver1.svc</Url> </Receiver> <Receiver> <Name>RemoteEventReceiver1ItemDeleting</Name> <Type>ItemDeleting</Type> <SequenceNumber>10000</SequenceNumber> <Url>~remoteAppUrl/RemoteEventReceiver1.svc</Url> </Receiver> </Receivers> </Elements>
Pour modifier les événements gérés par le récepteur d’événements, ouvrez l’Explorateur de solutions, ouvrez la fenêtre Propriétés pour le récepteur d’événements distants, développez le nœud Événements SharePoint, puis attribuez la valeur True uniquement aux événements que vous souhaitez gérer.
Remarque
Pour en savoir plus sur les récepteurs d’événements distants et la résolution de certains problèmes, consultez la section Questions les plus fréquentes sur les récepteurs d’événements distants.
Gérer des événements de complément
Les événements de complément sont également gérés par des services web distants, mais ils sont configurés différemment dans le package de compléments par rapport aux récepteurs d’événements distants de liste et d’élément de liste. C’est pourquoi ils sont traités comme une catégorie distincte de composant. Pour un événement de complément, le service web distant est inscrit auprès du manifeste de complément, et non dans une fonctionnalité du site web de complément. Le complément n’a même pas besoin de disposer d’un site web de complément. Il existe trois événements de complément comme vous pourrez le voir dans les sections suivantes.
Événement AppInstalled
L’événement AppInstalled s’exécute dès que SharePoint a terminé toutes les opérations qu’il doit effectuer après l’installation du complément (avant que l’utilisateur soit averti de la fin de l’installation). Bien qu’il s’agisse d’un événement postérieur, SharePoint exécute le gestionnaire de manière synchrone. Il est impossible d’utiliser le complément avant que le gestionnaire n’ait terminé. De plus, celui-ci peut annuler l’installation. (SharePoint restaurera alors toutes les modifications apportées dans le cadre de l’installation.) Nous vous recommandons de détecter les erreurs dans le gestionnaire et de demander à SharePoint d’annuler l’installation. Pour en savoir plus, consultez la section Inclure une logique de restauration et une logique « Déjà terminé » dans vos gestionnaires d’événements de complément plus loin dans cet article.
Remarque
Quand vous installez un complément avec une étendue client, il est installé dans la collection de sites de catalogue de compléments. L’événement AppInstalled s’exécute uniquement à ce moment-là. Le complément est visible dans plusieurs sites web du client, mais l’événement ne s’exécute pas séparément pour chacun d’eux.
En plus d’annuler l’installation d’un complément, cet événement peut servir à effectuer d’autres opérations, notamment :
Installer sur le site web hôte des composants SharePoint qui ne peuvent pas être installés de façon déclarative avec la fonctionnalité de site web hôte, comme des listes ou des sous-sites web.
Inscrire via un programme des gestionnaires d’événements de liste et d’élément de liste auprès du site web hôte ou du site web de complément.
Définir des paramètres d’initialisation relatifs à une instance d’application. Par exemple, votre complément peut disposer d’un conteneur de propriétés de site web de complément qui conserve les paramètres variant d’une instance de complément à l’autre. Votre gestionnaire AppInstalled peut écrire les différentes valeurs dans le conteneur des propriétés en fonction, par exemple, du type de site web hôte (site d’équipe ou site de blog).
Remarque
Vérifier si le site web hôte est un site AppCatalog est un bon moyen de détecter si le complément a été installé avec l’étendue du locataire. Voir Locations et étendues de déploiement des compléments pour SharePoint.
Configurer l’instance d’application dans l’application web distante du complément, par exemple en ajoutant une table à une base de données.
Importante
L’implémentation de l’événement AppInstalled doit être réalisée en moins de 30 secondes, sinon l’infrastructure de l’installation SharePoint considère que l’implémentation a échoué. L’infrastructure réexécute l’événement et répète votre code depuis le début trois fois maximum. Au bout de quatre expirations, SharePoint restaure toute l’installation du complément. Les répercussions de cette opération sont décrites dans la section Inclure une logique de restauration et une logique « Déjà terminé » dans vos gestionnaires d’événements de complément.
Événement AppUninstalling
L’événement AppUninstalling ne s’exécute pas lorsque le complément est supprimé du site web hôte. La suppression d’un complément déplace uniquement le complément vers la corbeille de l’utilisateur. Deux autres étapes doivent être réalisées avant le déclenchement de l’événement AppUninstalling. Tout d’abord, l’utilisateur doit supprimer le complément de la corbeille pour le déplacer vers la corbeille de second niveau. Deuxièmement, un utilisateur doit supprimer le complément de la corbeille de la deuxième étape. Cette dernière tâche déclenche l’événement AppUninstalling. L’événement AppUninstalling est synchrone et vous pouvez l’utiliser pour annuler la désinstallation, ce qui devrait laisser le complément dans la corbeille de second niveau.
Pour cet événement, le gestionnaire a pour principal objectif de supprimer ou de recycler les éléments déployés avec un gestionnaire AppInstalled (ou AppUpdated). SharePoint ne peut pas supprimer ces éléments ou les déplacer vers la corbeille car il ne les connaît pas, du moins en tant que composants du complément. Il est généralement recommandé de supprimer ces éléments. Cependant, évitez de supprimer les éléments qui peuvent être utiles une fois le complément désinstallé : si une liste ou un site web créé par votre gestionnaire AppInstalled peut encore être utilisé, ne le supprimez pas de votre gestionnaire AppUninstalling.
Événement AppUpgraded
L’événement AppUpgraded s’exécute dès que SharePoint a terminé toutes les opérations qu’il doit effectuer après la mise à jour du complément vers une nouvelle version (avant que l’utilisateur soit averti de la fin de la mise à jour). Tout comme l’événement AppInstalled, il s’agit d’un événement postérieur, mais il est essentiellement synchrone. Nous vous conseillons également de détecter les erreurs et de demander à SharePoint de restaurer la mise à jour.
Exemples d’opérations que peut effectuer un gestionnaire pour cet événement :
Ajouter, modifier ou supprimer des composants de complément dans le site web hôte.
Effectuer des opérations sur le site web de complément qui ne sont pas réalisables avec la sémantique de mise à jour déclarative dans une fonctionnalité de site web de complément. Par exemple, vous ne pouvez rien supprimer avec les balises déclaratives de mise à jour, mais vous pouvez le faire via un programme dans un gestionnaire AppUpgraded.
Apporter des modifications à des composants relatifs à une instance d’application dans l’application web ou la base de données distante du complément.
Pour savoir comment créer les gestionnaires d’événements de complément, consultez l’article Créer un récepteur d’événements de complément dans SharePoint.
Inclure une logique de restauration et une logique « Déjà terminé » dans vos gestionnaires d’événements de complément
Si SharePoint rencontre une erreur pendant le traitement de l’un des trois événements, il annule l’événement et restaure les modifications apportées dans le cadre de l’événement. Vos gestionnaires d’événements de complément doivent recourir à ce système car, en cas d’échec de la partie de l’événement implémentée, il vaut mieux restaurer l’ensemble de l’événement, au lieu de poursuivre et de laisser des éléments potentiellement endommagés. Voici ce que votre gestionnaire doit généralement faire :
Indiquer à SharePoint qu’une erreur s’est produite. Le message SOAP renvoyé à SharePoint par votre service web de gestion d’événements de complément comprend une propriété Status pouvant avoir pour valeur Continue, CancelWithError ou CancelWithoutError. L’état Cancel indique à SharePoint de restaurer l’événement.
Restaurer ce que le gestionnaire a déjà fait avant de rencontrer l’erreur. En général, SharePoint ne peut pas effectuer cette opération pour vous car il ne sait pas ce que votre gestionnaire a fait. Il ne s’agit pas d’une règle universelle. Par exemple, si l’installation d’un complément est annulée, SharePoint supprime l’intégralité du site web de complément. Il est donc inutile qu’un gestionnaire d’événements AppInstalled rétablisse les modifications apportées au site web de complément. Cependant, il doit généralement restaurer les modifications apportées au site web hôte ou aux composants distants du complément.
Remarque
Les points précédents s’appliquent à l’événement AppUninstalling, ainsi qu’aux deux autres événements de complément. Par exemple, si le gestionnaire de l’événement de désinstallation supprime une ligne dans une base de données distante et rencontre une erreur, la ligne doit être restaurée. Étant donné que votre service envoie un message d’annulation à SharePoint, le complément n’est pas supprimé de la corbeille. S’il est restauré à partir de là et réutilisé, il est possible qu’il ne fonctionne pas sans cette entrée de la base de données. Toutefois, votre gestionnaire AppUninstalling opère avant que SharePoint supprime le complément de la corbeille. Ainsi, si SharePoint lui-même rencontre une erreur et doit annuler la suppression, votre gestionnaire ne peut en aucun cas annuler ce qu’il a effectué.
Si SharePoint ne reçoit pas un message de résultats de la part de votre gestionnaire dans un délai de 30 secondes, il appelle à nouveau le gestionnaire. Au bout de trois tentatives (quatre tentatives en tout), il abandonne et restaure l’événement. Chaque fois qu’il appelle le gestionnaire, votre code recommence depuis le début. En général, il est préférable que votre gestionnaire n’ait pas à rétablir tout ce qu’il a déjà effectué, comme la création d’une liste sur le site web hôte. Par ailleurs, vous ne pouvez pas savoir si votre logique de restauration est terminée, ou même déclenchée, avant l’expiration du gestionnaire. C’est pourquoi votre logique de gestionnaire ne doit pas intervenir sans avoir vérifié au préalable si l’action a été effectuée, sauf si le fait de répéter l’action ne comporte aucun risque.
Les erreurs d’installation et de mise à jour sont affichées sur l’interface utilisateur SharePoint :
Accès aux détails de l’erreur d’installation
Stratégies d’architecture de gestionnaire d’événements de complément
Exprimé en pseudo-code, votre gestionnaire doit généralement être structuré comme suit. Si une erreur se produit dans la section Try, la section Catch and Rollback doit être appelée. (Cela peut se produire automatiquement en fonction de la langue et de l’infrastructure.)
Try
If X not already done,
Do X.
Catch
Send cancel message to SharePoint.
If X not already undone,
Undo X.
Toutefois, l’implémentation de votre logique de restauration et « Déjà terminé » dans votre service web peut ralentir le gestionnaire. Vos logiques d’installation et de restauration apportent généralement des modifications à un élément plus ou moins distant du service web, comme le site web hôte SharePoint ou une base de données principale. Si votre code d’installation et de restauration est réparti entre les sections Try et Catch, le service appelle séparément les composants distants (souvent plusieurs appels par section).
En règle générale, nous vous recommandons d’implémenter la logique d’installation et de restauration sur le composant distant dans une procédure pouvant être appelée depuis votre gestionnaire dans la section Try. La procédure doit renvoyer un message de réussite ou d’échec. Dans le cas d’un échec, le code de la section Try appelle la section Catch (en générant une exception, par exemple). La seule chose que la section Catch effectue est d’informer SharePoint. C’est ce que nous appelons la stratégie de délégation de gestionnaire. Le pseudo-code suivant illustre la stratégie :
Try
Call the "Do X" procedure on remote platform.
If remote platform reports failure, call Catch.
Catch
Send cancel message to SharePoint.
La procédure « Faire X », exécutée sur le système distant, contient la logique de restauration et « Déjà terminé » suivante :
Try
If X not already done,
Do X.
Set success flag to true.
Catch
If X was done before error,
Undo X.
Set success flag to false.
Send
Return success flag to the event handler.
Par exemple, si votre gestionnaire doit effectuer une action sur une base de données SQL Server, vous pouvez installer une procédure stockée sur l’instance SQL Server qui utilise un bloc TRY-CATCH pour implémenter une logique d’installation/de restauration, et des blocs IF-ELSE pour implémenter une logique « Déjà terminé ».
Le modèle de complément SharePoint ne fournit aucun moyen de stocker du code côté serveur personnalisé sur SharePoint et de l’appeler à partir du modèle CSOM (modèle objet côté client). Cependant, le modèle CSOM permet de grouper les logiques try-catch et if-then-else et de les envoyer au serveur pour exécution.
Pour obtenir un exemple détaillé de gestionnaire d’événements de complément qui utilise la stratégie de délégation de gestionnaire pour ajouter une liste à un site web hôte, consultez l’article Créer un récepteur d’événements de complément dans SharePoint. Pour obtenir un exemple de code, consultez la page SharePoint/PnP/Samples/Core.AppEvents.HandlerDelegation.
Vous ne pouvez pas toujours utiliser la stratégie de délégation de gestionnaire. Par exemple, quand votre gestionnaire appelle plusieurs composants, comme une base de données et le site web hôte SharePoint, il est possible que l’un réussisse et l’autre échoue. Dans ce cas, la logique de restauration pour le premier composant ne s’exécute pas si vous l’avez conçue avec la stratégie de délégation de gestionnaire. Ainsi, si vous appelez les composants de façon synchrone, seul le dernier composant appelé peut utiliser la stratégie de délégation de gestionnaire. S’ils sont appelés de façon asynchrone, vous ne pouvez utiliser cette stratégie pour aucun d’entre eux.
Pour obtenir un exemple de gestionnaire d’événements de complément qui n’utilise pas la stratégie de délégation de gestionnaire, voir SharePoint/PnP/Samples/Core.AppEvents.
Conseil
Si l’événement AppInstalled échoue, SharePoint supprime le site web de complément, le cas échéant. Si l’événement AppUpated échoue, SharePoint restaure le site web de complément à son état avant mise à jour. Ainsi, vos gestionnaires ne doivent jamais restaurer les actions qu’ils entreprennent sur le site web de complément. Si votre gestionnaire effectue des actions sur le site web hôte et sur le site web de complément, il doit d’abord traiter le site web de complément. Ainsi, l’utilisation de la stratégie de délégation de gestionnaire pour le site web hôte est sécurisée. Même si les actions du site web de complément réussissent et que les actions du site web hôte échouent, toutes les logiques de restauration sont exécutées.
Récepteurs d’événements distants dans les compléments prenant en charge plusieurs zones de sécurité
Il existe des restrictions sur la façon de concevoir un complément qui prend en charge plusieurs zones de sécurité et dispose d’un récepteur d’événements distants.
Questions les plus fréquentes sur les récepteurs d’événements distants
Voici les principales questions que vous pouvez vous poser lors de l’utilisation de récepteurs d’événements distants.
En quoi les récepteurs d’événements distants sont-ils différents des récepteurs d’événements de SharePoint 2010 ?
Dans SharePoint 2010, les récepteurs d’événements gèrent les événements qui se produisent sur des listes, des sites et d’autres objets SharePoint en exécutant le code sur le serveur SharePoint (en confiance totale ou dans un bac à sable [sandbox]). Ce type de récepteur d’événements existe toujours dans SharePoint. Cependant, SharePoint prend également en charge les récepteurs d’événements distants dans lesquels le code exécuté au déclenchement de l’événement est hébergé par un service web. Ainsi, si vous inscrivez un récepteur d’événements distants, vous devez aussi indiquer à SharePoint le service web à appeler.
Dans les exemples de code suivants, le premier exemple (solutions SharePoint) implémente la fonctionnalité à l’aide d’un gestionnaire d’événements. Le deuxième exemple (compléments SharePoint) implémente la même fonctionnalité à l’aide d’un récepteur d’événements distants.
Solutions SharePoint
// Trigger an event when an item is added to the SharePoint list.
Public class OnPlantUpdated : SPItemEventReceiver
{
Public override void ItemAdding (SPItemEventProperties properties)
{
Properties.After.Properties.ChangedProperties.Add("Image",CreateLink(properties));
Properties.status =SPEventReceiverStatus.Continue;
}
/// When an item updates, run the following.
Public override void ItemUpdating(SPItemEventProperties properties)
{
Properties.AfterProperties.ChangedProperties.Add("Image",CreateLink9properties));
Properties.Status= SPEventReceiverStatus.Continue;
}
Compléments SharePoint
/* Trigger an event when an item is added to the SharePoint list*/
Public class OnPlantUpdated : IRemoteEventService
{
public SPRemoteEventResult ProcessEvent (SPRemoteEventProperties properties)
{
SPRemoteEventResult result =new SPRemoteEventResult();
If (properties.EventType == SPRemoteEventType.ItemAdding ||
properties.EventType == SPRemoteEventType.ItemUpdating)
{
// Add code that runs when an item is added or updated.
}
Pour obtenir l’exemple de code complet, consultez la page relative à l’ajout des propriétés d’éléments de liste avec un récepteur d’événements distants.
Pour accéder à une démonstration détaillée de l’exemple de code, consultez la page relative à la migration d’un récepteur d’événements SharePoint vers un récepteur d’événements distants.
Pour en savoir plus, consultez la rubrique SPRemoteEventType - Énumération.
Comment les récepteurs d’événements distants fonctionnent-ils ?
La figure suivante illustre le fonctionnement des récepteurs d’événements distants :
L’utilisateur effectue une action sur SharePoint (par exemple, il modifie un élément de liste).
Ensuite, SharePoint communique avec le service web inscrit. Vous pouvez effectuer certaines opérations (par exemple, mettre à jour une propriété d’élément de liste ou un système principal).
Le service web peut également communiquer avec la fonction de contrôle d’accès (ACS) pour demander son propre jeton signé, afin d’effectuer un rappel vers SharePoint. Avec ce jeton, vous pouvez effectuer des actions à distance à partir du service web suite à l’opération précédente sur l’élément de liste ou dans le système principal.
Fonctionnement des récepteurs d’événements emote dans SharePoint
Comment déboguer les récepteurs d’événements distants ?
Consultez l’article Déboguer et dépanner un récepteur d’événement distant dans un complément pour SharePoint.
Puis-je exécuter le code côté client (JavaScript) à partir de récepteurs d’événements distants ?
Non, vous ne pouvez pas exécuter le code côté client (JavaScript) à partir de récepteurs d’événements distants.
Existe-t-il des restrictions quant à l’emplacement où un récepteur d’événements distants peut être hébergé sur son URL ?
Le récepteur d’événements distants peut être hébergé dans le cloud ou sur un serveur local qui n’est pas utilisé en même temps comme serveur SharePoint. L’URL d’un récepteur de production ne peut pas spécifier un port particulier. Cela signifie que vous devez utiliser soit le port 443 pour HTTPS (recommandé) soit le port 80 pour HTTP. Si vous utilisez HTTPS et que le service de récepteur est hébergé sur le serveur local, mais que le complément se trouve sur SharePoint Online, le serveur d’hébergement doit obtenir un certificat approuvé publiquement auprès d’une autorité de certification. (Un certificat auto-signé est valable uniquement si le complément se trouve sur une batterie de serveurs SharePoint locale.)
Un gestionnaire d’événements SharePoint 2010 fonctionnera-t-il sur SharePoint après la mise à niveau ?
Si un package de solution SharePoint 2010 contenant un gestionnaire d’événements est mis à niveau vers SharePoint, en fonction de vos personnalisations, le package de solution peut fonctionner sans aucune modification. Cela concerne également le gestionnaire d’événements. Si la solution SharePoint 2010 est remodelée en complément SharePoint dans SharePoint, le gestionnaire d’événements doit être réécrit comme un récepteur d’événements distants. Consultez la page relative à la migration d’un récepteur d’événements SharePoint vers un récepteur d’événements distants.