IWS und Body

**dschroeder** · 23-07-20, 11:58

Vielen Dank für Eure Antworten.

Ja, SQL haben wir bereits ausprobiert und grundsätzlich funktioniert es. Bisher ist es uns allerdings nur gelungen, eine "flache" JSON-Liste herauszubekommen. Komplexe JSON-Objekte kann man wohl nicht mit SQL machen, oder? Ich dachte, man könnte vielleicht mit JSON_OBJECT usw. selber ein JSON-Objekt bauen und dann zurückgeben. Hat aber bisher nicht geklappt. Der IWS hält das JSON-Object einfach für einen String und escaped die Klammern.

Auch nochmal herzlichen Dank an xenofob. Deine Aussagen zum IWS und den Beschränkungen bei den Parametern war genau das, was mir unklar war.

@Rainer: Wird würden natürlich gerne so viel wie möglich standardisiert machen. Wenn uns der IWS nicht reicht, gucken wir uns gerne deine Lib an. (Das du hochklassige Software schreiben kannst, hast du bei uns ja bereits bewiesen!).

Tja, dann mache ich mal weiter. Nochmals danke an alle.

Dieter

**andreaspr@aon.at** · 23-07-20, 17:37

Zitat von dschroeder

Ja, SQL haben wir bereits ausprobiert und grundsätzlich funktioniert es. Bisher ist es uns allerdings nur gelungen, eine "flache" JSON-Liste herauszubekommen. Komplexe JSON-Objekte kann man wohl nicht mit SQL machen, oder? Ich dachte, man könnte vielleicht mit JSON_OBJECT usw. selber ein JSON-Objekt bauen und dann zurückgeben. Hat aber bisher nicht geklappt. Der IWS hält das JSON-Object einfach für einen String und escaped die Klammern.

Hallo Dieter, du kannst mit den JSON Aggregationsfunktionen auch komplexe JSON Daten erzeugen. Ähnlich wie mit den XML Funktionen in SQL.

lg Andreas

**dschroeder** · 31-07-20, 11:31

Hallo Dieter, du kannst mit den JSON Aggregationsfunktionen auch komplexe JSON Daten erzeugen. Ähnlich wie mit den XML Funktionen in SQL.

Natürlich kann man

Du musst lediglich mit mehreren Common Table Expressions arbeiten.
Zuerst selektierst Du die Rohdaten und dann fängst Du an das JSON Dokument ausgehend vom untersten Level aus aufzubauen.

OK, ich habe verstanden, dass man auch komplexe JSON-Objekte mit SQL erstellen kann. Aber wir haben noch folgendes Problem: Wenn wir in einem IWS Webservice als Ausgabeart *JSON auswählen und dann ein (komplexes) JSON mittels SQL-Funktionen erstellen, packt der IWS das ganze, bereits fertige JSON, nochmal in ein JSON. Und dabei escaped er das von uns erstellte "innere" JSON. Wir finden da einfach keine Lösung.

Kann man dem IWS sagen, dass einfach nur "plain Text" herauskommen soll? Oder kann man angeben, dass das, was man zurückgibt, bereits JSON ist und er das nicht nochmal in JSON umbauen soll?

Vielleicht sehen wir den Wald vor lauter Bäumen nicht. Vielleicht nochmal zur Klarstellung, was ich meine:

Wenn man einen SQL-Webservice mit JSON-Ausgabeart definiert und ganz normale SQL-Ergebnisse (also in der Regel Datenbankfelder) zurückliefert, dann packt der IWS das Ergebnis richtig schön in JSON sein und gibt lupenreines JSON als Response zurück.

Aber wenn unser SQL selber schon JSON zusammenbaut (eben mit den SQL-JSON-Funktionen), dann packt der IWS das bereits fertige JSON nochmal in JSON ein. Der IWS kann auch gar nicht wissen, dass das SQL bereits ein gültiges JSON liefert, denke ich. Deshalb hält er das JSON für einen String und escaped alles und macht schließlich geschweifte Klammern drum.

Bin für jede Hilfe dankbar.

Dieter

**xenofob** · 31-07-20, 11:54

Hallo Dieter,

soweit mir bekannt, ist plaintext als Rückgabe nicht möglich. (Was ja auch verständlich ist..)
Entweder man lebt damit (json in nem json) oder greift auf alternativen zurück.
Scott Klemens hat ein kleines Tutorial erstellt, wie man einen eigenen Webserver aufsetzt und den Webserver programmieren kann. Wenn es dir nur darum geht plaintext durchzureichen, könntest du leicht den Server selber erstellen. Soll nicht Mal so schwer sein

(Ein eigenentwickelter Webserver könnte komplexe json auch selbst generieren, nur so als Input für dich)

**manuel.marcos** · 31-07-20, 12:15

Hallo,

so wie xenofob das beschreibt, verfahren wir auch bei uns.
Wir haben auf der i einen Apache Webserver in Kombination mit PHP am laufen, sind seit einigen Wochen auch vom Zend Server auf das Open Source PHP per yum rpm produktiv unterwegs.
Alle Webservices die wir anbieten, implementieren wir in PHP und haben so alle Freiheiten in der Gestaltung unserer Webservices.
Alternativ zu PHP bietet sich noch node.js auf der i an.

Gruß,
Manuel

**dschroeder** · 31-07-20, 13:07

Danke für eure Antworten.
Wir möchten eine möglichst standardisierte Lösung schaffen. Und da IBM mit dem IWS ja jetzt ganz neu die Möglichkeit geschaffen hat, SQL-basierte Services zu implementieren, wundert es mich, dass man das SQL dann nicht korrekt nach draußen bekommt. Das macht dann wenig Sinn, finde ich.

Unsere Standardmittel auf der IBM i sind SQL und RPG. Wenn wir mit diesen Mitteln keine Lösung hinbekommen, werden wir die Services mit Java (außerhalb der IBM i) implementieren. Java Webservices gibt bei uns bereits seit langem. Wir werden keine weitere Sprache (z.B. node.js oder php) bei uns einführen, denke ich.

Nochmals vielen Dank und die Frage an die Runde: Kann noch jemand etwas zum Umgang mit dem IWS beitragen?

Viele Grüße,
Dieter

**dschroeder** · 31-07-20, 14:20

Hallo zusammen,

ich denke, wir haben die Lösung gefunden. Wir haben die Ausgabeart des Service von *JSON auf *MEDIATYPE geändert. Jetzt gibt der Service immer ein Clob zurück. Und das kann unser selbst zusammengebautes JSON beinhalten.
Wir dachten zunächst, dass es ein Problem sein würde, wenn ein Clob zurückkommt. Aber für den Browser ist ein Clob anscheinend nichts besonderes. Er zeigt uns einfach die nicht escapte JSON-Zeichenkette an. Wahrscheinlich können die Java-Programme, die unseren Service nutzen und so eine Response bekommen, dann auch damit umgehen.

Gruß,
Dieter

**B.Hauser** · 23-07-20, 17:54

Zitat von dschroeder

Vielen Dank für Eure Antworten.

Komplexe JSON-Objekte kann man wohl nicht mit SQL machen, oder?

Natürlich kann man

Du musst lediglich mit mehreren Common Table Expressions arbeiten.
Zuerst selektierst Du die Rohdaten und dann fängst Du an das JSON Dokument ausgehend vom untersten Level aus aufzubauen.
Das folgende JSON-Dokument ist mit SQL erstellt.