RabbitMQ AMQP(Advanced Message Queuing Protocol)

[tarkusch]

Hallo,

Betrete hier Neuland und bin für jeden Tipp dankbar.

Wie kann ich von der AS400 AMQP send/receive machen?
Als AMQP Broker verwenden wir RabbitMQ.

Wollen das in Zukunft unser DataSync direkt auf einen QMQP verbindet und Messages(JSon-Files) liest/schreibt.

Wie sollte ich an dieses Thema rangehen? Wo könnte ich mich einlesen?

Im Internet habe ich den Link gefunden, aber mir ist der Ablauf nicht klar.
https://jbrisbin.wordpress.com/2010/...itmq-and-java/

Dank im Voraus

[Fuerchau]

Bevor man da mühsam wieder RPG mit Java bemüht ist es besser, dies native direkt in Java zu machen.
Du kannst das schön in Eclipse entwickeln und testen, schiebst das dann auf die AS/400 und lässt das per JAVA-Kommando ausführen.
Auch die Schnittstellen zur eigenen Datenbank sind dann komfortabel per JDBC und Toolbox verwendbar.
Ob das fertige Java-Archiv dann auf der AS/400 oder auf einem Windowsserver (Aufgabenplanung) oder sonstwo läuft ist dann vollkommen egal.

[tarkusch]

Du kannst das schön in Eclipse entwickeln und testen, schiebst das dann auf die AS/400 und lässt das per JAVA-Kommando ausführen.

Wie ist das gemeint?
Schreibe ich dann ein ServiceProgramm, welches das Java-Pgm aufruft?

     D getExampleValue...
     D                 PR             8F   ExtProc(*JAVA:
     D                                      'com.npci.cloud.iseries.+
     D                                       CALIB.CA9050JSRV':
     D                                      'getExampleValue')
     D  company                      10I 0 VALUE
     D  store_number                 10I 0 VALUE
     D  bus_date                     10I 0 VALUE

Sorry, ich stehe bei diesem Thema völlig auf der Leitung.

[Fuerchau]

Um Gottes Willen....

Nein!
Man installiert auf einem Windowsrechner (Linux geht wohl auch) ganz einfach Eclipse.
Die Java-Toolbox der AS/400 zieht man sich von dort.
Dann startet man eine Java-Entwicklung per Eclipse und schreibt sein Java-Programm.
Aber ich denke, das wird dir ein Java-Entwickler (z.B. D*B) besser erklären können.

Der Weg wäre z.B.:
Das Javaprogramm liest aus der QMQP die JSON-Daten, formatiert die DB-gerecht um und schreibt diese auf die DB oder sendet diese an eine DTAQ.
Auf der DB-Tabelle kann dann ein Trigger die Daten direkt verarbeiten und weiterleiten/verteilen.
DTAQ-Verarbeitung dürfte dir nichts neues sein.
Dies tut das Java-Programm solange bis der Job gezielt beendet wird.

[BenderD]

Wie ist das gemeint?
Schreibe ich dann ein ServiceProgramm, welches das Java-Pgm aufruft?

     D getExampleValue...
     D                 PR             8F   ExtProc(*JAVA:
     D                                      'com.npci.cloud.iseries.+
     D                                       CALIB.CA9050JSRV':
     D                                      'getExampleValue')
     D  company                      10I 0 VALUE
     D  store_number                 10I 0 VALUE
     D  bus_date                     10I 0 VALUE

Sorry, ich stehe bei diesem Thema völlig auf der Leitung.

... ich habe mit AMQP keine eigene Erfahrung und finde für meinen Geschmack bei den Stichworten AMQP und insbesondere RabbitMQ zuviel Rauch (reichlich Schlagworte vertreten) und zu wenig Feuer (Inhalt!).

Synchrone Aufrufe von Java per RPG JNI würde ich prinzipiell vermeiden, das skaliert nicht vernünftig und freut allenfalls IBM und JSON Verarbeitung per RPG ist für mich ungefähr genauso sinnvoll, wie das schreiben einer Dialoganwendung mit CL. Sicherlich geht vieles, wenn man die limitierten Möglichkeiten einer Programmiersprache trickreich ausreizt und als technisches Muster mag das auch Spass machen, aber andere sollen das ja dann auch verstehen, verwenden, Fehler analysieren und Änderungen vornehmen können.
Ohne die wirkliche Aufgabenstellung zu kennen, ist es immer schwierig Ratschläge zu geben (eines der großen Probleme in Foren), versuche ich es trotzdem wieder mal:
Wenn ich denn als Client einen mehr oder weniger nebulösen Serverdienst verwenden muss, dann suche ich erst mal eine möglichst standardisierte Implementierung, der ich vertraue (bei RabittMQ hätte ich da erst mal Probleme), Java oder .Net geht (fast) immer, ich würde Java vorziehen, weil ich das besser beherrsche und eine eigene Middleware (ist auch Open Source) für performante Schnittstellen zwischen Java und AS/400 native (sprich RPG) habe.
Aus der fachlichen Analyse bekomme ich dann (Wunsch) Schnittstellen in RPG Denke und Notation, vorstellbar als Prototyp in der Form:

