Und wieder eine ausführliche Blogserie zum Thema PowerBI dataflows. Diesmal wird ausführlich gezeigt, wie Daten aus NAV BC mittels dataflow in einen Azure Data Lake übetragen werden können. Ist ausführlich erklärt und somit auch leicht „nachzubauen“…
Using Power Platform Dataflows to extract and process data from Business Central
Ich liebe Lösungen, die verschiedene Technologien miteinander verheiraten. Zwei gute Beispiele sind diese Sessions der NAV TechDays 2019:
Business Central with Power Platform – more than ERP solution
Hier wird nochmalig sehr schön gezeigt, wie PowerApps, PowerBI sowohl Daten von BC konsumieren kann, aber auch, wie umgekehrt BC Daten aktualisiert werden können, oder auch, wie ein Power BI Report mit einem eingebetteten PowerApp direkt in BC angezeigt werden kann.
Give Business Central access to your data files
Hier geht es sehr stark um das Date Exchange Framework, ein zumindest für mich so auf den ersten Blick etwas sperriges, aber dafür umso mächtigeres Tool, um Daten mit BC auszutauschen. Man kriegt hier wirklich in kurzer Zeit viel geboten, auch wird beispielsweise auf File Provider von Azure eingegangen. Auch Flow oder jetzt halt Power Automate wird kurz angerissen.
Also ganz ehrlich, was da heute alles an Neuigkeiten pupliziert wird, ist ja schon fast beängstigend.
Wow to many news. Very hard to keep track. Here we go:
Microsoft Ignite 2019 News pdf download
Announcing Azure Synapse Analytics
Azure Data Factory Wrangling Task (No in public preview)
Very good article as always, highly recommend this site to anyone interested in Dynamics NAV and BC
MSDYN365BC – How Do I Replicate Data From on-Prem to SASS?
Very well written blog post. Highly recommend this…
Diese Seite finde ich empfehlenswert, geht zwar vorrangig um SSRS aber sind auch Tipps zum Dynamics NAV enthalten:
https://reportsyouneed.com/category/ssrs/
Vor alllem die Aussage, die Aufbereitung der Daten mittels SQL, Views oder procedures möglichst in der Datenbank zu behalten, würde ich in meinen Szenarien unterschreiben. Im Optimalfall sollte das Reportingtool lediglich für die Visualisierung zuständig sein. Ich sehe hier den großen Vorteil, dass die aufbereiteten Daten unabhängig vom Reporting Frontend universell verwendbar sind. Und es gibt dann auch nur eine Wahrheit der Daten und nicht im schlimmsten Fall eine je Report.
Auch für Power BI ist der Ansatz durchaus zulässig, ich sehe das in meinen Projekten (mit Power BI Pro) momentan so:
Wo immer möglich und sinnvoll, die Daten bereits an der Quelle (in der Datenbank) entsprechend vor-/aufbereiten
Dann die einzelnen Views als Power BI dataflows in den Service bringen.
Zentrale Datasets nach Star Schema entwickeln und auch im Service bereit stellen. Hier kann dann natürlich auch auf die gewohnten Tools wie Power Query und DAX zurückgegriffen werden.
Diese Datasets dann als Quelle für das Power BI Reporting verwenden.
