Lesender Zugriff auf Redis per RPG

[dschroeder]

Ich hatte schon befürchtet, dass ich hier eine Grundsatzdiskussion auslöse. Das war aber nicht meine Absicht.

Ich denke, ich bin da etwas missverstanden worden. Ob wir fremde Software einsetzen oder nicht, hängt natürlich zunächst davon ab, ob wir die Lösung mit vertretbarem Aufwand überhaupt selbst entwickeln könnten. Beim Office Paket ist das augenscheinlich nicht der Fall.

Wenn wir dann bei einem Probem, das wir selber lösen könnten, vor der Entscheidung stehen, ob wir Fremdsoftware einsetzen oder ob wir es selber bauen, stellen wir uns folgende Fragen:
- Wieviel Aufwand erspart uns die fremde Lösung?
- Wie abhängig machen wir uns von der fremden Software?
- Wie kritisch ist unser Problem, also: wie schnell benötigen wir einen workaround, falls die fremde Software mal nicht mehr läuft und wie schnell könnten dann wir einen workaround selber schaffen?

Was wir im konkreten Fall für den Redis Zugriff benötigen, ist ja nur ein sehr kleines Tool. Aber es wird an einer kritischen Stelle eingesetzt. Deshalb fände ich es besser, dieses Tool vollständig unter Kontrolle zu haben. Und deshalb fände ich ein Code-Snippet oder etwas ähnliches besser. Wenn es das nicht gibt, muss ich neu überlegen.

Zum Thema OpenSource: Ich habe die Befürchtung, dass, wenn eine Software komplex genug ist, einem OpenSource nicht zwingend weiterhilft. Man muss ja im Zweifel auch genug Zeit und Ressourcen haben, um den OpenSource Code zu lesen, zu verstehen und ggf. zu korrigieren. (Das ist allgemein gemeint. Ich habe überhaupt keine Ahnung, wie komplex ArdGate ist).

[dschroeder]

Übrigens noch eine Anmerkung zum IBM Support. Ich hatte schon oft mit dem Support zu tun. Die Webseiten von IBM sind immer noch furchtbar. Aber wenn man es geschafft hat, ein Ticket zu eröffnen (geht ja auch telefonisch), bekommt man meiner Erfahrung nach hervorragenden Support. Schnell und kompetent. Und IBM bleibt solange am Ball, bis das Problem gelöst ist. Das klappt natürlich alles am besten, wenn man sich komplett in der IBM Schiene befindet. Bei einem Problem im RDi bezieht der Support bei Bedarf z.B. automatisch Leute von der Datenbankentwicklung mit ein.

Ich muss allerdings zugeben, dass ich nicht weiß, wieviel der Wartungsvertrag kostet.

[ExAzubi]

Warum kapselst du nicht Dieter's Lösung in ein eigens PGM und ließt (rufst) das PGM als SPECIAL Datei auf. Dann sollte doch alles so sein wie gewünscht...

[dschroeder]

Danke für deine Anwort.
Aber wie ich schon sagte, ist das Installieren einer größeren Software nur eine Option, wenn wir keine einfachere Möglichkeit finden. Dieter Benders Lösung läuft ja letztendlich auch darauf hinaus, dass wir den Redis mittels Java ansprechen. Das könnten wir auch machen, indem wir eine Java-Klasse in RPGLE embedden. Das würde für uns weniger "fremde" Software bedeuten. Ist auch nicht schön, da in dem RPG Job dann immer eine VM hochgezogen wird. Aber das wäre in unserem Fall nicht tragisch, da der Job sowieso als Batch-Job den ganzen Tag über laufen wird.

Aber noch lieber wäre mir eben eine Lösung, die nativ mit RPG auskommt oder auch mit SQL. Aber das scheint es ja nicht zu geben bzw. das wohl noch niemand aus dem Forum programmiert.

Dieter

[Rainer Ross]

Hallo Dieter,

ich hatte mal die Aufgabe die Cloud Datenbank "Cloudant" der IBM anzuprogrammieren. Hier werden für alle Datenbankfunktionen Webservices zur Verfügung gestellt. Ich denke, dass es für Redis ähnlich sein sollte.

Diese Funktionen teste ich mit Google Postman und implementiere sie dann mit den SQL-Funktionen HTTPGETCLOB oder HTTPPOSTCLOB. Das funktioniert sehr gut und ist sehr performant.

Rainer

[BenderD]

Hallo Dieter,

ich hatte mal die Aufgabe die Cloud Datenbank "Cloudant" der IBM anzuprogrammieren. Hier werden für alle Datenbankfunktionen Webservices zur Verfügung gestellt. Ich denke, dass es für Redis ähnlich sein sollte.

