Dela via

Anslut till SAP HANA-datakällor med hjälp av DirectQuery i Power BI

  • Artikel

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 mått, hierarkier och attribut för den vyn är tillgängliga i fältlistan. När visuella objekt skapas hämtas alltid aggregerade data från SAP HANA. Den här tekniken är den rekommenderade metoden och är standard för nya DirectQuery-rapporter via SAP HANA.

  • Behandla SAP HANA som en relationskälla: I det här fallet behandlar Power BI SAP HANA som en relationskälla. Den här metoden ger större flexibilitet. Var noga med den här metoden för att säkerställa att mått aggregeras som förväntat och för att undvika prestandaproblem.

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 en relationskälla, enligt följande bild.

Screenshot of the Options dialog, showing the DirectQuery options.

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 öppnas. Så om alternativet för närvarande är avmarkerat, när du lägger till en ny anslutning till SAP HANA med hämta data, görs den anslutningen behandla SAP HANA som en flerdimensionell källa. Men om en annan rapport öppnas som också ansluter till SAP HANA fortsätter rapporten att fungera enligt det alternativ som angavs när den skapades. Det 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ör olika beteenden och det går inte att växla en befintlig rapport från en metod till en annan.

Behandla SAP HANA som en flerdimensionell källa (standard)

Alla nya anslutningar till SAP HANA använder den här anslutningsmetoden som standard och behandlar SAP HANA som en flerdimensionell källa. För att kunna behandla en anslutning till SAP HANA som relationskälla måste du välja Alternativ för filalternativ>och inställningar>. Markera sedan kryssrutan under Direct Query>Treat SAP HANA as a relational source (Hantera SAP HANA som relationskälla).

När du ansluter till SAP HANA som en flerdimensionell källa gäller följande överväganden:

  • I Hämta datanavigering kan du välja en enda SAP HANA-vy. Det går inte att välja enskilda mått eller attribut. Det finns ingen fråga som definierats vid tidpunkten för anslutningen, vilket skiljer sig från att importera data eller när du använder DirectQuery vid behandling av SAP HANA som relationskälla. Det här övervägandet innebär också 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 mått, hierarkier och attribut för den valda vyn visas i fältlistan.

  • När ett mått används i ett visuellt objekt efterfrågas SAP HANA för att hämta måttvärdet på den aggregeringsnivå som krävs för det visuella objektet. När du hanterar icke-additiva mått, till exempel räknare och förhållanden, utförs alla aggregeringar av SAP HANA och ingen ytterligare aggregering utförs av Power BI.

  • För att säkerställa att rätt mängdvärden alltid kan hämtas från SAP HANA måste vissa begränsningar införas. Det går till exempel 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 den alternativa relationsmetoden ger, men det är enklare. Metoden säkerställer också korrekta aggregeringsvärden när du hanterar mer komplexa SAP HANA-mått och ger vanligtvis högre prestanda.

Listan Fält innehåller alla mått, 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. De kan dock visas om det behövs genom att välja Visa dold från snabbmenyn i fältlistan. Från samma snabbmeny kan de göras synliga om det behövs.

  • I SAP HANA kan ett attribut definieras för att använda ett annat attribut som etikett. Till exempel kan Product, med värdena 1, 2, 3och så vidare, använda ProductName, med värdena Bike, Shirt, Glovesoch så vidare, som dess etikett. I det här fallet visas ett enda fält Produkt i fältlistan, vars värden är etiketterna Bike, Shirt, Gloves, och så vidare, men som sorteras efter, och med unikhet som bestäms av, nyckelvärdena 1, 2, 3. En dold kolumn Product.Key skapas också, vilket ger åtkomst till de underliggande nyckelvärdena om det behövs.

Alla variabler som definierats i den underliggande SAP HANA-vyn visas vid tidpunkten för anslutningen och de nödvändiga värdena kan anges. Dessa värden kan senare ändras genom att välja Transformera data från menyfliksområdet och sedan Redigera parametrar från den nedrullningsbara menyn som visas.

De modelleringsåtgärder som tillåts är mer restriktiva än i det allmänna fallet när du använder DirectQuery, med tanke på behovet av att säkerställa att rätt aggregerade data alltid kan hämtas från SAP HANA. Det är dock fortfarande möjligt att göra många tillägg och ändringar, inklusive att definiera mått, byta namn på och dölja fält och definiera visningsformat. Alla sådana ändringar bevaras vid uppdatering och eventuella icke-motstridiga ändringar som görs i SAP HANA-vyn tillämpas.

Ytterligare modelleringsbegränsningar

De andra primära modelleringsbegränsningarna vid anslutning till SAP HANA med DirectQuery (behandla som flerdimensionell källa) är följande begränsningar:

  • 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ängliga.
  • Ytterligare begränsningar för mått: Det finns andra begränsningar för 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: Endast en enda vy kan efterfrågas i en rapport, och därför finns det inget stöd för att definiera relationer.
  • Ingen datavy: Datavyn visar normalt data på detaljnivå i tabellerna. Med tanke på typen av OLAP-källor, till exempel SAP HANA, är den här vyn inte tillgänglig via SAP HANA.
  • Kolumn- och måttinformationen är fast: Listan över kolumner och mått som visas i fältlistan korrigeras av den underliggande källan och kan inte ändras. Det går till exempel inte att ta bort en kolumn eller ändra dess datatyp. Den kan dock byta namn.
  • Ytterligare begränsningar i DAX: Det finns andra begränsningar för DAX som kan användas i måttdefinitioner för att återspegla begränsningar i källan. Det går till exempel inte att använda en aggregeringsfunktion över en tabell.

Ytterligare visualiseringsbegränsningar

Det finns begränsningar i visuella objekt när du ansluter 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 det ä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 extra flexibilitet tillgänglig. Du kan till exempel skapa beräknade kolumner, inkludera 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 förtydliga 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 genomsnittspriset per ProductID.

Diagram showing a query defined in Power Query Editor that returns the average price by Product ID.

Om data importeras till Power BI jämfört med DirectQuery skulle följande situation uppstå:

  • Data importeras på den aggregeringsnivå som definieras av frågan som skapades i Power Query-redigeraren. Till exempel genomsnittligt pris per produkt. Det här faktumet resulterar i en tabell med de två kolumnerna ProductID och AveragePrice som kan användas i visuella objekt.
  • I ett visuellt objekt utförs alla efterföljande aggregeringar, till exempel Sum, Average, Min och andra, över dessa importerade data. Om du till exempel inkluderar AveragePrice för ett visuellt objekt används summan som standard och returnerar summan över AveragePrice för varje ProductID, i det här exemplet 13,67. Samma sak gäller för alla alternativa aggregeringsfunktioner, till exempel Min eller Average, som används i det visuella objektet. Medelvärdet av AveragePrice returnerar till exempel genomsnittet på 6,66, 4 och 3, vilket motsvarar 4,56, och inte medelvärdet av Price på de sex posterna i den underliggande tabellen, vilket är 5,17.

Om DirectQuery över samma relationskälla används i stället för Import gäller samma semantik och resultatet blir exakt detsamma:

  • Med samma fråga visas exakt samma data logiskt för rapporteringslagret – även om data faktiskt inte importeras.

  • I ett visuellt objekt utförs alla efterföljande aggregeringar, till exempel Sum, Average och Min, igen över den logiska tabellen från frågan. Och återigen returnerar ett visuellt objekt som innehåller genomsnittspris samma 4,56.

Tänk på SAP HANA när anslutningen behandlas som en relationskälla. Power BI kan fungera med både analysvyer och beräkningsvyer i SAP HANA, som båda kan innehålla mått. Men i dag följer metoden för SAP HANA samma principer som beskrivs tidigare i det här avsnittet: frågan som definieras i Hämta data eller Power Query-redigeraren avgör vilka data som är tillgängliga, och sedan är alla efterföljande aggregeringar 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 definieras i den inledande dialogrutan Hämta data eller Power Query-redigeraren alltid en aggregerad fråga och innehåller vanligtvis mått där den faktiska aggregering som används definieras av SAP HANA-vyn.

Motsvarigheten till det tidigare SQL Server-exemplet är att det finns en SAP HANA-vy som innehåller ID, ProductID, DepotID och mått, inklusive AveragePrice, som definieras i vyn som Genomsnitt av pris.

Om i hämta data-upplevelsen var de val som gjordes för ProductID och måttet AveragePrice, då definierar det en fråga över vyn och begär dessa aggregerade data. I det tidigare exemplet används pseudo-SQL för enkelhetens skull som inte matchar den exakta syntaxen för SAP HANA SQL. Sedan aggregeringar som definierats i ett visuellt objekt ytterligare aggregerar resultatet av en sådan fråga. Återigen, som beskrivits tidigare för SQL Server, gäller det här resultatet både för fallet Import och DirectQuery. I DirectQuery-fallet används frågan från Hämta data eller Power Query-redigeraren i ett underval i en enda 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 via SAP HANA:

  • All ytterligare aggregering som utförs i visuella objekt måste uppmärksammas när måttet i SAP HANA inte är additivt, till exempel inte en enkel summa, min eller max.

  • 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 är en fråga som måste vara en rimlig fråga som kan skickas till SAP HANA. Om till exempel dussintals kolumner har valts, med tanken att de kan behövas för efterföljande visuella objekt, innebär även för DirectQuery ett enkelt visuellt objekt att den mängdfråga som används i undermarkeringen innehåller de dussintals kolumner som vanligtvis presterar dåligt.

I följande exempel innebär valet av fem kolumner (CalendarQuarter, Color, LastName, ProductLine, SalesOrderNumber) i dialogrutan Hämta data , tillsammans med måttet OrderQuantity, att senare skapa ett enkelt visuellt objekt som innehåller Min OrderQuantity resulterar i följande SQL-fråga till SAP HANA. Den skuggade är undermarkeringen som innehåller frågan från Hämta data/Power Query-redigeraren. Om det här undermarkeringen ger ett resultat med hög kardinalitet kommer den resulterande SAP HANA-prestandan sannolikt att vara dålig.

Screenshot of a query example, showing the SQL query to SAP HANA.

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 de resulterar i en rimlig fråga för SAP HANA.

Bästa praxis

För båda metoderna för att ansluta till SAP HANA gäller även rekommendationer för användning av DirectQuery för SAP HANA, särskilt rekommendationer för att säkerställa bra prestanda. Mer information finns i använda DirectQuery i Power BI.

Beaktanden och begränsningar

I följande lista beskrivs alla SAP HANA-funktioner som inte stöds fullt ut, eller funktioner som fungerar annorlunda när du använder Power BI.

  • Överordnade underordnade hierarkier: Överordnade underordnade hierarkier visas inte i Power BI. Det beror på att Power BI har åtkomst till SAP HANA med hjälp av SQL-gränssnittet, och överordnade underordnade hierarkier inte kan nås fullt ut med hjälp av SQL.
  • Andra hierarkimetadata: Den grundläggande strukturen för hierarkier visas i Power BI, men vissa hierarkimetadata, till exempel att styra beteendet för ojämna hierarkier, har ingen effekt. Detta beror återigen på begränsningarna i SQL-gränssnittet.
  • Anslut ion med SSL: Du kan ansluta med import och flerdimensionellt med TLS, men kan inte ansluta till SAP HANA-instanser som konfigurerats för att använda TLS för relationsanslutningen.
  • Stöd för attributvyer: Power BI kan ansluta till analys- och beräkningsvyer, men kan inte 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 några SAP HANA-variabler direkt i Power BI-tjänst när rapporten har publicerats.

Kända problem

I följande lista beskrivs alla kända problem vid anslutning till SAP HANA (DirectQuery) med Power BI.

  • SAP HANA-problem när fråga efter räknare och andra mått: Felaktiga data returneras från SAP HANA om anslutning till en analysvy och ett räknarmått och något annat förhållandemått ingår i samma visuella objekt. Det här problemet omfattas av SAP Note 2128928 (oväntade resultat när du kör frågor mot en beräknad kolumn och en räknare). Ratio-måttet är felaktigt 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 mer än en hierarki, exponerar SAP HANA kolumnen som två separata attribut. Den här metoden resulterar i att två kolumner skapas i Power BI. Dessa kolumner är dock dolda som standard och alla frågor som rör hierarkierna, eller kolumnerna direkt, fungerar korrekt.

Relaterat innehåll

Mer information om DirectQuery finns i följande resurser: