Webservice per SQL abfragen

[KM]

Die Abfrage mit JSON_TABLE hatte ich auch schon versucht. Hat aber am Ergebnis nichts geändert. Auch die Abfrage mit dem geänderten httpHeader hat nichts geändert.

Ich hab jetzt mal eine Tabelle erstellt mit einem Feld erstellt, das die CCSID 1208 hat. Diese Tabelle fülle ich direkt mit folgender SQL-Abfrage:

insert into mai.testjson
select subject
from JSON_TABLE(systools.httpGetClob(
	'http://ban:8080/webservices/emarsys/list_email_campaigns/' concat systools.urlencode('D', 'UTF-8') concat '/' concat systools.urlencode('2017-01-01', 'UTF-8') concat '/' concat systools.urlencode('2018-02-15', 'UTF-8'), 
	'<httpHeader><header name="Content-Type" value="application/json; charset=utf-8"/></httpHeader>'),    
	'$.campaigns'
columns(
	name VARCHAR(50) ccsid 1208 PATH '$.name',
	status VARCHAR(1) ccsid 1208 PATH '$.status',
	contactlist VARCHAR(100) ccsid 1208 PATH '$.contactlist',
	subject VARCHAR(100) ccsid 1208 PATH '$.subject',
	fromemail VARCHAR(100) ccsid 1208 PATH '$.fromemail',
	fromname VARCHAR(100) ccsid 1208 PATH '$.fromname')
) as x

Das Ergebnis sieht dann so aus:



In der zweiten Zeile sollte eigentlich stehen "Grüße und Wünsche...".

Gruß,
KM

[Fuerchau]

Das Problem mit 1208 ist ja, dass es hier keine SQL-Unterstützung für die automatische Umsetzung gibt.
Beim Select kannst du UTF8-Felder z.B. in NCHAR/NVARCHAR umwandeln, was dann in STRSQL in SBCS (der Job-CCSID) umgewandelt wird. Im RPGLE bekommst du dann UCS2.

So liefert dein Select native UTF8-Daten und das sieht wiederum korrekt aus.

[Rainer Ross]

Hallo KM,

teste mal folgenden Webservice der auch Umlaute und russische Zeichen im ersten Datensatz enthält

Select x.*
  from JSON_TABLE(
     SYSTOOLS.HTTPGETCLOB('http://www.myhofi.com/myapp/websrv11.pgm',''), 
     '$'
     Columns(
        nested '$.items[*]' columns(
            "Id"     integer                   path 'lax $.id',
            "Name"   varchar(40)    ccsid 1208 path 'lax $.name'   
        )
    )
  ) x;

[KM]

Hallo Rainer,

stimmt, hier sind Umlaute vorhanden. Die werden auch richtig angezeigt.

Gruß,
KM

[KM]

Hallo Fuerchau,

Das Problem mit 1208 ist ja, dass es hier keine SQL-Unterstützung für die automatische Umsetzung gibt.

Das scheint hier auch das Problem zu sein. Ich denke, dass ich hier tatsächlich nachträglich per iconv die Daten von 1208 in 1141 konvertieren muss. Dann sollte es wieder passen. Ist halt umständlich.

Ich finde es nur seltsam, dass man nicht direkt die Daten aus dem Webservice in eine Tabelle mit CCSID 1208 speichern kann. Irgendwo dazwischen scheint wohl noch eine SBCS-Komponente mit im Spiel zu sein.

Gruß,
KM

[Fuerchau]

Warum kannst du das Ergebnis des "Select .. from Json..." nicht direkt mit
insert into MyTable
Select ... from Json...
speichern und dabei das Zielfeld der Tabelle als NVARCHAR oder gleich die Json-Tabelle mit
"Name" nvarchar(40)

laden?

[KM]

Ich hab das Problem nun gefunden. Und zwar hatte ich in meinem REST-Webservice, den ich mit der Java-Referenzimplementierung "Jersey" erstellt hatte, bei der "Produces"-Annotation folgendes angegeben:

@Produces({MediaType.APPLICATION_JSON , MediaType.APPLICATION_XML})

Ich bin hier davon ausgegangen, dass die Daten standardmäßig in UTF-8 zur Verfügung gestellt werden. In den Log-Files, die ich davor geschrieben hatte, waren die Daten zumindest noch UTF-8. Jetzt hab ich herausgefunden, dass man bei dieser Annotation das Charset explizit angeben muss. Das sieht dann so aus:

@Produces({MediaType.APPLICATION_JSON + "; charset=UTF-8", MediaType.APPLICATION_XML + "; charset=UTF-8"})

Damit passt nun alles und die Daten werden wie gewünscht in UTF-8 geliefert.

Trotzdem Danke für Eure Bemühungen!!!

Gruß,
KM

[mihael]

Ich weiss, dass ich hiermit viel zu spät dran bin (ein paar Jahre zu spät), aber für alle anderen, die auf dieses Thema treffen, könnte das hier helfen.

Das Problem hier lag höchstwahrscheinlich nicht am Web Service, sondern am Client. Der Client hat zwar mitgeteilt, dass er die Daten als JSON haben will, aber nicht in welcher Kodierung.

Zur Erklärung: Man gibt per HTTP Header mit in welchem Format man die Daten gern hätte. Ob das der Web Service dann wirklich tut, liegt am Web Service. Manche Frameworks setzen das automatisch richtig um und manche ignorieren es komplett (da "bestellt" man JSON und bekommt XML z. B.).

Wie in welchem Format man die Daten gerne hätte gibt man mit dem "Accept" HTTP Header an. Beispiel: Accept: application/json

Hier hat man jetzt aber noch nicht die Kodierung angegeben (Codepage/CCSID). Wenn man die Daten in UTF-8 haben will, dann gibt man das mit dem Attribut "charset" an.

Accept: application/json;charset=utf8

Note: Der HTTP Header "Content-Type" gibt nicht an, in welchem Format man die Daten vom Server gerne hätte, sondern in welchem Format die Daten sind, die man zum Server hin sendet (z. B. bei einer POST Anfrage).