Using Power Platform Dataflows to extract and process data from Business Central

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

Nav TechDays 2019

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.

 

News, News, News

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

Microsoft Power Platform News

Azure Data Factory Wrangling Task (No in public preview)

SQL Server 2019 GA

 

Announcing Visual Studio Online Public Preview

 

 

 

SSRS Reporting

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.