Ermitteln der Servergruppe
Um die Servergruppe zu ermitteln, die für die Abarbeitung eines Requests zuständig ist, geht der SAP Web Dispatcher vor wie im Folgenden beschrieben.
Zunächst prüft der SAP Web Dispatcher, ob es sich um einen ABAP- oder Java-Request handelt. Dementsprechend wendet er das ABAP- oder das Java-Loadbalancing an.
Die Prüfung erfolgt anhand des URL-Präfixes.
URL-Präfix-Check
Die Entscheidung, ob es sich um ein ICF-Präfix (also für das Internet Communication Framework des AS ABAP) handelt, wird im Folgenden im Detail beschrieben. Bei der URL http://hostname:port/A/B/page.htm ist das zu untersuchende Präfix also die Zeichenfolge /A/B/.
Der SAP Web Dispatcher muss also entscheiden, ob es sich um ein ICF-Präfix handelt, was an den ABAP-Server (dem ICF) gegeben werden soll, oder um ein dem ICF unbekanntes Präfix (was dann an den AS Java geht) handelt. Hierzu sucht er in der URL-Mapping-Tabelle nach dem Präfix. Enthält für das obige Beispiel die URL-Mapping-Tabelle zwar nicht den Eintrag /A/B/, jedoch den Eintrag /A/, so handelt es sich auch um ein ICF-Präfix.
Für die Startseite, bzw. das Root-Verzeichnis, gibt es eine Sonderbehandlung, weil man bei der Suche durch die Liste der Präfixe nicht nach dem Root-Verzeichnis suchen kann (es würde immer gefunden werden, weil alle URL-Präfixe mit / beginnen). Falls es sich bei der URL um eine Root-URL handelt, dann bestimmt der Profilparameter is/HTTP/default_root_hdl, welches Root-Verzeichnis benutzt werden soll. Zulässige Werte sind abap und j2ee, der Wert kann auch dynamisch, mit der Transaktion RZ11 oder SMMS, geändert werden.
Folgendes Flussdiagramm zeigt den verwendeten Algorithmus.
Die URL-Mapping-Tabelle des Web Dispatchers könnte z.B. folgenden URL-Präfixe enthalten.
|
/sap/bc/contentserver/ /sap/public/formgraphics/ /logon/ /echo/ /its/ /sap/ |
Wird die URL http://saphost:8080/index.html eingegeben, ist das zu untersuchende Präfix /. Dies wird in der URL-Mapping-Tabelle nicht gefunden, und es enthält nur einen Schrägstrich. Ist nun der Parameter is/HTTP/default_root_hdl = j2ee gesetzt (Default-Einstellung), so führt der Web Dispatcher Java-Loadbalancing durch und sucht dann im Root-Verzeichnis des ermittelten Servers nach der Datei index.html. Diese wird dann über den ICM des Applikationsservers dem Client zurückgegeben.
Das ABAP-Loadbalancing und das Java-Loadbalancing werden im Folgenden beschrieben.
ABAP-Loadbalancing
Beim ABAP-Loadbalancing bekommt im stateless Fall derjenige Applikationsserver den Request zugeteilt, der gemäß Lastausgleich an der Reihe ist. Die Servergruppe, die den Request bearbeiten kann, ist entweder eine ABAP-Logongruppe (vgl. Logongruppen zuordnen) oder die interne Gruppe !DIAG oder !DIAGS (falls HTTPS weitergeschickt wird, vgl. SAP Web Dispatcher und SSL). !DIAG/!DIAGS sind in diesem Fall alle Applikationsserver, die einen HTTP/HTTPS-Port konfiguriert haben (vgl. icm/server_port_<xx>).
Falls es sich um eine stateful Verbindung handelt, wird der Applikationsserver gewählt, der die Transaktion bearbeitet.
Sofern vorhanden, geschieht das Dispatching von stateful Verbindungen anhand des externen Session Identifiers (ESID), der vom SAP Portal generiert wird ( Session-Dispatching). Wenn kein externer Session Identifier vorhanden ist, wird der ABAP Session Identifier ausgewertet.
Während der Wert des ABAP Session Identifiers den Servernamen enthält, an den ein Request dann weitergeleitet wird, enthält der externe Session Identifier keinen solchen Servernamen. Daher werden im Falle des Dispatchings anhand des externen Session Identifiers die Servernamen in einer Tabelle gespeichert, die im Shared Memory des Web Dispatchers liegt.
Folgende Grafik zeigt den verwendeten Algorithmus.
Hierbei bezeichnet ESID den externen Session Identifier sap-ext-sid und Session-Cookie den ABAP Session Identifier sap-contextid.
Java-Loadbalancing
Auch hier können Logongruppen konfiguriert werden. Ist keine Gruppe konfiguriert, so verwendet der SAP Web Dispatcher die interne Gruppe !J2EE.
Bei einem stateless Request führt der Web Dispatcher das Loadbalancing in der spezifizierten Gruppe bzw. der internen Gruppe !J2EE (!J2EES bei der Verwendung von SSL, s.u.) durch.
Falls es sich um eine stateful Verbindung handelt, wird der Applikationsserver gewählt, der die Transaktion bearbeitet.
Sofern vorhanden, geschieht das Dispatching von stateful Verbindungen anhand des Load Balancing Identifiers, der im AS Java generiert wird.
Wenn kein Load Balancing Identifier vorhanden ist, wird der J2EE Session Identifier ausgewertet.
Während der Wert des Load Balancing Identifiers den Servernamen enthält, an den ein Request dann weitergeleitet wird, enthält der J2EE Session Identifier nicht notwendigerweise einen Servernamen.
Daher werden im Falle des Dispatchings anhand des J2EE Session Identifiers die Servernamen in einer Tabelle gespeichert, die im Shared Memory des Web Dispatchers liegt.
Folgende Grafik zeigt den verwendeten Algorithmus.
Hierbei bezeichnet saplb-Cookie den Load Balancing Identifier und jsessionid-Cookie den J2EE Session Identifier.
Sonderfall HTTPS-Wiederverschlüsselung
Wenn der SAP Web Dispatcher den Request (HTTP oder HTTPS nicht End-to-End) SSL-verschlüsselt weitergeben soll (Parameter wdisp/ssl_encrypt, vgl. SAP Web Dispatcher und SSL), muss er als interne Gruppe !DIAGS bzw. !J2EES wählen. Ansonsten läuft der Algorithmus gleich.
Weitere Informationen über die internen Gruppen des Web Dispatchers finden Sie unter Architektur und Funktionsweise des SAP Web Dispatchers.