
SAP HANA-data via XS OData
Yres leest SAP HANA niet rechtstreeks op de SQL-poort uit: een directe database- of ODBC-verbinding bestaat in Yres niet. HANA-data komt binnen via een XS OData-service, een adres dat eindigt op .xsodata en dat je HANA-beheerder publiceert, of via een exportroute zoals SAP Business Data Cloud. Yres koppelt de service als OData-bron, met een HANA-/XS-gebruiker of OAuth, en laadt de data naar een Azure SQL-database in je eigen Azure-tenant. Daar wordt ze gehistoriseerd en is ze beschikbaar voor Power BI.
Heb je één rapport dat één gepubliceerde HANA-service uitleest en hoef je niet terug te kijken in de tijd, dan is een rechtstreekse koppeling vanuit je rapportagetool de kortste weg.
Yres wordt zinvol zodra HANA-data naast andere bronnen in Power BI moet staan, je wijzigingen wilt bewaren die HANA zelf overschrijft, of meerdere services volgens een vast schema geladen en bewaakt moeten worden.
Nee. Yres heeft geen HANA- of ODBC-brontype, niet in de bronkeuze en niet in de laadengine. HANA-data haal je op via een XS OData-service of via een exportroute zoals SAP Business Data Cloud.
Het adres van de XS OData-service (eindigend op .xsodata) en een HANA-/XS-gebruiker met wachtwoord die leesrechten heeft op de betreffende objecten. De hostnaam en SQL-poort van de databaseserver zelf heb je niet nodig.
Alleen als de XS OData-service achter een firewall staat en vanuit Azure niet bereikbaar is. Is de service via internet bereikbaar, dan kies je de standaard cloud-runtime van Azure Data Factory.
Als jullie HANA-omgeving data niet als OData-service publiceert maar als bestanden aanbiedt via SAP Business Data Cloud. Die route werkt met een SAS-token op Azure-opslag en draait op de cloud-runtime. Welke route past, stem je af met je SAP-/HANA-beheerder.
Volledige technische beschrijving in de kennisbank →·Laatst gecontroleerd:
Gebouwd voor organisaties op Azure en Power BI. Yres koppelt je bronnen, bewaart de historie en rolt wijzigingen gecontroleerd uit, zonder handwerk.