d getSomeDS PR like(someDS)
d EXPROC('SRVPGMXXX_getSomeDS')
d someInfo like(someInfo)

Das gesamte JSON Geschäft, inklusive Transfer der DS someInfo) nach JSON und Extraktion von someInfo aus der Anwort des Serverdienstes würde ich in Java machen. Im Java erfolgt dann auch der Aufruf des eigentlichen Serverdienstes, zusätzlich natürlich auch einstellbare Protokollierungen per log4j etc.

D*B

[mihael]

Bevor man da mühsam wieder RPG mit Java bemüht ist es besser, dies native direkt in Java zu machen.
Du kannst das schön in Eclipse entwickeln und testen, schiebst das dann auf die AS/400 und lässt das per JAVA-Kommando ausführen.
Auch die Schnittstellen zur eigenen Datenbank sind dann komfortabel per JDBC und Toolbox verwendbar.
Ob das fertige Java-Archiv dann auf der AS/400 oder auf einem Windowsserver (Aufgabenplanung) oder sonstwo läuft ist dann vollkommen egal.

Ich bin etwas spät dran zu diesem Thema, möchte aber dennoch meinen Senf dazugeben, da ich es immer wieder nervend finde, wieso alle Welt meint, dass man so was (und andere Sachen) nicht in ILE mache könnte und das ganze ordentlich von RPG aus ansprechen könnte.

Zum einen gibt es das STOMP Protokoll, welches ein einfaches Textprotokoll ist, mit dem man verschiedenste Message Queues ansprechen kann, u. a. ActiveMQ und auch RabbitMQ.

Da das STOMP Protokoll so einfach ist, gibt es hierfür auch gleich einige Client Implementierungen. Eine sogar in RPG (wobei das noch ein Prototyp ist und es noch Probleme gibt bei der Socketverbindung zu einem nicht lokal laufenden Server, aber das lässt sich sicher noch hinkriegen. 99% der Arbeit ist schon getan). http://rpgnextgen.com/index.php?content=stomp

Zum anderen gibt es genügend STOMP C clients, die man sicher auch nach ILE C portieren kann. Vielleicht ist portieren auch schon zu viel des guten und es reich ein einfaches kompilieren, wenn der Quellcode kompatibel ist.

Notiz: Dieser Beitrag geht davon aus, dass nicht zwingenderweise AMQP verwendet werden muss, sondern nur aus Unwissenheit nicht nach Alternativen gesucht wurde.

[BenderD]

... da ich es immer wieder nervend finde, wieso alle Welt meint, dass man so was (und andere Sachen) nicht in ILE mache könnte und das ganze ordentlich von RPG aus ansprechen könnte.

... dass diese blaugestreiften RPG Begeisterten immer so empfindlich reagieren müssen!?

Ich kann nicht erkennen, dass hier jemand gemeint hat, dass man das mit RPG nicht machen kann - zwischen machen können und machen mag es allerdings zuweilen Unterschiede geben.

Ich für meinen Teil habe mich zu diesem Thema (mangels einschlägiger Erfahrung) lediglich geäußert, da ich per PM des TE darum gebeten wurde und geschrieben wie ich vorgehen würde. Nebenbei bemerkt: Dein Vorschlag hört sich für mich nach F&E an und bietet mir die Auswahl zwischen einem bestenfalls Beta RPG Stand und dem Versuch eine C Implementierung einer anderen Plattform zu compilieren, hilfsweise zu portieren, hört sich spannend an, hätte ich aber wahrscheinlich keinen Bock drauf - und ob das Protokoll frei wählbar ist, ist ja auch noch offen.

D*B

[Rainer Ross]

Hallo Forum,

ich werfe noch ein paar Ideen in die Runde.

Wer die RabbitMQ kostenlos testen möchte, kann hier https://www.cloudamqp.com/ einen Probeaccount registrieren.

Damit RabbitMQ angesprochen werden kann, gibt es verschiedene Clients. Die für IBM i Entwickler interessanten Clients sind meiner Meinung nach der JAVA und die Node.js Client.

- Java gibt es schon lang auf der IBM i und da hat D*B gutes Know-how
- Node.js gibt es ab 7.2 als OpenSource mit dem kostenlosen Lizenzprogramm 5733OPS

