Probleme mit Webservice und HTTP API

[ncc1701e]

Euch allen einen guten Morgen

mich plagt heute ein nerviges Problem und ich hoffe ihr könnt mir weiterhelfen oder ein Schubs in die richtige Richtung geben.

Ich habe eine Prozedur geschrieben die mittels REST-Webservice Daten aus unserem Kundenportal erhalten soll. Realisiert ist dies mit dem HTTP API von S. Klements.

Teilausschnitt:

dcl-c XMLOPTIONS 'doc=file case=any trim=all +
  allowmissing=yes allowextra=yes'; 

dcl-c WSLINKUSER 'http://prodportal01/Portal/api/v2/+
  users?filter=username:';     

HTTP_SetfileCCSID(1208);

xmlPath = '/WebServices/GetUserData/' + %trim(username)
  + '_ID_' + %char(%timestamp()) + '.xml';

http_xproc(HTTP_POINT_ADDL_HEADER:%paddr(AddHeaderData));
returnCode = http_url_get(WSLINKUSER + %trim(username):xmlPath);
if (returnCode <> 1);
   http_crash();
   return *off;
endif;

xml-into(e) WebserviceRequest %xml(xmlPath:'path=PagedListView'
  + 'ModelOfuserNcCATIYq/items/user'
  + ' '
  + XMLOPTIONS);

Soweit so gut, dies klappt auch solange keine Umlaute oder Sonderzeichen genutzt werden. Nun dachte ich mir das ich dafür die http_url_encoder_new() & die http_url_encoder_addvar Funktion nutzen muss, aber das klappt nur für die Sonderzeichen. Die Funktionen setzten zwar auch die Umlaute um(Bsp: ü = %FC) aber sobald das passiert findet der Webservice keine Daten mehr.

Ich habe dies dann getestet und festgestellt das der Aufruf nur mit encodierten Umlauten nicht klappt, es scheint also tatsächlich nur an den Umlauten zu liegen. Usernamen mit Sonderzeichen oder ohne Sonderzeichen/Umlauten liefen ohne Probleme.

Ich habe dann mittels des Firefox Addons HTTPRequester mehrmals den Webservice aufgerufen und dabei die verschiedenen Möglichkeiten probiert, das Ergebnis ist folgendes:

username = testuser -> klappt
username - Max%20Musterman -> klappt
username = G.Jüttner -> klappt
username = G.J%FCttner -> klappt.

Der Webservice an sich hat also keine Probleme mit Umlauten, seien diese nun plain oder encodiert, aber warum klappt dies dann nicht mit der HTTP API ?

Mir sind die Ideen ausgegangen und ich hoffe das einer von euch vllt. noch eine neue Idee einbringen kann.

[Fuerchau]

Die einzige Idee die ich habe ist, die Daten für http_url_get() auf die richtige CCSID zu bringen.
Da du die Daten in EBCDIC übergibst wird igendwo eine Umsetzung in ASCII/ANSI erfolgen.
Hier ist die Frage, mit welchen CCSID's da umgegangen wird (ggf. mal in den Code sehen).
Wenn dein Job ggf. auf *HEX steht, könnte als Default-CCSID z.B. 037 verwendet werden.

Dein Test in Firefox ist in soweit nicht aussagefähig. Du musst da einen Line-Trace mitlaufen lassen um zu sehen, was tatsächlich raus geht. Da auch hier die Eingabe nach diversen Kriterien oder Optionen ggf. in UTF-8 umgewandelt wird.

[Rainer Ross]

Hallo,

falls Du auf 7.1 bist und die SQL Function HTTPGETCLOB hast, dann geht das mit SQL

Values SYSTOOLS.HTTPGETCLOB
 ('http://prodportal01/Portal/api/v2/users?filter=username:',''); 

Für das URL-Encoding gibt diese SQL-Function

values(systools.urlencode('G.Jüttner','UTF-8')); 

Herzliche Grüße
Rainer

[ncc1701e]

Ja vorhin habe ich bereits einen Thread gefunden wo du dies erklärst (Link)

Habe die Prozedur dann auch demtnsprechend einmal angepasst:

ctl-opt main(main) dftactgrp(*no) option(*nounref);
//------------------------------------------------------------------//
// Procedure - Main                                                 //
//------------------------------------------------------------------//
dcl-proc main;
dcl-s   myfile      sqltype(CLOB_FILE);      // CLOB-File
dcl-s   myurl       varchar(256);            // URL
dcl-s   myheader    varchar(1500);            // HTTP-Header
dcl-s   query       varchar(256);            // QueryString
 
dcl-ds WebserviceRequest qualified;
           email varchar(100);
           email_allowed varchar(5);
           fax varchar(20);
           has_registered varchar(5);
           kundeid varchar(10);
           locked varchar(5);
           telefon varchar(20);
           terms_of_service_accepted varchar(5);
           terms_of_service_accepted_on varchar(10);
           anrede varchar(5);
           display_name varchar(100);
           firma varchar(100);
           name varchar(100);
           ort varchar(100);
           plz varchar(100);
           strasse varchar(100);
           username varchar(10);
           vorname varchar(50);
           id varchar(10);
         end-ds;

dcl-c XMLOPTIONS 'doc=file case=any trim=all +
                  allowmissing=yes allowextra=yes';
dcl-s testvar char(1);
dcl-s xmlPath char(1000);

EXEC SQL SET OPTION DATFMT=*ISO, timfmt=*ISO, COMMIT=*NONE,
                CLOSQLCSR=*ENDACTGRP;
 

myurl = 'http://prodportal01/Portal/api/v2/users?filter=';
query = 'username:testüser';

// URL-Encoding
exec sql set :query = systools.urlencode(:query,'UTF-8');
myurl += query;                            // URL + QueryString

myfile_name = '/WebServices/GetUserData/test' + %char(%timestamp()) + '.xml';    // StreamFile
myfile_nl   = %len(%trim(myfile_name));    // NameLength
myfile_fo   = SQFOVR;                      // FileOverwrite


EXEC SQL VALUES systools.httpgetclob (:myurl, :myheader)
       INTO :myfile;

clear WebserviceRequest;
xmlPath = myfile_name;
xml-into(e) WebserviceRequest %xml(%trim(xmlPath):'path=PagedListView'
                                        + 'ModelOfuserNcCATIYq/items/user'
                                        + ' '
                                        + XMLOPTIONS);

testvar = '1';
end-proc;

Das klappt soweit auch jetzt alles, ich bekomme nun endlich auch bei Umlauten Daten zurück!
Das einzige Problem was ich nun habe ist das meine Daten wenn Sie Umlaute enthalten so aussehen:

WEBSERVICEREQUEST.USERNAME = 'testüser

Ich hätte jetzt gedacht das kommt dadurch das die XML nicht UTF-8 codiert ist, dies scheint aber der Fall zu sein, jedenfalls steht folgendes zu Beginn der XML: version="1.0" encoding="utf-8"

Es scheint wohl ein Codepage Problem zu sein, aber ich habe keine Ahnung wie ich einen String in RPG in eine andere Codepage überführen kann....unter wrkjobd habe ich jedenfalls keine Option für die CCSID gefunden

[Rainer Ross]

Wie sehen die Daten im IFS-File aus. Sind dort die Umlaute in Ordnung, wenn Du die Daten mit wrklnk überprüfst? Sonst das File mit CHGATR auf CCSID 1208 ändern.

Die CCSID für den Job kannst Du mit CHGJOB CCSID(1141) ändern

[B.Hauser]

Was passiert, wenn Du anstatt Single Byte Character Set Double Byte verwendest, d.h. HTTPGETDBCLOB und DBCLOB_FILE und bei der XML-Verarbeitung ebenfalls auf Unicode gehst.

Anstatt ins IFS zu schreiben und dann mit XML-INTO zu verarbeiten, würde ich das Ergebnis direkt mit SQL und XML_TABLE ermitteln.

Birgitta

[Fuerchau]

