Ansluta till SAP HANA-datakällor med hjälp av DirectQuery i Power BI
Du kan ansluta till SAP HANA-datakällor direkt med DirectQuery. Det finns två alternativ när du ansluter till SAP HANA:
Behandla SAP HANA som en flerdimensionell källa (standard): I det här fallet liknar beteendet när Power BI ansluter till andra flerdimensionella källor som SAP Business Warehouse eller Analysis Services. När du ansluter till SAP HANA med den här inställningen väljs en enda analys- eller beräkningsvy, och alla åtgärder, hierarkier och attribut för den vyn blir tillgängliga i fältlistan. Då visuell information skapas, kommer sammanställda data alltid att hämtas från SAP HANA. Det är den rekommenderade metoden och är standard för nya DirectQuery-rapporter över SAP HANA.
Behandla SAP HANA som en relationskälla: I det här fallet behandlar Power BI SAP HANA som en relationskälla. Detta ger större flexibilitet. Med den här metoden bör du se till att åtgärder aggregeras som förväntat och så att prestandaproblem undviks.
Anslutningsmetoden bestäms av ett globalt verktygsalternativ, som anges genom att välja Filalternativ > och inställningar och sedan Alternativ > DirectQuery och sedan välja alternativet Behandla SAP HANA som relationskälla, enligt följande bild.
Alternativet att behandla SAP HANA som en relationskälla styr den metod som används för alla nya rapporter med DirectQuery över SAP HANA. Det har ingen effekt på några befintliga SAP HANA-anslutningar i den aktuella rapporten eller på anslutningar i andra rapporter som är öppna. Om alternativet för närvarande är avmarkerat gör tillägget av en ny anslutning till SAP HANA med hjälp av Hämta data att anslutningen behandlar SAP HANA som en flerdimensionell källa. Men om en annan rapport öppnas som också ansluter till SAP HANA kommer den rapporten att fortsätta bete sig enligt det alternativ som angavs när den skapades, vilket innebär att alla rapporter som ansluter till SAP HANA som skapades före februari 2018 fortsätter att behandla SAP HANA som en relationskälla.
De två metoderna utgörs av olika beteenden, och det går inte att växla en befintlig rapport från en metod till den andra.
Nu ska vi titta på mer information om dessa två metoder var för sig.
Hantera SAP HANA som en flerdimensionell källa (standard)
För alla nya anslutningar till SAP HANA används den här anslutningsmetoden som standard, och SAP HANA behandlas som en flerdimensionell källa. För att kunna behandla en anslutning till SAP HANA som en relationskälla måste du välja Filalternativ > och inställningar > Alternativ och sedan markera kryssrutan under Direct Query > Treat SAP HANA as a relational source (Behandla SAP HANA som en relationskälla). När den här funktionen är i Förhandsgranskning, kan inte rapporter som skapas med den flerdimensionella metoden publiceras till Power BI-tjänsten vilket leder till fel när rapporten öppnas i Power BI-tjänsten.
Vid anslutning till SAP HANA som en flerdimensionell källa gäller följande överväganden:
I Hämta datanavigatör kan en enda SAP HANA-vy väljas. Det går inte att välja enskilda åtgärder eller attribut. Det finns ingen fråga definierad vid tidpunkten för anslutning, vilket skiljer sig från att importera data eller när du använder DirectQuery när du behandlar SAP HANA som en relationskälla. Det innebär även att det inte går att använda en SAP HANA SQL-fråga direkt när du väljer den här anslutningsmetoden.
Alla åtgärder, hierarkier och attribut för den valda vyn kommer att visas i listan.
Då ett mått används i en visualisering efterfrågas SAP HANA om att hämta måttvärdet på den aggregeringsnivå som krävs för visualiseringen. Så när du hanterar icke-additiva mått (räknare, kvoter och så vidare) utförs alla aggregeringar av SAP HANA, och ingen ytterligare aggregering utförs av Power BI.
Vissa begränsningar måste införas för att säkerställa att rätt aggregeringsvärden alltid kan hämtas från SAP HANA. T.ex. går det inte att lägga till beräknade kolumner eller kombinera data från flera SAP HANA-vyer i samma rapport.
Att behandla SAP HANA som en flerdimensionell källa ger inte den större flexibilitet som tillhandahålls av relationsmetoden, men det är enklare och säkerställer rätt aggregeringsvärden när du hanterar mer komplexa SAP HANA-åtgärder och ger vanligtvis bättre prestanda.
Listan Fält kommer att innehålla alla åtgärder, attribut och hierarkier från SAP HANA-vyn. Observera följande beteenden som gäller när du använder den här anslutningsmetoden:
Alla attribut som ingår i minst en hierarki döljs som standard. Dock kan du se dem om det behövs genom att välja Visa dolda på snabbmenyn i fältlistan. På samma snabbmenyn kan de göras synliga, om det behövs.
I SAP HANA kan du definiera ett attribut för att använda ett annat attribut som dess etikett. Till exempel kan Produkt (med värdena 1, 2, 3 och så vidare) använda ProductName (med värdena cykel, skjorta, handskar och så vidare) som sin etikett. I det här fallet kommer endast ett fält, Produkt att visas i listan vars värden kommer att vara etiketterna cykel, skjorta, handskar och så vidare, men som kommer att sorteras enligt, och med unikhet bestämmas av, nyckelvärdena 1,2,3. En dold kolumn Product.Key skapas också, för att tillåta åtkomst till de underliggande nyckelvärdena om det behövs.
Alla variabler som definieras i den underliggande SAP HANA-vyn visas vid tidpunkten för anslutning och nödvändiga värden kan anges. Dessa värden kan sedan ändras genom att välja Transformera data från menyfliksområdet och sedan Redigera parametrar från den nedrullningsbara menyn som visas.
De modelleringar som tillåts är mer restriktiva än i vanliga fall när du använder DirectQuery, eftersom det är nödvändigt att säkerställa att rätt aggregeringsdata alltid kan hämtas från SAP HANA. Det är dock fortfarande möjligt att göra många tillägg och ändringar, inklusive definiera åtgärder, byta namn på och dölja fält samt definiera visningsformat. Alla ändringar kommer att bevaras vid uppdatering och alla icke motstridiga ändringar av SAP HANA-vyn kommer att tillämpas.
Ytterligare modelleringsbegränsningar
Den primära ytterligare modelleringsbegränsningen vid anslutning till SAP HANA med DirectQuery (behandla som flerdimensionell källa) är följande:
- Inget stöd för beräknade kolumner: Möjligheten att skapa beräknade kolumner är inaktiverad. Det innebär också att gruppering och klustring, som skapar beräknade kolumner, inte är tillgängligt.
- Ytterligare begränsningar för mått: Det finns ytterligare begränsningar av de DAX-uttryck som kan användas i mått för att återspegla den supportnivå som erbjuds av SAP HANA.
- Inget stöd för att definiera relationer: Bara en enda vy i en rapport kan tillfrågas, och därför finns det inget stöd för att definiera relationer.
- Ingen datavy:Datavyn visar normalt detaljerade nivådata i tabellerna. På grund av naturen för OLAP-källor som SAP HANA, är den här vyn inte tillgänglig via SAP HANA.
- Information om kolumner och mått är fasta: Listan över kolumner och mått som visas i fältlistan korrigeras i den underliggande källan och kan inte modifieras. Det går till exempel inte att ta bort en kolumn eller ändra dess datatyp (det går däremot att byta namn på den).
- Ytterligare begränsningar i DAX: Det finns ytterligare begränsningar för DAX som kan användas i måttdefinitioner när man vill återspegla begränsningar i källan. Det är till exempel inte möjligt att använda en aggregeringsfunktion via en tabell.
Ytterligare visualiseringsbegränsningar
Den finns ett antal begränsningar i visualiseringar vid anslutning till SAP HANA med DirectQuery (behandla som flerdimensionell källa):
- Ingen sammansättning av kolumner: Det går inte att ändra aggregeringen för en kolumn i ett visuellt objekt, och den är alltid Sammanfatta inte.
Behandla SAP HANA som en relationskälla
När du väljer att ansluta till SAP HANA som relationskälla blir viss ytterligare flexibilitet tillgänglig. Du kan exempelvis skapa beräknade kolumner, ta med data från flera SAP HANA-vyer och skapa relationer mellan de resulterande tabellerna. Det finns dock skillnader från beteendet vid behandling av SAP HANA som en flerdimensionell källa, särskilt när SAP HANA-vyn innehåller icke-additiva mått (till exempel distinkta antal eller medelvärden, snarare än enkla summor) och relaterade till effektiviteten hos de frågor som körs mot SAP HANA.
Det är användbart att börja med att klargöra beteendet för en relationskälla, till exempel SQL Server, när frågan som definieras i Hämta data eller Power Query-redigeraren utför en aggregering. I exemplet nedan returnerar en fråga som definierats i Power Query-redigeraren det genomsnittliga priset efter ProductID.
Om data som importeras till Power BI (jämfört med DirectQuery), återges följande resultat:
- Data importeras på den aggregeringsnivå som definieras av frågan som skapats i Power Query-redigeraren. Till exempel, genomsnittligt pris på produkten. Detta resulterar i en tabell med de två kolumnerna ProductID och AveragePrice som kan användas i visuella objekt.
- I ett visuellt objekt kommer all efterföljande aggregation (exempelvis summa, medelvärde, minimivärde, övrigt) att utföras över den importerade informationen. Till exempel, om du inkluderar genomsnittspris i ett visuellt objekt kommer Summa att användas som standard. Summan returneras över AveragePrice för varje ProductID – vilket i detta exempelfall är 13,67. Samma gäller för en annan mängdfunktion (t.ex minimivärde, medelvärde, osv) som används på den visuella informationen. Till exempel returnerar medelvärde för genomsnittspris medelvärdet för 6,66, 4 och 3, vilket är lika med 4,56 och inte medelvärdet av Pris från sex poster i den underliggande tabellen, vilket är 5,17.
Om DirectQuery (över samma relationskälla) används i stället för Importera gäller samma semantik och samma resultat skapas:
Exakt samma data presenteras på rapportnivån för samma fråga – trots att data inte importeras.
I ett visuellt objekt kommer all efterföljande aggregation (summa, medelvärde, minimivärde, övrigt) att utföras över den logiska tabellen från frågan. Och igen, ett visuellt objekt med medelvärdet av Genomsnittspris returnerar 4,56 igen.
Nu ska vi titta på SAP HANA när anslutningen behandlas som en relationskälla. Power BI kan arbeta med både Analytiska vyer och Beräkningsvyer i SAP HANA och båda innehåller mått. Men idag följer metoden för SAP HANA samma principer som beskrivs tidigare i det här avsnittet: frågan som definierats i Hämta data eller Power Query-redigeraren avgör vilka data som är tillgängliga, och sedan är eventuell efterföljande aggregering i ett visuellt objekt över dessa data, och detsamma gäller för både Import och DirectQuery.
Men med tanke på sap hana-typen är frågan som definierats i den första dialogrutan Hämta data eller Power Query-redigeraren alltid en aggregeringsfråga och innehåller vanligtvis mått där den faktiska aggregering som ska användas definieras av SAP HANA-vyn.
Motsvarigheten till SQL Server-exemplet ovan är att det finns en SAP HANA-vy som innehåller ID, ProductID, DepotID och mått inklusive AveragePrice som har definierats i vyn som Medelvärde av priset.
Om upplevelsen Hämta data innehåller val för måtten ProductID och AveragePrice är detta den definierande frågan för vyn som begär aggregerade data (i tidigare exempel har pseudo-SQL använts för enkelhetens skull, även om detta inte motsvarar den exakta syntaxen hos SAP HANA SQL). I sådant fall kommer ytterligare aggregeringar som definieras i det visuella objektet att aggregeras ytterligare till följd av en sådan fråga. Igen, enligt beskrivningen ovan för SQL Server gäller detta både för Import och DirectQuery. I DirectQuery-fallet används frågan från Hämta data eller Power Query-redigeraren i ett underval i en enskild fråga som skickas till SAP HANA, och därför är det faktiskt inte så att alla data skulle läsas in, innan du aggregerar ytterligare.
Alla dessa överväganden och beteenden kräver följande viktiga överväganden när du använder DirectQuery över SAP HANA:
Lägg märke till all annan aggregering som utförs i visuella objekt när måttet i SAP HANA inte är additivt (till exempel inte en enkel summa, minimivärde eller maxvärde).
I Hämta data eller Power Query-redigeraren ska endast nödvändiga kolumner inkluderas för att hämta nödvändiga data, vilket återspeglar det faktum att resultatet blir en fråga, som måste vara en rimlig fråga som kan skickas till SAP HANA. Om du till exempel väljer dussintals kolumner eftersom du tror att de kommer att behövas för efterföljande visuella objekt kommer den aggregatfråga som används i det underordnade valet för DirectQuery att innehålla dessa dussintals kolumner. De kommer allmänt att prestera under förväntan.
Låt oss ta en titt på ett exempel. Om vi väljer fem kolumner i följande exempel (CalendarQuarter, Color, LastName, ProductLine, SalesOrderNumber) i dialogrutan Hämta data tillsammans med måttet OrderQuantity betyder det att följande SQL-fråga ställs till SAP HANA om vi skapar ett enkelt visuellt objekt med Min OrderQuantity (minsta beställningskvantitet). Den skuggade är undermarkeringen som innehåller frågan från HämtaDataPower-frågeredigeraren / . Om den här delmarkeringen ger ett resultat med hög kardinalitet kommer resultatet från SAP HANA antagligen vara otillfredsställande.
På grund av det här beteendet rekommenderar vi att de objekt som valts i Hämta data eller Power Query-redigeraren begränsas till de objekt som behövs, samtidigt som det resulterar i en rimlig fråga för SAP HANA.
Metodtips
För båda metoderna för att ansluta till SAP HANA gäller även rekommendationer för att använda DirectQuery för SAP HANA, särskilt de som är relaterade till att säkerställa bra prestanda. De här rekommendationerna beskrivs i detalj i artikeln använda DirectQuery i Power BI.
Överväganden och begränsningar
I följande lista beskrivs alla SAP HANA-funktioner som inte stöds fullt ut eller funktioner som fungerar annorlunda mot när du använder Power BI.
- Överordnade-underordnade hierarkier – Överordnade-underordnade hierarkier visas inte i Power BI. Detta beror på att Power BI har åtkomst till SAP HANA med SQL-gränssnittet och överordnade-underordnade hierarkier inte fullständigt kan nås via SQL.
- Andra metadata för hierarki – Grundstrukturen för hierarkier visas i Power BI, men vissa metadata för hierarki (till exempel att styra beteendet för ojämna hierarkier) har ingen effekt. Detta beror på begränsningar av SQL-gränssnittet.
- Anslutning med hjälp av SSL – Du kan ansluta med hjälp av import och flerdimensionell med SSL, men kan inte ansluta till SAP HANA-instanser som konfigurerats till att använda SSL för relationsanslutningen.
- Stöd för attributvyer – Power BI kan ansluta till vyer för analys och beräkning, men det går inte att ansluta direkt till attributvyer.
- Stöd för katalogobjekt – Power BI kan inte ansluta till katalogobjekt.
- Ändra till variabler efter publicering – Du kan inte ändra värdena för SAP HANA-variabler direkt i Power BI-tjänsten när rapporten har publicerats.
Kända problem
I följande lista beskrivs alla kända problem vid anslutning till SAP HANA (DirectQuery) med hjälp av Power BI.
SAP HANA-problem vid fråga för räknare och andra åtgärder – Felaktiga data returneras från SAP HANA om anslutning till en analysvy och ett räknarmått och vissa andra förhållandemått ingår i samma visualisering. Detta omfattas av SAP Note 2128928 (oväntade resultat när du frågar en beräknad kolumn och en räknare). Förhållandemåttet blir felaktig i det här fallet.
Flera Power BI-kolumner från en enda SAP HANA-kolumn – För vissa beräkningsvyer, där en SAP HANA-kolumn används i fler än en hierarki, visar SAP HANA detta som två separata attribut. Detta resulterar i att två kolumner skapas i Power BI. Dessa kolumner döljs som standard, men alla frågor som rör hierarkierna eller kolumnerna direkt fungerar korrekt.
Nästa steg
Mer information om DirectQuery finns i följande resurser: