Arbeiten mit Dynamics 365:  Reports erstellen, testen, verteilen

Jeder von uns, der mit Dynamics CRM 365 zu tun hat, wird früher oder später mit dem Thema Berichte konfrontiert. Die Berichte im CRM sind im Allgemeinen vom ersten Tag an von einer Hass-Liebe begleitet. Das fängt bei dem teilweise sehr umständlichen Procedere an, bis man eine entsprechende Entwicklungsumgebung hat, geht über die Komplexität bei der Erstellung und dem Design selbst und endet mehr oder weniger bei dem Testen und der Verteilung der Berichte.

(Bildquelle: Canva)

Ob Sie nun als Berater, wie wir bei infinitas, mit diesem Thema in Berührung kommen oder als Administrator und Mitarbeiter in einem Unternehmen, welches Dynamics CRM einsetzt, die Aufgabe bekommen, Berichte zu verteilen, Sie sollten ein klares Vorgehen haben.

Ich möchte Ihnen hier meinen Weg aufzeigen, wie ich aktuell in einem größeren Projekt die Erstellung, den Test und die Verteilung der Berichte über die verschiedenen Umgebungen durchführe. Auch in kleineren Projekten könnte ja das eine oder andere Vorgehen Ihnen helfen.

Erstellung

Hierzu ist schon viel geschrieben. Ein noch immer über alle Versionen weitestgehend gut funktionierender Ansatz ist mit den SQL Server Data Tools für Visual Studio 2012.

Diese Data Tools sind zwar auch im VS2015 enthalten (und hier bei mir auch gleichzeitig installiert), aber sie werden bei der Installation von den Reporting-Erweiterungen nicht erkannt. Zumindest ist es mir auch mit den Infos aus der Netzgemeinde nicht gelungen. Es kommt der im Netz mehrfach genannte Fehler, dass eine Voraussetzung für die Reporting Authoring Extension fehlt.

Für neue Tipps bin ich immer dankbar. ☺

Wir wollen hier nicht weiter von der Berichterstellung schreiben. Wichtig ist in diesem Zusammenhang nur, dass wir uns den Ordner merken, in dem das Berichtsprojekt gespeichert wird und die RDL-Dateien liegen. Diesen werden wir später in einem anderen Tool benötigen.

Die Berichte verteilen…

Wenn ein Projekt etwas größer wird, dann kommen zumeist auch weitere Umgebungen neben der Produktion zum Einsatz. Klassisch sind das die Entwicklungs- und die Test- & Abnahme-Umgebung.

Die Entwicklungsumgebung ist, wie der Name schon sagt, der Ursprung der Bearbeitung aller Dinge. Hier sollten auch die Berichte erstellt und abgelegt* werden. Zu dem Stern an „abgelegt“ komme ich noch.

Aber zumeist finden sich in der Entwicklungsumgebung nur wenige Daten, wenn überhaupt. Um einen Bericht genauer zu testen und zu schauen, ob die verschiedenen Daten inhaltlich richtig wiedergegeben werden, benötigt man dann eben die Abnahme-Umgebung.

Gegen die Entwicklung können zumeist nur die Abfragen der Daten, also die Selektionen getestet werden, ob alles passt und keine technischen Fehler enthalten sind.

Do Fetch or not do FetchXML – that is the question…

Kleiner Ausflug im Zusammenhang, wie die Abfragen geschrieben werden, nämlich als SQL oder FetchXML-Abfrage. Mittlerweile würde ich, obwohl ich großer SQL-Fan bin, immer wieder zu FetchXML für die Abfragen greifen. Allein durch Microsofts „Cloud first“-Parole sollte sich jeder mit den FetchXML-Berichten anfreunden, da sie in der Cloud Voraussetzung sind!

Aber zurück zum Thema. ☺

Was mache ich hier überhaupt? Es liegen in diesem Fall angepasste Versionen der Kunden-Übersicht, einem Standard-Bericht aus CRM, vor. Dieser Bericht heißt als Original-Datei „Account Overview.rdl“ und hat noch einen Unterbericht dabei, mit dem Namen „Account Overview – Sub-Report.rdl“.

Ich erwähne das nur hier schon mal, da man gleich sehen wird, dass der tatsächliche Dateiname bei dieser Art von Bericht-Verteilung eine Rolle spielt.

Ich möchte nun die erstellten Berichte über die anderen Umgebungen verteilen. Dies kann man ganz klassisch „zu Fuß“ machen. Wenn ich einen Bericht im CRM anlege, werde ich gefragt, woher der Bericht kommt. Wenn man hier die RDL-Datei angibt, kann man den zuvor erstellten Bericht hochladen und so zur Verfügung stellen. Spätere Anpassungen an den Berichten müssen dann auf dem gleichen Weg zur Verfügung gestellt werden. Bericht öffnen, Datei auswählen, Bericht speichern… - und das bei jeder kleinen Änderung, die von den Anwendern getestet werden soll.

Ja klar, aus dem Visual Studio kann man sich auch mit dem CRM-System verbinden und eine Vorschau bereits bei der Entwicklung aufrufen. Aber das kann eben nur der Entwickler während seiner Arbeit. Der Fachbereich bzw. die Anwender des Systems brauchen den Bericht eben schon an der entsprechenden Stelle. Und das Verhalten von Filtern und Datenselektionen ist zumeist eben auch nur in der Abnahme oder Produktion richtig zu sehen.

XrmTool Box - da schau an…

Als ich mal wieder ein Update der XrmToolbox (http://www.xrmtoolbox.com) vorgenommen habe, ist mir ein neues Plug-In aufgefallen, welches uns in diesem Zusammenhang gute Dienste erweisen wird. Nämlich dieses:

Der ReportSync – herzlichen Dank an Andreas Seitz!

Mit diesem Tool ist das Herunter- und Hochladen von Berichten ein Kinderspiel! ;-)

Dann wollen wir es mal in unsere Strukturen einbinden.

Zuerst habe ich im Projektverzeichnis einen neuen Ordner für die Berichte angelegt. Das ist der Ordner, der auch im Visual Studio als Speicherort verwendet wird.

Settings für den ersten Aufruf… insbesondere hier das „include Reports which only exists in CRM“ Häkchen setzen. Es gibt bei uns ja noch keine Reports lokal…

Es werden nun alle Berichte aus dem CRM heruntergeladen. Möchte man bestimmte Berichte ausklammern, kann man auch noch mit dem Filter arbeiten. Ich möchte aber einmal „mit alles“ und daher ab die Post! Ein Klick auf „Check Reports“…

Beim ersten Lauf sind alle Berichte „in CRM, but not on disk“, was ja auch klar ist. Aber aufgepasst. Das Tool arbeitet ausschließlich mit den Dateinamen und nicht mit dem Anzeige-Namen des Berichts in CRM. Hat man also einmal einen Bericht neu angelegt und eine namentlich gleiche RDL-Datei verwendet, dann kriegt man hier Probleme, wie ich mit dem Account Overview und seinem Unterbericht (Account Overview Sub-Report). Hier lerne ich gleich, wie wichtig es ist, auch für die RDL-Dateien unterschiedliche und sprechende Namen zu verwenden!

Intermezzo: Das Problem löse ich eben mal, indem ich die Berichts-RDL-Dateien herunterlade und unter anderem Namen wieder hochlade… ;-)

Danach gibt es den Account Overview nur noch einmal:

Und den zweiten Bericht neu mit den RDL-Dateien mit Custom vorweg:

Sind nun diese und ggf. weitere Dopplungen ausgeräumt, dann kann der erste Sync gestartet werden.

Nachdem nun einmal aktuell alle Berichte heruntergeladen wurden, sollte das Bild im Tool so aussehen:

Alle Berichte auf der Platte entsprechen den Berichten im CRM! Klasse, erstes Ziel erreicht!

In unserem Berichts-Server-Projekt können wir nun die RDL-Dateien als vorhandene Objekte hinzufügen. Ich habe das mal eben nur mit meinen Custom Account Overview Dateien gemacht.

Nachdem ich nun im VS an dem Bericht eine Änderung vorgenommen habe, ist dieser Bericht wie folgt im ReportSync aufgeführt:

