HTTP-Sitzungsmanager mit WebSphere Portal konfigurieren

Sie können HTTP-Sitzungen über WebSphere Portal persistent in einem Daten-Grid speichern.

Vorbereitende Schritte

Ihre Umgebungen von WebSphere eXtreme Scale Client und WebSphere Portal müssen die folgenden Voraussetzungen erfüllen:
  • Installieren Sie WebSphere eXtreme Scale Client auf Ihren Knoten von WebSphere Application Server und WebSphere Portal.Weitere Informationen finden Sie unter WebSphere eXtreme Scale Client mit WebSphere Application Server installieren.
  • WebSphere Portal Version 7 oder höher.
  • Angepasste Portlets müssen in WebSphere Portal konfiguriert werden. Die Verwaltungsportlets, die mit WebSphere Portal bereitgestellt werden, können momentan nicht mit Daten-Grids integriert werden.

Informationen zu diesem Vorgang

Die Einführung von WebSphere DataPower XC10 Appliance in eine Umgebung von WebSphere Portal kann in den folgenden Szenarien hilfreich sein:
Wichtig: Obwohl die folgenden Szenarien Vorteile bieten, kann die Einführung von WebSphere DataPower XC10 Appliance in die Umgebung zu einer erhöhten Prozessorauslastung auf der WebSphere-Portal-Schicht führen.
  • Wenn Sitzungspersistenz erforderlich ist.

    Wenn die Sitzungsdaten aus Ihren angepassten Portlets bei einem Ausfall von WebSphere Portal Server verfügbar bleiben müssen, können Sie die HTTP-Sitzungen persistent im Daten-Grid von WebSphere DataPower XC10 Appliance festschreiben. Die Daten werden auf vielen Servern repliziert, was die Datenverfügbarkeit erhöht.

  • In einer Topologie mit mehreren Rechenzentren.

    Wenn sich Ihre Topologie über mehrere Rechenzentren an verschiedenen physischen Standorten erstreckt, können Sie die HTTP-Sitzungen von WebSphere Portal im Daten-Grid von WebSphere DataPower XC10 Appliance persistent speichern. Die Sitzungen werden in den Daten-Grids in den Rechenzentren repliziert. Wenn ein Rechenzentrum ausfällt, werden die Sitzungen von einem anderen Rechenzentrum übernommen, das eine Kopie der Daten im Daten-Grid besitzt.

  • Speicherbedarf auf der WebSphere-Portal-Server-Schicht verringern.

    Durch die Auslagerung der Sitzungsdaten in eine ferne Schicht von Container-Servern befindet sich ein Teil der Sitzungen auf den Servern von WebSphere Portal. Dieser Datenauslagerung verringert den Speicherbedarf der WebSphere-Portal-Server-Schicht.

