Show TOC Anfang des Inhaltsbereichs

Hintergrunddokumentation Server-Architektur  Dokument im Navigationsbaum lokalisieren

Dieser Abschnitt beschreibt den Aufbau der Softwareschichten in der Server-Architektur des ICF. In der Serverfunktion erzeugt das ICF mit Hilfe der entsprechenden Anwendung eine Antwort (Response) auf eine Anforderung (Request).

In dem beschriebenen Szenario  wird ein HTTP-Request von einem Client (z.B. einem Web Browser) zum Server gesendet. Der Request wird durch das ICF an eine Anwendung weitergereicht. Dort werden die angeforderten Daten zusammengestellt und als Response durch das ICF an den Client zurückgesendet. Die Daten der Response können daraufhin im Browser angezeigt bzw. weiter verarbeitet werden.

Diese Grafik wird im zugehörigen Text erklärt

Hinweis

Die Pfeile in der Grafik stellen den Kontroll- und Datenfluss dar.

Erläuterung:

      Der Request wird an den Internet Communication Manager (ICM) gesendet (1). Der ICM entscheidet, ob die durch den URL bezeichnete Resource  (d.h. die gewünschte Anwendung) im ABAP oder Java Stack des NW Application Servers realisiert ist.

      Wenn es sich um eine ABAP Anwendung handelt, wird der Request an den Taskhandler weitergereicht (2).

      Der Taskhandler startet den ICF-Controller, der durch den Funktionsbaustein HTTP_DISPATCH_REQUEST realisiert ist (3).

      Der ICF-Controller übergibt den Request an den ICF-Manager, der durch die ABAP-Klasse CL_HTTP_SERVER implementiert ist (4). Hier wird zunächst ein Server-Kontrollblock angelegt. In dem Server-Kontrollblock werden nach und nach alle Daten zu dem Request, einschließlich der Response, gehalten.

      Nachdem der Server-Kontrollblock angelegt worden ist, werden die Daten des Requests vom ICM angefordert (5+6+7).

      Die Daten des Requests werden vom ICM an den ICF-Manager übergeben (8+9+10) und im Attribut Requestdes Server-Kontrollblocks abgelegt.

      Der spezielle HTTP-Request-Handler, der die Bearbeitung des Requests übernimmt, wird anhand des URL im ICF-Controller bestimmt (11). Dazu wird der URL in seine Pfadkomponenten zerlegt.

Diese Grafik wird im zugehörigen Text erklärtBeispiel

In dem URL http://<hostname>:<port>/bc/ping handelt es sich bei der Pfadkomponente <hostname>:<port> um den virtuellen Host und bei der Pfadkomponente /bc/ping um den Servicepfad bzw. Servicenamen.

Hinweis

Die Zuordnung von virtuellem Host und Service zu einem HTTP Request-Handler wird in der Transaktion SICF gepflegt. Alle Pfadkomponenten werden von links nach rechts abgearbeitet, um die entsprechenden Services zu identifizieren. Zu einem Service können mehrerer HTTP Request-Handler hinterlegt sein. Über das Attribut IF_HTTP_EXTENSION~FLOW_RC wird gesteuert, in welcher Reihenfolge die einzelnen HTTP Request-Handler aufgerufen werden.

      Nachdem der oder die HTTP Request-Handler bestimmt sind, erfolgt die Authentifizierung des Clients (12).

Hinweis

Hierzu stehen verschieden Anmeldeverfahren zur Verfügung. Schlägt der Login fehl, führt das System ggf. weitere Anmeldeversuche durch, bevor es die Kommunikation abbricht.

      Nach erfolgreicher Authentifizierung erfolgt die Bearbeitung des Requests durch einen oder mehrere HTTP Request-Handler. Hierzu übergibt der ICF Controller (Funktionsbaustein HTTP_DISPATCH_REQUEST) die Kontrolle an den HTTP-Request-Handler (13). Jeder dieser Handler implementiert das Interface IF_HTTP_EXTENSION. In der Implementierung der Methode HANDLE_REQUEST() sind die speziellen Eigenschaften eines HTTP Request-Handlers definiert.

      Der HTTP Request-Handler beschafft sich zunächst den Inhalt des Request-Objekts aus dem Server-Kontrollblock (Attribut Request), der vom ICF-Manager verwaltet wird (14). Dazu verwendet er die Methode HANDLE_REQUEST().

      Aus dem Request-Handler kann beliebig mit einer Anwendung interagiert werden (15), beispielsweise könnten ein Aufruf von bestehenden ABAP Programmen oder ein Datenbankzugriff ausgeführt werden.

      Im Laufe dieser Verarbeitung kann der HTTP Request-Handler dann das Response-Objekt mit Daten füllen, indem er das Attribut Response mit den Daten setzt (16).

      Wenn der HTTP Request-Handler alle Aufgaben durchgeführt hat, gibt er die Kontrolle an den ICF-Controller, also den Funktionsbaustein HTTP_DISPATCH_REQUEST, zurück (17).

Diese Grafik wird im zugehörigen Text erklärt 

Die Schritte (13+14+15+16+17) können mehrfach ausgeführt werden, so dass mehrere auch unterschiedliche HTTP Request-Handler auf einen Request angewendet werden können. Die Einstellung dazu erfolgt in der Transaktion SICF.

      Nun liegt die Kontrolle wieder beim ICF-Controller (HTTP_Dispatch_Request). Dieser fordert vom ICF-Manager die Daten des Server-Kontrollblocks an (18).

      Die Daten werden von der internen Speicherrepräsentation in das HTTP-Format serialisiert und als HTTP-Response an den ICF-Controller übergeben (19).

      Der ICF-Controller reicht die Daten an den Taskhandler weiter (20), der Taskhandler an den ICM (21) und dieser an den Client (22), wo die Daten z.B. als HTML-Seite angezeigt werden können.

Weitere Informationen

      Klassen und Interfaces für die Server-Rolle

Detaillierte Informationen zu HTTP Request-Handlern, Services und Anmeldeverfahren erhalten Sie hier:

      Der HTTP Request-Handler

      ICF-Service anlegen und konfigurieren

      Anmeldeverfahren pflegen

 

Ende des Inhaltsbereichs