Reports / Berichte / Listen

[ricardo1885]

Hallo,

ich bin auf der Suche nach Konkurrenzprodukten von Crystal Reports und C1 Reports.

Kennst du solche?

Gruß

[flashpixx]

JasperReports

List & Label

[Goulasz]

SQL Server Reporting Services

[ricardo1885]

Da sind ja schonmal ein paar zusammen gekommen...

@flashpixx:

Jasper Reports ist offensichtlich leider nur für Java... mich interessiert aber eigentlich eher die .NET-Welt... (hätte ich vielleicht explizit dazu schreiben sollen... trotzdem Danke.)

@Goulasz:

Können die "SQL Server Reporting Services" auch von der eigenen Software aus gesteuert werden? Gibt es hier eine API? ... ein Nachteil ist hier allerdings, dass ich das auch für Oracle brauche...

Ich fasse meine Anforderungen nochmal neu zusammen:

- Konkurrenzprodukten von Crystal Reports und C1 Reports

- .NET-Welt fähig

- läuft mit Oracle und SQL-Server

- lässt sich in das eigene Programm integrieren

Gibt es noch mehr Report-Tools, auf die das zutrifft?

[Goulasz]

Zu Api: Report Server-Webdienst

Zu Oracle:

Wenn das nicht ausreichend ist, gucke ich nochmal im Studio nach. Ich hab meine Reports bisher immer direkt dort erstellt, vermute aber, dass es auch da Mittel und Wege gibt, die Daten fremdgesteuert über den Server aufzubereiten.

Gruß, Goulasz

[flashpixx]

Naja Java kann via JDBC auf Oracle zugreifen, d.h. Du kannst Jasper nutzen. List & Label funktioniert mit .NET, aber CR ist jetzt nicht "so" schlecht, also warum wechseln.... !?

[ricardo1885]

Ähm... irgendwie läuft da hier aus dem Ruder...

Ich kann keinem Kunden erklären, dass er sich auf seinem DB-Server anmelden soll, wenn er einen bestimmten Bericht haben will. Das muss über die Anwendungsoberfläche passieren.

Was den "Report Server-Webdienst" angeht, ist der nur auf SQL-Server 2012 (?) vorhanden... ich glaube auch mitlerweile, nachdem ich diesen Link gelesen habe nicht, dass es das ist, was ich brauche... ich habe den Verdacht, dass dieses "Instrument" Berichte vom DB-Server selbst erstellt, was absolut nicht mein Ansatz ist.

Ich wiederhole an dieser Stelle nochmal meine Anforderungen:

- Konkurrenzprodukten von Crystal Reports und C1 Reports

- .NET-Welt fähig

- läuft mit Oracle und SQL-Server

- lässt sich in das eigene Programm integrieren

[flashpixx]

Ich kann keinem Kunden erklären, dass er sich auf seinem DB-Server anmelden soll, wenn er einen bestimmten Bericht haben will. Das muss über die Anwendungsoberfläche passieren.

Im Normalfall wird ein entsprechendes Objekt der Reportanwendung erzeugt und dann wird die Datenquelle durch die Anwendung übergeben und der Report geöffnet. Unter Windows wäre dies wohl mittels COM zu realisieren.

Es gibt aber zig Möglichkeiten dies zu realisieren z.B. wäre auch LaTeX mit CTAN: tex-archive/support/SQLTeX eine Möglichkeit.

Ebenso wäre Extensible Stylesheet Language auch eine weitere Möglichkeit

Ich wiederhole an dieser Stelle nochmal meine Anforderungen:

Jeder versteht was Du machen willst, Du brauchst Dich nicht zu wiederholen

- .NET-Welt fähig

- läuft mit Oracle und SQL-Server

- lässt sich in das eigene Programm integrieren

Sowohl die oben genannte LaTeX, wie auch die XML-Fo Lösung erfüllen dies. Ebenfalls List & Label, selbst JasparReports würde das Erfüllen.

[ricardo1885]

Ah, okay... Danke.

Wie ist das eigentlich mit Latex? Da gibt es ja mitex usw...