Diese Funktionen teste ich mit Google Postman und implementiere sie dann mit den SQL-Funktionen HTTPGETCLOB oder HTTPPOSTCLOB. Das funktioniert sehr gut und ist sehr performant.

Rainer

... das mit der Performance wage ich zu bezweifeln (oder ich habe eine andere Vorstellung von sehr performant). Die Implementierung ist Java und fährt eine JVM im aufrufenden Job hoch. Funktioniert sehr gut: nur solange, wie man in dem Job nicht selber was mit Java machen will. Das sind doch mit heißer Nadel gestrickte Krücken, von denen ich abraten würde.

D*B

[Andreas_Prouza]

Bei zeitkritischen Prozessen sollte man hier den Weg über vorgestartete Jobs die via Data Queue angesteuert werden nachdenken.
Dann fällt das Problem mit der gestarteten JVM weg, da dies dann nur 1 mal für den vorgestarteten Job gemacht wird.
Funktioniert prima.
Auch synchron wenn gewünscht mit Rückantwort.

[BenderD]

... redis ist eine Art cache von Parametern, eingesetzt als schnellere Alternative zur Datenbank; da würde ich die Anzahl der Layer klein halten, da wäre mir Webservice via Java und SQL schon fragwürdig.

[dschroeder]

Ich habe auch gelesen, dass Redis als Cache Unterstützung verwendet werden kann. Bei uns haben wir aber einen anderen Einsatzzweck: Wir nutzen Redis als Message System für Events. Wenn z.B. in einer (nicht auf der i laufenden) Java Anwendung ein neuer Datensatz angelegt wird, sendet die Java Anwendung per Redis ein entsprechendes Ereignis. Jede andere Anwendung, die sich auf genau dieses Ereignis abonniert hat, weiß dann, das es neue Daten gibt und dass diese (per Webservice) vom anderen System geholt werden können.
Das heißt, Geschwindigkeit ist gar nicht so entscheidend in unserem Fall.

[BenderD]

Ich habe auch gelesen, dass Redis als Cache Unterstützung verwendet werden kann. Bei uns haben wir aber einen anderen Einsatzzweck: Wir nutzen Redis als Message System für Events. Wenn z.B. in einer (nicht auf der i laufenden) Java Anwendung ein neuer Datensatz angelegt wird, sendet die Java Anwendung per Redis ein entsprechendes Ereignis. Jede andere Anwendung, die sich auf genau dieses Ereignis abonniert hat, weiß dann, das es neue Daten gibt und dass diese (per Webservice) vom anderen System geholt werden können.
Das heißt, Geschwindigkeit ist gar nicht so entscheidend in unserem Fall.

... seltsames Design, wer lässt sich denn sowas einfallen, wo es doch messanger systeme genug gibt, open source und auch von IBM, wenn man mehr Geld für weniger Support bezahlen will. Wie auch immer, gibt es immer Lösungen, die krumme Wege wieder zum Ziel leiten.
Vielleicht findest Du ja hier was:
https://stackoverflow.com/questions/...edis-datastore
Weiterreichen kann man das event dann über MQ-series, einen anderen messanger oder in eine DB2 Tabelle auf der as400 schreiben, die dann per Trigger synchron reagiert.

D*B

[dschroeder]

Vielen Dank. Werde ich mir mal ansehen.

[Rainer Ross]

Ich habe auch gelesen, dass Redis als Cache Unterstützung verwendet werden kann. Bei uns haben wir aber einen anderen Einsatzzweck: Wir nutzen Redis als Message System für Events. Wenn z.B. in einer (nicht auf der i laufenden) Java Anwendung ein neuer Datensatz angelegt wird, sendet die Java Anwendung per Redis ein entsprechendes Ereignis. Jede andere Anwendung, die sich auf genau dieses Ereignis abonniert hat, weiß dann, das es neue Daten gibt und dass diese (per Webservice) vom anderen System geholt werden können.
Das heißt, Geschwindigkeit ist gar nicht so entscheidend in unserem Fall.

In diesem Fall sieht es so aus, dass es einen fertigen Node.js Client gibt https://www.npmjs.com/package/redis der das Event abonniert. Diese Events schreibt man dann in eine DTAQ oder in eine DB2 Tabelle mit Trigger für die weitere Verarbeitung. Auf https://github.com/RainerRoss/Send-S...taFromQueue.js hab ich ein Beispiel für ein Programm das Daten aus einer DTAQ liest, um zu zeigen, dass es nicht sehr kompliziert ist. Wir können auch über das Thema telefonieren.