Vorgehensweise

  1. Konfigurieren Sie die Anwendung wps von WebSphere Portal und alle angepassten Portlets so, dass die Sitzungen im Daten-Grid gespeichert werden können.

    Weitere Informationen finden Sie unter Sitzungspersistenz für ein Daten-Grid. Diese Aktion führt dazu, dass die angepassten Portlets so verbunden werden, dass die Sitzungspersistenz in Ihrem Daten-Grid möglich ist.

  2. Wenn Transport Layer Security/Secure Sockets Layer (TLS/SSL) für den Server von WebSphere Portal und für das Gerät konfiguriert ist, müssen Sie die TLS/SSL-Truststores konfigurieren.
    • Wenn die resultierende abgehende Kommunikation vom Server von WebSphere Portal zum Gerät TLS/SSL verwendet, müssen Sie das Gerätezertifikat der Konfiguration von WebSphere Application Server hinzufügen. Verwenden Sie das Script addXC10PublicCert.py. Dieses Script befindet sich im Verzeichnis WAS-Stammverzeichnis/bin:
      wsadmin.bat -conntype SOAP -port <PORTAL-SERVER-SOAP-PORT> -lang jython 
      -user wpsadmin -password wpsadmin -f addXC10PublicCert.py
    • Wenn die resultierende eingehende Kommunikation vom Gerät zum Server von WebSphere Portal TLS/SSL verwendet, aktualisieren Sie den Truststore des Geräts, und fügen Sie die öffentlichen Zertifikate für den Server von WebSphere Portal hinzu. Die Aktualisierung des Truststores ermöglicht die Kommunikation zwischen dem Gerät und WebSphere Portal.
    1. Extrahieren Sie den öffentlichen Schlüssel des persönlichen Zertifikats von Portal Server. Verwenden Sie das Dienstprogramm IKEYMAN. Dieses Dienstprogramm erstellt eine Datei mit der Erweiterung .arm. Weitere Informationen finden Sie im Artikel Öffentliche Zertifikate für Truststoredateien extrahieren.
    2. Laden Sie den öffentlichen Truststore für das Gerät herunter. Weitere Informationen finden Sie unter Transport Layer Security (TLS) konfigurieren.
    3. Verwenden Sie das Dienstprogramm iKeyman, um die Datei truststore.jks, die Sie vom Gerät extrahiert haben, mit dem öffentlichen Zertifikat von Portal Server in der Datei .arm zu aktualisieren. Weitere Informationen finden Sie im Artikel Unterzeichnerzertifikate importieren.
    4. Laden Sie die aktualisierte Truststoredatei auf das Gerät hoch. Klicken Sie auf TLS-Einstellungen übergeben, nachdem Sie den Truststore hochgeladen haben. Der Verbund wird automatisch erneut gestartet, wenn Sie die TLS-Einstellungen übergeben und der neue Truststore den anderen Geräten im Verbund hinzugefügt wird. Weitere Informationen finden Sie unter Transport Layer Security (TLS) konfigurieren.
  3. Starten Sie die Server von WebSphere Portal erneut. Weitere Informationen finden Sie unter WebSphere Portal Version 7: Starting and stopping servers, deployment managers, and node agents.

Ergebnisse

Sie können auf WebSphere Portal Server zugreifen, und die HTTP-Sitzungsdaten für die konfigurierten angepassten Portlets werden persistent im Daten-Grid gespeichert.
Wenn das gesamte Daten-Grid, in dem die Anwendungssitzungsdaten gehostet werden, über den Web-Container-Client nicht verfügbar ist, verwendet der Client stattdessen den Basis-Web-Container in WebSphere Application Server für die Sitzungsverwaltung. Das Daten-Grid kann in den folgenden Szenarien nicht erreichbar sein:
  • Es besteht ein Netzproblem zwischen dem Web-Container und den fernen Container-Servern.
  • Die fernen Container-Server-Prozesse wurden gestoppt.
Die Anzahl der im Speicher verwalteten Sitzungsreferenzen, die mit dem Parameter sessionTableSize angegeben wird, wird auch auch dann beibehalten, wenn die Sitzungen im Basis-Web-Container gespeichert werden. Die Sitzungen, die am längsten nicht mehr verwendet wurden, werden aus dem Sitzungscache des Web-Containers entfernt, wenn der Wert von sessionTableSize überschritten wird. Wenn das ferne Daten-Grid wieder verfügbar ist, können Sitzungen, die aus dem Web-Container-Cache entfernt wurden, Daten aus dem fernen Daten-Grid abrufen und die Daten in eine neue Sitzung laden. Wenn das gesamte ferne Daten-Grid nicht verfügbar ist und die Sitzung aus dem Sitzungscache entfernt wird, gehen die Sitzungsdaten des Benutzers verloren. Aufgrund dieses Problems sollten Sie nicht das gesamte Produktionsdatengrid beenden, wenn das System unter Last ausgeführt wird.
Übergeordnetes Thema: Sitzungspersistenz für ein Daten-Grid
Zugehörige Tasks:
Transport Layer Security (TLS) konfigurieren
Mit HTTP-Befehlsschnittstelle verwalten
Zugehörige Informationen:
Schlüssel mit der grafischen Schnittstelle IKEYMAN verwalten