Wir bei cubido beschäftigen uns nun schon seit einiger Zeit damit, angestaubte Reports, die mit dem Oracle Report Designer erstellt wurden, in zeitgemäße Reports zu migrieren. Für Projekte im Dotnet- und Oracle Umfeld ist "List & Label" die Lösung unserer Wahl.
Was ist „List & Label“ und was unterscheidet es von anderen Reporting Lösungen?
In erster Linie handelt es sich bei „List & Label“ um eine Reporting-Komponente, die für den Einsatz in der eigenen Software-Lösung konzipiert ist. Was „List & Label“ nicht ist und auch nicht sein will, ist eine Druck- und Reportinglösung für den Stand-Alone Einsatz und das wird in den Lizenzbedingungen auch ganz klar kommuniziert.
Mit „List & Label“ wird ein Windows Forms Control zur Verfügung gestellt, das man problemlos in die eigene Anwendung integrieren und diese damit um die Funktionalität „Druck und Reporting“ ergänzen kann. Dabei ist man jedoch nicht alleine auf Desktop Anwendungen beschränkt, auch Web und Cloud Reporting sind selbstverständlich möglich.
Der wohl größte Unterschied zu Reporting-Lösungen wie der von Oracle ist, dass dafür ein programmatisch erstellter Datenbank-Layer erforderlich ist, um einem Report die benötigten Daten zur Verfügung zu stellen. Das bedeutet, dass man im Report Designer keine SQL Queries, Funktionen und Parameter einzufügen braucht, so wie man das von anderen Reporting Lösungen kennt. Das hat den Vorteil einer klare Trennung der Datenbeschaffungslogik zum eigentlichen Design des Reports.
Der Nachteil ist hierbei allerdings, dass der Report alleine nicht funktionieren kann, was aber in Anbetracht des Anwendungsgebietes in der Praxis keine nennenswerte Einschränkung darstellt. Man könnte den Datenbank-Layer auch sehr einfach und generisch halten, sodass dieser nur bestimmte Tabellen oder gar alle Tabellen der Datenbank an den Report liefert. Damit vergeudet man allerdings das eigentliche Potential von „List & Label“ und erschwert die Report Gestaltung im Designer unnötig.
Die Best Practice ist hier ganz klar, die Daten so genau wie möglich auf die Bedürfnisse des Reports abzustimmen. Mit der richtigen Datenaufbereitung kann man sich somit eine Menge Arbeit sparen.
Wir migrieren einen Oracle Report
Bei der Migration eines Oracle Reports gilt es nun, einige Dinge zu beachten, denn in Oracle Reports kann sich Funktionalität und Logik an vielen Stellen verbergen.
Der erste Schritt wird häufig sein, dass man ein Formular für Eingabe der Inputparameter des Reports erstellen wird, es sei denn, es handelt sich um automatisch generierte Reports. Auf Basis der übergebenen Parameter werden dann die Daten geladen und der Reporting Komponente in Form eines ADO.NET DataSets übergeben.
Die Erstellung des Report Layouts selbst stellt dann keine besonders große Herausforderung mehr dar und ist in der umfangreichen Dokumentation auch sehr gut beschrieben. Der aufwändigste Teil der Reportmigration wird häufig die Analyse der bestehenden Oracle Reports sein. Oft sind diese Reports schon seit vielen Jahren im Einsatz, wurden immer wieder von unterschiedlichen Personen angepasst und am Ende sieht man sich mit einem unübersichtlichen Wirrwarr an SQL Queries, Report Triggern und PL/SQL Funktionen konfrontiert, deren Zusammenspiel untereinander erst einmal verstanden werden muss.
Unsere Lösung
Aufgrund der Tatsache, dass man Dotnet Code erstellen muss, um die Daten für den Report aus der Datenbank zu lesen, ist man natürlich versucht, die SQL Queries in den Programmcode einzubetten, gerade in der Phase des Prototypings. Dieses Vorgehen ist aber nicht zu empfehlen, da man so bereits von Anfang an schwer wartbaren Code erzeugt.
Im Zuge der Migration zahlreicher Oracle Reports haben wir eine Lösung entwickelt, welche es ermöglicht, die Queries, Trigger und Funktionen eines oder auch mehrerer Oracle Reports in einer XML Datei abzulegen. Damit wird zugleich die Hierarchie der Daten abgebildet und es werden entsprechende Master-Detail-Relationen angelegt, auf welche dann im Report Designer zugegriffen werden kann. Ein weiterer Vorteil dieser Lösung ist, dass man die Datenbeschaffung der Reports auch später noch anpassen kann, ohne die Programmlogik abändern und aufwändige Deployments der gesamten Anwendung durchführen zu müssen.
Fazit
Mit der Reporting Komponente „List & Label“ der Firma Combit und dem flexibel konfigurierbaren Datenbank-Layer von cubido hat man eine praxistaugliche Lösung, um bestehende Oracle Reports effizient migrieren und in die eigene Applikation einbinden zu können.
Verfasst von Thomas Polaschek
