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.
Notes
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 des événements d’élément de liste et de liste, créez des récepteurs d’événement distants (RER). Il s’agit de services web qui s’exécutent hors de la batterie SharePoint ou de SharePoint Online. L’URL du service RER est enregistrée pour les événements qu’il gère. Il existe deux façons d’enregistrer 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.
Notes
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 |
Notes
*Il est possible que ces deux nouveaux événements ne soient pas disponibles dans l’interface 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 distant 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 « postérieurs ». Il s’exécute de manière asynchrone et ne renvoie rien à SharePoint.
Lorsqu’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 (à partir de l’une des deux tables plus haut dans cet article) est identifié, afin que votre code puisse créer une branche vers la logique appropriée pour l’événement.
Un élément de projet pour le récepteur d’événements distant est ajouté au projet de Complément SharePoint. Le fichier Elements.xml pour le récepteur d’événements distant 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.
Notes
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ément à partir des RER d’éléments de liste et de liste, et sont donc traités comme une catégorie distincte de composants. Pour un événement de complément, le service web distant est enregistré auprès du manifeste de complément, et non dans une fonctionnalité 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 décrit 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). Même s’il s’agit d’un événement postérieur, SharePoint exécute votre gestionnaire de façon 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.
Notes
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éfinition des paramètres d’initialisation relatifs à l’instance d’application. Par exemple, votre complément peut avoir un conteneur de propriétés web de complément pour contenir des paramètres qui varient d’une instance du complément à une autre. Votre gestionnaire AppInstalled peut écrire des valeurs variables dans le conteneur de propriétés, en fonction, par exemple, du type de site web hôte (par exemple, site d’équipe ou site de blog).
Notes
Vérifier si le site web hôte est un site AppCatalog. Il s’agit d’un bon moyen pour détecter si le complément a été installé avec une étendue de location. Voir Tenancies and deployment scopes for SharePoint Add-ins.
Configurer l’instance d’application dans l’application web distante du complément, par exemple en ajoutant une table à une base de données.
Important
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 ne fait que le déplacer vers la Corbeille de l’utilisateur. Deux étapes supplémentaires sont nécessaires pour déclencher l’événement AppUninstalling. Tout d’abord, un utilisateur doit supprimer le complément de sa Corbeille, afin de le déplacer vers la Corbeille second niveau. Ensuite, un utilisateur doit supprimer le complément de la Corbeille second niveau. 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 laisserait le complément dans la Corbeille second niveau.
L’objectif principal d’un gestionnaire pour cet événement est de supprimer ou de recycler des éléments qui ont été 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 pas en tant que composants du complément. Il est généralement recommandé de supprimer ces éléments. Mais vous ne souhaitez pas supprimer des éléments qui ont encore une vie utile après la suppression du complément : si une liste ou un site web créé par votre gestionnaire AppInstalled va toujours être utilisé, ne le supprimez pas dans votre gestionnaire AppUninstalling.
Événement AppUpgraded
L’événement AppUpgraded s’exécute immédiatement une fois que SharePoint a terminé toutes les opérations qu’il doit effectuer lors de la mise à jour du complément vers une nouvelle version, mais avant que l’utilisateur soit averti que la mise à jour est terminée. Comme l’événement AppInstalled, il s’agit d’un événement postérieur, mais qui est principalement synchrone et il est recommandé de détecter les erreurs et de notifier à 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 possibles 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 le balisage déclaratif de mise à jour, mais vous pouvez le faire par programmation 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 lors du traitement de l’un des trois événements de complément, il annule l’événement et restaure les modifications qu’il a apportées à l’événement. Vos gestionnaires d’événements de complément doivent s’intégrer à ce système, car si la partie de l’événement que vous implémentez échoue, vous souhaitez que l’ensemble de l’événement soit restaurée, plutôt que de continuer et de laisser les éléments dans un état potentiellement endommagé. 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.
Annulez ce que le gestionnaire a déjà fait avant que le gestionnaire ne rencontre l’erreur. SharePoint ne peut généralement pas le faire 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 une installation de complément est annulée, SharePoint supprime l’intégralité du site web de complément. Par conséquent, il n’y a aucun point dans un gestionnaire d’événements AppInstalled qui rétablit tout ce qu’il a fait sur le site web du complément. Mais il doit généralement restaurer les opérations qu’il a effectuées sur le site web hôte ou sur les composants distants du complément.
Notes
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 de message de résultats de votre gestionnaire en 30 secondes, il appelle à nouveau le gestionnaire. Il abandonne complètement et restaure l’événement après trois nouvelles tentatives (quatre tentatives au total). Chaque fois qu’il appelle le gestionnaire, votre code redémarre à partir du début. Toutefois, vous ne souhaitez généralement pas que votre gestionnaire rétablisse les tâches qu’il a déjà effectuées, par exemple créer une liste sur le site web hôte, et vous ne pouvez pas savoir si votre logique de restauration a été terminée, voire déclenchée, avant que le gestionnaire n’expire. Pour cette raison, votre logique de gestionnaire ne doit effectuer aucune action sans vérifier d’abord si l’action a déjà été effectuée, sauf s’il serait inoffensif de le faire à nouveau.
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ée » dans votre service web peut ralentir le gestionnaire. Votre logique d’installation et de restauration apporte généralement des modifications à un élément plus ou moins distant du service web, tel que le site web hôte SharePoint ou une base de données back-end. Si votre code d’installation et de restauration est fractionné entre les sections Try et Catch, le service effectue des appels distincts aux composants distants, souvent plusieurs appels de ce type dans chaque section.
La meilleure pratique consiste généralement à implémenter la logique d’installation et de restauration sur le composant distant lui-même dans une procédure qui peut être appelée à partir de votre gestionnaire dans votre section Try. La procédure doit retourner un message de réussite ou d’échec, et si elle signale un échec, le code de votre section Try appelle la section Catch (par exemple, lever une exception). La seule chose que fait la section Catch est de notifier SharePoint. Nous appellerons cela la stratégie de délégation du 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 permet pas de stocker du code côté serveur personnalisé sur SharePoint et de l’appeler à partir du modèle objet côté client (CSOM). Toutefois, le modèle CSOM fournit un moyen de regrouper la logique try-catch et if-then-else et de l’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, lorsque votre gestionnaire appelle plusieurs composants, tels qu’une base de données et le site web hôte SharePoint, il est possible que l’un se termine correctement et que l’autre échoue. Dans ce scénario, la logique de restauration du premier composant ne s’exécute pas si vous l’avez conçu avec la stratégie de délégation du gestionnaire. Pour cette raison, si vous appelez les composants de façon synchrone, seul le dernier appelé peut utiliser la stratégie de délégation du gestionnaire. S’ils sont appelés de façon asynchrone, vous ne pouvez utiliser cette stratégie dans aucune d’entre elles.
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, consultez la page SharePoint/PnP/Samples/Core.AppEvents.
Conseil
Si l’événement AppInstalled échoue, SharePoint supprime le site web du complément s’il en existe un ; et si l’événement AppUpated échoue, SharePoint restaure le site web du complément à son état de pré-mise à jour. Pour cette raison, vos gestionnaires n’ont jamais besoin de restaurer les actions qu’ils effectuent sur le site web du complément. Si votre gestionnaire effectue des actions sur le site web hôte et le site web de complément, il doit d’abord traiter le site web du complément. Cela permet d’utiliser en toute sécurité la stratégie de délégation de gestionnaire pour le site web hôte. Même si les actions web du complément réussissent et que les actions web de l’hôte échouent, aucune logique de restauration n’est annulée.
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. Pour en savoir plus, consultez l’article kb3135876 de la Base de connaissances relatif à l’impossibilité d’ajouter un complément hébergé par un fournisseur à un site SharePoint 2013 dans les zones non définies par défaut.
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).
SharePoint communique ensuite avec le service web inscrit. Vous pouvez effectuer certaines opérations (par exemple, mettre à jour une propriété d’élément de liste ou mettre à jour 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 distants 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 également utilisé 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 le port 443 pour HTTPS, ce que nous vous recommandons, ou le port 80 pour HTTP. Si vous utilisez HTTPS et que le service récepteur est hébergé localement, mais que le complément se trouve sur SharePoint Online, le serveur d’hébergement doit disposer d’un certificat approuvé publiquement par une autorité de certification. (Un certificat auto-signé fonctionne 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.