IWS und Body

[dschroeder]

Hallo,

ich kämpfe immer noch mit der Implementierung eines Webservices mittels des IWS auf der i.

Der Assistent ist eigentlich ganz gut. Es ist mir auch gelungen, ein Serviceprogramm und ein normales ILE-RPG-Programm per Webservice zur Verfügung zu stellen. (Achtung: Es werden nur Serviceprogramme mit maximal 7 Parametern unterstützt. Normale Programme werden mit mehr Parametern (ich glaube 254), unterstützt).

Eine normale GET-Abfrage kann problemlos implementiert werden. Man definiert im Programm einfach alle Input- und Output-Parameter und der IWS kümmert sich darum, dass der Output in JSON eingepackt wird.

Bestimmte "Transportmetadaten", wie QUERY_STRING, REQUEST_METHOD usw. kann man im IWS-Wizzard ankreuzen und bekommt sie dann im Job als Environment-Variablen zur Verfügung gestellt. Alles sehr schön.

Aber ich frage mich, wie ich eine POST-Methode verarbeiten soll. Dabei werden die Daten ja nicht in der URL, sondern im Body übergeben (denke ich). Weiß jemand, wie der Body der Webservice-Anfrage ins RPG-Programm kommt? Bzw. wie kann sich das RPG-Programm den Body holen? Ich habe da im IWS-Wizzard nichts gefunden.

Dieter

[xenofob]

Das gibst du im IWS an. Da gibst du das Service Programm an und die jeweiligen Parameter. Die Daten übergibst du als json object.
Du machst den Post mit dem json object im Body und gibst da ja dann an { "param1":"Blabla", "param2":"blabla2"}
Dein Service Programm hat param1 und param2 als Input Felder.

[dschroeder]

Hallo xenofob,


danke für deine Antwort. Mir ist eines noch nicht ganz klar: Wenn ich das Programm oder Serviceprogramm im IWS angebe, ermittelt der IWS ja automatisch die Parameter des Programms. Wenn ich zusätzlich zu dem Body noch Path-Parameter mitgeben möchte, muss ich diese im IWS-Wizzard ja den Input Parametern des Programms zuordnen:

Im folgenden Beispiel (ist allerdings ein GET) ordne ich den Path-Parameter "PKNR" dem Input-Parameter "I#_PKNR" des Programms zu. Als Eingabequelle habe ich *PATH_PARAM ausgewählt.


Wenn ich mir die Möglichkeiten der Eingabequelle ansehe, finde ich da nichts, was namensmäßig auf Body hindeutet:


Es wäre für klar, wenn es da die Auswahl *BODY gäbe und ich diese Auswahl dann dem passenden Programmparameter zuordnen könnte.

Vielleicht habe ich ja auch nur ein Brett vor dem Kopf und sehe den Wald vor lauter Bäumen nicht.

Ich werde auf jeden Fall weiter testen. Vielleicht ergibt sich das ja alles noch.

Gruß,
Dieter

[camouflage]

Dieter,
hast Du dich auch mal beschäftigt, ob du evtl. die Webservices auch via SQL lösen könntest? Birgitta hat diesbezüglich an der Power einen interessanten Vortrag gehalten. Das PP-PDF mit HowTo und Beispiel ist verfügbar.

Nachtrag Download Link: https://bit.ly/3eTus9w

[Rainer Ross]

Hallo Dieter,

Du kannst es auch ohne IWS mit meiner OpenSource LIB machen https://github.com/RainerRoss/WEBSRVUTL, hier gehen bis zu 1000 Parameter und GET und POST sind kein Problem. Auch die Parameter als Query-String, JSON oder XML sind kein Thema.

Beispielrequest mit GET und 1 Parameter

values systools.httpgetclob('http://www.myhofi.com/myapp/websrv11.pgm?id=1', null);

Beispielrequest mit POST und 1 Parameter

values systools.httppostclob('http://www.myhofi.com/myapp/websrv11.pgm', null, 'id=1');

[xenofob]

Hallo dschroeder,

ein GET sollte man immer ohne Body schicken. Da ist PATH_PARAM (QUERY_PARAM ist auch gut) schon korrekt.
Das hat IBM mit dem IWS auch schön so implementiert, dass man eben keine Möglichkeit hat die Parameter innerhalb eines Requests auf unterschiedlichen Arten zu schicken.
Entweder Body oder eines der anderen Parameter.

Wenn du zum Beispiel ein POST machst und ein Json Object im Body schicken möchtest, dann musst du "Eingabeparameter einschließen" auswählen.

[xenofob]

Dieter,
hast Du dich auch mal beschäftigt, ob du evtl. die Webservices auch via SQL lösen könntest? Birgitta hat diesbezüglich an der Power einen interessanten Vortrag gehalten. Das PP-PDF mit HowTo und Beispiel ist verfügbar.

Ja genau, es gibt auch SQL via Rest als Webservices. Sehr empfehlenswert. Äußerst schnell und easy to install . 1 MB Daten im Json format in unter 300 ms!!

[dschroeder]

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

[dschroeder]

Dieter,
hast Du dich auch mal beschäftigt, ob du evtl. die Webservices auch via SQL lösen könntest? Birgitta hat diesbezüglich an der Power einen interessanten Vortrag gehalten. Das PP-PDF mit HowTo und Beispiel ist verfügbar.

Nachtrag Download Link: https://bit.ly/3eTus9w

Danke. Das schaue ich mir an!

[andreaspr@aon.at]

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

[B.Hauser]

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.

[dschroeder]

Hallo Birgitta, hallo Andreas,

herzlichen Dank. Das bringt uns auf die richtige Spur, denke ich !

Viele Grüße,
Dieter