SharePoint et Event Handlers

Publié le par

Un SharePoint Event Receiver est un code custom (personnalisé) déployé au sein d’une assembly dans le GAC, héritant de l’une des implémentations de Microsoft.SharePoint.SPEventReceiverBase qui peuvent être attachés au webs (SPWebEventReceiver), les listes (SPListEventReceiver) et des éléments de liste (SPListItemEventReceiver) pour interagir sur des événements.

  • Utilisez les Event Receiver pour effectuer la validation des données, l’accès ou manipuler des données dans d’autres endroits tels que les bases de données, des Web services ou des listes SharePoint, convertir des documents ou lancer des workflows. Récepteurs d’événements permettent d’effectuer des opérations logiques supplémentaires et la validation des données.
  • Utilisez les fonctions événement pour recevoir un événement de création de web FeatureActivated. Bien qu’il existe plusieurs événements mis à disposition par le SPWebEventReceiver, la création de web doit être géré lorsque le web est provisionné (asynchronous !).
  • Utilisez les Event Receivers en collaboration avec des types de contenu. Event Receivers pour les listes et ListItems sont généralement liés à un type de contenu spécifique et peuvent être déclarative associées à un contenu en utilisant une feature pour le déploiement.
  • Ne pas utiliser des event receivers pour modifier les workflows. Les workflows ont leurs propres événements SharePoint et ceux-ci devraient être utilisés pour intercepter les item events.
  • Évitez les modifications apportées aux documents de l’élément à l’origine de l’événement. Bien que les propriétés d’un item peuvent être modifiées dans un événement synchrone, les modifications sur un document appartenant à un article sera en aucun cas provoquer un nouvel événement à être licenciés dès qu’ils sont enregistrés ou une erreur à cause du processus en cours.
  • Ne pas utiliser les event receivers comme un substitut des workflows. Alors que de nombreux Event Receivers ont été mis en place dans les versions précédentes de SharePoint pour fournir des capacités de workflow-like, un workflow ne doit être implémenté que en utilisant le Windows Workflow Foundation.
  • Évitez les event handlers dans les scénarios de déploiement de contenu SharePoint. Par défaut, les listeners ne se déclenchent pas lors du déploiement de contenu crée du contenu. Toutefois, si les event receivers doivent être tiré lors de l’importation, vous pouvez définir la propriété SuppressAfterEvents à false. Lorsque cette option est activée, vous pouvez rencontrer une perte significative des performances, mais toutes les exigences spécifiées dans l’importation sont reçus

    • En plus de l’évidence que les événements synchrones se produisent avant un changement événements engagés et asynchrone seulement après, il est important de comprendre que :
    – Les événements synchrones peuvent être annulées tandis que les asynchrones ont déjà eu lieu.
    – Les événements synchrones bloquent l’exécution du code, les événements asynchrones pas dutout – ils sont lancés dans un leur propre thread
    – Les événements synchrones sont garantis d’être remis lorsque l’action se déroule, les événements asynchrones peuvent avoir un retard en fonction de nombreux facteurs qui ne sont pas contrôlables.

    Best practices pour les événements synchrones :
    – Une validation de données peut entraîner une annulation. Valider les entrées utilisateur contre les règles métier et de fournir un message d’erreur approprié si la validation échoue.
    – L’information complète si nécessaire pour un traitement ultérieur par exemple par des workflows, After-Event Handlers etc.
    – Assurer les transactions. Exécuter des data transactions liées à la cohérence.
    – Gardez le temps d’exécution le plus court possible. Évitez les long opération d’accès de données, etc
    – Ne pas démarrer les processus qui dépendent d’un list item. Dans les Before-Events, l’action n’est pas encore terminée et il n’est pas garanti qu’un worflow ou tout autre procédé le trouveront lors de son lancement.
    – Ne pas mettre à jour les informations dans d’autres listes ou systèmes. Ce n’est pas extensible et peut dégrader considérablement les performances.

    Best practices pour les événements asynchrones :
    – Compléter l’information. Informations supplémentaires qui nécessitent des processus plus vastes pour être assemblés (queries, lookups to databases etc.) peut être ajouté aux métadonnées de l’objet. Cependant, les événements circulaires doivent être évités car le même event handler peut se déclencher à nouveau après le changement.
    – Commencez les procédés et les actions supplémentaires. D’autres actions telles que la manipulation d’autres listes, des conversions de documents / pièces jointes et les workflows de départ doivent être effectués en After-Events.
    – Ne pas valider. Les données de l’objet qui déclenche l’événement doivent déjà être dans un état valide, puisque l’événement se déclenche avec un retard et l’action de l’objet a déjà été exécuté.
    – Ne pas faire les mises à jour transactionnelles. Depuis l’opération qui a déclenché l’événement a déjà eu lieu, la cohérence des transactions ne peut plus être garantie.
    – Évitez les événements circulaires. Manipulation sur l’objet courant peut conduire à de nouveaux events firing. Également d’autres actions exécutées par un utilisateur ou automatisés peuvent déclencher des événements en même temps. Mettre en place des verrous sur les sections critiques.

    Best practices pour développer et déployer Event Receivers :

    – Gérer des événements isolés les uns des autres. Même si différents types d’événements peuvent utiliser les mêmes helper fonctions, pas d’objets doivent être stockés dans des variables membres. Chaque événement doit être examiné à l’échelle atomique avec toutes les informations nécessaires passé à l’aide des propriétés de l’événement.
    – Mettre en Å“uvre la gestion des erreurs appropriée pour tous les cas possibles avec le logging, éviter de bloquer les worker process avec des erreurs qui peuvent conduire à une dégradation significative des performances, en particulier dans la gestion des événements synchrones.
    РDisposer correctement toutes les ressources, mais ne disposer pas les objets pass̩s dans les propri̩t̩s.
    – Fournir un message sur une annulation. Informer les utilisateurs pourquoi l’annulation a eu lieu.
    – Déployer des event receivers comme une feature. C’est le mécanisme le plus facile, non seulement pour le déploiement, mais aussi pour l’association à un site Web, une liste ou appartenant à un type de contenu. Bundle event receivers dans la même feature comme types de contenu personnalisés ou des définitions de la liste, ou utiliser la fonction de dépendance en cas de déploiement à un stade ultérieur.

    Laisser un commentaire