Wie erzeugt man heutzutage (Massen)Druckoutput?

[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).