Die RDL-Datei in dem Projektordner von VS ist also neuer als der Stand im CRM.

Nun einfach diesen Bericht markieren und wieder den Up/Download-Knopf drücken! Dadurch wird er ins CRM übertragen und im Anschluss wird im Tool alles wieder als OK angezeigt.

Voila!

So, nun haben wir also unsere Entwicklungsumgebung. Dort erstellen und testen wir auf technischer Ebene unsere Berichte. Diese können mit dem ReportSync sehr einfach im CRM veröffentlicht werden.

Jetzt kommen unsere weiteren Umgebungen zum Tragen. Die Abnahme (ggf. nicht überall vorhanden) und die Produktion.

Die XrmToolbox unterstützt in diesem Zusammenhang mehrere Verbindungen, die gleichzeitig im Tool hinterlegt werden können.

Wenn ich nun wieder eine Verbindung mit einer anderen CRM-Organisation herstelle,

dann werde ich gefragt, welche Tabs ich entsprechend auf die neue Verbindung umstellen möchte!

Schon kann ich mit den gleichen RDL-Dateien gegen meine nächste Umgebungsstufe arbeiten!

Wenn ich nun wieder die Berichte gegen das CRM prüfen lasse, dann sind die meisten OK, weil sich in der Produktion die gleichen Berichtsversionen befinden, wie sie in der Entwicklung erstellt wurden. Es ergibt sich aber ein weiterer Fall, den ich kurz erwähnen möchte:

Dies sind die zwei umbenannten RDL-Dateien, welche in Produktion noch als die vorhin gefundenen Namens-Doppelungen vorliegen, also noch nicht das Wort „Custom“ am Anfang haben. Hier sieht man also nochmals ganz gut, dass alles beim Sync nur über die Dateinamen läuft. Die RDL-Datei „weiß“ ja nicht, wie ihr zugehöriger Bericht im CRM heißt!

Da das Tool keine Anlage von Berichten unterstützt und wir diese ja auch nicht als neue Berichte im System haben wollen, müssen wir die Korrektur der Dateien am Bericht auch hier nochmals kurz selbst durchführen…

Bericht bearbeiten, neue Datei (mit dem Namen Custom*) hochladen, speichern. Fertig! Jetzt ist auch der Custom Report aktuell!

Zusammenfassung

Diese Struktur hat mir nun schon in einigen Projekten einen guten Dienst geleistet, um die Erstellung, Erneuerung und die Verteilung von Berichten zu managen.

Durch Visual Studio und die Möglichkeit, die Berichts-RDL-Dateien dann gleich in einem Source Verwaltungssystem á la TFS zu sichern, hat man hier noch einen weiteren Mechanismus, eine Versionsverwaltung der Berichte zu ermöglichen.

Mit dem XrmToolbox-Modul „ReportSync“ hat man ein tolles Hilfsmittel, um Berichte aus Umgebungen zu sichern (Backup-Gedanke vorhandener Berichte) und im Umfeld von mehreren Umgebungen (Stages) ein komfortables „Deployment“-Vorgehen.

Ich hoffe, dem einen oder anderen damit einen Ansatz für ein solches Vorgehen gegeben zu haben und würde mich freuen, wenn es dann genauso hilft wie mir. Genauso freue ich mich auch über Kommentare, Ergänzungen und Ideen zu dem Thema. Es gibt bestimmt immer noch was daran zu optimieren!

Microsoft Dynamics 365 bietet dir durch seine hohe Flexibilität die Möglichkeit, dein Lead- und Kundenmanagement perfekt auf deine individuellen Anforderungen abzustimmen und damit deinen Erfolg auf das nächste Level zu heben.

Als langjähriger Microsoft-Partner mit viel Erfahrung unterstützen wir dich dabei, das volle Potenzial dieser leistungsstarken Plattform auszuschöpfen. Mit unserem engagierten Support und unserer Expertise in der Weiterentwicklung von Microsoft Dynamics 365 sorgen wir dafür, dass du jederzeit optimal aufgestellt bist – für mehr Effizienz, bessere Kundenbindung und nachhaltiges Wachstum.