Gib bei den XMLOPTIONS die CCSID 1208 an, dann wird UTF-8 automatisch in die Job-CCSID deiner Zielvariablen umgewandelt.
Möchtest du ggf. multinational werden, so definiere deine XML-Struktur als Unicode.

[Fuerchau]

Achja, wenn du anstelle "into : MyFile" direkt in eine CLOB-Variable ausgibst?

[ncc1701e]

Also die Datei(XML) hat die CCSID 1208. Jedoch tritt bereits in der XML der Fehler mit der Umsetzung auf. Vermutlich importiere ich dann einfach diesen Fehler mit xml-into in meine DS oder?

Die Idee mit XMLOPTIONS und ccsid=1208 hatte ich auch schon, doch wenn ich dies mache wirft der Compiler einen Fehler

RNF0224: Fehler in %XML-Optionen an Stelle 59, "ccsid=1208".

Wenn ich die Referenz richtig verstehe scheine ich ja auch nur die Wahl zwischen ccsid=best, ccsid=job oder ccsid=ucs2 zu haben.

[ncc1701e]

Was passiert, wenn Du anstatt Single Byte Character Set Double Byte verwendest, d.h. HTTPGETDBCLOB und DBCLOB_FILE und bei der XML-Verarbeitung ebenfalls auf Unicode gehst.

Anstatt ins IFS zu schreiben und dann mit XML-INTO zu verarbeiten, würde ich das Ergebnis direkt mit SQL und XML_TABLE ermitteln.

Birgitta

HTTPGETDBCLOB kann ich nicht verwenden jedenfalls wirft mir RDi die Warnung das er dieses Objekt in systools nicht findet.

Hast du für die Alternative mittels SQL und XML_Table ein Beispielcode? Ich arbeite heute das erstemal damit und habe daher folglich keine Ahnung von XML_Table noch wie genau ich das nutzen kann um damit meinen XML Response verarbeiten zu können.

Also weder in der RPG/SQL-Referenz noch in IBM POWER Systems i Softwareentwicklung und ‑modernisierung finde ich was zu XML_Table, ab welcher Version ist dies denn enthalten? Ich glaube unsere Maschine läuft mit V7R2, wobei wir ein paar Patches noch nicht installiert haben.

[Fuerchau]

Nach der Ausgabe der Datei musst du per CHGATR-Kommando die CCSID der IFS-Datei auf 1208 setzen. Dann sollte es automatisch klappen.
Das Problem ist, dass wohl der Parser sich für die "processingoptions" des XML nicht interessiert sondern auf die CCSID der IFS-Datei geht.
Ansonsten ist der CCSID-Parameter wohl für die Ausgabe und nicht die Eingabe relevant.

[ncc1701e]

Nach der Ausgabe der Datei musst du per CHGATR-Kommando die CCSID der IFS-Datei auf 1208 setzen. Dann sollte es automatisch klappen.
Das Problem ist, dass wohl der Parser sich für die "processingoptions" des XML nicht interessiert sondern auf die CCSID der IFS-Datei geht.
Ansonsten ist der CCSID-Parameter wohl für die Ausgabe und nicht die Eingabe relevant.

Dies klappt bei mir leider nicht, habe nach dem erstellen der XML den Befehl per ExecuteCMD in RPG einmal abgesetzt und dies bewirkt nichts, der username steht noch immer wie vorher dort drin.
Ich verstehe ehrlich gesagt auch nicht warum das was hätte bringen sollen, die CCSID ist doch schon beim erstellen 1208(sagt jedenfalls wrklnk/rdi).

Ich habe mir die XML jetzt einmal per Rdi auf meinen Desktop geschoben und mittels notepad++ geöffnet. Dort wird mir der username korrekt angezeigt, mit 'testüser' statt 'testüser'.

Irgendetwas scheine ich nicht zu verstehen, für mich gibt das ganze gerade keinen Sinn, wenn die Datei CCSID 1208 hat,also UTF-8, warum kann dann dieser dumme Umlaut nicht angezeigt werden...