Gibt es da auch .dlls, die in das eigene .NET-Projekt integriert werden können?

Eine weitere Alternative wäre vermutlich auch das Open-Document-Format, oder?

Da wird es vermutlich dann aber mit dem Bauen der Berichte schneller kompliziert, wenn ich mir da tatsächlich alles selber zusammen bastle...?!

[flashpixx]

Wie ist das eigentlich mit Latex? Da gibt es ja mitex usw...

Gibt es da auch .dlls, die in das eigene .NET-Projekt integriert werden können?

Miktex ist eine LaTeX Distribution es gibt mehrere. Eine DLL für .NET brauchst Du nicht, denn Du musst nur pdflatex oder latexmk als Kommando ausführen und das PDF wird generiert. Das Anzeigen kann dann mit einem Viewer Deiner Wahl geschehen.

Eine weitere Alternative wäre vermutlich auch das Open-Document-Format, oder?

Ob das eine Alternative ist, ist wohl eher etwas subjektiv. Ich persönlich ziehe ein LaTeX Dokument vor, denn es reiner Plaintext und kann mit einem einfachen Texteditor bearbeitet werden. Wenn man die Struktur des TeX-Dokumentes entsprechend wählt, lassen sich auch dynamisch Layoutstrukturen sehr leicht verändern. Nach meiner Erfahrung ist der Satz eines TeX Dokumentes bisher "ungeschlagen", die Erweiterungen sind im Grunde weit über dem Maß was Bundelsoftware wie z.B. OO, MS Office bieten. Es reicht ja nicht nur "ein Format" zu verwenden, Du musst ja letztendlich auch eine Anwendung haben mit der Du das Texterzeugnis auch setzen kannst.

Da wird es vermutlich dann aber mit dem Bauen der Berichte schneller kompliziert, wenn ich mir da tatsächlich alles selber zusammen bastle...?!

Am Bsp LaTeX: Da TeX reiner Plaintext ist, kann man ihn z.B. in einer Datenbank lagern, wobei man da z.B. dann direkt sehr schön auch eine Versionierung machen kann. Ein Bericht ist ja meist modular aufgebaut, d.h. Du hast irgendwie einen Teil, der das Basislayout definiert und ggf diverse Unterstrukturen. TeX selbst bietet include Mechanismen, so dass Du eben den Bericht einfach als ein TeX File aus der Datenbank generieren kannst, Du kannst ggf eben via Include Verweise erzeugen, so dass Du auch Teile des Berichtes cachen kannst. Als weitere Option kannst Du den TeX Code z.B. mittels XSLT aus XML Daten erzeugen lassen. Zum Schluss generiert z.B. LatexMK das PDF, wobei er eben auch Referenzen zu einem Glossar, Indizes, Literaturverzeichnis, etc automatisch erkennt.

Ggf bietet es sich an dies auch zentralisiert zu machen, d.h. Du benötigst nur auf einem Server eine TeX Installation, wenn nun der Aufruf des User kommt, dass ein Bericht generiert werden muss, dann werden die Daten auf dem Server aus der Datenbank extrahiert (LaTeX kann natürlich selbstverständlich Daten direkt aus einer Datenbank lesen und in den Bericht einfügen), auf dem Server werden dann die notwendigen Dateien temporär abgelegt und der TeX Interpreter gestartet, der das PDF generiert. Ist dies dann fertig wird dem User nur das PDF gesendet bzw der Pfad, der dann direkt lokal beim User geöffnet werden kann.

Vorlagen müssen natürlich in TeX Code erzeugt werden, aber es gibt für TeX sehr viele gute Editoren, die man verwenden kann bzw. nimm als Basis XHTML und transformiere dieses per XSLT in TeX Code, dann würde sich ein HTML Editor für das Editieren eignen.

Zusätzlich braucht der User für die Anzeige nur einen PDF Viewer und keine weiteren Tool. TeX lässt sich im Grunde sehr einfach automatisieren, da es eben "nur" aus dem Aufruf eines Shellcommandos besteht. Natürlich kannst Du nicht erwarten, dass Du eine fertige einfache Komponente bekommst, denn das ist nicht das Ziel von TeX. TeX ist eben dafür gedacht, komplexe Dokumente in einem hervorragenden Satz zu erstellen, alles was Du als "Usability" haben willst, dafür musst Du selbst sorgen.

Für mich sind in solchen Dingen folgende Punkte sehr wichtig:

Ich brauche ein System, das hervorragende Layoutstrukturen beherrscht (diverse DIN, C ... Formate, Einseitig / Doppelseitig, ...)

Weiterhin benötige ich einen Modularen Aufbau meiner Dokumente, da ich nicht überall immer den gleichen Header / Footer rein kopieren möchte.

Ich brauche Skalierfähigkeit, d.h. das Dokument soll in DIN A 4 genauso aussehen wie in DIN A 5.

Verzeichnisstrukture (Tabellen, Bilder, Indizes, Glossare, ...) müssen direkt automatisiert vom System generiert werden. Im PDF müssen die Hyperlinks (Referenzen) direkt mit gesetzt werden können.

Ich will mich nicht mit Layoutproblemen rum schlagen. Ich will keine großen externen Komponenten installieren müssen, um Berichte anzupassen bzw. anzuzeigen.

Ich will bei Austausch der PC / Server, dass die Dokumente vorher genauso aussehen, wie nach dem Austausch. Migration auf ein anderes OS muss jederzeit ohne Probleme möglich sein.

Mehrere 100 Seiten müssen ohne Probleme erzeugbar sein.

Graphiken z.B. Plots sollen in beliebiger Komplexität möglich sein und auch mit dem Layout passend skalieren (ohne dabei Qualität einzubüßen).

Dazu dann natürlich immer noch der Punkt der Kosten für ein solches System.

Ich habe über einige Jahre hinweg diverse Tools ausprobiert, sicherlich gibt es da je nach Geschmack durchaus auch sinnvolle Ansätze (kenne selbst auch CR), aber bisher habe ich kein Tool gefunden, was auch nur annähernd an TeX heranreicht. TeX erfordert durchaus etwas Einarbeitungszeit, aber es gibt da viele sehr gute Tutorials und Editoren. Ich habe z.B. TeX in einer Webanwendung eingebaut, der User gibt via HTML Editor im Browser seinen Text ein und via PHP Scripte wird dann auf dem Server ein PDF geniert und es zurück an den Browser des Users geschickt.

Ich habe auch zu Beginn Zeit investieren müssen, um den TeX Syntax zu lernen, aber die Community ist wirklich hilfsbereit und es gibt entsprechende Literatur. Ob es nun für Deine Zwecke passend ist, müsstest Du Dir halt mal überlegen, das was mich überzeugt ist eben, dass TeX selbst mit komplexesten Dokumenten (> 500 Seiten, Graphiken, etc) absolut keine Probleme hat.

[ricardo1885]

Mh... die Geschichte mit den Shell-Kommandos macht mir bei einigen der Vorschläge vorallem sehr große Sorgen, da dies unter Windows 8 zu bestimmten Problemen führen kann.

Eigentlich habe ich auch schon an Latex gedacht, habe da auch bereits fürs Studium einige Schritte drin gemacht.

Hintergrund meines Problems ist der:

Ich soll ein Software-Modul zur Generierung verschiedenster Berichte neu Umsetzen. Die einfachen Reports, wie von C1 oder so werden mit Sicherheit eine Art "Berichtskonfiguarator", bei dem mehrere unterschiedliche Berichte gebündelt ausgegeben werden können, nicht umsetzen können.

Diese XML-Fo-Lösung ist bereits Teil einer der drei verschiedenen bestehenden Architekturen, hat sich aber im Laufe der Zeit als zu komplex und auch wartungsunfreundlich erwiesen.

Ist die Tex-Geschichte eigentlich Open-Source? Unter welcher Lizenz stehen diese Parser?

[flashpixx]

Mh... die Geschichte mit den Shell-Kommandos macht mir bei einigen der Vorschläge vorallem sehr große Sorgen, da dies unter Windows 8 zu bestimmten Problemen führen kann.

Es ist ja kein direktes Shellcommand, Du startest letztendlich ein Executable mit Parametern. Wie man dies konkret macht, müsste man von der Architektur abhängig machen. Ich würde hier den Schritt mittels LatexMK wählen (was ein Perlscript ist).

Ich soll ein Software-Modul zur Generierung verschiedenster Berichte neu Umsetzen.

Da sehe ich jetzt nicht das Problem mit TeX.

Diese XML-Fo-Lösung ist bereits Teil einer der drei verschiedenen bestehenden Architekturen, hat sich aber im Laufe der Zeit als zu komplex und auch wartungsunfreundlich erwiesen.

Das sehe ich ähnlich, wobei aus Sicht von XML das natürlich deutlich besser wäre, weil man eben rein XML Transformationen beschreiben würde.

Ist die Tex-Geschichte eigentlich Open-Source? Unter welcher Lizenz stehen diese Parser?

LaTeX Project Public License

Wo siehst Du denn Problem? Was evtl wichtig wäre, zu wissen, um welche Art von Berichten geht es primär, was für Anforderungen werden an die Schrifterzeugnisse gestellt. Wie sieht der Arbeitsprozess des Users aus.

[ricardo1885]

Die zusammengesetzten Berichte bestehen aus Texten, Charts/Diagrammen, Bildern und Tabellen... sehr vielseitig also und mit normalen gängigen Report-Systemen vermutlich nicht wirklich abzudecken.

Ich habe mitlerweile mal die Source von Latex gefunden und mal nachgesehen, wie groß das überhaupt ist... alleine die Binaries kommen schon auf 160MB ... das ist im Endeffekt für ein paar Listen (sind so um die 10 Stück) ein bischen viel...

Die genaueren Anforderungen werde ich erst in einigen Wochen ermitteln, ich bin im Moment lediglich dabei schonmal ein bischen zu suchen und zu recherchieren, was es so alles an Strategien geben könnte...

[flashpixx]

Ich habe mitlerweile mal die Source von Latex gefunden und mal nachgesehen, wie groß das überhaupt ist... alleine die Binaries kommen schon auf 160MB ... das ist im Endeffekt für ein paar Listen (sind so um die 10 Stück) ein bischen viel...

Je nach Distribution kann man die Installation auch kompakt gestalten. Aber sorry 160 MB sind nicht viel, schau Dir mal dagegen entsprechende Office Installationen an. Und außerdem musst ja nicht jeder eine TeX Installation haben, im Grunde reicht eine Installation auf einem zentralen Server, für den User reicht dann ein PDF Viewer.

[flashpixx]

Zur technischen Seite: Ich würde eine Component Object Model bzw Distributed Component Object Model entwickeln, die lediglich den Aufruf an den TeX Compiler (ich würde zu LatexMK raten) anstößt und Fehlermeldungen ggf sammelt und zurück sendet, d.h. die Komponente müsste nur eine dieser drei Funktionen für den Aufruf implementieren:

CreateProcess function (Windows) / ShellExecute function (Windows) / ShellExecuteEx function (Windows)

Ich würde generell das ganze nicht auf das Erzeugen von Listen reduzieren, sondern eine allgemeingültige Schnittstelle schaffen, mit der Textdokumente generiert werden können.

[ricardo1885]

Das sind genau die Funktionen, die unter Win8 so nicht mehr lauffähig sind... zumindest über die Wege, wie ich sie aufzurufen hätte und das mit der XML-Fo ja schon mache.

COM kommt nich in Frage... es wird definitiv eine .NET-Komponente werden, die dann über Interop COM sichtbar gemacht werden muss.

Um das Design werde ich mich erst später kümmern...

[flashpixx]

Das sind genau die Funktionen, die unter Win8 so nicht mehr lauffähig sind

Kannst Du dies bitte einmal belegen, denn ich habe kein Information dazu gefunden, warum es unter Windows 8 Probleme geben sollte.

[ricardo1885]

Weil das im Betrieb schon durchgetestet worden und einwandfrei ermittelt worden ist?!