Conseils sur la journalisation du service ULS - 2ème partie

Dans la première partie du billet de blog « Conseils sur la journalisation du service ULS » (http://blogs.msdn.com/b/sharepoint_fr/archive/2011/03/21/conseils-sur-la-journalisation-du-service-uls.aspx), j’ai inséré du code afin d’ajouter une Zone de journalisation ULS personnalisée et j’ai expliqué comment l’utiliser dans votre projet.  Après avoir travaillé dessus, j’ai remarqué quelques petites choses :

1.       Certaines portions de code indiquées dans le dernier SDK étaient un peu fantaisistes, notamment des parties implémentées dont, d’après le Kit, je n’aurais pas besoin. Par ailleurs, il y a des choses que je ne faisais pas tout à fait comme dans l’exemple (celui-ci a d’ailleurs besoin d’une mise à jour, ce que je ferai mais dans un autre blog).

2.       La journalisation ne se produisait que lorsque j’attribuais au paramètre TraceSeverity la valeur Moyenne ; il n’y avait pas de moyen efficace de sélectionner d’autres niveaux de suivi.

3.       Le point le plus ennuyeux, lorsque j’essayais d’invoquer ma classe personnalisée requise pour ma Zone personnalisée, c’est que les tâches de journalisation que je tentais d’effectuer au cours d’une activité POST échouaient.  Une erreur courante se déclenchait, à savoir que je ne pouvais pas mettre à jour un objet SPWeb au cours d’une activité POST, à moins de définir la propriété AllowUnsafeUpdates sur true.  Maintenant, créer ce paramétrage sur un objet SPWeb uniquement pour faire fonctionner mon événement de journal semblait limite.  Il devait exister une méthode plus efficace.

Dans ce billet de blog, je vais m’employer à améliorer l’exemple décrit dans la première partie.  Voici ce que je vais vous montrer :

1.       Une classe améliorée pour la Zone personnalisée, qui est un peu légère dans cette version.

2.       L’intégration avec l’option Configurer la journalisation des diagnostics dans la section Analyse de l’Administration centrale.  Cette intégration permettra plus tard la prise en charge de la configuration des niveaux de suivi pour la Zone et la Catégorie personnalisées.

3.       Les informations d’inscription, un moyen très simple d’inscrire et de désinscrire la classe de journalisation ULS personnalisée pour l’intégrer à l’Administration centrale ou l’en retirer.

Commençons par examiner la nouvelle version rationalisée de la classe.  Il existe beaucoup de similitudes entre cette version et celle du premier billet de blog, mais la nouvelle version a été allégée et simplifiée.  Elle ressemble à présent à ceci :

    [Guid("833B687D-0DD1-4F17-BF6A-B64FBC1AC6A8")]

    public class SteveDiagnosticService : SPDiagnosticsServiceBase

    {

 

        private const string LOG_AREA = "Steve Area";

 

 

        public enum LogCategories

        {

            SteveCategory

        }  

 

 

        public SteveDiagnosticService()

        {

        } 

 

 

        public SteveDiagnosticService(string name, SPFarm parent)

            : base(name, parent)

        {

        } 

 

 

        public static SteveDiagnosticService Local

        {

            get

            {

                return SPDiagnosticsServiceBase.GetLocal<SteveDiagnosticService>();

            }

        }  

 

 

 

        public void LogMessage(ushort id, LogCategories LogCategory,

TraceSeverity traceSeverity, string message,

params object[] data)

        {

 

            if (traceSeverity != TraceSeverity.None)

            {

                SPDiagnosticsCategory category

                 = Local.Areas[LOG_AREA].Categories[LogCategory.ToString()];

                Local.WriteTrace(id, category, traceSeverity, message, data);

            }

 

        }

 

 

        protected override IEnumerable<SPDiagnosticsArea> ProvideAreas()

        {

yield return new SPDiagnosticsArea(LOG_AREA, 0, 0, false,

new List<SPDiagnosticsCategory>()

{

new

SPDiagnosticsCategory(LogCategories.AzureConfig.ToString(),

                     TraceSeverity.Medium, EventSeverity.Information, 1,

                     Log.LOG_ID)

                     });

        }

    }

 

Voici les informations les plus importantes par rapport à la première version :

1.        L’attribut Guid a été ajouté à la classe :

[Guid("833B687D-0DD1-4F17-BF6A-B64FBC1AC6A8")]

 

J’ai ajouté un attribut Guid à la classe car SharePoint en avait besoin pour identifier celle-ci de façon unique dans la base de données de configuration.

2.       Le constructeur par défaut a été modifié :

        public SteveDiagnosticService()

        {

        } 

 

À présent, ce n’est plus qu’un constructeur standard vide.  Auparavant, j’appelais l’autre surcharge pour le constructeur qui prend un nom pour le service et un SPFarm.  En fait, il y a juste moins de code, ce qui est une bonne chose.

3.       La substitution de HasAdditionalUpdateAccess a été supprimée.  Comme je n’utilisais pas vraiment cette fonction, je l’ai retirée.

 

4.       La méthode ProvideAreas a été raccourcie de manière significative ; à présent, elle correspond au modèle utilisé dans le SDK :

 

yield return new SPDiagnosticsArea(LOG_AREA, 0, 0, false,

new List<SPDiagnosticsCategory>()

{

new

SPDiagnosticsCategory(LogCategories.AzureConfig.ToString(),

                     TraceSeverity.Medium, EventSeverity.Information, 1,

                     Log.LOG_ID)

                     });

Bon, le premier problème indiqué plus haut est résolu : mon code est plus propre et plus simple.  Les autres problèmes - absence de niveaux de suivi, déclenchement d’une exception lors de la journalisation pendant une activité POST et intégration avec l’Administration centrale - ont été en grande partie résolus par le développement du code et l’inscription.  L’exemple du SDK est à ce niveau un peu faible mais j’ai tout de même pu faire ce que je voulais faire.  Pour simplifier les problèmes, j’ai créé une nouvelle fonctionnalité pour mon assembly, qui contient ma classe ULS personnalisée décrite plus haut.  J’ai ajouté un récepteur de fonctionnalité, j’ai inscrit l’assembly ULS personnalisé pendant l’événement FeatureInstalled et je l’ai désinscrit pendant l’événement FeatureUninstalling.  Cette solution a été la bonne dans mon cas car elle m’a permis d’étendre ma fonctionnalité à la batterie de serveurs. De ce fait, celle-ci s’active automatiquement lorsque la solution est ajoutée et déployée.  Le code qui permet d’effectuer cette inscription et cette désinscription est terriblement simple. Jugez-en par vous-même :

public override void FeatureInstalled(SPFeatureReceiverProperties properties)

{

try

       {

SteveDiagnosticsService.Local.Update();

}

catch (Exception ex)

       {

throw new Exception("Error installing feature: " + ex.Message);

}

}

 

 

public override void FeatureUninstalling(SPFeatureReceiverProperties properties)

{

try

       {

SteveDiagnosticsService.Local.Delete();

}

catch (Exception ex)

{

throw new Exception("Error uninstalling feature: " + ex.Message);

}

}

 

L’autre point à signaler est que j’ai pu faire référence à "SteveDiagnosticService" car a) j’ai ajouté une référence à l’assembly avec ma classe de journalisation personnalisée dans le projet dans lequel j’ai conditionné la fonctionnalité et b) j’ai ajouté une instruction d’utilisation à ma classe de récepteur de fonctionnalité pour l’assembly avec ma classe de journalisation personnalisée.

L’inscription de ma classe de journalisation ULS personnalisée a été bénéfique sur bien des points :

·         Je n’ai plus d’erreurs sur la mise à jour de l’objet SPWeb lorsque j’écris dans le journal ULS au cours d’une activité POST.

·         Ma Zone et ma Catégorie de journalisation personnalisées s’affichent dans l’Administration centrale, ce qui me permet d’aller dans l’option Configurer la journalisation des diagnostics et de modifier le niveau de suivi et d’événement.  Par exemple, lorsque le niveau de suivi Moyen (valeur par défaut) est défini, toutes les entrées du service ULS de type TracingSeverity.Medium sont écrites dans le journal, mais pas celles de type TracingSeverity.Verbose.  Pour que les entrées TracingSeverity.Verbose soient journalisées, il me suffit d’aller dans l’option Configurer la journalisation des diagnostics et de remplacer le niveau de suivi défini par Détaillé.

Dans l’ensemble, la solution est plus simple et plus fonctionnelle.  J’espère qu’elle vous donnera satisfaction.

PS : Je souhaite émettre un vote de protestation à propos de LaMarcus Aldridge des Trail Blazers de Portland. Sa blessure qui l'a empêché de rejoindre l'équipe Western Conference NBA All Star est un événement vraiment très triste. Mais trève de commentaires personnels. Je sais qu'en venant sur ce blog, vous recherchez des infos Dipity à partager. J'espère sincèrement qu'elles vous seront utiles.

Ce billet de blog a été traduit de l’anglais. L’article d’origine est disponible à la page Tips for ULS Logging Part 2