systools httpPostClobVerbose Status ermitteln

[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 :-)

[BenderD]

... wartungsfreundlich??? Funktionen, die im Fehlerfall einen nebulösen Fehlercode zurückgeben???
Alleine das ist mir schon Grund genug diesen mit heißer Nadel zusammen geschusterten Murks nicht zu verwenden.

D*B

[Fuerchau]

In den Beispielen der Textdateien hat man das @-Problem ja ausgeklammert.
Zu oben muss ich noch ergänzen, dass ja die XML-Interpretation von irgend einer Routine ausgeführt werden muss. Das @ ist ja nicht Bestandteil des SQL's sondern eine Arbeitsanweisung für den Interpreter.
Aber in welcher CCSID wurde dieser entwickelt?
Welchen Code für @ erwartet diese Funktion?
Am Beispiel der C-Funktion RegComp/RegEx haben wir mal festgestellt, dass der Job dafür kurzfristig auf 037 gestellt werden muss.

[andreaspr@aon.at]

... wartungsfreundlich??? Funktionen, die im Fehlerfall einen nebulösen Fehlercode zurückgeben???
Alleine das ist mir schon Grund genug diesen mit heißer Nadel zusammen geschusterten Murks nicht zu verwenden.

D*B

Jep, wartungsfreundlichER! Mit den seltsamen Fehlercodes bin ich ganz bei dir. Ein Grund mehr so wenig wie möglich miteinander zu vermischen.
Ist aber nur meine Meinung. Ich würde halt die Lösung nehmen die funktioniert. Wenn notwendig kann man es später immernoch umbauen. Bzw. gibt es später vielleicht sogar noch bessere oder einfachere Lösungen.
Ich persönlich habe mit den neuen Technologien der letzten Releases mir immer weniger Gedanken um CCSID oder Unicode machen müssen. (Weniger != gar nicht)

[dschroeder]

Zur Info:
Die Lösung von Andreas mit dem verschachtelten SQL läuft jetzt bei mir.

Nochmals herzlichen Dank!

[Fuerchau]

Natürlich brauche ich fast keine CCSID wenn ich alles mit Unicodemachen kann.
Allerdings benötige ich dies immer noch, wenn ich mit COBOL, ILERPG und CLP/CLLE arbeite.
Denn hier hocken die größten Fehlermöglichkeiten.