SQL Based Webservice im IWS: Get mit Input-JSON

[dschroeder]

Hallo Baldur,
ich verstehe deine Antwort nicht. Möglicherweise habe ich meine Frage nicht richtig rübergebracht.
Deshalb noch mal etwas klarer:

1. Ich möchte einen Webservice mit dem IWS erstellen.
2. Da die Rückgabewerte bei RPG-basierten Services relativ klein sind, möchte ich einen SQL-basierten Service erzeugen.
3. Der SQL-basierte Service besteht aus einer SQL-UDF, die ein clob (mit JSON-Inhalt) zurückgibt.
4. Im Erfolgsfall wird ein JSON zurückgeliefert und der http Statuscode wird (automatisch vom IWS) auf 200 gesetzt. Das ist genau so, wie ich es haben möchte.
5. Im Fehlerfall (fachlicher Fehler) möchte ich ebenfalls ein JSON mit den Fehler-Informationen zurückliefern und ich möchte den HTTP-Statuscode auf 400 (oder wegen mir auch 500) setzen. Das klappt nicht.
   Um den IWS dazu zu bewegen, den Statuscode auf ungleich 200 zu setzen, muss ich einen (technischen) SQL-Fehler erzeugen. Wenn ich das tue, kann ich aber kein JSON mehr zurückgeben.

Falls da jemand eine Idee hat ...

LG, Dieter

[Fuerchau]

Wenn eine SQL-Funktion einen SQLSTATE und SQL-Diagnostics zurück gibt, gehe ich ganz stark davon aus, dass der Text im Response zurück gegeben wird. Ein zusätzliches JSON macht da keinen Sinn.

https://www.ibm.com/docs/en/i/7.5?to...eter-style-sql

Siehe SQLSTATE und Diagnostic Message.
Das kannst du wohl auch kurz testen, in dem du eine unbekannte Funktion aufrufst. Da wiird dir bestimmt mehr also nur der Errorcode zurückgegeben.

[dschroeder]

Wenn eine SQL-Funktion einen SQLSTATE und SQL-Diagnostics zurück gibt, gehe ich ganz stark davon aus, dass der Text im Response zurück gegeben wird. Ein zusätzliches JSON macht da keinen Sinn.

Es geht hier allerdings nicht primär um den Aufruf einer SQL-Funktion, sondern um einen Webservice, der im IWS als sogenannter "SQL-based" -Service definiert ist. Bei einem Webservice macht ein JSON (meines Erachtens) immer Sinn. Der Konsument des Webservices soll ja gar nicht wissen, dass der Webservice intern SQL-basiert arbeitet. Er soll als Antwort immer ein Json und den passenden Statuscode zurückbekommen. Mit einem SQL_status kann der Konsument nichts anfangen.

[Andreas_Prouza]

Der IWS ist sehr beschränkt in vielen Bereichen (dabei rede ich noch nicht einmal von Versionsverwaltung, Deployment usw.).
Deshalb habe ich mit Python auf der IBM i ein kleines Beispiel-Projekt auf Github für WebServices erstellt:
https://github.com/andreas-prouza/python-webapi

Das habe ich schon bei einigen Kunden produktiv seit mehreren Jahren im Einsatz.
Noch nie ein Absturz oder Probleme.
Und solche Anforderungen wie du sie Beschrieben hast, sind ein einfacher 2-Zeiler.

Das würde in Python so aussehen:

return Response({'a':'b'}, status=400, mimetype='application/json')

[dschroeder]

Hallo Andreas,
ich würde gerne auf eine weitere Technologie, in der sich bei uns keiner auskennt (Python), verzichten.

Eine schöne Webservice Lösung in nativem RPG fände ich toll.

[Andreas_Prouza]

Hi Dieter,

Das verstehe ich auch sehr gut.
Ergänzend sei hier nur angemerkt, dass die Kunden bei denen ich es im Einsatz habe sich ebenfalls großteils nicht mit Python auskennen.
Ich habe ihnen das Grundgerüst installiert und der Rest ist Copy/Paste wodurch man sich auf das SQL konzentrieren kann.
Somit war es für die Kollegen einfacher dort eine Änderung/Erweiterung durchzuführen als PHP, Java oder IWS ... so wie ja auch bei deinem Beispiel jetzt :-)
Außerdem verwende ich Python nur für die Schnittstelle zur Web-Welt. Alles andere bleibt in SQL/RPG.

Auch das Generieren oder Auslesen von JSON/XML ist ein 1 Zeiler.
Ich bin ein Fan von SQL und RPG, jedoch im Vergleich zu (z.B.) Python benötigt man viel mehr Aufwand und ist viel komplexer ein JSON/XML.

Ich sag nur, dass ihr immer wieder in Zukunft in solche Sackgassen kommen werdet und dann viel Aufwand betrieben wird dort wieder raus zu kommen.
Ist natürlich immer eine Frage von Kosten/Nutzen und ob man das ganze langfristig betreiben will (Stichwort: Nachwuchs), oder nur bis zur Ablöse irgendwie am Leben erhalten möchte.

Ich beschäftige mich seit sehr langer Zeit, sehr viel mit WebServices. Wenn ich einen alternativen Hinweis für dein Problem hier hätte, würde ich ihn dir gerne liefern.

[dschroeder]

Vielen Dank für deine ehrliche Antwort, Andreas.

Wenn ich deine Lösung richtig verstehe, sähe es folgendermaßen aus:

1. Jemand (z.B. Du) installiert ein bisschen Software auf unserem System. Damit müssten wir uns nicht rumschlagen.
2. Wir zusammen würden (sehr kleine) Python Scripte erstellen, die uns den "Webservice-Kram" vom Hals halten. In so einem Script (was man einfach kopieren und anpassen kann) können SQL-Anweisungen ausgeführt werden.
3. Die Scripte können Clobs oder Blobs zurückliefen.
4. Ich nehme mal an, dass wir den IWS dann nicht mehr brauchen würden. Es würde je Service ein Python Script erstellt und als SBMJOB ausgeführt?
5. Die Jobs könne ich debuggen (ich meine nicht das Python, sondern das, was im SQL aufgerufen wird (UDF, RPG). Oder läuft das in einer "merkwürdigen" Umgebung, wo man nicht rankommt?

Habe ich das grob so korrekt verstanden?

[Andreas_Prouza]

@1: Genau, entweder habt ihr jemanden mit Erfahrung mit Python, ansonsten unterstütze ich gerne

@2: Genau, im Prinzip ist es immer der gleiche Aufbau:

• Funktion erstellen (z.B. hier get_active_jobs(subsystem))
• Die gewünschte Route (URL-Pfad) dafür festlegen (@app.route)
• Funktions-Code selbst

cnxn = pyodbc.connect('DSN=*LOCAL')
cursor = cnxn.cursor()


@app.route('/get-active-job/', methods=['GET', 'POST'])
def get_active_jobs(subsystem):

cursor.execute("Select job_name, subsystem, job_type, thread_count, cpu_time, function_type, FUNCTION, job_status \
from table(QSYS2.ACTIVE_JOB_INFO(SUBSYSTEM_LIST_FILTER=>upper(?))) t", subsystem)

rows = cursor.fetchall()

return jsonify(result)



Diesen Block kannst du kopieren. Statt SELECT kannst du auch einen CALL absetzen (dadurch auch RPG direkt aufrufen) ... halt alles was SQL unterstützt.

@3: CLOB & Co sind kein Problem. Hab ich auch in Verwendung. Python & ODBC handeln das automatisch.

@4: Genau, kein IWS. Man kann (und sollte) einen vorgelagerten Webserver verwenden (Apache oder NGINX).
Dieser leitet die Anfragen weiter an den Applikation Server (Python).
Ist beim IWS genauso. Dadurch können im WebServer diverse Konfigurationen vorgenommen werden, wie Berechtigungen und Verschlüsselung (HTTPS) und der Applikations Server braucht sich nur um die Verarbeitung kümmern.

Du kannst die Funktionen in diverse Skripts verteilen (am Besten mit entsprechender Ordnerstruktur je Bereich).

Grundsätzlich können die unterschiedlichen Requests alle unter dem gleichen Applikations-Server laufen.
Man kann aber auch mehrere WebServer und/oder mehrere Applikations-Server verwenden wenn man will. Es muss halt die Python App (das Grundgerüst) mehrfach kopiert werden.

@5: Zunächst gibt es die Möglichkeit vom Logging. Du kannst alles im Python in ein Log ausgeben lassen.
Für mich reicht das aus um damit den SQL Aufruf nachzustellen und ggf. interaktiv zu debuggen.
Ansonsten verbindet sich Python via ODBC mit der DB2. Dadurch sind das normale Jobs in der QUSRWRK.
Um diese Jobs direkt zu debuggen gibt es mehrere Möglichkeiten. Man könnte z.B. im RPG ein DSPLY mit Antwort-Aufforderung einbauen. Dadurch steht der Job auf MSGW und man kann sich via STRSRVJOB verbinden und mit STRDBG debuggen.

In der Regel reicht jedoch das Logging aus. Im IWS hab ich ja gar kein Logging, bis auf das was der IWS von sich aus ausgibt.

[Fuerchau]

Als weitere Alternative wird auch Node.js unterstützt. Hier ist die Unterstützung genauso native und die Node.js-Community ebenso groß.
Es kommt ja immer nur darauf an, die richtigen Externen Mitarbeiter zu finden, die einem die Probleme abnehmen. Ich lebe davon seit 1997.

[dschroeder]

Vielen Dank an euch beide!

Ich werde das hier mal ansprechen. Mal sehen, ob wir einen der er beiden Wege gehen.

[Fuerchau]

Node.js läuft native auf der IBM i, ein zusätzlicher Web-Server ist nicht erforderlich, da Node.js Web-Requests behandeln kann, genauso auch wie auch DB-Zugriffe.
Man braucht auch keine Angst vor Performance haben. Mein Kunde betreibt einen Web-Shop, der 1000de JSON-Abfragen sowie Order-Uploads pro Minute schafft, ohne die ERP-Software zu beeinträchtigen.