Wie erzeugt man heutzutage (Massen)Druckoutput?

[delora]

Hallo zusammen,

ich arbeite als Entwickler in einem international tätigen Unternehmen, welches als Dienstleister in der Energiebranche auftritt.
Unsere Software erzeugt Druckoutput in verschiedenen Formaten, welche zum Teil der Archivierung dienen (PDF) aber auch direkt an den Kunden gehen (PCL -> Papier).
Unsere Datenbasis wird in einer Oracle-Datenbank verwaltet.

Das von uns selbst entwickelte Drucksystem ist mittlerweile in die Jahre gekommen.
Wir verwalten unterschiedliche Formulare in inhaltlich und layoutmässig unterschiedlichen Ausprägungen (da international unterschiedliche Anforderungen an den Output).

Beispiel:

Zitat:

Anschreiben zur Rechnung für Land 1
...
Anschreiben zur Rechnung für Land n

Rechnung für Land 1
...
Rechnung für Land n

Mahnschreiben für Land 1
...
Mahnschreiben für Land n

Das Ganze ist objektorientiert gelöst, so dass es für jedes Formular eine Basis mit den Hauptfunktionalitäten gibt und dann für jedes Land abgeleitet die jeweiligen Spezialanforderungen.
Die benötigten Daten werden auf Zuruf innerhalb dieser Formulare zusammengesammelt und in eine Queue gestellt.
Aus dieser werden dann nachts unterschiedliche Druckengines aufgerufen (PDF, PCL...) die die Daten dann entsprechend umsetzen und den eigentlichen Output erzeugen.
Dieses ist alles native gelöst, d.h. wir benutzen hier keine Reporting-Tools oder so, sondern wird schreiben die PCL-, Postscriptbefehle usw. selber, inkl. der kompletten Formatierungen etc.
Zu dieser Aufbereitung gehören auch weiterführende Prozesse wie bspw. der Aufruf von Webservices zur Archivierung der Daten oder das Erzeugen von Mails, die den Druckoutput als Attachment mit auf die Reise bekommen.

Das ist alles schön und gut und funktioniert, aber was das für ein Moloch ist, könnt Ihr Euch sicherlich vorstellen.
Die Integration neuer Technologien wie bspw. QR-Codes usw. sind recht aufwändig, da sie auch immer in allen Druckengines implementiert werden müssen.
Des Weiteren bedarf es zwingend eines Programmierers (was für mich nicht unbedingt zum Nachteil ist ), um kleinste Anpassungen am Layout oder so vorzunehmen.

Nun ist es so, dass im Rahmen einer Umstrukturierung auch das Layout unserer Dokumente (und das sind ein paar 100) angepasst werden soll.
So eine Runde haben wir zuletzt vor etwa 13 Jahren gedreht und zu meiner Schande muss ich gestehen, dass wir mit den Auswirkungen zum Teil heute noch zu kämpfen haben.
Es ist so viel, was man in dem Bereich zu beachten hat, seien es passende Seitenumbrüche, horizontale Ausdehnung von dynamischen Elementen usw.
Dieses in der aktuellen Infrastruktur umzusetzen, sehe ich als sehr kritisch.

Somit komme ich zu meinem eigentlichen Anliegen

Ich bin nun auf der Suche nach einer Alternative, die unser aktuelles Drucksystem ablösen soll.
Und da ich mich diesbezüglich auf dem aktuellen Markt gar nicht auskenne, wende ich mich an Euch und hoffe, ein paar nette Ideen zu bekommen

Fakten:

• Unsere Datenbasis wird weiterhin eine Datenbank sein. Welche, soll irrelevant sein.
• Unsere Datenbasis ist SEHR (!) groß! Wir sprechen von vielen vielen Milliarden Datensätzen.
• Der Umfang der zu erzeugenden Dokumente liegt derzeit bei mehreren 100, Tendenz steigend.

Must have:

• Die Texte müssen für jedes Dokument individuell übersetzbar sein (ja, nicht nur die statischen, sondern auch die aus der Datenbank gelesenen ).
• Da die Anzahl der täglich zu erzeugenden Dokumente hoch ist, muss das System sehr performant sein. Das impliziert, dass die Lösung skalierbar sein muss.
• Ein Layout für mehrere Formate. Soll heißen, dass ich festlege, wie das Ergebnis auszusehen hat, und das System erzeugt mir darauf basierend PDF, PCL, Postscript.... whatever.
• Über den Weg, wie der Output letztendlich erzeugt wird, möchte ich mir keine Gedanken machen müssen. Ich möchte also nicht an PDF-Spezifika oder so rumschrauben (aber können - siehe Nice to haves)
• Das Ganze soll softwareseitig gesteuert werden können, so dass auch Folgeverarbeitungen (siehe oben, Webservices usw.) erfolgen können.
• Die Lösung muss aktuell weiterentwickelt werden und auch dann noch funktionieren, wenn die Entwicklung irgendwann einmal eingestellt werden sollte.
• Das Layout muss flexibel gestaltet werden und mit unterschiedlichen Grafikformaten umgehen können (für Logos usw.) (ich möchte mich nicht mehr mit PCL-Macros rumschlagen müssen )

Nice to have:

• Das Layout der Dokumente sollte auch von Nicht-Programmierern angepasst werden können, so dass die Länder in Eigenverantwortung Änderungen implementieren können. Wie sich soetwas unabhängig einer Kenntnis der zugrundeliegenden Daten allerdings realisieren lassen soll - keine Ahnung.
• Eine OpenSource-Lösung wäre natürlich schön. Nicht wegen des finanziellen Aspektes, sondern wegen der möglichen Mitgestaltung.
• Schön wäre es auch, wenn man sich um das Erzeugen des eigentlichen Outputs selber nicht kümmern muss, aber kann. Bedeutet, dass ich keine PDF-Engine programmieren, diese aber u.U. erweitern möchte, sollten benötigte Features nicht vorhanden sein.

Nicht-Anforderungen:

• Die Lösung muss nicht zwingend Delphi-basiert sein. (Java muss es aber auch nicht unbedingt sein )

Das ist erstmal das, was mir spontan so einfällt

Ich habe mich schoneinmal mit XSLT auseinander gesetzt, weiß aber nicht, ob dieses bei dem Umfang einsetzbar ist. Da fehlt es an Erfahrungen.

Ich freue mich über Eure Anregungen

[Neutral General]

Generell brauchst du Report-Generatoren. Da gibt es z.B. FastReport oder Quickreport (dann lieber Fastreport).
Aber wenn du dich in der Richtung mal umschaust wirst du sicherlich was finden.
Der Reportgenerator ist normalerweise ähnlich zu bedienen wie der Formular-Generator in Delphi.
Programmierkenntnisse sind normalerweise nicht erforderlich.

Wenn mich nicht alles täuscht gibt es bei fast allen (oder sogar alle) Report-Generatoren eine Option den Quelltext mitzukaufen. Kostet dann etwas mehr aber man kann die Engine als auch den Editor seinen wünschen anpassen. Wobei das eigentlich normalerweise nicht nötig ist.

[Sir Rufo]

Und für die Skalierbarkeit nimmt man etwas wie MSMQ, ActiveMQ, usw. und schiebt die Jobs in so eine Queue. An der Queue lauschen dann 1-n Systeme, die diese Jobs verarbeiten können.

[mjustin]

Wenn es Java sein darf:

http://www.jaspersoft.com/editions

In der Community Edition kostenlos, lizensiert unter AGPL.

Zitat:

Pixel Perfect Report Designer
Create very sophisticated Business Intelligence report layouts containing charts, images, subreports, crosstabs and much more with Jaspersoft Studio.

Zitat:

Reporting Engine
Java based reporting library uses data from any data source to compile and render pixel-perfect documents that can be viewed, printed, or exported in a variety of formats including HTML, PDF, Excel, OpenOffice and Word.

[Neutral General]

Zitat von mjustin:

Wenn es Java sein darf:

Ich gehe mal nicht davon aus, dass sie ihre Software nur deswegen komplett in Java neu schreiben wollen....

[mjustin]

Zitat von Neutral General:

Zitat von mjustin:

Wenn es Java sein darf:

Ich gehe mal nicht davon aus, dass sie ihre Software nur deswegen komplett in Java neu schreiben wollen....

Egal auf welches Werkzeug man die Erstellung der Reports umstellt: eine Schnittstelle muss man immer schreiben. Ob jenseits der Schnittstelle C#, Java oder COBOL arbeitet, das spielt erst mal keine Rolle.

Wenn man unbedingt zur Laufzeit des Reports noch eigene Delphi-Funktionen aufrufen will, sollte man dies zuerst noch mal überdenken.

[Neutral General]

Zitat von mjustin:

Egal auf welches Werkzeug man die Erstellung der Reports umstellt: eine Schnittstelle muss man immer schreiben. Ob jenseits der Schnittstelle C#, Java oder COBOL arbeitet, das spielt erst mal keine Rolle.

Es existiert ja bereits eine in Delphi geschriebene Software. Aus dieser heraus soll gedruckt werden (-> Reporte generiert werden).
Die einzige Möglichkeit da eine andere Sprache als Delphi einzubringen ist entweder die vorhandene Software umzuschreiben (was wie gesagt total übertrieben wäre) oder ein zweites Programm in Java/C#/WasAuchImmer zu schreiben mit dem das Delphi Programm dann erst mal kommunizieren muss. Aber das wäre ja wohl mehr als umständlich/unnötig.

[mjustin]

Zitat von Neutral General:

Zitat von mjustin:

Egal auf welches Werkzeug man die Erstellung der Reports umstellt: eine Schnittstelle muss man immer schreiben. Ob jenseits der Schnittstelle C#, Java oder COBOL arbeitet, das spielt erst mal keine Rolle.

Es existiert ja bereits eine in Delphi geschriebene Software. Aus dieser heraus soll gedruckt werden (-> Reporte generiert werden).
Die einzige Möglichkeit da eine andere Sprache als Delphi einzubringen ist entweder die vorhandene Software umzuschreiben (was wie gesagt total übertrieben wäre) oder ein zweites Programm in Java/C#/WasAuchImmer zu schreiben mit dem das Delphi Programm dann erst mal kommunizieren muss. Aber das wäre ja wohl mehr als umständlich/unnötig.

Wenn die zu druckenden Daten - so wie im Posting beschrieben - erst in eine Queue gestellt werden, und dann daraus nachts verschiedene Druckengines die Ausdrucke erzeugen, kann das Austauschen der Druckengine schon eine Lösung sein. In der Queue stehen Daten, die von der Druckengine verarbeitet werden müssen. Da ist nichts Delphi-spezifisch.

[ernschd]

Gibt es denn einen Reportgenerator, der PCL-Dokumente erzeugen kann? So was wäre für mich auch interessant.
Ansonsten stört mich ein wenig die Dateigröße von PDFs, die mit Fastreport erstellt wurden.

[Sir Rufo]

Zitat von ernschd:

Gibt es denn einen Reportgenerator, der PCL-Dokumente erzeugen kann? So was wäre für mich auch interessant.
Ansonsten stört mich ein wenig die Dateigröße von PDFs, die mit Fastreport erstellt wurden.

Wieso PCL-Dokumente? Das Umsetzen in PCL sollte der Druckertreiber erledigen.

Und mit FastReport erzeugt man auch (direkt) keine PDF-Dokumente (es sei denn man ist sehr leidensfähig oder es ist einem egal, was da raus kommt).