HCL Connections basiert auf Java und nutzt JSP als serverseitige Platform zur Generierung der dynamischen Seiten. Verschiedene JSPs können angepasst werden. Es gibt verschiedene Gründe dafür, meist geht es um Anpassungen: Beispielsweise lässt sich das Navigationsmenü verändern oder man kann eigenen CSS/JavaScript Code einfügen. Zwar ermöglicht dies auch der Customizer, der als Reverse-Proxy vor Connections geschaltet wird. Die JSPs haben dennoch ihre Daseinsberechtigung. Beispielsweise immer dann, wenn serverseitige Logik benötigt wird, die man clientseitig mit JS nicht abbilden kann. Oder auch für den Fall, dass der Customizer nicht installiert ist. Falls nur kleinere Anpassungen vorgenommen werden sollen, sind die JSPs eine Alternative, die ohne Erweiterung der Infrastruktur genutzt werden können.
JSP-Änderungen funktionieren wie folgt: Es gibt „vanilla“ JSPs für jede Anwendung. Wir können diese auf Ebene der Anwendung überschreiben, damit eine bestimmte Änderung z.B. nur in Wikis oder Foren greift. Bestimmte JSPs wie header.jsp, footer.jsp oder login.jsp sind global genutzt und können auch global überschrieben werden. Möchte man z.B. im gesamten Connections eine andere Schrift setzen, wäre die header.jsp Datei dafür geeignet.
Der Basis-Zielordner ist immer ${SHARED_DIRECTORY}/customization, zum Beispiel /opt/IBM/shared/customization/.
Erstellt mit HCL Connections v7.0.0.0 Build IC7.0_Integration_20210423-1915
Überschreiben von JSPs einer bestimmten Anwendung
Die JSPs finden wir im Pfad /opt/IBM/WebSphere/AppServer/profiles/CnxNode01/installedApps/CnxCell/Wikis.ear/wikis.web.war/nav/templates, wobei CNXNode01/CnxCell entsprechend der WebSphere Umgebung zu setzen sind. Wikis.ear ist in diesem Beispiel die Anwendung, welche angepasst werden soll. In unserem Customization-Directory kann für jede Anwendung ein Unterordner erstellt werden. Er heißt wie die Anwendung selbst, jedoch in Kleinbuchstaben. Eine Übersichtsliste findet man hier in der Dokumentation.
Überschreiben von globalen JSPs
Möchten wir globale JSPs wie unter anderem z.B. header.jsp oder footer.jsp in der gesamten Connections-Umgebung anpassen, kopieren wir die jeweiligen Ansichten aus einer beliebigen Anwendung. Beispielsweise Wikis. Das Basis-Zielverzeichnis ist ${SHARED_DIRECTORY}/customization/common, ab hier gilt die Verzeichnisstruktur der Anwendung. Am besten legen wir den Basispfad zunächst an, da er standardmäßig nicht existiert:
mkdir -p /opt/IBM/shared/customization/common/nav/templatesNun kopieren wir im Beispiel die header.jsp aus der Wikis-Anwendung
cp /opt/IBM/WebSphere/AppServer/profiles/CnxNode01/installedApps/CnxCell/Wikis.ear/wikis.web.war/nav/templates/header.jsp /opt/IBM/shared/customization/common/nav/templatesDie Zieldatei /opt/IBM/shared/customization/common/nav/templates/header.jsp kann nun verändert werden. Zur Demonstration fügen wir nach dem letzten schließenden </div> Tag eine Überschrift ein. Diese befindet sich dadurch später in der Navigation, aber zum Testen spielt das keine Rolle.
418 --%></div><%--
wird zu
418 --%></div><h1>Dies ist eine Anpassung</h1><%--So werden die Änderungen wirksam
Um die Änderungen wirksam zu machen, muss entweder die jeweilige Anwendung (hier ist das die Homepage) per ISC neu gestartet werden. Oder man setzt die Umgebungsvariable CONNECTIONS_CUSTOMIZATION_DEBUG (siehe unten). Letzteres ist vor allem für das Testen interessant, da man so nicht ständig händisch neu starten muss.
Ergebnis:
Bei globalen Änderungen ist zu beachten, dass diese nur in den Anwendungen greifen, die neu gestartet wurden! Wenn also z.B. Wikis neu gestartet wurde, sind die Änderungen dort aktiv – in z.B. Blogs, Foren, etc. jedoch nicht. Falls es Probleme gibt, empfehle ich Common ebenfalls neu zu starten bzw. für den Testbetrieb am besten das automatische Neu laden zu aktivieren (siehe folgender Abschnitt).
JSP-Änderungen in Echtzeit darstellen, ohne händische Neustarts
Connections besitzt einen Debugmodus, der die JSPs alle paar Sekunden von der Festplatte lädt. In der ISC öffnen wir die WebSphere-Variablen:
Dort nach CONNECTIONS_CUSTOMIZATION_DEBUG suchen. Steht unten Filtered total: 0 muss die Variable wie folgenden gezeigt angelegt werden. Ansonsten genügt es, ihren Wert auf true zu ändern.
Muss die Variable erstellt werden, ist es erforderlich, zunächst oben einen Scope (Cell) auszuwählen. Dann ist es möglich, über den New Button neue Variablen anzulegen.
Name: CONNECTIONS_CUSTOMIZATION_DEBUG
Wert: true
Mit OK und anschließend Save bestätigen.
Anschließend alle AppsCluster neu starten. Alternativ kann man auch den ganzen Node neu starten, das ist gerade auf Testsystemen oft einfacher:
cd /opt/IBM/WebSphere/AppServer/profiles/CnxNode01/bin/
./stopNode.sh -stopservers -username wasadmin -password cnx
./startNode.shNach dem Neustart werden JSP-Änderungen automatisch wirksam. Es dauert jedoch ein paar Sekunden, bis diese greifen. Dafür spart man sich den händischen Neustart, der deutlich länger dauert. Gerade wenn mehrere Anwendungen involviert sind, denn ansonsten müsste man die alle von Hand stoppen und wieder starten.