Del via

TripPin del 8 – Tilføjelse af diagnosticering

  • Artikel

Bemærk

Dette indhold refererer i øjeblikket til indhold fra en ældre implementering til diagnosticering i Visual Studio. Indholdet opdateres i den nærmeste fremtid, så det dækker det nye Power Query SDK i Visual Studio Code.

Dette selvstudium i flere dele dækker oprettelsen af en ny datakildeudvidelse til Power Query. Selvstudiet er beregnet til at blive udført sekventielt – hver lektion bygger på den connector, der blev oprettet i tidligere lektioner, og føjer trinvist nye funktioner til din connector.

I denne lektion skal du:

  • Få mere at vide om funktionen Diagnostics.Trace
  • Brug hjælpefunktionerne til diagnosticering til at tilføje sporingsoplysninger som en hjælp til fejlfinding af din connector

Aktivering af diagnosticering

Brugere af Power Query kan aktivere sporingslogføring ved at markere afkrydsningsfeltet under Indstillinger | Diagnosticering.

Aktivér sporing i Power Query.

Når indstillingen er aktiveret, medfører alle efterfølgende forespørgsler, at M-programmet sender sporingsoplysninger til logfiler, der er placeret i en fast brugermappe.

Når du kører M-forespørgsler fra Power Query SDK, aktiveres sporing på projektniveau. På siden med projektegenskaber er der tre indstillinger relateret til sporing:

  • Ryd log – når dette er angivet til true, nulstilles loggen/ryddes, når du kører dine forespørgsler. Vi anbefaler, at du beholder dette sæt til true.
  • Vis programsporinger – denne indstilling styrer outputtet af indbyggede sporinger fra M-programmet. Disse sporinger er kun nyttige for medlemmer af Power Query-teamet, så du vil typisk beholde dette sæt til false.
  • Vis brugersporinger – denne indstilling styrer outputtet af sporingsoplysninger fra din connector. Du skal angive dette til true.

Projektegenskaber.

Når indstillingen er aktiveret, får du vist logposter i vinduet M-forespørgselsoutput under fanen Log.

Diagnostics.Trace

Funktionen Diagnostics.Trace bruges til at skrive meddelelser til M-programmets sporingslog.

Diagnostics.Trace = (traceLevel as number, message as text, value as any, optional delayed as nullable logical as any) => ...

Vigtigt

M er et funktionelt sprog med doven evaluering. Når du bruger Diagnostics.Trace, skal du være opmærksom på, at funktionen kun kaldes, hvis det udtryk, den er en del af, faktisk evalueres. Eksempler på dette kan findes senere i dette selvstudium.

Parameteren traceLevel kan være en af følgende værdier (i faldende rækkefølge):

  • TraceLevel.Critical
  • TraceLevel.Error
  • TraceLevel.Warning
  • TraceLevel.Information
  • TraceLevel.Verbose

Når sporing er aktiveret, kan brugeren vælge det maksimale niveau af meddelelser, vedkommende vil se. Alle sporingsmeddelelser på dette niveau og under sendes til logfilen. Hvis brugeren f.eks. vælger niveauet "Advarsel", vil sporingsmeddelelserne for TraceLevel.Warning, TraceLevel.Errorog TraceLevel.Critical blive vist i loggene.

Parameteren message er den faktiske tekst, der sendes til sporingsfilen. Teksten indeholder value ikke parameteren, medmindre du eksplicit inkluderer den i teksten.

Parameteren value er det, som funktionen returnerer. Når parameteren delayed er angivet til true, value er det en parameterfunktion på nul, der returnerer den faktiske værdi, du evaluerer. Når delayed er angivet til false, value er den faktiske værdi. Du kan finde et eksempel på, hvordan dette fungerer, nedenfor.

Ved hjælp af Diagnosticering. Spor i TripPin-connectoren

Hvis du vil have et praktisk eksempel på brug af Diagnostics.Trace og virkningen af delayed parameteren, skal du opdatere TripPin-connectorens GetSchemaForEntity funktion for at ombryde error undtagelsen:

GetSchemaForEntity = (entity as text) as type =>
    try
        SchemaTable{[Entity=entity]}[Type]
    otherwise
        let
            message = Text.Format("Couldn't find entity: '#{0}'", {entity})
        in
            Diagnostics.Trace(TraceLevel.Error, message, () => error message, true);

Du kan gennemtvinge en fejl under evalueringen (til testformål!) ved at overføre et ugyldigt enhedsnavn til funktionen GetEntity . Her kan du ændre linjen withData i funktionen TripPinNavTable og erstatte [Name] med "DoesNotExist".

TripPinNavTable = (url as text) as table =>
    let
        // Use our schema table as the source of top level items in the navigation tree
        entities = Table.SelectColumns(SchemaTable, {"Entity"}),
        rename = Table.RenameColumns(entities, {{"Entity", "Name"}}),
        // Add Data as a calculated column
        withData = Table.AddColumn(rename, "Data", each GetEntity(url, "DoesNotExist"), type table),
        // Add ItemKind and ItemName as fixed text values
        withItemKind = Table.AddColumn(withData, "ItemKind", each "Table", type text),
        withItemName = Table.AddColumn(withItemKind, "ItemName", each "Table", type text),
        // Indicate that the node should not be expandable
        withIsLeaf = Table.AddColumn(withItemName, "IsLeaf", each true, type logical),
        // Generate the nav table
        navTable = Table.ToNavigationTable(withIsLeaf, {"Name"}, "Name", "Data", "ItemKind", "ItemName", "IsLeaf")
    in
        navTable;

Aktivér sporing for dit projekt, og kør dine testforespørgsler. Under fanen Errors kan du se teksten til den fejl, du har udløst:

Fejlmeddelelse.

Under fanen Log kan du også se den samme meddelelse. Hvis du bruger forskellige værdier for parametrene message og value , vil disse være forskellige.

Fejllog.

Bemærk også, at feltet Action i logmeddelelsen indeholder navnet (Datakildetype) for filtypenavnet (i dette tilfælde Engine/Extension/TripPin). Det gør det nemmere at finde de meddelelser, der er relateret til din udvidelse, når der er flere involverede forespørgsler, og/eller sporing af system (miksmaskine) er aktiveret.

Forsinket evaluering

Som et eksempel på, hvordan delayed parameteren fungerer, skal du foretage nogle ændringer og køre forespørgslerne igen.

Angiv først værdien delayed til false, men lad parameteren være value som den er:

Diagnostics.Trace(TraceLevel.Error, message, () => error message, false);

Når du kører forespørgslen, får du vist en fejl om, at "Vi kan ikke konvertere en værdi af typen Funktion til type", og ikke den faktiske fejl, du har udløst. Det skyldes, at kaldet nu returnerer en function værdi i stedet for selve værdien.

Fjern derefter funktionen fra value parameteren:

Diagnostics.Trace(TraceLevel.Error, message, error message, false);

Når du kører forespørgslen, får du vist den korrekte fejl, men hvis du markerer fanen Log , vil der ikke være nogen meddelelser. Det skyldes, at det error ender med at blive opløftet/evalueret under opkaldet til Diagnostics.Trace, så meddelelsen faktisk aldrig sendes.

Nu, hvor du forstår virkningen af delayed parameteren, skal du sørge for at nulstille connectoren tilbage til en arbejdstilstand, før du fortsætter.

Diagnosticeringshjælpefunktioner i Diagnostics.pqm

Filen Diagnostics.pqm , der er inkluderet i dette projekt, indeholder mange hjælpefunktioner, der gør sporing nemmere. Som vist i det forrige selvstudium kan du inkludere denne fil i projektet (huske at angive handlingen Opret til Kompiler) og derefter indlæse den i din connectorfil. Nederst i connectorfilen skal det nu ligne kodestykket nedenfor. Du er velkommen til at udforske de forskellige funktioner, dette modul indeholder, men i dette eksempel bruger Diagnostics.LogValue du kun funktionerne og Diagnostics.LogFailure .

// Diagnostics module contains multiple functions. We can take the ones we need.
Diagnostics = Extension.LoadFunction("Diagnostics.pqm");
Diagnostics.LogValue = Diagnostics[LogValue];
Diagnostics.LogFailure = Diagnostics[LogFailure];

