RabbitMQ AMQP(Advanced Message Queuing Protocol)

[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