Auf dem Weg zum Portal
Aus RDUG Wiki
Auf dem Weg zum Portal: Was bisher geschah …
Es war einmal die Firma SMS Demag AG, die ein Intranet hatte. Dieses Intranet wird seit 1999 mit den Produkten aus dem Hause InfoOffice/RedDot gepflegt. Aktuell setzen wir CMS 7.5.0.48 ein und haben ca. 50 Redakteure bei rund 2000 statischen Informationsseiten und ca. 25 kleineneren Anwendungen die im Laufe der Jahre mit ASP, ASP.NET 1.1, 2.0, JSP/Struts oder sogar Notes Domino entstanden sind.
Dann kam unser Chef und sagte: "Wir brauchen ein Portal". Die Produktauswahl war leicht. Da wir im Bereich EDM/ERP mit SAP arbeiten und auch im HR das ESS Employee Self Service ein Thema ist, war das SAP Portal gesetzt. Von RedDot gibt es das SAP Portal Kit, so dass (glücklicherweise) das Ersetzen von CMS nicht zur Diskussion stand.
Da wir in unserer IT gerne so viel wie möglich selber machen, habe ich im Juli '07 zwei Schulungen besuchen dürfen: in KW27 war ich 3 Tage in Oldenburg zur Liveserver Schulung. In KW29 besuchte ich den SAP Kurs NET310, Abap für WebDynpro in Berlin. Zwischen den Schulungen habe ich den Liveserver auf einem Testsystem aufgesetzt und erste Experimente mit einer Kopie unseres Intranet-Projektes gemacht. Das hatte schon ganz gut geklappt. Letzte Woche habe ich dann SAP-seitig mit den ersten WebDypros Erfahrungen gesammelt.
Momentan bereite ich die weiteren Schritte vor. Mehr dazu demnächst hier. Ach ja. Online gehen wir am 1.1.2008 (man muß ja Ziele haben).
Zu meiner Motivation hier etwas zu schreiben: Ich möchte die RedDot-Community stärken und alle RedDot-User dazu bewegen sich mehr auszutauschen. Wir sind doch alle so Internet-Fuzzies. Warum nutzen wir nicht viel mehr die Foren, die uns die RDUG, Google oder RedDot selber bieten? Habt ihr Angst mitzumachen? Ok, ich weiss: alle stehen in den verschiedensten Projekten unter Druck. Aber vielleicht kann die Community in dem ein oder anderen Fall gangbare Wege aufzeigen und so etwas von dem Druck nehmen.
Auf dem Weg zum Portal: Schritt 1 (und schon am Stolpern)
Mit der Kopie unseres CMS Intranet-Projektes mache ich zur Zeit erste Experimente bezüglich des Liveservers. Das klappt auch ganz gut und die Startseite hat schon einige personalisierte Bereiche. Hier frage ich mich: Brauche ich eigentlich wirklich das Python-Skript zur Linkersetzung, wie wir das in Oldenburg bei der Schulung gezeigt bekommen haben? Eigentlich ja nicht, denn das CMS kann die Pfade über die entsprechende Funktion ja selber zusammenbauen. Ist in der Online-Hilfe schön beschrieben.
Der erste Schritt auf dem Weg zum Portal bringt mich auch schon zum Stolpern: In Hinblick auf das SAP-Portal-Kit und insbesondere den Portal-Navigation-Manager besteht derzeit die größte Herausforderung darin, das bestehende Projekt mit einer Navigationsmanager-fähigen Navigationsstruktur zu versehen. In der Theorie gar nicht so schwer (unser Internet-Auftritt läuft bereits erfolgreich mit Navigationsmanager), beiße ich mir momentan (trotz Hilfe des RedDot-Supports) daran die Zähne aus. Das Problem: irgendwo hat sich ein Bug versteckt. Unser Navigationsindex lässt sich nicht mehr zurücksetzen und es lassen sich auch keine bestehenden Master-Seiten in die Struktur hinein importieren. Es kommt immer die Meldung: "Zur Zeit wird der Navigationsindex neu importiert!" Mal gucken, was der Support sagt, die haben von mir kürzlich einen Oracle-Dump geschickt bekommen. Vielleicht muss ich nochmal ein neues Testprojekt von Null anfangen und dann die alten Sachen da rein laden.
Gibt es irgendwo schon eine schöne Anleitung, wie man nachträglich den Navigationsmanager in ein Projekt bringt? Ok, da gibt es demnächst einen Workshop der RDUG, aber da bin ich "leider" im Urlaub.
Terminlich sieht es so aus, dass die Portal-Spezies von RedDot momentan sehr beschäftigt sind. Wir werden wohl erst im Oktober einen Termin finden, bei dem die erste Integration von Liveserver und SAP Portal vorgenommen wird. Das gibt mir zum Glück hoffentlich genug Zeit, um unser Intranet Liveserver-fähig zu machen und die bestehende Navigation dem Layout des Portals anzupassen.
In einem Gespräch mit 2 voneinander unabhängigen Agenturentwicklern wurde mir stark davon abgeraten den RedDot Navigation Manager in bestehende Projekte älteren Datums zu integrieren. Nachdem, was ich für mich aus diesen Gesprächen als Fazit ziehen konnte, muss man stark abwägen, ob der Aufwand der hierbei entsteht nicht einen Relaunch mit Neuimplementierung rechtfertigt. Bei extrem großen Projekten mit Sharing ist das leider meist nur schwer zu realisieren. – Markus Giesen
Auf dem Weg zum Portal: Schritt 2 (oder eigentlich 3.6)
Heute morgen habe ich mal den Liveserver 3.6 installiert. Ich habe mich an die Installationsanleitung gehalten und erstmal schön einige bestehende Projekte sowie die Userdaten exportiert und anschließend den 3.5er deinstalliert. Die 3.6er Installation habe ich dann mit den Standardoptionen durchgeführt und schließlich das ganze Zeugs wieder importiert. Und siehe da: es hat geklappt und alles zusammen nur rund ein Stündchen gedauert.
Auf dem Weg zum Portal: Schritt 3
Portalmäßig läuft bei mir momentan nicht besonders viel. Das liegt zum einen an dem im Forum beschriebenen Problem (RedDot Support Ticket #16343), das übrigens bei mir auch auf einem Testserver (MS SQL statt Oracle) genauso auftritt. Zum anderen habe ich die letzten Wochen mit der Erstellung hübscher SAP-Webdynpros für Abap verbracht. Bis zum 1. Januar ist ja noch jede Menge Zeit.
Auf dem Weg ins Portal: Schritt 4 (jetzt geht’s los)
Als ich dann heute wieder im Büro war, bekam ich von Herrn Osterkamp die Mail, dass unser Einkauf tatsächlich die Bestellung für den Liveserver und das Portal-Kit abgeschickt hatte. Sehr kurze Zeit später war auch schon für nächste Woche ein Termin mit dem Kollegen vom Professional Service für die Installationsunterstützung gemacht. Ich bin sehr gespannt, denn das wird die heissnadeligste und hemdärmeligste Installation seit langem. So richtig gut vorbereit ist da nämlich nichts.
Auf dem Weg ins Portal: Schritt 5 Die Technik steht (quasi)
Also, die letzte Woche war -was unser Portalprojekt betrifft- überaus erfolgreich. Herr Oltmanns aus Oldenburg hat uns für drei Tage besucht und gemeinsam mit meinen Kollegen der SAP-Basis-Administration haben wir dann die beiden Welten SAP und RedDot miteinander verknüpft.
Zunächst war am Dienstag ein Update des CMS auf 7.5.1.36 fällig. Das ging problemlos. Anschließend wurde auf dem System der Portal-Navigation-Manager (PNM) als Plugin installiert. Das ergibt zwei neue Menüpunkte im Smarttree, die sich bei der Navigationsstruktur einklinken.
Der nächste Schritt war die Vorbereitung des Liveservers bezüglich Single Sign On mit dem SAP Portal. Dafür wird ein Zertifikat aus dem Portal heraus exportiert und mittels des Javaprogramms Keytool in eine für den Liveserver brauchbare Form gebracht. Auch diverse Einstellungen für Cookies, Sessions usw. müssen passen.
Der Mittwoch war geprägt von den SAP-seitigen Einstellungen. Zunächst wird ein par-File im Portal installiert (wenn’s die richtige Version ist, die zum CMS passt, hilft das später ungemein, nicht war, Herr Oltmanns? ;-) ) Nach der Installation ist dann ua. ein Webservice verfügbar, der die Infos aus dem Portal ziehen kann. Danach konnten über das Portal Content Directory wieder Attribute bezüglich Liveserver-URL, Cookies usw. gesetzt werden. Zusätzlich erfolgt die Definition bestimmter Portalgruppen und -rollen.
Pünktlich nach der Mittagspause war es dann schon so weit: Der PNM im CMS konnte die Navigationsstruktur des Portals auslesen. Via drag and drop werden dann einfach Einträge der CMS-Navigation in die Portalnavigation hineingezogen. Per Kontextmenü können dann auch SAP-Rollen zugewiesen werden, damit man später nur die Punkte angezeigt bekommt, die man braucht. Das Übertragen der Struktur erfolgt per Publizierung einer XML-Datei, die das Portal über einen Konnektor auslesen kann. Um 13:36 erhielt ich dann zum ersten Mal eine Mail mit folgendem Inhalt: The RedDot Portal Navigation Manager finished the publishing process of Portalversion Intranet 007 successfully. Hurra !!! Nachmittags bekamen wir dann netten Besuch aus Köln, der sich über den aktuellen Stand bei uns informiert hat.
Am Donnerstag schließlich kamen auch meine SAP-Basis-Kollegen aus dem Siegerland nach Düsseldorf um die Architektur des Systems kennen zu lernen. Außerdem haben wir noch einige Kleinigkeiten grade ziehen müssen, wie die Konfiguration eines Python-Files zur Linkersetzung oder die Ldap-Anbindung des Liveservers.
Das ganze sind jetzt noch Testsysteme, aber prinzipell können wir das so auch in der Produktivumgebung nutzen. Nächste Woche trifft sich unser Projektteam, damit wir noch so kleine inhaltliche Fragen klären können: Wie soll die Navigationsstruktur im Portal überhaupt ausssehen? Was für Rollen werden wir überhaupt haben? Wie soll die Startseite aussehen?
Alles im Allem bin ich auf jeden Fall angenehm überrascht, wie gut das ganze Thema quasi ohne Vorbereitung geklappt hat.
Ich würde mich gerne noch ein wenig mit anderen RedDot-Kunden austauschen, die auch das SAP-Portal mit dem Liveserver verknüpft haben und würde mich freuen, wenn sich jemand diesbezüglich bei mir meldet.
Auf dem Weg ins Portal - Schritt 6: Langsam wird’s ernst
Portalmäßig geht es jetzt voran. Viele Kleinigkeiten sind noch zu tun. Momentan arbeite ich am Berechtigungskonzept. Vielleicht kann mir von den Lesern jemand einen Tipp geben, wie es richtig geht. Ich habe mir jetzt für die Seiten Inhaltsbedingungen gebastelt, die die Gruppenzuordnungen überprüfen. Das ganze wird im CMS mit Liveserver-Bedingungen bestückt und via Import-Dynaments in den Liveserver gebracht. So weit - so gut. Das ganze hat nur einen Haken. Bislang haben wir die Berechtigung im CMS über die Exportstruktur und unterschiedliche Verzeichnisse geregelt. Gibt es für den Liveserver irgendwie die Möglichkeit Berechtigungen auf Verzeichnisse zu setzen oder muss ich tatsächlich jede Seite im CMS anpacken und die richtige Zugriffsgruppe zuordnen?
Bezüglich meines Navigation-Manager-Bugs habe ich mir jetzt mit einem Script beholfen. Das Problem ist, dass ich keine bestehenden Seiten in den Navigation-Manager hineinbekomme. Jetzt wir erst im Navigation-Manager eine neue Seite eingelegt und anständig im Menü verlinkt. Dann gehe ich her, trage in meinem Script die neue und die alte ID der Seite ein und dann werden per RQL sämtliche Inhalte und Verlinkungen von der alten Seite auf die neue übertragen und die alte auf ein Abstellgleis umgehängt.
Mit unseren englischen Seite muss ich auch tricksen. Da der Umfang höchstens 10% des deutschen Contents ausmacht, habe ich bislang im CMS nicht mit Sprachvarianten gearbeitet. Für die Liveserver-Portal-Integration ist das aber zwingend erforderlich. Es gibt auch für die beiden Sprachen zwei Projekte auf dem Liveserver. Also erweitere ich die Content-Klasse um ein URL-Feld. Ist dieses gefüllt, wissen wir, dass es sich um eine Dummy-Seite in der englischen Sprachvariante handelt, die mittels einem Process-Dynament ein Redirect auf die dazugehörige englische Seite in der Deutschen-Sprachvariante durchführt. Kapiert?
Letzte Woche habe ich dann angefangen unseren Produktiv-Server aufzusetzen und habe dafür auch schon den Liveserver 4.0.0.8 installiert.
Zur Zeit überarbeitet unser Haus und Hof Designer das Layout, d.h. ich werde die Templates demnächst auch noch mal anpacken müssen.
Es bleibt spannend. Der Zeitplan sieht vor, bis Ende Januar mit der Inbetriebnahme fertig zu sein, das ganze dann abteilungsintern 4 Wochen zu testen und im März für alle Kollegen online zu gehen.
Auf dem Weg ins Portal - Schritt 7: Mögen die Spiele beginnen
[1] Seit gestern testen wir mit rund 30 Kollegen das Portal. Haben meine SAP-Basis-Kollegen und ich bislang im Stillen gewerkelt, so wagen wir jetzt das erste Schrittchen in die Öffentlichkeit. Nächste Woche kommen dann die restlichen IT-Kollegen dazu, so dass wir mit rund hundert Leuten testen können, wie sich das Portal verhält, bevor wir den alten Intranet-Server abschalten. Wir sind also ein wenig hinter dem Zeitplan. Aber ich mußte mir von meinem Chef auch schon anhören: "Das ist ja eine Neverending Story". Hat einer von euch schonmal jemand (alleine) schneller ein SAP-Portal mit Liveserver-Integration in Betrieb genommen?
Erinnert ihr euch noch? Ich bekomme im CMS ja nach wie vor keine bestehenden Seiten in den Navigationmanager. Meine Skriptlösung hat zwar ganz gut funktioniert, aber dadurch bekam ja jede Seite eine neue ID. Deswegen habe ich einfach ein Template gebastelt, das quasi nur aus einem Container besteht. Damit wird nun eine neue Seite via NavMan erstellt und die bestehende in den Container gehangen. Das klappt ganz gut, ist aber natürlich eine Fleißaufgabe.
Zu den Inhalten des Portals: Unsere oberste Navigationsebene enthält nun die Menüpunkte Informationen, Anwendungen, Services und Zusammenarbeit. Wie findet ihr das? Unter Informationen befindet sich quasi unser altes Intranet mit den statischen Informationsseiten der verschiedenen Abteilungen. Auf der zweiten Ebene sind hier organisatorische Unterteilungen wie Geschäfts- und Zentralbereiche oder Unternehmensleitung. Unter Anwendungen verstehen wir webbasierte Applikationen, wie z.B. MS CRM. Der Punkt Services umfasst Sachen wie Telefonbuch, Speiseplan, Employee-Self-Service, Kataloge und Dienstleistungen, wie Mietwagenbestellungen. Der letzte Punkt Zusammenarbeit beinhaltet alles was wir so zum Thema Collaboration haben. Das ist heute allerdings nicht viel: Notes-Webmail und Sametime. Später sollen hier vielleicht auch Foren oder Wikis landen.
Noch ein bisschen was Technisches, am dem wir uns einige Zeit die Zähne ausgebissen haben: Zwischen dem SAP Portal und dem Liveserver funktionierte das Single-Sign-On manchmal nicht, bis es vorgestern soweit war, dass es gar nicht mehr klappte. Wir haben alle Systeme neu gestartet. Erfolglos. Wir haben die Konfiguration überprüft. Nichts zu finden. Wir haben ins rde.log geguckt: Verifying a SAP Ticket failed: com.sap.security.api.ticket.TicketExpiredException: Ticket not valid until Wed Mar 12 09:28:00 CET 2008. Was heißt das? Die Uhrzeiten differierten zwischen Portal- und Liveserver um mehr als zwei Minuten. Kleine UHRsache, große Wirkung.
Die größte Herausforderung ist für mich momentan der Parallelbetrieb zwischen altem und neuem Intranet. Über eine neue Projektvariante und neue Templates kann ich problemlos das neue Layout und auch schon erste Personalisierungen über Dynaments verwenden. Bei statischen Seiten klappt das auch gut, aber an einigen Stellen haben wir alte ASP-Anwendungen, die auf dem Liveserver natürlich nicht richtig laufen. Ich habe zwar schon zu Fuß über Include-Dynaments brauchbare Lösungen entwickelt, aber das jetzt alles automatisiert über Templates und Python-Action-Skripts hinzubekommen ist nicht so einfach.
Gibt es zu dem Projekt Eckdaten? Wie viele Intranetseiten gibt es nachher? Wie viele Manntage sind tatsächlich in die Entwicklung gesteckt worden? Wie viele parallele Benutzer arbeiten nachher mit dem System und wie viele insgesamt? Sieht auf jeden Fall nach einer spannenden Lösung aus. Was passiert denn mit Daten, die in Formulare eingegeben werden? Wie werden diese versand? Und werden diese geloggt? z.B. Suchanfragen. Auf jeden Fall weiter so! Grüße, Markus – Markus Giesen
Hallo Markus, zum Glück bist du nicht neugierig :-) Also gut: Gibt es zu dem Projekt Eckdaten? Ja. Vorgabe der IT-Leitung: Wir machen mal eben ein Portal. SAP EP ist gesetzt. Wir machen soviel selbst wie eben möglich. Das ganze so schnell es geht. Wir sind im Januar 08 fertig. (ok jetzt ist März) Wie viele Intranetseiten gibt es nachher? Es sind so ca. 2000 Seiten, unsere Seiten-Id ist aber schon größer 10.000. Wie viele Manntage sind tatsächlich in die Entwicklung gesteckt worden? Muß ich mal zusammenrechnen. Kann ich allerdings nur für meinen Part(RedDot CMS / LS). Wie viele parallele Benutzer arbeiten nachher mit dem System und wie viele insgesamt? Wir haben gut 3000 Mitarbeiter in Deutschland, die die Hauptzielgruppe sind. Weltweit kommen noch weitere dazu, für die wir einen Extrakt auf Englisch anbieten. Sieht auf jeden Fall nach einer spannenden Lösung aus.? Finde ich allerdings auch. CMS betreiben wir ja schon seit 1999 aber das hier ist schon eine andere Liga. Was passiert denn mit Daten, die in Formulare eingegeben werden? Wie werden diese versand? Web-Applikationen haben wir aller Art integriert: asp, asp.net, jsp/struts, notes domino, abap webdynpro... Und werden diese geloggt? z.B. Suchanfragen. ? Noch gar nicht. Erst mal gucken, dass das Ding ans Laufen kommt. Die Suche ist eh ein Thema für sich. Da müssen wir portalseitig noch mit dem T-Rex kämpfen. Ich habe jetzt schon Angst. Wie viele Manntage sind tatsächlich in die Entwicklung gesteckt worden: Bis jetzt habe ich ca. 60 Manntage (a 7 Stunden) RedDot-seitig aufgeschrieben.
Auf dem Weg ins Portal - Schritt 8: Portalfavoriten
[2]Selten habe ich länger für eine Zeile Code benötigt: Hier waren es rund zwei Tage, die mich ein kleiner Hyperlink gekostet hat.
Der Code im CMS-Template:
<a href="javascript:parent.parent.AddToPortalFavorites('XMLNAVURL1://<%info_Dateiname%>','<%Ueberschrift%>');"><img src="<%abo_rahmen%>" border="0" align="left" /></a>
Was passiert denn da? Das SAP Portal hat eine niedliche Funktion, die sich Portalfavoriten nennt. Zu jedem iview (Portlet) gibt es eine Menü, dass die aktuelle Seite den Favoriten hinzufügen können sollte. Leider funktioniert das nur für Seiten, die das Portal kennt und das ist bei tiefer liegenden Seiten bei uns nicht der Fall. Außerdem haben wir im "alten" (noch aktiven) Intranet auf jeder Seite ein Knöpfchen für eine selbstgebastelte Funktion gehabt, die wir Abonnement nennen.
Durch forschen mit der IE Developer Toolbar und im SAP Developer Network (da ist eine Community, die noch aktiver ist als die von RedDot) und Try And Error habe ich es letztlich rausbekommen.
Auf dem Weg ins Portal - Schritt 9: Englische Version
Unser Intranet besteht zu rund 90 Prozent aus deutschsprachigen Inhalten. Aber da gibt es noch einige Seiten, die in Englisch verfügbar sind. Und in dieser großen Differenz liegt mein Problem beim Handling der Inhalte:
Mit mehreren Sprachvarianten in CMS zu arbeiten macht nur dann Sinn, wenn die Inhalte fast deckungsgleich sind. Darum werden bei uns die englischen Seiten einfach mit in der deutschen Sprachvariante in einem Teilbaum des Projektes gehalten.
Der PortalNavigationManager und letztendlich auch das Portal erfordern die Arbeit mit Sprachvarianten. Auch auf dem Liveserver gibt es je Sprache ein eigenes Projekt (intra_de bzw. intra_en). Es führte kein Weg daran vorbei in unserem CMS auch eine englische Variante anzulegen. Für Seiten, die jetzt tatsächlich in Englisch verfügbar sind, muss ich dort die Überschrift übersetzen und die Seiten-ID dieses Inhaltes in der deutschen Variante eintragen (Feld <%SeitenIDdeutscheVersion%>).
Ruft nun jemand die englische Version des Portals auf, wird im Englischen Liveserver-Projekt die Seite angefordert und ein Redirect auf den entsprechenden englischen Inhalt im „deutschen“ Liveserver-Projekt durchgeführt.
Der dazu erforderliche CMS Code macht reichlich Gebrauch von CMS-Render-Tags und Liveserver-Dynaments. Man mag es kaum glauben, aber das hier klappt tatsächlich:
<!IoRangeNoRedDotMode> <rde-dm:import> <keywords> sprachvariante: <%Sprache%>, author: <%AutorName%>/<%AutorBeschreibung%>, standort: <%Standort%>, </keywords> <constraints> <constraint mode="expression" description="Berechtigung setzen"> (user:rde-groups containsany "<%Berechtigungsgruppen%>") </constraint> </constraints> </rde-dm:import> <reddot:cms> <if> <query valuea="<%SeitenIDdeutscheVersion%>" operator="==" valueb="String:-"> <htmltext><!-- keine Umleitung--></htmltext> </query> <query type="else"> <htmltext> <rde-dm:attribute mode="condition" source="request" attribute="rdeContentProjectId" op="eq" value="intra_en" tag="notag"> <rde-dm:if> <rde-dm:process mode="redirect" url="/cps/rde/xchg/intra_de/hs.xsl/<%SeitenIDdeutscheVersion%>.htm" > </rde-dm:process> </rde-dm:if> <rde-dm:else> <!-- <rde-dm:attribute mode="read" source="request" attribute="rdeContentProjectId" tag="notag" /> --> </rde-dm:else> </rde-dm:attribute> </htmltext> </query> </if> </reddot:cms> <!/IoRangeNoRedDotMode>
Markus Giesen danke ich recht herzlich für die Bereitstellung eines If-Code-Beispiels in seinem lesenswerten Blog.
Ach so. Als offiziellen Starttermin für unser Portal haben wir den 23. Juni 2008 festgelegt (passend zum Sommeranfang). Die Tests laufen zur Zeit sehr erfolgreich.
Auf dem Weg ins Portal: Tag X und eine Woche im Juli
Ein Satz mit X? Das war wohl nix!
Die gute Nachricht: Wir haben am Wochenende unser Portal in Betrieb genommen. Die schlechte Nachricht: Am Montagmorgen ab 8:35 Uhr ging nichts mehr und ich habe für zweineinhalb Stunden Blut geschwitzt.
Unser Intranet-Portal ist online seit dem 21. Juli 2008, 11:10 Uhr!
Was war passiert? Am späten Freitagabend haben wir eine Hinweismeldung und einen Hyperlink auf unseren alten Intranetserver gebracht. Gleichzeitig verteilten wir per Policy die URL des Portals als Startseite für alle unsere Benutzer. Montagmorgen bin ich dann zeitig aufgestanden und habe ab 7:00 Uhr auf einem Platz in unserer IT-Serviceline gesessen und den Gesprächen meiner Kolleginnen Petra und Brigitte gelauscht, die alle IT-Probleme entgegennehmen. Den beiden gilt übrigens ein herzlicher Dank, da sie mich den ganzen Tag über mit Nervennahrung in Form von ca. 1kg Schokolade über Wasser gehalten haben. Dazu hatte ich den Taskmanager des Liveservers und die Sessionübersicht offen. Und so wuchs die Anzahl der Sessions erst stetig, dann Sprunghaft bis gegen 8:30 rund 500 Sessions auf dem Liveserver aktiv waren. Der Taskmanager zeigte da schon vermehrt Ausschläge an die hundert Prozentmarke..... Und dann hätte es auf einer Intensivstation einen piepsenden Dauerton gegeben: Die Serverlast lag bei 100% und es ging nichts mehr. Mir ist jetzt noch ganz übel. Sekunden später starteten Petra und Brigitte einen Telefonmarathon erster Klasse.
Als erstes habe ich in probiert den Tomcat neu zu starten, aber das Arbeiten war auch per Fernsteuerung auf dem Server nur sehr zäh möglich. Direkt nach dem Neustart ging die Last wieder auf hundert Prozent hoch. Dann bin ich zu meinen Kollegen Stefan aus der Servertruppe gelaufen. Da es sich bei der Kiste um eine virtuelle Maschine handelt war es leicht den verfügbaren Speicher von 1GB auf 2GB hochzusetzen. Auch nach diesem Reboot ging die Auslastung direkt wieder auf 100%. Also habe ich den RedDot-Support angerufen und dort auch schnelle Hilfe erhalten. Der Tomcat wurde wieder gestoppt, dann das Blob-Hotfix und das Servicepack eins installiert. Zu dem Zeitpunkt waren die Roten Punkte ausschließlich in meinem Gesicht und meine Servicelinedamen verrieten einzelnen Anwendern, dass die alte Intranet-URL doch wieder funktioniert. Dann überprüften wir die Einstellungen für den verfügbaren Speicher der JVM. Und siehe da: 512MB Maximum sind eindeutig zu wenig! Diesen Punkt hatte ich in meinen ganzen Betrachtungen überhaupt nicht auf dem Schirm, da wir von einem Rd-Mitarbeiter gesagt bekommen hatten, dass die Standardinstallation des Liveservers auch für den Produktivbetrieb geeignet sei. Über die rdsetenv.cmd haben wir den Speicher auf 1024MB gesetzt und den Tomcat wieder gestartet. Und siehe da: Gegen 11:10 Uhr wurden die ersten Request erfolgreich und zügig abgearbeitet. Abends um sieben habe ich den Tomcat nochmal angehalten und ihn als Dienst gestartet. Seit dem sind jetzt schon vier Arbeitstage ohne Ausfälle und mit zügiger Seitenauslieferung vergangen.
Da letztendlich eine hohe Prozessorlast zum "offline" führte, haben meine Chefs entschieden, die virtuelle Maschine durch eine "echte" Hardware zu ersetzen - und das möglichst sofort. Meine Kollegen aus der Servertruppe haben mir dann einen eigentlich anderweitig verplanten Dual-Quadcore-Superduperserver zur Verfügung gestellt. Der Montagnachmittag verging dann zügig mit Bestellung eines neuen Lizenzschlüssels und der Basisinstallation des Liveservers. Dienstagvormittag wurden dann sämtliche Inhalte des deutschen und englischen Projektes vom aktiven Liveserver auf den künftigen überspielt und nachmittags die Integration in ein SAP-Test-Portal durchgeführt. Das funktionierte alles ganz gut nur leider gab es am späten Nachmittag, als dann auch die Navigation vom CMS ins Portal publiziert wurde, einen Rückschlag: Beim Klicken auf deutschsprachige Navigationspunkte wurden die Englischsprachigen Seiten ausgeliefert. Mittwochmorgen haben wir dazu den Rd-Support eingeschaltet und die konnten bis jetzt die Nuss auch nicht knacken. Am Donnerstagnachmittag hat mein Kollege Achim von der SAP Basis zum Glück die betreffende Stelle gefunden: es gibt tatsächlich eine Option "erzwungene Anzeigesprache", die auf dem Testportal auf englisch stand.
Nebenher habe ich die Tickets oder Anrufe vieler Kollegen abgearbeitet, die irgendeine Information im Portal nicht gefunden haben: Entweder wussten Sie nicht, wo sie gucken mußten oder sie waren nicht in den richtigen LDAP-Gruppen oder die Berechtigung auf der Seite war nicht richtig gesetzt. Ein Haufen Kleinkram halt. An meiner englisch Version muss ich auch noch was tun: für einen normalen Redakteur ist es nicht ersichtlich, wann und wo er eine Umleitung einbauen muss.
Der Freitag stand dann im Zeichen von Tests: Damit zumindest in etwa geguckt werden kann, ob der neue Liveserver hält was er verspricht habe ich mich mit dem Tool Apache Jmeter beschäftigt. Auf dem LS habe ich 10 Dummy User angelegt und die automatisch auf die Loginmaske und 5 weitere Seiten geschickt. So konnte ich innerhalb weniger Minuten 1250 Session auf dem Liveserver öffnen. Der Dualquadcore schlug im Taskmanager achtfach aus, kam aber nie auf hundert Prozent.
Jetzt ist es Freitagnachmittag und ich sitze in der Straßenbahn auf dem Weg nach Hause. Das Wetter ist schön und ich werde wahrscheinlich mit meinen Töchter im Garten zelten.
Nachtrag: Das Wochenendwetter war dann leider doch sehr durchwachsen. Dafür haben sich meine Frau und ich mal mit der ursprünglichen Form des Debuggings beschäftigt: Meine Töchter hatten sich im Kindergarten mit Läusen infiziert....
