Der erste Eindruck ist entscheidend, besonders bei Kundenportalen im Internet. Denn lange Lade- oder Antwortzeiten sowie Fehlermeldungen beim Aufruf bestimmter Funktionen verstimmen selbst die geduldigsten Besucher. Doch gerade angesichts der Komplexität leistungsfähiger Portale – beispielsweise SAP NetWeaver Portal –, die eine Vielzahl unterschiedlicher Anwendungen und Backend-System integrieren, steigt das Risiko von Performanceproblemen. Gleichzeitig ist es für Systemadministratoren nicht einfach, die Performance des Portals zuverlässig zu messen und die Ursache mangelhafter Verfügbarkeit zu ermitteln.
Selbst wenn die meisten Anwendungen und Backend-Systeme eine Verfügbarkeit von über 99 Prozent erreichen, kann ein einziger Fehler gravierende Auswirkungen auf die Performance des Portals haben.

Das schwächste Glied entscheidet

Das lässt sich am Beispiel des Online-Bankings verdeutlichen. Die meisten Banken erlauben es ihren Kunden, persönliche Kontodaten über das Internet einzusehen. Bei SAP NetWeaver Portal melden sich die Kunden dabei in der Regel über einen zentralen Zugang an, wo verschiedene iViews – wieder verwendbare Web-Komponenten, die relevante Informationen aus den Backend-Systemen anzeigen – die Finanzdaten abrufen. So zeigt ein iView beispielsweise die Girokontodaten an, während ein anderes die Sparkontodaten darstellt. Ein drittes iView ruft Daten von einem Börsen-Backend ab, um dem Kunden den Wert seines Portfolios mitzuteilen. Fällt auch nur eine der Anwendungen, auf die die iViews zugreifen, aus, wird das iView nicht geladen – selbst wenn die anderen Komponenten des Portals perfekt funktionieren.
Der Kunde hat den Eindruck, die Performance des gesamten Portals sei unzureichend und reklamiert das beim Kundenservice. Dort ergibt eine rasche Prüfung der gängigen Administrationswerkzeuge, dass das Portal einwandfrei arbeitet. Aus Sicht des Administrators trifft dies auch wirklich zu, denn das Portal funktioniert und ist erreichbar. Ohne einen Einblick in die mit dem Portal verbundenen Anwendungen kann der Administrator nicht herausfinden, wo die Ursache für das Problem liegt.
Nach verschiedenen Diagnose-Durchläufen, die viele Stunden dauern können, wird der Portaladministrator schließlich feststellen, dass ein iView fehlerhaft ist. Er muss anschließend jedes dieser Komponenten einzeln testen, bis er die problematische Anwendung gefunden hat. Er benachrichtigt schließlich den Anwendungsentwickler und wartet, bis dieser eine Lösung findet. Das Szenario zeigt, wie hoch der Aufwand ist, ein Performanceproblem zu ermitteln und zu beheben.

Gängige Fehler

Ganz allgemein lassen sich die potenziellen Probleme im Portal drei Kategorien zuordnen. Zum einen kann es vorkommen, dass SAP NetWeaver Portal durch die komplexen Strukturen ab Version 6 aufgrund von HTTP- und 404-Fehlern nicht über mehrere Knoten hinweg korrekt bereitgestellt wird. Weitere Anzeichen für HTTP-Fehler sind Null-Pointer, bei denen auf ein nicht existierendes Objekt verwiesen wird. Ganz ähnlich verlaufen Out-of-Bound-Fehler bei einem Verweis auf einen nicht auf dem Webserver befindlichen Array-Index. Die Fehlermeldung „500 Internal Server Error“ tritt meist dann auf, wenn das Portal auf eine Komponente zu verweisen versucht, die auf dem Server nicht vorhanden oder falsch benannt ist. Da sich die meisten IT-Umgebungen ständig verändern, dauert es unter Umständen Tage, solche Fehler zu diagnostizieren.
Eine zweite mögliche Ursache für eine schlechte Portalperformance sind Probleme in den im iView dargestellten Anwendungen. Während es für den Anwender so aussieht, als würden die verschiedenen iViews selbst extrem lang im Aufbau brauchen, können die Ursachen hierfür in der im Hintergrund laufenden Applikationslogik liegen. An welcher Stelle im Transaktionsstack einer Java Virtual Machine die Inperfomanz verursacht wird, bleibt unsichtbar. Der Portaladministrator hat keine Möglichkeit, die denkbaren Fehlerursachen rasch einzugrenzen, sondern muss eine zeitaufwändige Diagnose durchführen.

