Version 4.2.6	SUCHEN   INDEX   INHALT   |   PDF-SEITE   PDF-BÜCHER   |   HOME   HOCH   ZURÜCK   VOR

Dieses Dokument behandelt folgende Themen:

• Funktion

• Syntax-Beschreibung

• Kodierung von eingehenden/ausgehenden Daten

• Beispiele

Eine Erläuterung der in dem Syntax-Diagramm verwendeten Symbole entnehmen Sie dem Abschnitt Syntax-Symbole.

Gehört zur Funktionsgruppe: Internet und XML

Funktion

Mit dem Statement REQUEST DOCUMENT haben Sie die Möglichkeit, auf ein externes System zuzugreifen.

Informationen bezüglich Unicode-Support finden Sie im Abschnitt Statements in der Unicode and Code Page Support-Dokumentation.

Einschränkungen für Protokollarten

Das HTTPS-Protokoll wird nur unter z/OS unterstützt.

Einschränkungen für Cookies

Unter dem HTTP-Protokoll setzt ein Server Cookies ein, um Status-Informationen zur Client-Workstation zu verwalten.

REQUEST DOCUMENT wird mit Optionseinstellungen für das Internet implementiert. Dies bedeutet, dass abhängig von den Sicherheitseinstellungen Cookies verwendet werden.

Wenn in den Einstellungen der Internet-Optionen Disabled (Sperren) gesetzt ist, werden keine Cookies versandt, auch wenn ein Cookie-Header (operand 4/5) versandt wird. Benutzen Sie für Server-Umgebungen nicht die Internet-Optionseinstellung Prompt (Eingabeaufforderung). Mit dieser Einstellung bleibt der Server hängen, weil kein Client auf die Eingabeaufforderung reagieren kann.

In Großrechner-Umgebungen werden Cookies nicht unterstützt und ignoriert.

Syntax-Beschreibung

Operanden-Definitionstabelle:

Syntax-Element-Beschreibung:

HTTP/1.0 200 OK

Automatisch erzeugte Header (operand4/5)

Request-Method

Die folgenden Werte werden für operand5 unterstützt: HEAD, POST, GET und PUT.

Die folgende Tabelle zeigt die automatische Berechnung der request-method in Abhängigkeit von den vorgegebenen Operanden:

Content-Type

Wenn die request-method POST ist, muss ein Header des Typs content-type mit der HTTP-Anfrage angegeben werden. Wenn kein content-type explizit gesetzt wird, ist der automatisch generierte Wert von operand5 wie folgt:

application/x-www-form-urlencoded

Anmerkung:
Es ist möglich, die automatisch erzeugten Headers zu überschreiben. Natural überprüft sie nicht auf Fehler. Es können unerwartete Fehler auftreten.

Allgemeiner Hinweis zur URL-Kodierung

Wenn Sie POST-Daten mit dem Inhaltstyp application/x−www−form−urlencoded versenden, müssen bestimmte Zeichen mittels URL-Kodierungen dargestellt werden, was bedeutet, dass das Zeichen durch einen hexadezimalen Zeichencode (%hexadecimal−character−code) ersetzt wird. Die vollständigen Einzelheiten, wann und warum die URL-Kodierung erforderlich ist, sind in RFC 1630, RFC 1738 und RFC 1808 erläutert. Sie finden hier einige grundsätzliche Informationen. Alle Nicht-ASCII-Zeichen (d.h. gültige ISO 8859/1-Zeichen, die nicht auch ASCII-Zeichen sind) müssen URL-kodiert sein, z.B. die Datei köln.html würde in einer URL als k%F6ln.html erscheinen.

Einige Zeichen gelten als "unsicher", wenn Web-Seiten per Email angefordert werden.

Diese Zeichen lauten:

Wenn Sie URLs schreiben, sollten Sie diese Zeichen URL-kodieren.

