-
systools httpPostClobVerbose Status ermitteln
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:
Code:
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
-
-
Hallo Dieter,
ich löse das ganze via SQL.
Zuerst wird der response in eine Tabelle geschrieben:
Code:
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:
Code:
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
-
Wofür ist das '@' im Pfad?
Name VARCHAR(128) PATH '@responseCode',
Im Text heißt das ja nicht so.
-
@ liest Attribute - sonst liest man ja den Elementinhalt.
<element attribut="wertAttribut">wertElement</element>
-
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.
-
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.
-
Leider klappt das ganze noch nicht so, wie ich mir das vorstelle, Ich wollte die SQL-Lösung von Andreas etwas auseinanderziehen, damit es übersichtlicher wird. Außerdem möchte ich den Response nicht in einer Extra-Datei speichern, sondern lieber in einer Hostvariablen des SQLRPGLE-Programms ablegen.
Jetzt habe ich anscheinend aber ein Zeichensatzproblem. Ich speichere den ResponseHeader zunächst in einem Clob, das folgendermaßen deklariert ist:
Code:
dcl-s responseHeaderClobDS sqltype(CLOB:100000);
Dann speichere ich den Clob-Inhalt in eine "normale" Variable vom Typ varucs2:
Code:
dcl-s httpHeaderString varucs2(2000);
httpHeaderString = %subst(responseHeaderClobDS_data:1:responseHeaderClobDS_len);
Jetzt lese ich aus dem Header die gewünschten Werte:
Code:
exec sql select * into :responseCode, :responseMsg
from xmltable('/httpHeader' passing xmlparse(document :httpHeaderString)
columns resCode varchar(128) path '@responseCode',
resMsg varchar(128) path 'responseMessage') msg;
Dabei bekomme ich den SQL Fehlercode -16168. Der erweiterte Fehlertext (für die aufgetretene Fehlerart 7) ist: XML-Deklaration in XML-Dokument ungültig. ... Angegebene Codierung wird nicht unterstützt oder interne Codierung weicht von externer Codierung ab.
Ich glaube, dass das an dem Beginn des XML-Strings liegt. Dort steht ?xml version="1.0" encoding="UTF-8" drin. Wenn ich diesen Teil manuell aus dem XML-String entferne, liefert mir die xmltable-Funktion die korrekten Werte.
Ich dachte, wenn ich die HeaderString Variable ucs2 deklariere, müsste das auch UTF-8 umfassen.
Hat jemand eine Idee?
Dieter
-
Hallo Baldur, wir haben eben fast zeitgleich gepostet. Ich habe nochmal einen Test gemacht und das @-Zeichen einfach weggelassen. Ich hätte dann eine andere Fehlermeldung erwartet. Aber ich bekomme immer noch die gleiche Fehlermeldung "XML-Deklaration ... ungültig".
Ich habe wahrscheinlich ein Zeichensatzproblem, aber es liegt nicht (allein) am @-Zeichen, denke ich.
Andreas hat in seinem Post noch geschrieben:
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.
Heißt das, dass es da noch eine einfachere Lösung gibt?
-
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
-
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.
-
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:
Code:
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
Similar Threads
-
By dschroeder in forum NEWSboard Programmierung
Antworten: 25
Letzter Beitrag: 14-02-18, 11:11
-
By Bratmaxxe in forum NEWSboard Programmierung
Antworten: 15
Letzter Beitrag: 21-12-17, 08:29
-
By KM in forum IBM i Hauptforum
Antworten: 4
Letzter Beitrag: 25-04-17, 09:44
-
By rischer in forum IBM i Hauptforum
Antworten: 28
Letzter Beitrag: 02-10-15, 11:36
-
By pille in forum IBM i Hauptforum
Antworten: 4
Letzter Beitrag: 28-11-02, 09:37
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks