Die obenstehende Grafik zeigt beispielhaft eine Systemlandschaft, in der Webbrowser vom Internet und Intranet aus mit einem AS ABAP (hier auf mehrere Server verteilt) verbunden sind. Wichtige Features sind:
Unterstützung von Standard-Web-Protokollen wie HTTP, HTTPS, WebDAV, SOAP und SMTP
Ausgabe von Standard-Web-Formaten wie HTML, XML, OData und XSLT
Vollständige Integration in die SAP-Umgebung (Entwicklungsumgebung, Benutzerverwaltung, Berechtigungskonzept, Systemüberwachung, Kommunikationsprotokolle)
Der AS ABAP kann sowohl als Web-Server (Serverrolle) als auch als Web-Client (Clientrolle) fungieren. Die Serverrolle, in der der AS ABAP HTTP(S)-Requests von einem beliebigen Web-Client (z.B. einem Web-Browser) annehmen und verarbeiten und eine HTTP(S)-Antwort zurücksenden kann, wird in dieser Lektion besprochen.
eines Workprozesses stellt das Internet Communication Framework (ICF) die Umgebung für die Behandlung von HTTP(S)-Requests zur Verfügung. Das ICF stellt die Brücke zwischen dem C-Kernel des SAP-Systems und dem in ABAP erstellten Anwendungsprogramm dar.
Communication Manager ist eine Komponente der SAP-Architektur, die es dem ABAP-basierten SAP-System ermöglicht, direkt mit dem Internet zu kommunizieren. Technisch gesehen ist das Internet Communication Management ein eigenständiger Multi-Thread-Prozess, der vom ABAP-Dispatcher gestartet und überwacht wird.
Workprozesse können direkt Web-kompatible Inhalte erzeugen, die über den ICM an einen Web-Browser weitergeleitet werden können. Eine Möglichkeit, Inhalte dieses Typs anzulegen, ist die Verwendung von Web-Dynpro-Anwendungen, die im SAP-System mit der ABAP Workbench (z.B. Transaktion SE80) entwickelt werden.
Technisch betrachtet handelt es sich beim ICM um einen eigenen Prozess (icman auf Betriebssystemebene), der vom ABAP Dispatcher gestartet und überwacht wird. Seine Aufgabe besteht darin, die Kommunikation vom SAP-System mit der Außenwelt (über die Protokolle HTTP, HTTPS und SMTP) zu gewährleisten. In der Serverrolle kann er Anfragen aus dem Internet bearbeiten, die mit URLs mit der Server/Port-Kombination eingehen, auf die der ICM reagiert. Abhängig von der URL ruft der ICM dann den entsprechenden lokalen Handler auf. Der ICM-Prozess benutzt Threads, um die anfallende Last zu parallelisieren.
Bestandteile des ICM sind:
Thread-Steuerung: Dieser Thread nimmt die eingehenden TCP/IP-Anfragen entgegen und erstellt (oder erhöht) einen Worker-Thread aus dem Thread-Pool, um die Anfrage zu verarbeiten.
Worker-Thread: Dieser Thread verarbeitet Anfragen und Antworten für eine Verbindung. Ein Worker-Thread enthält einen I/O-Handler für die Netzwerkein- und ausgabe und diverse Plug-Ins für die verschiedenen unterstützten Protokolle.
Watchdog: Ein Worker-Thread wartet in der Regel auf eine Antwort (ob Client oder Server). Wenn ein Timeout auftritt, übernimmt der Watchdog die Aufgabe, auf die Antwort zu warten. Der Worker-Thread kann wieder für andere Anfragen verwendet werden.
Signalhandler: Dieser Thread verarbeitet Signale, die vom Betriebssystem oder einem anderen Prozess (z.B. dem ABAP-Dispatcher) gesendet werden.
Verbindungsinformationen: Tabelle mit Informationen zu jeder vorhandenen Netzwerkverbindung.
Memory Pipes: Diese speicherbasierten Kommunikationsobjekte ermöglichen die Datenübertragung zwischen dem ICM und den ABAP-Workprozessen.
Die Requests vom ICM müssen auch in der Dialog-Queue des ABAP-Dispatchers warten. Wenn ein freier Dialog-Workprozess gefunden wird, kommunizieren ICM-Threads und Dialog-Workprozesse direkt miteinander.
Der ICM nutzt Plug-Ins, um die verschiedenen Kommunikationsprotokolle zu realisieren. Nach der Installation des AS ABAP können folgende Protokolle verwendet werden:
HTTP
HTTPS
SMTP
LDAP
für Antwortseiten des ICM. Dieser speichert Seiten, bevor sie zum Client gesendet werden. Beim nächsten Aufruf der entsprechenden URL wird dann – sofern die Verfallszeit nicht abgelaufen ist – die Seite direkt vom ICM an den Client zurückgeschickt; es muss in diesem Fall nicht in den Taskhandler und das ICF verzweigt werden.
Ein Teil des ICM, der für die Performance wichtig ist, ist der Internet Server Cache (ISC), der HTTP(S)-Objekte speichert, bevor sie an den Web-Browser gesendet werden. Die nächste Anfrage kann dann direkt aus dem ISC erfolgen, sofern die Verfallszeit nicht abgelaufen ist. Dadurch wird ein Absprung in den ABAP-Workprozess vermieden, was den Zugriff erheblich beschleunigen kann.
Einige Funktionen des ISC sind:
Zweistufige Hierarchie: Beim Speichern von Objekten werden die Vorteile sowohl der hohen Geschwindigkeit des Hauptspeichers (Memory Cache) als auch der Speicherkapazität von Festplatten (Disk Cache) genutzt.
Dynamisches Caching: Herkömmliche Produkte basieren auf HTTP-Proxys und bieten in der Regel nur das Caching von statischen Inhalten, wie z.B. Bildern. Der ISC beherrscht auch das Caching dynamischer Inhalte wie JSPs oder BSPs.
Aktives Caching: Die Anwendung hat die volle Kontrolle darüber, ob die Objekte im Cache aktuell sind.
UFO-Caching: Ungültige Requests („UnFound Objects"), die zu Fehlersituationen auf dem Applikationsserver oder der Datenbank führen, werden direkt abgelehnt, so dass das System vor ungültigen oder bösartigen Requests geschützt ist.
Browserabhängiges Caching: Der Entwickler einer BSP kann festlegen, ob seine Anwendung vom Browsertyp abhängig ist. Ist dieses Kennzeichen gesetzt, nutzt der ISC die Daten im Cache nur für Anfragen vom gleichen Browser-Typen.
Der ISC wird durch Profilparameter icm/HTTP/server_cache* konfiguriert und kann vom SAP-System aus überwacht und invalidiert werden.
