Wenn die Zahl der Web-Benutzer steigt, kann ITS entsprechend skaliert werden. Die mehrschichtige ITS-Architektur bietet zwar zahlreiche Möglichkeiten, erfordert aber auch das Einhalten bestimmter Regeln. Hier werden einige der Mechanismen beschrieben, die eingesetzt werden können.

Verfügbarkeit und Skalierbarkeit sind miteinander verknüpft. Eine hohe Verfügbarkeit Ihres ITS-Service erreichen Sie nur, wenn Sie wirklich jeden Fehler vermeiden und somit verhindern, daß das Versagen einer einzigen Komponente das gesamte System zum Stillstand bringt. Dies bedeutet, daß Sie mindestens zwei getrennte ITS-Instanzen benötigen. Auf Verfügbarkeitsfragen wird, soweit dies erforderlich ist, kurz eingegangen.

Die CPU-Belastung des WGate-Rechners hängt hauptsächlich vom Programm des Web-Servers ab, da das WGate keine Datenverarbeitung durchführt und somit kaum CPU-Ressourcen verbraucht. Aus diesem Grund sollte das CGI-WGate nicht für ITS-Anwendungen, die eine hohe Performance benötigen, eingesetzt werden. Allgemein gilt, daß der Rechner, auf dem der Web-Server und das WGate laufen, eine deutlich geringere CPU-Belastung aufweist als der Rechner, auf dem das AGate läuft. Falls der Web-Server außer den SAP-Internet-Anwendungskomponenten noch weitere Anwendungen ausführt, kann selbstverständlich keine allgemeingültige Aussage getroffen werden.

Beachten Sie auch, daß diese Aussage nur auf die ISAPI- und NSAPI-Web-Server-Erweiterungen zutrifft. Bei Verwendung des CGI-WGate ist die Systembelastung für den Start eines neuen ausführbaren WGate-Programms für jede Anfrage sehr hoch und überschreitet bei weitem die Belastung des WGate selbst.

Das AGate führt die tatsächliche Verarbeitung der Internet-Anwendungskomponenten durch. Dazu analysiert es Web-Anfragen, öffnet Verbindungen, stellt Anfragen an das SAP-System, interpretiert HTML-Templates und andere Ressourcendateien und führt sie zusammen. Das Ergebnis sind neu generierte HTML-Seiten. Diese Aufgaben können recht zeitaufwendig sein.

Detaillierte Informationen über die Skalierung erhalten Sie bei den SAP-Hardwarepartnern.

Mehrere WGates, die auf separaten Web-Server-Rechnern laufen, können auf ein AGate zugreifen. Dies ist möglich, weil das WGate für jede Anfrage eine Verbindung zum AGate herstellt. Das AGate sendet die Antwort an das WGate über dieselbe Verbindung zurück.

Wenn mehrere WGates mit einem AGate verbunden werden, sind diese alle als zur selben ITS-Instanz gehörig zu sehen. Dies kann von Nutzen sein, wenn ein ITS verschiedene Netzwerke gleichzeitig bedient z.B. das Internet und Ihr Firmennetzwerk. Die folgende Grafik zeigt diese Einrichtung.

Wenn eine einzige AGate-Maschine nicht alle ITS-Benutzer bedienen kann, müssen mehrere AGate-Rechner eingesetzt werden. Auf diese Weise sind ITS-Anwendungen fast unbegrenzt skalierbar, vorausgesetzt das SAP-System kann mit der Belastung umgehen.

Für jeden AGate-Rechner ist ein eigener Web-Server notwendig, da das WGate derzeit nur mit einem AGate kommunizieren und Anfragen nicht auf mehrere AGate-Rechner verteilen kann. Auf die Web-Server wird über verschiedene IP-Adressen (falls sie sich auf eigenen Rechnern befinden), Port-Nummern oder IP-Namen (falls mehrere Web-Server auf einem Rechner eingesetzt werden) zugegriffen. Damit der Benutzer einen einzigen Zugangspunkt hat, muß die Möglichkeit geschaffen werden, die eingehenden Anfragen auf diese Web-Server zu verteilen.

Für diesen Lastausgleichsmechanismus gibt es eine wichtige Bedingung: Es muß sichergestellt werden, daß die Anfragen eines Benutzers immer an den Web-Server geleitet werden, auf dem der Benutzer seine Sitzung eröffnet hatte. Dies ist notwendig, da das AGate den Zustand einer Benutzersitzung (z.B. Anmeldedaten und den Zustand der SAP-Transaktion) im Speicher behält. Würde eine spätere Anfrage an einen anderen Web-Server geleitet, käme sie zu einem AGate, das keinerlei Informationen über diese Sitzung hat (Siehe helle Pfeile in der nachfolgenden Grafik). Dies würde zu einer Fehlermeldung führen.

Die meisten Web-Services haben im Gegensatz zum ITS keinen Zustand. Viele Produkte, die Lastausgleich bieten, können Web-Anwendungen mit Zustand nicht bearbeiten. Stellen Sie bei der Planung eines großen ITS-Service sicher, daß die gewählte Technologie mit dem ITS zusammen arbeiten kann. In den folgenden Abschnitten wird diskutiert, wie ein Lastausgleich erreicht werden kann, der die ITS-Anforderung erfüllt.

Ein weiterer Grund für den Einsatz mehrerer ITS-Instanzen ist, die Verfügbarkeit des Service zu erhöhen, falls einige Komponenten ausfallen. Der Aspekt der Verfügbarkeit der verschiedenen Methoden wird ebenfalls erörtert.

Round Robin DNS ist eine einfache Lösung, um eine eingeschränkte Form des Lastausgleichs für Netzwerk-Services zu erhalten. Das Domain Name System (DNS) wird verwendet, um den Namen eines Servers einer IP-Adresse zuzuordnen. Round Robin DNS ordnet DNS-Anfragen einem definierten Satz IP-Adressen zu, die den verfügbaren Web-Servern gehören. Dabei wird eine aufeinanderfolgende, umlaufende Belegung (Round Robin) eingesetzt.

Round Robin DNS funktioniert mit dem ITS, da der Client für die erste Verbindung lediglich eine Anfrage stellt und diese Informationen einige Zeit - länger als die Benutzersitzung üblicherweise dauert - im Speicher behält. Falls der Server ausfällt, muß eine Methode implementiert werden, die den Server aus dem DNS entfernt. Dennoch werden Clients versuchen, eine Verbindung zu dem ausgefallenen Server herzustellen, bis die DNS-Information auf der Client-Maschine wegen Zeitüberschreitung entfernt wird. Zwischenzeitlich haben die Clients keine Möglichkeit eine Verbindung zum Service herzustellen. Round Robin DNS verfügt nicht über eine intelligente Möglichkeit des Lastausgleichs.

Ein Web-Server kann zur Verteilung der Anfragen auf eine Reihe weiterer Web-Server eingesetzt werden. Dazu rufen die Benutzer den WGate-URL nicht direkt auf, sondern geben vielmehr eine Anforderung nach einem CGI-Programm auf dem Web-Server aus. Hierfür kann ein eigener Server oder einer der WGate-Server verwendet werden. Das CGI-Programm leitet die Anforderung an einen der WGate-Services um. Ein einfaches Lastverteilungsschema wäre, alle verfügbaren WGate-Server durch aufeinanderfolgende, umlaufende Belegung (Round Robin) auszuwählen. Ein etwas ausgeklügelteres Umleitungsprogramm könnte die Verfügbarkeit und Lastsituation der Server periodisch prüfen und die Server entsprechend auswählen.

Alle modernen Web-Browser unterstützen die Umleitung. Diese läuft für den Benutzer transparent ab: Der Browser stellt an Server A eine Anforderung. Server A sendet eine Anwort mit einem Kopf, der eine Umleitung beispielsweise zu Server Y enthält. Wenn der Browser diese Antwort erhält, wiederholt er automatisch die Anforderung, stellt sie jedoch an Server Y, in diesem Fall wäre dies ein WGate-Server.

Die folgende Grafik veranschaulicht den Vorgang.

Diese Technik hat den Nachteil, daß der im Browser angezeigte URL angibt, daß eine Umleitung stattfand. Manche Benutzer legen bookmarks für eine Transaktion an, die sie häufig benutzen, und untergraben damit den Lastausgleich. Dieses Problem kann bis zu einem gewissen Grad durch Verwendung von frames umgangen werden, wenn diese den URL verbergen, mit dem der ITS-Service aufgerufen wird.

Multiplexing der Anforderungen von einer IP-Adresse an die Server überwindet diesen Nachteil, da es für den Benutzer vollkommen transparent ist. Mit einem Netzwerkgerät, das Lastausgleich zwischen den Web-Servern bietet (z.B. ein programmierbarer Router oder ein spezieller Multiplexer), kann dies realisiert werden.

Wenn Sie diese Technik implementieren wollen, stellen Sie sicher, daß das Gerät für den Netzwerklastausgleich die oben beschriebene ITS-Zustandsanforderung erfüllen kann. Eine Möglichkeit ist, die eingehenden Anfragen auf Grundlage der Client-IP-Adressen weiterzuleiten. Ein weiteres Kriterium bei der Auswahl des Produkts ist, ob es intelligente Schemata für den Lastausgleich und die Hochverfügbarkeit zuläßt.

Die folgende Grafik veranschaulicht die Technik. Nach außen hat der Multiplexer die IP-Adresse A. Er leitet IP-Pakete an die Web-Server X und Y, die nach außen vollständig verborgen sind.

Die Last der Internet-Anwendungskomponenten für das SAP-System ist mit der Last gewöhnlicher SAP-Transaktionen vergleichbar. Wie bei normalen SAP-Transaktionen bestimmt die Last die Antwortzeit des Systems. Offizielle Skalierungstests werden von den SAP-Partnern durchgeführt.

ITS unterstützt den normalen SAP-Lastausgleichmechanismus, der den SAP-Message-Server zur Verteilung der Last auf mehrere SAP-Anwendungsserver verwendet. Sie sollten eine eigene Logon-Gruppe für den Zugang zum Web anlegen, die auf einige Anwendungsserver beschränkt ist. Dadurch schützen Sie interne Benutzer vor einer möglichen Überlastung durch das Internet.

Einen Service im Internet anzubieten, kann Probleme mit sich bringen, die üblicherweise in ERP-Systemen nicht auftreten. Beispielsweise ist die Zahl der potentiellen Benutzer im Internet sehr groß. Außerdem kann sich die Zahl der Personen, die Ihren Service tatsächlich nutzen, schnell ändern. Um ein internes SAP-Produktivsystem vor möglicher Überlastung aus dem Internet zu schützen, empfiehlt es sich, eine besondere Logon-Gruppe für den Internet-Zugang anzulegen und auf eine Teilmenge der Anwendungsserver zu beschränken.