AS/400 / iSeries / i5 / System i

Posts 1-10 of 12

Back
Next

Michael Haufler
The company name is only visible to registered members.

Listendaten RPG --> Java
Hallo liebe RPG Spezialisten,

eine Frage aus dem Java Lager. Wir haben eine Lösung welche SQL Abfragen in schicke Excelreports konvertieren kann. Auf der Anwenderseite kam das Begehren auf auch die Ausgabe von RPG Programmen (mit komplexer Businesslogik) in schicken Exceltabellen zu bekommen.

Ich habe mich etwas umgesehen und mir sind folgende Ansätze eingefallen:

1. Physische Datei
Man bau die RPG Programme so um das Sie unter der Angabe einer Jobnummer in eine physische Datei schreiben.
Vorteil:
Klares Datenformat, einfach auszulesen und kann zur Not per JOIN einfach mit weiteren Daten angereichert werden.

2. DataQ
Man sendet die Ergebnisse als DataQEntry wobei da bei großen Auswertungen glaube ich nicht so super toll ist.

3. Spoolfile analysieren
Man liest ein Spoolfile aus und hofft das derjenige der da reinschreibt sich auch an die vereinbarte Schnittstelle hält.

4. Stored Procedure
Habe im Netz einen interessanten Artikel gefunden wie man aus einem RPG Programm eine SP macht.
Siehe: http://www.itjungle.com/mpo/mpo031402-story06.html#
Allerdingt wird bei diesem Beispiel nur ein Wert zurückgegeben. Hier als gleich die Frage. Kann man mit SPs aus RPG auch eine ganze Liste an Werten zurückgeben?.
Zweite Frage: Wird man von einem Admin erschossen weil die SPs die RPG Programme interaktiv callen oder läuft das dann auch wie SQL als prestarted Job?

Nun meine Hauptfrage an die AS400 Gurus:
Was macht denn am meißten Sinn? Gibt es noch andere Ansätze um Listendaten aus RPG in Java zu bekommen? Wir suchen auch nicht die Lösung die aus informationstechnischer Sicht die beste ist, sondern das beste Verhälntis zwischen Kotzen und Nutzen aufweist. Natürlich sollte die Lösung trotzdem so stabil sein das man ab und zu auch etwas schlaf bekommt.

Ich freue mich auf Ihre Anregungen.

Freundliche Grüße

Michael Haufler
- 12 Mar 2009, 1:56 pm
Michael Haufler wrote: > Hallo liebe RPG Spezialisten, > > eine Frage aus dem Java Lager. Wir haben eine Lösung welche SQL > Abfragen in schicke Excelreports konvertieren kann. Auf der > Anwenderseite kam das Begehren auf auch die Ausgabe von RPG > Programmen (mit komplexer Businesslogik) in schicken Exceltabellen zu > bekommen. > > Ich habe mich etwas umgesehen und mir sind folgende Ansätze > eingefallen: > > 1. Physische Datei > Man bau die RPG Programme so um das Sie unter der Angabe einer > Jobnummer in eine physische Datei schreiben. > Vorteil: > Klares Datenformat, einfach auszulesen und kann zur Not per JOIN > einfach mit weiteren Daten angereichert werden. > > 2. DataQ > Man sendet die Ergebnisse als DataQEntry wobei da bei großen > Auswertungen glaube ich nicht so super toll ist. > > 3. Spoolfile analysieren > Man liest ein Spoolfile aus und hofft das derjenige der da > reinschreibt sich auch an die vereinbarte Schnittstelle hält. > > 4. Stored Procedure > Habe im Netz einen interessanten Artikel gefunden wie man aus einem > RPG Programm eine SP macht. > Siehe: http://www.itjungle.com/mpo/mpo031402-story06.html# > Allerdingt wird bei diesem Beispiel nur ein Wert zurückgegeben. Hier > als gleich die Frage. Kann man mit SPs aus RPG auch eine ganze Liste > an Werten zurückgeben?. > Zweite Frage: Wird man von einem Admin erschossen weil die SPs die > RPG Programme interaktiv callen oder läuft das dann auch wie SQL als > prestarted Job? > > Nun meine Hauptfrage an die AS400 Gurus: > Was macht denn am meißten Sinn? Gibt es noch andere Ansätze um > Listendaten aus RPG in Java zu bekommen? Wir suchen auch nicht die > Lösung die aus informationstechnischer Sicht die beste ist, sondern > das beste Verhälntis zwischen Kotzen und Nutzen aufweist. Natürlich > sollte die Lösung trotzdem so stabil sein das man ab und zu auch > etwas schlaf bekommt. > > Ich freue mich auf Ihre Anregungen. > > Freundliche Grüße > > Michael Haufler
Robert Jordan Premium Member
The company name is only visible to registered members.

