Client-Architektur
Wenn ein ABAP-Anwendungsprogramm im
SAP-System einen HTTP-Request über das Internet an einen Web Server sendet,
werden folgende Schritte durchgeführt (Erläuterungen unter der Grafik):
Erläuterungen:
● Das ABAP-Anwendungsprogramm erzeugt ein Objekt der Klasse CL_HTTP_CLIENT (1).
Dies geschieht durch den Aufruf der Methode CL_HTTP_CLIENT=>CREATE, CL_HTTP_CLIENT=>CREATE_BY_DESTINATION oder CL_HTTP_CLIENT=>CREATE_BY_URL.
Das Objekt wird in folgenden als Client-Kontrollblock (analog zum Server-Kontrollblock) bezeichnet. Der Aufruf erfolgt im ABAP-Anwendungsprogramm, das den Request sendet.
Die Struktur der Klasse CL_HTTP_CLIENT ist unter Interface IF_HTTP_CLIENT beschrieben.
Beachten Sie bitte, dass auch die Aktivitäten der Punkte 2, 3, 5, 6, 7, 11, 12 und 13 durch das ABAP-Anwendungsprogramm angestoßen werden müssen – durch Aufrufen von entsprechenden Methoden. Das ABAP-Anwendungsprogramm arbeitet also mit den Komponenten der Klasse CL_HTTP_CLIENT, um die Request-Daten zu erzeugen und Response-Daten verarbeiten zu können.
○ Wenn die Methode CL_HTTP_CLIENT=>CREATE aufgerufen werden soll, müssen dieser Methode die folgenden Informationen zur Verfügung stehen: HOST (Hostname),SERVICE (Port),PROXY_HOST (Hostname des Proxy-Rechners), PROXY_SERVICE (Port des Proxy-Rechners) und SCHEME (Angabe, ob HTTP oder HTTPS verwendet werden soll; mit dem Default-Wert ‚SCHEMETYPE_HTTP’). Bei Kommunikation über SSL-Protokoll (‚SCHEMETYPE_HTTPS’) können hierfür passende SSL-Zertifikate mit Hilfe des Parameters SSL_ID spezifiziert werden. Wenn diese Zertifikate zu einer Anmeldung am Application Server ABAP verwendet werden sollen, können über SAP_USERNAME und SAP_CLIENT die notwendigen Zusatzangaben vorgenommen werden.
○ Wenn die Methode CL_HTTP_CLIENT=>CREATE_BY_DESTINATION aufgerufen werden soll, muss die gewünschte HTTP-Destination in der Transaktion SM59 gepflegt sein (Knoten HTTP-Verbindungen zu ABAP-System oder HTTP-Verbindungen zu ext. Server). Details zu den Einstellungen sind unter Verbindungsaufbau über Destination (SM59) beschrieben.
Für die Proxy-Einstellungen im System gibt es eine zentrale Konfigurationsumgebung, die über Transaktion SICF Menü Client -> Proxy-Einstellung erreicht werden kann.
● Der erzeugte Client-Kontrollblock wird gefüllt, indem das Attribut Request mit den gewünschten Request-Daten gefüllt wird (2).
● Danach wird der Request durch Aufruf der Methode SEND abgesendet (3). Dazu wird die Verbindung geöffnet und der Request in einen HTTP-Datenstrom verwandelt (serialisiert).
● Über Taskhandler und Internet Communication Manager geht der Request an den gewünschten HTTP-Server (4).
● Falls der HTTP-Server eine Authentifizierung verlangt (z.B. wenn er auch ein SAP-System ist), erfolgt nun der Logon des Clients (5,6,7,8). Dies geschieht über ein SAP-Anmelde-Popup, falls der HTTP-Server ein SAP-System ist, ansonsten über das HTTP-Standard-Popup. Die Abfrage, ob für die Authentifizierung das SAP-Anmelde- oder HTTP-Standard-Popup verwendet werden soll, wird innerhalb der Methode RECEIVE durchgeführt (siehe 6.). Falls ein Anmelde-Popup von der Anwendung nicht gewünscht wird, kann man dies über das Attribut IF_HTTP_CLIENT~PROPERTYTYPE_ LOGON_POPUP mit dem Wert CO_DISABLED steuern.
Diese Authentifizierung erfolgt nur in Dialogprozessen, in Batchprozessen wird dieser Schritt nicht durchgeführt.
Falls der gerufene Service nicht auf diesem URL erreichbar ist, und die Response beinhaltet einen Redirect, so übernimmt der ICF-Manager die Aufgabe den Request auf den neuen URL umzuleiten. Falls dieses Verhalten von der Anwendung nicht gewünscht wird, können Sie dies über das Attribut IF_HTTP_CLIENT~PROPERTYTYPE_REDIRECT mit dem Wert CO_DISABLED verhindern.
Der ICF-Manager übernimmt auch die Aufgabe die zentralen Proxy-Einstellungen für den Request auszuwerten, falls der Request keine Proxy-Angaben vorgenommen hat. Falls dieses Verhalten von der Anwendung nicht gewünscht wird, können Sie dies über das Attribut IF_HTTP_CLIENT~ PROPERTYTYPE_APPLY_SPROXY mit dem Wert CO_DISABLED steuern.
● Der HTTP-Server generiert eine Response und sendet sie zurück (9,10). Durch Aufruf der Methode RECEIVE werden die Response-Daten eingelesen und das Attribut RESPONSE des Client-Kontrollblocks gefüllt (10).
● Danach erfolgt die Verarbeitung oder Ausgabe der Daten durch Zugriff auf das Response-Attribut (11,12).
Es ist auch möglich, die Ausgabe an das HTML-Control zu übergeben, dann wird die Response wie in einem Browser dargestellt.
● Nach Ausgabe wird die Verbindung durch Aufrufen der Methode CLOSE geschlossen (13).
Nach der Ausführung der Methode Close darf nicht mehr auf die Objekte Request und Response zugegriffen werden.
Die Anwendung sollte nach der Abarbeitung ihrer Requests und Responses die Verbindung mit Hilfe der Methode Close schließen, um einen erhöhten Ressourcenverbrauch zu vermeiden.
Weitere Informationen