systools httpPostClobVerbose Status ermitteln

[dschroeder]

Hallo,
wir verwenden die Funktion httpPostClobVerbose, um einen Webservice aufzurufen. Als Rückgabe bekommen wir 2 Clobs, nämlich die responseMsg und den responseHttpHeader.

Mein Kollege, der den Webservice erstellt hat, meinte, es sei Standard, dass man den Status der HTTP-Anfrage zurückerhält. Z.B 200 = OK oder 403 = Forbidden.

Weiß jemand, ob (und wie) man den Status ermitteln kann? Was wir zur Zeit zurückbekommen, ist eine leere responseMsg und im Fehlerfall ein responseHeader, in dem z.B. "Server Error" drinsteht. Die echten HTTP-Statuswerte wären uns aber lieber.

Wir setzen die Funktion im embedded SQL ein:

clear responseMsgClobDS;
clear responseHeaderClobDS;
exec sql select ifnull(responsemsg, ''), ifnull(responsehttpheader, '')
           into :responseMsgClobDS, :responseHeaderClobDS
           from table(SYSTOOLS.HTTPPOSTCLOBVERBOSE(:url,
                                                   cast (:header as clob(1k)),
                                                   cast (:body   as clob(1k)) ) ) as a;

Dieter

[dschroeder]

Ich glaube, ich habe den Status gefunden. Der Status scheint doch im Header mitgeliefert zu werden.

Das führt mich allerdings zu meinem nächsten Problem:

Der Rückgabe-Header sieht folgendermaßen aus (ich kann das in diesem Editor anscheinend nur als Grafik einfügen. (Irgendwie ist die Grafik jetzt 2 mal da)):

Man sieht, dass die XML-Datei aus dem Basisobjekt "httpHeader" mit der Eigenschaft "responseCode="404" besteht (ich weiß nicht, ob die Begrifflichkeiten richtig gewählt sind).

Irgendwie schaffe ich es im Moment nicht, diese Struktur mit xml-into korrekt einzulesen. Es gibt zwar keinen Fehler, aber die Result-Struktur ist leer.

Ich habe folgendes Kodiert:

//Struktur für XLM-Header:
dcl-ds httpHeaderTempl qualified template;
   responseCode  char(3);
end-ds;
 
dcl-ds httpHeaderDS likeds(httpHeaderTempl);
  ...
xml-into httpHeaderDS %xml(httpHeaderString :
      'doc=string allowmissing=yes allowextra=yes path=httpHeader countprefix=count');

Vielleicht hat ja jemand auf Anhieb eine Idee.

[andreaspr@aon.at]

Hallo Dieter,

ich löse das ganze via SQL.
Zuerst wird der response in eine Tabelle geschrieben:

Insert Into PRANLIB.HTTPRESPONSE 
(MSG, HEADER, JOB) 
(Select HTTPDATA.*, JOB_NAME 
 FROM TABLE (HTTPGETCLOBVERBOSE (...)) AS HTTPDATA)

Um dann den HTTP Status-Code zu ermitteln benötigst du folgendes SQL:

WITH
RespHead AS (
  SELECT XMLPARSE(DOCUMENT HEADER) AS "doc"
  FROM PRANLIB.HTTPRESPONSE
  Where ID = 480984)
,
formated_header AS (
  SELECT *
  FROM XMLTABLE (
    '$doc_header/httpHeader' PASSING
    (SELECT "doc" FROM RespHead) AS "doc"
    COLUMNS
	Name  VARCHAR(128) PATH '@responseCode',
	Value VARCHAR(128) PATH 'responseMessage'
  ) MsgResponse 
)
select * from formated_header

Du kannst dir aber auch eine Tabelle mit einer Auflistung aller HTTP-Headerinformationen ausgeben lassen.
Darin ist dann u.a. auch der HTTP Code enthalten.

lg Andreas

[Fuerchau]

Wofür ist das '@' im Pfad?
Name VARCHAR(128) PATH '@responseCode',

Im Text heißt das ja nicht so.

[AG1965_2]

@ liest Attribute - sonst liest man ja den Elementinhalt.

<element attribut="wertAttribut">wertElement</element>

[dschroeder]

Hallo Andreas,
vielen Dank. Ich werde mal versuchen, das mit der SQL-Funktion hinzubekommen. Es würde mich trotzdem interessieren, weshalb das mit dem XML-INTO nicht klappt. Das fände ich etwas lesbarer.

Das mit dem @ war mir übrigens auch neu. Genau das ist auch mein Problem beim XML-INTO, glaube ich. Der Response Code ist ein Attribut, kein Element. Vielleicht klappt das ja auch noch irgendwie.

[Fuerchau]

Bisher war da eine Unterscheidung eigentlich nicht nötig.
Der Pfad verweist auf die Knoten, ein Name entweder auf den Knoten- oder Attributnamen.
Es mag sein, dass "@" für die Unterscheidung zwischen Knoten und Attribut bei Namensgleichheit ist.

Ansonsten habt ihr natürlich ein typisches CCSID-Problem, da der "@" je nach Codepage unterschiedlich kodiert ist.
Nun kommt es darauf an, welche CCSID eure Quelle und der Job zur Umwandlungszeit haben und anschließend ob die Job-CCSID wiederum von der HTTP-Funktion korrekt ausgewertet wird.
Hier kann es durchaus zu Schwierigkeiten kommen, denn eine Programmkonstante unterliegt wiederum keiner Codeanpassung, insbesonders wenn der Job wie blöderweise üblich auf *HEX steht.

[B.Hauser]

Baldur!

Die Pfad-Angaben in XML-Table basieren auf der XPATH-Syntax, so wie sie vom W3C vorgegeben ist.
Auch wenn Db2 XPATH noch nicht alles abdeckt, beruht die Syntax auf diesem Standard.
W3C XPath Syntax


Da die XPATH Syntax in Hochkommata angegeben wird, erfolgt auch keine Konvertierung innerhalb der Quellen. Ausserdem wird von SQL alles automatisch in UTF-8 umgesetzt.

Vielleicht sollte man sich auch mal das folgende White Paper anschauen:
SQL XML Programming

[Fuerchau]

Da spricht der RPG-Compiler wieder anders.
Eine SRC-PF ist eine Tabelle mit CCSID wie eben auch jede andere Tabelle.
Beim Lesen durch den [Pre-]Compiler erfolgt wie immer automatisch eine Codewandlung in die Job-CCSID. Es gibt dabei sogar im Handbuch Erklärungen, wie mit unterschiedlichen CCSID's der Copy-Member umgegangen wird, wenn der Job mal auf *HEX stehen sollt (was wirklich nie der Fallsein dürfte).
Somit stehen die Konstanten nun mal im Code in der CCSID, die zum Compilezeitpunkt galt.
Dies hat mit SQL erst mal überhaupt nichts zu tun.
Embedded SQL's werden dazu noch in SQLPKG's (im Programm) abgelegt. Diese haben aber keine CCSID!
Wenn dann nun der SQL zur Laufzeit ausgeführt wird, wird der SQL selber natürlich erstmal nicht in eine andere CCSID umgewandelt.
Allerdings, und das steht auch irgendwo, werden Konstanten vom Optimizer als Parametermarker umgesetzt und die Inhalte in Variablen kopiert.
Und was soll ich dir sagen, was nun mit den Variablen passiert?
Sie werden natürlich entsprechend der Anforderung in den benötigten Code übersetzt (DB-CCSID, CCSID des XML-Dokuments).
Alles andere würde dem Prinzip CCSID der AS/400 ja vollkommen wiedersprechen.
Und wie gesagt, da kann es bzgl. des "@", ebenso auch anderen Sonderzeichen im Code, schon mal Probleme geben (auch hier im Forum schon ausgiebig diskutiert).

Übrigens: im benannten White-Book wird explizit auf das Verfahren mit der CCSID hingewiesen.

Mappings of encoding names to effective CCSIDs for stored XML data
If data that you store in an XML column is in a binary application variable, or is an internally encoded
XML type, the DB2 database manager examines the data to determine the encoding. If the data has an
encoding declaration, the database manager maps the encoding name to a CCSID.

Das Encoding im XML-Header betrifft im Übrigen nicht nur die Daten sondern das gesamte Dokument.

Inzwischen habe ichganz gute Erfahrungen damit gemacht, Konstanten in UCS2-Variablen zu speichern (gibts übrigens auch einen Thread dafür). Diese werden vom Compiler korrekt initialisiert, wenn die Job-CCSID nicht *HEX ist.
Übergibt man diese Variablen an SQL so werden diese auch bzgl. der CCSID korrekt behandelt.

[andreaspr@aon.at]

Hallo Dieter,

Ja, diese Mischformen, SQL, RPG, CCSID sind nicht immer ganz unproblematisch.
Du kannst aber den kompletten Teil via SQL realisieren.

Mit folgenden SQL bekommst du den ResponseMsg + HTTP Code als ein Ergebnis:

WITH
http AS (SELECT responsehttpheader, responsemsg
FROM TABLE (SYSTOOLS.HTTPGETCLOBVERBOSE ('https://www.orf.at', 
					CAST ('' AS CLOB(10K)))) T1
)
,
RespHead AS (
  SELECT XMLPARSE(DOCUMENT responsehttpheader) AS "doc_header", responsemsg
  FROM http)
,
formated_header AS (
  SELECT *
  FROM RespHead, XMLTABLE (
    '$doc/httpHeader' PASSING "doc_header"  AS "doc"
    COLUMNS
	Name  VARCHAR(128) PATH '@responseCode',
	Value VARCHAR(128) PATH 'responseMessage'
  ) MsgResponse
)
select responsemsg, Name, value from formated_header

Ich hoffe das hilft dir weiter.
Ist meiner Meinung nach einfacher als die Mischform und es gibt weniger Probleme.

lg Andreas

[dschroeder]

Hallo Andreas,
vielen Dank. Ich habe eben geposted, ohne deinen neuesten Post gesehen zu haben. Danke für die Lösung. Ich werde das dann erstmal so machen!

Um ehrlich zu sein, finde ich das SQL aber etwas komplex (wegen der Verschachtelungen). Wenn das mal nicht klappt, kann man die einzelnen Schritte schlecht debuggen. Deshalb hätte ich es gerne im RPG in einzelne Schritte zerlegt. Aber das scheint ja nicht zu gehen. (Vielleicht bekommt ja doch noch jemand das Beispiel aus meinem anderen Post (der Post mit den 2 Anhängen) zum Laufen).

Viele Grüße,
Dieter

[andreaspr@aon.at]

Hehe, ja das verstehe ich, aber es sieht am ersten Blick nur so komplex aus.
Und ehrlich gesagt debugge ich lieber die SQL Version als die RPG, SQL Mischung.
Du kannst nämlich ganz simple die 3 Parts vom SQL (WITH-Parts) einzeln nehmen und von jedem SQL Client ausführen lassen.
Außerdem glaube ich auch, dass eine Lösung, die schon beim ersten mal funktioniert, auch in zukunft wartungsfreundlicher ist, als jene wo im Forum diverse Experten an einer Lösung des Problems suchen :-)