Diagnostics.LogValue

Funktionen Diagnostics.LogValue minder meget om Diagnostics.Trace, og den kan bruges til at angive værdien af det, du evaluerer.

Diagnostics.LogValue = (prefix as text, value as any) as any => ...

Parameteren prefix er forudforberedt til logmeddelelsen. Du skal bruge dette til at finde ud af, hvilket kald der skriver meddelelsen. Parameteren value er det, som funktionen returnerer, og den skrives også til sporingen som en tekstrepræsentation af M-værdien. Hvis value f.eks. er lig med med table kolonnerne A og B, indeholder logfilen den tilsvarende #table repræsentation: #table({"A", "B"}, {{"row1 A", "row1 B"}, {"row2 A", row2 B"}})

Bemærk

Serialisering af M-værdier til tekst kan være en dyr handling. Vær opmærksom på den potentielle størrelse af de værdier, du skriver til sporingen.

Bemærk

De fleste Power Query-miljøer afkorter sporingsmeddelelser til en maksimal længde.

Du skal f.eks. opdatere funktionen TripPin.Feed for at spore de argumenter og schema , der url overføres til funktionen .

TripPin.Feed = (url as text, optional schema as type) as table =>
    let
        _url = Diagnostics.LogValue("Accessing url", url),
        _schema = Diagnostics.LogValue("Schema type", schema),
        //result = GetAllPagesByNextLink(url, schema)
        result = GetAllPagesByNextLink(_url, _schema)
    in
        result;

Du skal bruge de nye _url værdier og _schema i kaldet til GetAllPagesByNextLink. Hvis du brugte de oprindelige funktionsparametre, Diagnostics.LogValue evalueres kald aldrig, hvilket medfører, at der ikke skrives nogen meddelelser til sporingen. Funktionel programmering er sjovt!

Når du kører dine forespørgsler, kan du nu se nye meddelelser i logfilen.

Adgang til URL-adresse:

Adgang til URL-meddelelse.

Skematype:

Skematypemeddelelse.

Du kan se den serialiserede version af schema parameteren typei stedet for det, du får, når du gør en simpel Text.FromValue på en typeværdi (hvilket resulterer i "type").

Diagnostics.LogFailure

Funktionen Diagnostics.LogFailure kan bruges til at ombryde funktionskald og skriver kun til sporingen, hvis funktionskaldet mislykkes (dvs. returnerer en error).

Diagnostics.LogFailure = (text as text, function as function) as any => ...

Diagnostics.LogFailure Føjer en try operator til opkaldet function internt. Hvis kaldet mislykkes, skrives text værdien til sporingen, før den oprindelige errorreturneres. Hvis kaldet function lykkes, returneres resultatet uden at skrive noget til sporingen. Da M-fejl ikke indeholder en fuld staksporing (dvs. du får normalt kun vist meddelelsen om fejlen), kan det være nyttigt, når du vil finde ud af, hvor fejlen blev udløst.

Som et (dårligt) eksempel skal du ændre withData funktionens TripPinNavTable linje for at gennemtvinge en fejl igen:

withData = Table.AddColumn(rename, "Data", each Diagnostics.LogFailure("Error in GetEntity", () => GetEntity(url, "DoesNotExist")), type table),

I sporingen kan du finde den resulterende fejlmeddelelse, der indeholder dine text, og de oprindelige fejloplysninger.

LogFailure-meddelelse.

Sørg for at nulstille din funktion til en arbejdstilstand, før du fortsætter med det næste selvstudium.

Konklusion

Denne korte (men vigtige!) lektion viste dig, hvordan du bruger diagnosticeringshjælpefunktionerne til at logge på Power Query-sporingsfilerne. Når disse funktioner bruges korrekt, er de nyttige til fejlfinding af problemer i din connector.

Bemærk

Som connectorudvikler er det dit ansvar at sikre, at du ikke logfører følsomme eller personligt identificerbare oplysninger som en del af logføringen af diagnosticering. Du skal også være forsigtig med ikke at sende for mange sporingsoplysninger, da det kan have en negativ indvirkning på ydeevnen.

Næste trin

TripPin Del 9 - Test Forbind ion