Einige Zeichen haben spezielle Bedeutungen in URLs, wie z.B. der Doppelpunkt (:), der das URL-Schema vom Rest des URLs abtrennt, der doppelte Schrägstrich (//), der angibt, dass der URL der Common Internet Scheme-Syntax entspricht, und das Prozentzeichen (%). Wenn diese Zeichen als Teile von Dateinamen erscheinen, müssen sie generell URL-kodiert werden, um sie von ihrer Sonderbedeutung in URLs zu unterscheiden (dies ist eine Vereinfachung, die vollständigen Informationen finden Sie in den RFCs).

Diese Zeichen sind:

Übersicht über Response-Nummern für HTTP-/HTTPs-Anforderungen

Response 301 - 303 (Umleitung)

Umleitung bedeutet, dass der angeforderte URL umgezogen ist. Als Response (Rückmeldung) wird der Rückgabe-Header mit dem Namen LOCATION (Adresse) angezeigt. Dieser Header enthält den URL, wohin die angeforderte Seite umgezogen ist. Eine neue REQUEST DOCUMENT-Anfrage kann benutzt werden, um die umgezogene Seite zu suchen.

HTTP-Browser leiten automatisch zur neuen URL um, aber das Statement REQUEST DOCUMENT nimmt die Umleitung nicht automatisch vor.

Response 401 (Verweigert)

Die Rückmeldung Access Denied (Zugriff verweigert) bedeutet, dass die angeforderte Seite nur aufgerufen werden kann, wenn mit der Anfrage eine gültige Benutzer-ID und ein gültiges Passwort angegeben werden. Als Rückmeldung wird der Rückgabe-Header mit dem Namen WWW−AUTHENTICATE mit dem für diese Anfrage erforderlichen Bereich ausgegeben.

HTTP-Browser zeigen normalerweise einen Dialog mit Benutzer-ID und Passwort an, aber beim Statement REQUEST DOCUMENT wird kein Dialog angezeigt.

Kodierung von eingehenden/ausgehenden Daten

Bei der Datenübertragung mit dem Statement REQUEST DOCUMENT kommt es normalerweise nicht zu Konvertierungen von Codepages. Wenn Sie möchten, dass die ausgehenden und/oder eingehenden Daten in einer bestimmten Codepage kodiert werden, können sie die Klausel DATA ALL und/oder die Klausel RETURN PAGE verwenden, um dies anzugeben.

DATA ALL-Klausel

Zur Kodierung der ausgehenden Daten wird die Klausel DATA ALL benutzt:

Syntax-Beschreibung:

RETURN PAGE-Klausel

Zur Kodierung von eingehenden Daten wird die Klausel RETURN PAGE verwendet:

Als Rückmeldung für eine HTTP-/HTTPS-Anfrage können eingehende Daten binäre Daten (zum Beispiel image/gif) oder Zeichen-Daten (zum Beispiel text/html) enthalten. Zusammen mit der Rückmeldung erhält das Statement REQUEST DOCUMENT einen Parameter, der die Art des Inhalts des angeforderten Dokuments angibt (Mime-Typ). Dieser Parameter kann Informationen über die Codepage enthalten, in der das Dokument kodiert ist.

Diese Klausel bietet eine automatische Umsetzung in die voreingestellte (Default-)Codepage (Wert der Systemvariablen *CODEPAGE) der Natural-Session.

Syntax-Beschreibung:

Anmerkung:
"Zurückgegebener Mime-Typ enthält eine Kodierung" bedeutet, dass der HTTP-Server einen Content-Type-Header mit einer charset=-Klausel zurückliefert, zum Beispiel: charset=ISO-8859-1.

Beispiele für die Verwendung der RETURN PAGE ENCODED-Klausel

1. Server liefert einen Header zurück: 'Content-type: text/html;charset=UTF-8'

   Programmcode-Beispiel 1:

   ... 
   RETURN PAGE operand13

   Resultierende Verarbeitung:

   operand13 bleibt UTF-8-kodiert.

   Programmcode-Beispiel 2:

   ... 
   RETURN PAGE operand13 ENCODED [..]

   Resultierende Verarbeitung:

   operand13 wird unabhängig von den eventuell vorhanden Angaben in operand14 und operand15 von UTF-8 in die voreingestellte (Default-)Codepage umgesetzt. Die beiden Operanden werden nicht ausgewertet, weil im zurückgelieferten Content-Type-Header eine gültige Kodierung festgestellt wurde.

2. Server liefert einen Header zurück: 'Content-type: text/xml'

   Programmcode-Beispiel 1:

   ... 
   RETURN PAGE operand13 ENCODED

   Resultierende Verarbeitung:

   operand13 wird nicht umgesetzt, weil der Content-Type-Header keine gültige Kodierung enthält.

   Programmcode-Beispiel 2:

   ... 
   RETURN PAGE operand13 ENCODED FOR TYPES 'text/xml' IN CODEPAGE 'USASCII'                  
   

   Resultierende Verarbeitung:

   operand13 wird von USASCII-Codepage in die voreingestellte (Default-)Codepage umgesetzt. In diesem Fall erfolgt die Umsetzung gemäss der Annahme des Programmierers über die Kodierung der empfangenen Seite.

   Programmcode-Beispiel 3:

   ... 
   RETURN PAGE operand13 ENCODED FOR TYPES 'text/html' 
       IN CODEPAGE '  '
                     
   

   Resultierende Verarbeitung:

   operand13 wird nicht umgesetzt, weil der in operand14 angegebene Mime-Typ 'text/html' nicht mit dem im Content-Type-Header angegebenen Mime-Typ 'text/xml' übereinstimmt.

   Programmcode-Beispiel 4:

   ... 
   RETURN PAGE operand13 ENCODED IN CODEPAGE ' ' 
                     
   

   Resultierende Verarbeitung:

   operand13 wird von der mit dem Subparameter RDCP des Profilparameters XML angegebenen Standard-Codepage in die voreingestellte (Default-)Codepage umgesetzt.

   Anmerkung:
   Der Standardwert für den RDCP-Subparameters, der gültig ist, wenn nichts anderes explizit angegeben wird, ist 'ISO-8859-1'. Siehe auch XML - Activate PARSE XML and REQUEST DOCUMENT Statements in der Parameter-Referenz-Dokumentation.

Beispiele

• Beispiel 1 — Allgemeine Anforderung

• Beispiel 2 — Einfache Get-Anforderung (keine Daten)

• Beispiel 3 — Einfache Head-Anforderung (keine zurückgelieferte Seite)

• Beispiel 4 — Einfache Post-Anforderung (Voreinstellung)

• Beispiel 5 — Einfache Put-Anforderung (mit allen Daten)

Anmerkung:
Es gibt einen Beispiel-Dialog V5−RDOC für dieses Statement in der Beispiel-Library SYSEXV.

Beispiel 1 — Allgemeine Anforderung

REQUEST DOCUMENT FROM "http://bolsap1:5555/invoke/sap.demo/handle_RFC_XML_POST" 
  WITH
    USER #User PASSWORD #Password
    DATA
    NAME 'XMLData'       VALUE #Queryxml
    NAME 'repServerName' VALUE 'NT2'
  RETURN
    PAGE #Resultxml
RESPONSE #rc

Beispiel 2 — Einfache Get-Anforderung (keine Daten)

REQUEST DOCUMENT FROM "http://pcnatweb:8080"
  RETURN
    PAGE #Resultxml
RESPONSE #rc

Beispiel 3 — Einfache Head-Anforderung (keine zurückgelieferte Seite)

REQUEST DOCUMENT FROM "http://pcnatweb"
RESPONSE #rc

Beispiel 4 — Einfache Post-Anforderung (Voreinstellung)

REQUEST DOCUMENT FROM "http://pcnatweb/cgi-bin/nwwcgi.exe/sysweb/nat-env"
  WITH 
    DATA 
    NAME 'XMLData'       VALUE #Queryxml
    NAME 'repServerName' VALUE 'NT2'
  RETURN
    PAGE #Resultxml
RESPONSE #rc

Beispiel 5 — Einfache Put-Anforderung (mit allen Daten)

REQUEST DOCUMENT FROM "http://pcnatweb/test.txt"
  WITH 
    DATA ALL     #document
  RETURN
    PAGE #Resultxml
RESPONSE #rc

www.softwareag.com

Copyright © 1979-2010 Software AG, Darmstadt, Germany. Alle Rechte vorbehalten.

SUCHEN   INDEX   INHALT   |   PDF-SEITE   PDF-BÜCHER   |   HOME   HOCH   ZURÜCK   VOR