Re: Listendaten RPG --> Java
wie wäre es denn mit dem Nachfolger von QU1 - Web Query (Qu2, QU3 , QU4) - erstellt direkt dynamische Berichte zur i5 ohne Umweg file -> exel . QU1 ist abgekündigt - als Bestandskunde gibt es je nach Prozessorklasse kostenfreie Webquery Lizenzen allerdings ist gesonderte Software mainteneance nötig.

Mehr infos hier :

http://www-03.ibm.com/systems/i/software/db2/webquery/

http://www.common.at/docs/200803_GRU_DB2_Web_Query_for_Syste...

Gruß

Robert Jordan
- 13 Mar 2009, 09:50 am
Robert Jordan wrote: > wie wäre es denn mit dem Nachfolger von QU1 - Web Query (Qu2, QU3 , > QU4) - erstellt direkt dynamische Berichte zur i5 ohne Umweg file -> > exel . QU1 ist abgekündigt - als Bestandskunde gibt es je nach > Prozessorklasse kostenfreie Webquery Lizenzen allerdings ist > gesonderte Software mainteneance nötig. > > Mehr infos hier : > > http://www-03.ibm.com/systems/i/software/db2/webquery/ > > http://www.common.at/docs/200803_GRU_DB2_Web_Query_for_System_i_Short.pdf > > Gruß > > Robert Jordan
Michael Haufler
The company name is only visible to registered members.

Re^2: Listendaten RPG --> Java
Sehr geehrter Herr Jordan,

wir sind ein Konkurrenzprodukt von IBM Web Query. Mit dem Unterschied das wir günstiger und besser sind. Die Auswertung von SQL Abfragen ist nicht das Problem. Das beherscht unser Tool wunderbar. Es gibt jedoch in ERP Systeme auch sehr komplexe Abragen z.B. Kundenrabattblatt in dem aus zig Files ein Preis und ein Rabattsatz ermittelt wird. So was möchte man einfach nicht in SQL nachstricken sondern lieber das RPG Programm anzapfen.

fg

Michael Haufler
- 13 Mar 2009, 5:53 pm
Michael Haufler wrote: > Sehr geehrter Herr Jordan, > > wir sind ein Konkurrenzprodukt von IBM Web Query. Mit dem Unterschied > das wir günstiger und besser sind. Die Auswertung von SQL Abfragen > ist nicht das Problem. Das beherscht unser Tool wunderbar. Es gibt > jedoch in ERP Systeme auch sehr komplexe Abragen z.B. > Kundenrabattblatt in dem aus zig Files ein Preis und ein Rabattsatz > ermittelt wird. So was möchte man einfach nicht in SQL nachstricken > sondern lieber das RPG Programm anzapfen. > > fg > > Michael Haufler
Post visible to registered members
Michael Haufler
The company name is only visible to registered members.

Re^4: Listendaten RPG --> Java
Sehr geehrter Herr Hausmann,

vielen Dank für die Info.
Kann Ihre Software mit *DBEXPORT so eine Exceltabelle auf Knopfdruck erstellen:
http://scireum.de/files/Beispielauswertung.xls
(Inkl. aller Gruppierungen, Farben, Formate)

Wenn nicht vielleicht können wir Sie auch bei bestimmten Projekten unterstützen.

mfg

Michael Haufler
- 18 Mar 2009, 08:24 am
Michael Haufler wrote: > Sehr geehrter Herr Hausmann, > > vielen Dank für die Info. > Kann Ihre Software mit *DBEXPORT so eine Exceltabelle auf Knopfdruck > erstellen: > http://scireum.de/files/Beispielauswertung.xls > (Inkl. aller Gruppierungen, Farben, Formate) > > Wenn nicht vielleicht können wir Sie auch bei bestimmten Projekten > unterstützen. > > mfg > > Michael Haufler
Jens Bleuel Premium Member Group moderator
The company name is only visible to registered members.

Re^5: Listendaten RPG --> Java
Hallo Zusammen,

man könnte auch Überlegen die Business-Logik durch ein ETL-Tool zu modelieren (Anfangs aufwändiger aber langfristig besser wartbar). Wenn das doch zu komplex ist, ggf. mit Stored Procedures die RPG Programme aufrufen bzw. direkt aus Java die RPGs aufrufen. Das hatte ich "damals" schon mal gemacht.

Übrigens gibt es mittlerweile in der Open-Source-Ecke einiges in diesem Umfeld: mit Pentaho Reporting können recht komplexe Reports im Web/PDF etc. und Excel-Dateien erstellt werden - wenn's einfacher genügt, kann das direkt in der ETL-Komponenten Pentaho Data Integration durchgeführt werden. In letzteres kann man auch eigene Java Plug-Ins integrieren, die dann die Schnittstelle zu RPG bzw. die Logig abbilden. Und das ganze ist auch in eigene Web-Anwendungen integrierbar....

Ich hatte das vor Jahren auf einer iSeries mit Java5 schon mal getestet.

Viele Grüße

Jens Bleuel
- 18 Mar 2009, 09:11 am
Jens Bleuel wrote: > Hallo Zusammen, > > man könnte auch Überlegen die Business-Logik durch ein ETL-Tool zu > modelieren (Anfangs aufwändiger aber langfristig besser wartbar). > Wenn das doch zu komplex ist, ggf. mit Stored Procedures die RPG > Programme aufrufen bzw. direkt aus Java die RPGs aufrufen. Das hatte > ich "damals" schon mal gemacht. > > Übrigens gibt es mittlerweile in der Open-Source-Ecke einiges in > diesem Umfeld: mit Pentaho Reporting können recht komplexe Reports im > Web/PDF etc. und Excel-Dateien erstellt werden - wenn's einfacher > genügt, kann das direkt in der ETL-Komponenten Pentaho Data > Integration durchgeführt werden. In letzteres kann man auch eigene > Java Plug-Ins integrieren, die dann die Schnittstelle zu RPG bzw. die > Logig abbilden. Und das ganze ist auch in eigene Web-Anwendungen > integrierbar.... > > Ich hatte das vor Jahren auf einer iSeries mit Java5 schon mal > getestet. > > Viele Grüße > > Jens Bleuel
Michael Haufler
The company name is only visible to registered members.

Re^6: Listendaten RPG --> Java
Hallo Herr Bleuel,

danke für die Anregungen. Ich denke wir werden den Weg über SPs nehmen. Direkte Calls aus Java gehe auch aber die Rückgabe der Resultsets ist bei SPs meiner Meinung nach an entspanntesten.

Kettle ist mir durchaus ein Begriff und wird auch fleißig eingesetzt. Jedoch für ETL Prozesse nicht für Reports.
Pentaho Reports steht auch immer wieder auf meiner Wachlist. Ich hoffe das hier eine Vernünftige Alternative zu "Kasper" Repoprts entsteht ;-).

mfg

Michael Haufler
- 18 Mar 2009, 09:31 am
Michael Haufler wrote: > Hallo Herr Bleuel, > > danke für die Anregungen. Ich denke wir werden den Weg über SPs > nehmen. Direkte Calls aus Java gehe auch aber die Rückgabe der > Resultsets ist bei SPs meiner Meinung nach an entspanntesten. > > Kettle ist mir durchaus ein Begriff und wird auch fleißig eingesetzt. > Jedoch für ETL Prozesse nicht für Reports. > Pentaho Reports steht auch immer wieder auf meiner Wachlist. Ich > hoffe das hier eine Vernünftige Alternative zu "Kasper" Repoprts > entsteht ;-). > > mfg > > Michael Haufler
Post visible to registered members
Holger L. Scherer Premium Member Group moderator
The company name is only visible to registered members.

Re^2: Listendaten RPG --> Java
Robert Jordan schrieb:
wie wäre es denn mit dem Nachfolger von QU1 - Web Query (Qu2, QU3 , QU4) - erstellt direkt dynamische Berichte zur i5 ohne Umweg file -> exel
Weil ich grade letzte Woche wieder Probleme damit habe, hier ein Rant von mir:

WebQuery ist der größte Müll, den IBM in den letzten Jahren zugekauft hat! Ich habe inzwischen drei PMRs offen, die dort irgendwo zwischen IBM und WebFocus rumschwirren, nur bis zu mir ist noch nichts brauchbares durchgedrungen...

QU1 ist abgekündigt
damit schiesst sich die IBM wieder eine Kugel ins Knie und vergrault die letzten Kleinanwender. Die wollen kein buntes WebQuery, die wollen mal eben ein paar Daten rausholen, und das geht mit QU1 prima.

So, genug gemotzt für heute :)

-h
- 28 Mar 2009, 04:25 am
Holger L. Scherer wrote: > Robert Jordan schrieb: > > wie wäre es denn mit dem Nachfolger von QU1 - Web Query (Qu2, QU3 , > > QU4) - erstellt direkt dynamische Berichte zur i5 ohne Umweg file -> > > exel > > Weil ich grade letzte Woche wieder Probleme damit habe, hier ein Rant > von mir: > > WebQuery ist der größte Müll, den IBM in den letzten Jahren zugekauft > hat! Ich habe inzwischen drei PMRs offen, die dort irgendwo zwischen > IBM und WebFocus rumschwirren, nur bis zu mir ist noch nichts > brauchbares durchgedrungen... > > > QU1 ist abgekündigt > > damit schiesst sich die IBM wieder eine Kugel ins Knie und vergrault > die letzten Kleinanwender. Die wollen kein buntes WebQuery, die > wollen mal eben ein paar Daten rausholen, und das geht mit QU1 prima. > > So, genug gemotzt für heute :) > > -h
Michael Haufler
The company name is only visible to registered members.

Re^3: Listendaten RPG --> Java
Hallo Herr Scherer,

ich denke mit QU1 meinen Sie Query/400, was sicherlich eine feine Sache ist. Ich habe damit auch mehrere Jahre sehr intensiv gearbeitet.
Leider gibt es auch einige sehr ärgerlichen Einschränkungen.
1. Von einem Query kann man nur auf eine Datei nicht auf ein anderes Query zugreifen (SQL kann das...sogar MS Access ;-) gerade bei BWAs mit Umsatz aktuelles und Vorjahr ist das super ärgerlich)
2. Mit Query kann man ein Ergebnisfeld nicht so nennen wie ein bestehendes Feld in einer der Dateien (wiederum SQL kann das wunderbar mit "as".
3. Warum um alles in der Welt kann man nur neun Gruppenwechsel machen ?! (Bei SQL ist das limit für GROUP PY bei 32.000 Zeichen!)
4. Man kann jedes Query mit RTVQMQRY in SQL umkompilieren. Warum nimmt das Query dann nicht den neuen Optimizer
5. Aufruf durch den Benutzer mit RecordSelection *YES ist alles andere als komfortabel.

Für kleine schnelle sachen (mal eben reinschauen warum...) kann ich natürlich heute auch noch nicht widerstehen, für regelmäßige Abfragen die eventuell auch noch Endbenutzern zur Verfügung gestellt werden sollen gibt es aber wirklich bessere Alternativen.

Da sie mit IBM Web Query nicht ganz zufrieden sind könnte ich Ihnen eventuell eine Alternative anbieten.
Bei Interesse können Sie mir gerne eine kurze Nachricht zukommen lassen, ich melde mich dann bei Ihnen.

freundliche Grüße
Michael Haufler
- 29 Mar 2009, 2:31 pm
Michael Haufler wrote: > Hallo Herr Scherer, > > ich denke mit QU1 meinen Sie Query/400, was sicherlich eine feine > Sache ist. Ich habe damit auch mehrere Jahre sehr intensiv > gearbeitet. > Leider gibt es auch einige sehr ärgerlichen Einschränkungen. > 1. Von einem Query kann man nur auf eine Datei nicht auf ein anderes > Query zugreifen (SQL kann das...sogar MS Access ;-) gerade bei BWAs > mit Umsatz aktuelles und Vorjahr ist das super ärgerlich) > 2. Mit Query kann man ein Ergebnisfeld nicht so nennen wie ein > bestehendes Feld in einer der Dateien (wiederum SQL kann das > wunderbar mit "as". > 3. Warum um alles in der Welt kann man nur neun Gruppenwechsel machen > ?! (Bei SQL ist das limit für GROUP PY bei 32.000 Zeichen!) > 4. Man kann jedes Query mit RTVQMQRY in SQL umkompilieren. Warum > nimmt das Query dann nicht den neuen Optimizer > 5. Aufruf durch den Benutzer mit RecordSelection *YES ist alles > andere als komfortabel. > > Für kleine schnelle sachen (mal eben reinschauen warum...) kann ich > natürlich heute auch noch nicht widerstehen, für regelmäßige Abfragen > die eventuell auch noch Endbenutzern zur Verfügung gestellt werden > sollen gibt es aber wirklich bessere Alternativen. > > Da sie mit IBM Web Query nicht ganz zufrieden sind könnte ich Ihnen > eventuell eine Alternative anbieten. > Bei Interesse können Sie mir gerne eine kurze Nachricht zukommen > lassen, ich melde mich dann bei Ihnen. > > freundliche Grüße > Michael Haufler

Back
Next