Probleme im Backend

Drittens hängt die Performance auch vom „befragten“ Backend ab. Beim Aufruf eines Backend-Systems, sei es eine Datenbank oder ein Data Warehouse, das nicht korrekt eingerichtet ist oder nicht antwortet, verschlechtert sich die Performance des gesamten Portals. So beispielsweise, wenn Daten zum Börsenwert eines Portfolios direkt von einem „langsamen“ Nicht-SAP-System in das iView extrahiert werden.
Manchmal harmoniert das Unternehmensportal nicht mit dem fraglichen Backend. Der Großteil des Informationsflusses zwischen Backend-Systemen und Portal erfolgt über SAP Java Connectors (SAP JCo), die Java-Systemen die Kommunikation mit jeder beliebigen SAP-Java-Anwendung ermöglichen. Langsame Servlets oder unterbrochene Verbindungen beeinträchtigen die Performance der JCos und verhindern die Kommunikation.
Neben den JCos bilden auch synchrone Datenbank-Anfragen, so genannte Datenbank-Threads, eine mögliche Ursache für eine Verlangsamung des Unternehmensportals. Wenn in der Datenbank-Queue zu wenig Threads vorhanden sind, treten immer mehr Verzögerungen auf. Die langen Antwortzeiten zwischen den Anwendungen und der Datenbank beinträchtigen ebenfalls die Performance des Portals.

Automatische Performance-Kontrolle

Portale liefern die Technologie, mit der Unternehmen kohärente webbasierte IT-Services für ihre Kunden, Partner und Mitarbeiter bereitstellen. Da die Lösungen für Unternehmensportale jedoch zunehmend komplexer werden, steigen auch die Anforderungen an die Verwaltung von Performance und Verfügbarkeit. Spezielle Werkzeuge und Prozesse gewährleisten, dass portalbasierte Anwendungen konstant den von ihnen erwarteten Geschäftswert liefern. Eine solche Lösung muss in Echtzeit Daten darüber liefern, wie sich die Performance des Portals für die Anwender darstellt. Darüber hinaus muss sie für geschäftliche Anwender, so genannte Application Owner, und IT-Mitarbeiter sämtliche Transaktionen über die gesamte Anwendungsarchitektur von SAP NetWeaver Portal durchgehend sichtbar machen.
Die Lösung Introscope von Wily bietet diese Unterstützung an. Sie ermöglicht damit, komplexe Web-Anwendungen zu überwachen und Probleme frühzeitig zu erkennen. Introscope gewinnt direkt auf Bytecode-Ebene Metriken aus Java-Applikationen, indem es den Bytecode zur Laufzeit gezielt mit Messpunkten über die Methoden, die Laufzeit und die Anzahl der Methodenaufrufe anreichert. Die Messpunkte, so genannte „Probes“, werden mittels eines Agenten, der Bestandteil der virtuellen Maschine ist, ausgelesen und an eine zentrale Verarbeitungskomponente gesendet. So hat die Messung keine negativen Auswirkungen auf die Performance der Applikation.
Die Laufzeitwerte über die Metriken zur Aufrufdauer oder die Anzahl der Aufrufe lassen sich mit Hilfe so genannter Dashboards für die unterschiedlichen Zielgruppen visualisieren. Damit rufen beispielsweise Systemadministratoren Informationen über die Verfügbarkeit oder die Einhaltung diverser Service Level Agreements ab, während Entwickler auf detailliertere Daten über das Laufzeitverhalten bestimmter Objekte oder über die jeweilige Methode zugreifen. Die unterschiedlichen Stakeholder erhalten somit verschiedene Ansichten auf Basis derselben Informationsmenge: Die Portalperformance ist jederzeit unter Kontrolle.