Nun hängt die Antwort auf das, was Ihre Definition von "integrierbare" ist.
BIRT ist in reinem Java geschrieben.
Ich denke an 3 verschiedene Möglichkeiten könnten:
Natürlich ist es möglich, Java-Code in eine bestehende C/C++ Programm (siehe Embed Java into a C++ application?) zu integrieren.
Sie könnten einfach die BIRT-Runtime-Engine verwenden und den Bericht als PDF oder HTML von der Befehlszeile generieren (das heißt, Sie rufen im Grunde die Java-Programmdatei mit mehreren Argumenten aus Ihrem Programm auf). Weitere Informationen finden Sie unter Birt - How to run report engine on the console? und http://eclipser-blog.blogspot.de/2008/02/automatic-generation-of-birt-reports.html.
Sie könnten einen Java-Webserver wie Tomcat in einem zweiten Prozess ausführen und dann Ihren Bericht starten, indem Sie eine HTTP-URL aufrufen (z. B. das mitgelieferte Servlet-Beispiel). Siehe http://www.eclipse.org/birt/documentation/integrating/viewer-usage.php
ähnlich 3. (siehe unten)
Einige Anmerkungen:
Die zweite Option ist langsam, aufgrund des Java und BIRT Motorstart-Overhead (dies kann einige Sekunden dauern). Mit der ersten und dritten Option wird der Startup-Overhead auf einmal (und für jeden Report) minimiert.
Für die zweite und dritte Option kann es notwendig sein, den vorhandenen Code der Beispielprogramme an Ihre Bedürfnisse anzupassen.
Die erste Option ist wahrscheinlich die beste für eine Lösung in Industriequalität, aber sie ist auch am schwierigsten zu entwickeln.
Wie auch immer, Java Fähigkeiten sind notwendig IMHO.
Wenn Sie dies auf einem SOC statt auf einem PC ausführen möchten, berücksichtigen Sie die Leistung. Ist eine Java-basierte Lösung für diese Art von Hardware geeignet? BIRT benötigt ziemlich viel RAM und CPU (für einen SOC). Hardware wie der Raspi 3 sollte das ganz einfach handhaben, denke ich.
Ich integrierte die BIRT-Laufzeit in eine vorhandene Python-Anwendung (alles auf einem Anwendungsserver) auf eine vierte Art: Ich schrieb ein Listener-Programm, das auf einem TCP-Socket für BIRT-Aufgaben abhört. Es verwendet einen Pool von Worker-Prozessen (in Java geschrieben), die wiederum die BIRT-Report-Engine zum Generieren der Ausgabe verwenden. Das Client-Programm (hier: in Python geschrieben) öffnet eine TCP-Verbindung zum Listener und verwendet diesen Socket, um ihm mitzuteilen, welcher Bericht generiert werden soll (einschließlich Berichtsparameter und Zieldateiname). Das Listener-Programm wählt dann wiederum einen Arbeitsprozess für die Aufgabe und übergibt die Aufgabe an den Arbeitsprozess.
Also, im Grunde ist diese vierte Option ähnlich dem dritten, mit zwei Unterschieden:
Die Kommunikation ist socket-basierte (statt http), bi-di-Kommunikation ermöglicht.
Die Architektur ist Multi-Prozesse statt Multi-Threading. Wir wählen dies, weil sehr große Berichte zu Fehlern bei der Arbeitsspeicherung führen können, wenn ansonsten nicht zusammenhängende Berichte gleichzeitig ausgeführt werden. Es ist dieselbe grundlegende Architektur, die Oracle für seinen Berichtsserver gewählt hat.
Die Entwicklung der Programme dauerte jedoch Monate.
Danke Hub für die Erklärung. – Raju