Die Installation des Rabbit Clients auf der IBM i geht mit dem Node.js Package Manager einfach mit "npm install amqplib" Quelle https://www.rabbitmq.com/tutorials/tutorial-one- javascript.html

Node.js kann auf IBM i Ressourcen wie DB/2 über SQL, Dataqueues und RPG-Programme zugreifen oder als Webservice auf der IBM i eingerichtet und mit RPG und embedded SQL angesprochen werden.
Hier ist ein Beispiel, wie man mit RPG, einer DataQueue und dem Twilio-Client professionell SMS-Nachrichten von der IBM i versenden kann https://github.com/RainerRoss/Send-S...lio-from-IBM-i

Was das Erzeugen und Parsen von JSON-Daten auf der IBM i betrifft, habe ich folgende Erfahrung, da ich viele Webanwendungen für Kunden entwickle, die über AJAX und JSON mit der IBM i als Webserver kommunizieren: JAVA, JavaScript und PHP können sehr gut JSON erzeugen und parsen.

Auf der IBM i kann man JSON-Daten direkt in der DB2 in einem Character oder besser CLOB-Feld speichern und mit der SQL-Function JSON_TABLE auch wieder parsen. Ich wünsche mir noch eine Möglichkeit mit Bordmitteln der IBM i direkt aus der DB2 JSON zu erzeugen. Da hoffe ich auf den nächsten Technologierefresh. In der Zwichenzeit arbeite ich mit den YAJL-Tools von Scott Klement, die OpenSource https://www.scottklement.com/yajl/ in C geschrieben und deshalb überragend performant sind.

-- Tabelle erstellen

create or replace table mylib.wrkjson (                             
       id        int       not null default,
       json_data clob(16M) not null default ccsid 1208                       
);

-- JSON-Daten einfügen

insert into mylib.wrkjson 
           (id, json_data)
    values (1, '{
    "success": true,
    "errmsg": "",
    "items": [
        {
            "id": 1,
            "name": "MINERALÖL-TANKSTELLE",
            "land": "DE",
            "plz": "12559",
            "ort": "BERLIN",
            "str": "GOETHESTR. 8",
            "umsatz": 535647.59,
            "kredit": 5000.00,
            "saldo": 1650.00,
            "aendatum": "2015-02-06"
        }
    ]
}');

-- JSON Daten parsen

Select x.*
  from mylib.wrkjson,
   JSON_TABLE(
     json_data, 
     '$'
     Columns(
        nested '$.items[*]' columns(
            "Id"     integer        path 'lax $.id',
            "Name"   varchar(40)    path 'lax $.name'   
        )
    )
  ) x; 

Herzliche Grüße
Rainer

[tarkusch]

Hallo,

Danke Aufrichtig für euren tollen Input von allen Seiten.
Da habe ich einiges zum Studieren.

Glg

[BenderD]

Auf der IBM i kann man JSON-Daten direkt in der DB2 in einem Character oder besser CLOB-Feld speichern und mit der SQL-Function JSON_TABLE auch wieder parsen. Ich wünsche mir noch eine Möglichkeit mit Bordmitteln der IBM i direkt aus der DB2 JSON zu erzeugen.

an der Inflation von SQL Table Functions der letzten Zeit stören mich gleich mehrere Sachen:
- eingeschränkte Portabilität innerhalb DB2/400 (wo ist den jetzt welcher TR installiert?)
- zum großen Teil fehlen selbst für ältere functions die Dokus in der SQL Reference (da gehört sowas hin und nicht in halboffizielle Quellen)
- man verliert die Portabilität von SQL (deshalb machen Oracle und IBM und Co. sowas recht gerne)
- Datenbank ist Datenbank und gehört von Applikationslogik getrennt (das ist für mich das wichtigste _ Design Sünden wird man nur zu hohen Preisen wieder los!!!)
- die Parameterschnittstellen der Funktionen sind recht komplex.
- die JSON und XML functions sind in ihrer Funktion eng limitiert, insbesondere beim error handling wirds schwierig, wenn man mehr Info braucht als "ging leider nicht"

D*B

[dschroeder]

- zum großen Teil fehlen selbst für ältere functions die Dokus in der SQL Reference (da gehört sowas hin und nicht in halboffizielle Quellen)
D*B

Da muss ich dir wirklich Recht geben. Die Doku-Politik von IBM ist echt katastrophal. Man traut sich ja kaum, auf den Original IBM-Seiten mal nach etwas zu suchen. Das artet oft in ein konfuses Hier- und Da-Klicken aus.

Dieter S.

[BenderD]

... nicht finden macht ja (fast) nichts, fatal sind Pseudodokumentationen in Redpapers, Redbooks, Tech Notes etc. die falsch sein können oder nur fast richtig sind und sich beim nächsten relase oder TR wieder ändern.

D*B