Dela via

TripPin del 8 – Lägga till diagnostik

  • Artikel

Kommentar

Det här innehållet refererar för närvarande till innehåll från en äldre implementering för diagnostik i Visual Studio. Innehållet kommer att uppdateras inom en snar framtid för att täcka den nya Power Query SDK:n i Visual Studio Code.

Den här självstudien i flera delar beskriver hur du skapar ett nytt datakällans tillägg för Power Query. Självstudien är avsedd att utföras sekventiellt – varje lektion bygger på anslutningsappen som skapades i föregående lektioner och lägger stegvis till nya funktioner i anslutningsappen.

I den här lektionen kommer du att:

  • Läs mer om funktionen Diagnostics.Trace
  • Använd diagnostikhjälpfunktionerna för att lägga till spårningsinformation för att felsöka anslutningsappen

Aktivera diagnostik

Power Query-användare kan aktivera spårningsloggning genom att markera kryssrutan under Alternativ | Diagnostik.

Aktivera spårning i Power Query.

När de här frågorna har aktiverats kommer M-motorn att generera spårningsinformation för att logga filer som finns i en fast användarkatalog.

När du kör M-frågor inifrån Power Query SDK aktiveras spårning på projektnivå. På sidan projektegenskaper finns det tre inställningar som rör spårning:

  • Rensa logg – när detta är inställt på trueåterställs/rensas loggen när du kör dina frågor. Vi rekommenderar att du behåller den här inställningen till true.
  • Visa motorspårningar – den här inställningen styr utdata från inbyggda spårningar från M-motorn. Dessa spårningar är bara användbara för medlemmar i Power Query-teamet, så du vill vanligtvis behålla den här inställningen till false.
  • Visa användarspårningar – den här inställningen styr spårningsinformationens utdata från anslutningsappen. Du vill ange detta till true.

Projektegenskaper.

När du är aktiverad börjar du se loggposter i fönstret M Query Output (M Query-utdata) under fliken Logg.

Diagnostics.Trace

Funktionen Diagnostics.Trace används för att skriva meddelanden till M-motorns spårningslogg.

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

Viktigt!

M är ett funktionellt språk med lat utvärdering. När du använder Diagnostics.Traceska du tänka på att funktionen bara anropas om uttrycket det ingår i faktiskt utvärderas. Exempel på detta finns senare i den här självstudien.

Parametern traceLevel kan vara ett av följande värden (i fallande ordning):

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

När spårning är aktiverat kan användaren välja den maximala nivån av meddelanden som de vill se. Alla spårningsmeddelanden på den här nivån och under kommer att matas ut till loggen. Om användaren till exempel väljer nivån "Varning" spårar du meddelanden för TraceLevel.Warning, TraceLevel.Erroroch TraceLevel.Critical visas i loggarna.

Parametern message är den faktiska text som ska matas ut till spårningsfilen. Texten innehåller inte parametern value om du inte uttryckligen inkluderar den i texten.

Parametern value är vad funktionen returnerar. När parametern delayed är inställd på trueär value den en nollparameterfunktion som returnerar det faktiska värde som du utvärderar. När delayed är inställt på falseär value det faktiska värdet. Ett exempel på hur detta fungerar finns nedan.

Använda diagnostik. Spåra i TripPin-anslutningsappen

Om du vill ha ett praktiskt exempel på hur du använder Diagnostics.Trace och effekten av parametern delayed uppdaterar du TripPin-anslutningsappens GetSchemaForEntity funktion för att omsluta error undantaget:

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 framtvinga ett fel under utvärderingen (i testsyfte!) genom att skicka ett ogiltigt entitetsnamn till GetEntity funktionen. Här ändrar withData du raden i TripPinNavTable funktionen och ersätter [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;

Aktivera spårning för projektet och kör testfrågorna. På fliken Errors bör du se texten för det fel som du har genererat:

Felmeddelande.

På fliken Log bör du också se samma meddelande. Om du använder olika värden för parametrarna message och value skulle dessa vara olika.

Fellogg.

Observera också att fältet Action i loggmeddelandet innehåller namnet (Typ av datakälla) för tillägget (i det här fallet Engine/Extension/TripPin). Detta gör det enklare att hitta meddelanden som är relaterade till ditt tillägg när det finns flera frågor som berörs och/eller systemspårning (kombinationsmotor) är aktiverat.

Fördröjd utvärdering

Som ett exempel på hur parametern delayed fungerar gör du några ändringar och kör frågorna igen.

delayed Ange först värdet till false, men lämna parametern value som den är:

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

När du kör frågan får du ett felmeddelande om att "Vi kan inte konvertera ett värde av typen Funktion till typ", och inte det faktiska felet som du har genererat. Det beror på att anropet nu returnerar ett function värde i stället för själva värdet.

Ta sedan bort funktionen från parametern value :

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

När du kör frågan får du rätt fel, men om du markerar fliken Logg visas inga meddelanden. Det beror på att det slutar med att upphöjs error /utvärderas under anropet till Diagnostics.Trace, så meddelandet matas aldrig ut.

Nu när du förstår effekten av parametern måste du återställa anslutningsappen delayed till ett fungerande tillstånd innan du fortsätter.

Diagnostikhjälpfunktioner i Diagnostics.pqm

Filen Diagnostics.pqm som ingår i det här projektet innehåller många hjälpfunktioner som gör spårning enklare. Som du ser i den föregående självstudien kan du inkludera den här filen i projektet (kom ihåg att ställa in kompileringsåtgärden på Kompilera) och sedan läsa in den i anslutningsfilen. Längst ned i anslutningsfilen bör nu se ut ungefär som kodfragmentet nedan. Utforska gärna de olika funktionerna i den här modulen, men i det här exemplet använder Diagnostics.LogValue du bara funktionerna och 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 liknar , Diagnostics.Traceoch kan användas för att mata ut värdet för det du utvärderar.

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

Parametern prefix läggs till i loggmeddelandet. Du använder detta för att ta reda på vilket anrop som matar ut meddelandet. Parametern value är vad funktionen returnerar och skrivs även till spårningen som en textrepresentation av M-värdet. Om value till exempel är lika med en table med kolumnerna A och B innehåller loggen motsvarande #table representation: #table({"A", "B"}, {{"row1 A", "row1 B"}, {"row2 A", row2 B"}})

Kommentar

Serialisering av M-värden till text kan vara en dyr åtgärd. Tänk på den potentiella storleken på de värden som du matar ut till spårningen.

Kommentar

De flesta Power Query-miljöer trunkerar spårningsmeddelanden till en maximal längd.

Som ett exempel uppdaterar TripPin.Feed du funktionen för att spåra argumenten url och schema som skickas till 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 måste använda de nya _url värdena och _schema i anropet till GetAllPagesByNextLink. Om du använde de ursprungliga funktionsparametrarna skulle anropen Diagnostics.LogValue aldrig utvärderas, vilket resulterade i att inga meddelanden skrevs till spårningen. Funktionell programmering är roligt!

När du kör dina frågor bör du nu se nya meddelanden i loggen.

Åtkomst till URL:

Åtkomst till URL-meddelande.

Schematyp:

Schematypmeddelande.

Du ser den serialiserade versionen av parametern schema typei stället för vad du skulle få när du gör ett enkelt Text.FromValue typvärde (vilket resulterar i "typ").

Diagnostics.LogFailure

Funktionen Diagnostics.LogFailure kan användas för att omsluta funktionsanrop och skriver bara till spårningen om funktionsanropet misslyckas (det vill säga returnerar en error).

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

Diagnostics.LogFailure Internt lägger du till en try operatör i anropetfunction. Om anropet misslyckas skrivs text värdet till spårningen innan det ursprungliga errorreturneras. Om anropet function lyckas returneras resultatet utan att något skrivs till spårningen. Eftersom M-fel inte innehåller en fullständig stackspårning (det vill säga att du vanligtvis bara ser meddelandet om felet) kan detta vara användbart när du vill fastställa var felet uppstod.

Som ett (dåligt) exempel ändrar du withData funktionens TripPinNavTable rad för att framtvinga ett fel igen:

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

I spårningen hittar du det resulterande felmeddelandet som innehåller din text, och den ursprungliga felinformationen.

LogFailure-meddelande.

Se till att återställa funktionen till ett fungerande tillstånd innan du fortsätter med nästa självstudie.

Slutsats

Den här korta lektionen (men viktigt!) visade hur du använder diagnostikhjälpfunktionerna för att logga in på Power Query-spårningsfilerna. När de används korrekt är dessa funktioner användbara vid felsökning av problem i anslutningsappen.

Kommentar

Som anslutningsutvecklare är det ditt ansvar att se till att du inte loggar känslig eller personligt identifierbar information (PII) som en del av din diagnostikloggning. Du måste också vara noga med att inte mata ut för mycket spårningsinformation, eftersom det kan ha en negativ prestandapåverkan.

Nästa steg

TripPin del 9 - Test Anslut ion