[NEWSboard IBMi Forum]
Seite 2 von 2 Erste 1 2

Thema: IWS und Body

  1. #13
    Registriert seit
    Apr 2020
    Beiträge
    16
    I just leave this here https://github.com/sitemule/ILEastic

  2. #14
    Registriert seit
    Jan 2012
    Beiträge
    1.102
    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

  3. #15
    Registriert seit
    Apr 2019
    Beiträge
    43
    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)

  4. #16
    Registriert seit
    Feb 2017
    Beiträge
    41
    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

  5. #17
    Registriert seit
    Jan 2012
    Beiträge
    1.102
    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

  6. #18
    Registriert seit
    Jan 2012
    Beiträge
    1.102
    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

  7. #19
    Registriert seit
    Jan 2012
    Beiträge
    1.102
    Zitat Zitat von xenofob Beitrag anzeigen
    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.
    Ich versuche verzweifelt, für einen REST Service Query-Parameter zu definieren. Kennt jemand die genaue Syntax im IWS?
    Path-Parameter funktionieren prima. Man schreibt sie einfach in geschweifte Klammern:
    .../kostenstellen/{kst}

    Aber wie geht das bei Query-Parametern? Ich möchte die Möglichkeit schaffen, dass man zusätzlich zur Kostenstelle (also {kst}) das Gültigkeitsjahr und den Gültigkeitsmonat mitgeben kann. Der Aufruf soll also so sein:
    .../kostenstellen/12345?jahr=2020&monat=10

    Weiß jemand, wie man das im IWS (wahrscheinlich in der URI Pfadvorlage) definiert?

    Dieter

  8. #20
    Registriert seit
    Jan 2012
    Beiträge
    1.102
    Habe das Problem gefunden. Man darf die query parms gar nicht im uri Pfad angeben, sondern muss sie einfach mit ihren Variablennamem unten in der IWS Zuordnungstabelle zuordnen.

    Dieter

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •