[NEWSboard IBMi Forum]
Seite 1 von 2 1 2 Letzte
  1. #1
    Registriert seit
    Jan 2012
    Beiträge
    894

    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

  2. #2
    Registriert seit
    Jan 2012
    Beiträge
    894
    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:
    Code:
    //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.
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken Klicken Sie auf die Grafik für eine größere Ansicht 

Name:	header.PNG 
Hits:	10 
Größe:	20,8 KB 
ID:	473  

    Klicken Sie auf die Grafik für eine größere Ansicht 

Name:	header.JPG 
Hits:	8 
Größe:	204,6 KB 
ID:	474  


  3. #3
    Registriert seit
    Aug 2003
    Beiträge
    1.462
    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

  4. #4
    Registriert seit
    Feb 2001
    Beiträge
    18.495
    Wofür ist das '@' im Pfad?
    Name VARCHAR(128) PATH '@responseCode',

    Im Text heißt das ja nicht so.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

  5. #5
    Registriert seit
    Oct 2013
    Beiträge
    167
    @ liest Attribute - sonst liest man ja den Elementinhalt.

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

  6. #6
    Registriert seit
    Jan 2012
    Beiträge
    894
    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.

  7. #7
    Registriert seit
    Feb 2001
    Beiträge
    18.495
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

  8. #8
    Registriert seit
    Jan 2012
    Beiträge
    894
    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

  9. #9
    Registriert seit
    Jan 2012
    Beiträge
    894
    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?


  10. #10
    Registriert seit
    Aug 2001
    Beiträge
    2.606
    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
    Birgitta Hauser

    Contractor for Fresche Solutions Inc.
    Anwendungsmodernisierung, Beratung, Schulungen im Bereich RPG, SQL und Datenbank
    IBM Champion 2020
    RPG und SQL-Schulungen
    Erstellen und Verarbeiten XML- und JSON-Daten mit SQL

  11. #11
    Registriert seit
    Feb 2001
    Beiträge
    18.495
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

  12. #12
    Registriert seit
    Aug 2003
    Beiträge
    1.462
    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

Ähnliche Themen

  1. REST Webservices / Verwendung von SYSTOOLS
    Von dschroeder im Forum NEWSboard Programmierung
    Antworten: 25
    Letzter Beitrag: 14-02-18, 11:11
  2. SYSTOOLS / HTTPGETBLOB Verhalten
    Von Bratmaxxe im Forum NEWSboard Programmierung
    Antworten: 15
    Letzter Beitrag: 21-12-17, 08:29
  3. SYSTOOLS.URLENCODE
    Von KM im Forum IBM i Hauptforum
    Antworten: 4
    Letzter Beitrag: 25-04-17, 09:44
  4. SYSTOOLS.JSON2BSON
    Von rischer im Forum IBM i Hauptforum
    Antworten: 28
    Letzter Beitrag: 02-10-15, 11:36
  5. Spools Status Fin
    Von pille im Forum IBM i Hauptforum
    Antworten: 4
    Letzter Beitrag: 28-11-02, 09:37

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •