Oracle Fusion Middleware Blog

Deutsche Informationen rund um Oracle Fusion Middleware

Archive for Oktober 2013

Performanceanalyse von WebCenter Portal

leave a comment »

Wer aus alten Zeiten das Oracle Portal noch gut kennt, der hat vielleicht noch den URL Parameter _debug (http://docs.oracle.com/cd/B14099_19/portal.1014/b19305/cg_app_c.htm#i643076) in Erinnerung und schätzen gelernt. Hierüber bekam man angezeigt, welche Zeit für welches Portalseitenelement bzw. für welche Phase des Renderns benötigt wurde. So konnte man mögliche Performance Bottlenecks des Portals genauer lokalisieren.

Mit dem WebCenter Portal 11.1.1.8 gibt es nun auch eine Möglichkeit, ein solches Performance Debugging einzuschalten und die einzelnen Services auf der Portalseite zu messen.

image

Im WebCenter Portal Admin Guide beschreibt das Kapitel G4: Troubleshooting Oracle WebCenter Portal Performance Issues das Vorgehen zur Performanceanalyse.

Zuerst muss der Performance Debug Modus auf dem Portal per WLST Kommando, wie in der Doku beschrieben, eingeschaltet werden. Dazu werden zuerst Portalkonfigurationen aus dem MDS gelesen und in eine webcenter-config.xml ins Filesystem extrahiert. Dann schaltet man in dieser Datei den Debug Modus ein und importiert sie schließlich über WLST wieder zurück ins MDS. Ein Neustart des Portals ist nicht notwendig.

Die Anzeige des Timings schaltet man dann auf der Portalseiten URL mit dem Parameter &perfDebug=on ein bzw. mit &perfDebug=off wieder aus. Es werden nun die einzelnen Taskflow Renderingzeiten ermittelt und farblich gekennzeichnet.

Farbe Zeit
grün <100ms
grün/gelb 100 – 500ms
gelb 500ms –1s
orange 1-3s
rot >3s

 

<DM>

Written by fmtechteam

24/10/2013 at 15:40

Java EE Hackaton für DevOps – Anmeldung jetzt

leave a comment »

Unsere deutschsprachige Java Application Server Plattform Community hat das Ziel, Kunden, Partner und Interessenten über die letzten Entwicklungen in den Bereichen Java EE, GlassFish und WebLogic Server zu informieren.

In unserer Auftaktveranstaltung für Entwickler und Administratoren (DevOps) wollen wir uns zwei Themen widmen:

HTML5 Entwicklung mit Java EE 7 und GlassFish 4: HTML5 ermöglicht die Entwicklung von modernen Web-Anwendungen für Desktops und verschiedene Endgeräte, die den neuen Anforderungen wie Offline-Betrieb und Real-Time Kommunikation gerecht werden. Das Programmiermodell setzt den Browser als einheitliche Plattform voraus. Die Anwendung setzt sich typischerweise aus HTML5, JavaScript, CSS3 und bereitgestellten Server-Ressourcen zusammen. Die einfache Bereitstellung von Server-Ressourcen ist der Sweet-Spot von Java und mehrere Teilspezifikationen von Java EE 7 tragen entscheidend dazu bei. Dazu gehören u.a. JAX-RS, JSON und WebSocket. Das neue Open-Source Framework Avatar erleichtert zusätzlich die Erstellung von HTML5 basierten Anwendungen.

WebLogic 12.1.2 New Features: Das Release 12.1.2 des Oracle WebLogic Servers enthält wieder wichtige Neuerungen, die sowohl für Administratoren, aber auch für Architekten und Entwickler unternehmenskritischer Java EE Anwendungen interessant und hilfreich sind. Einige ausgewählte Neuerungen sollen anhand von Beispielen und Demos praxisnah vorgestellt werden, u.a. Server Templates und Dynamische Cluster, Unterstützung von HTML5 Technologien wie WebSockets, angepasste Installation und neues Patching, vereinfachte Konfiguration (u.a. NodeManager).

In dieser Veranstaltung werden Sie die oben genannten Java-Technologien und Plattformen näher kennenlernen und können in praktischen Hands-On Lab einige davon selbst ausprobieren!

Ran an die Tasten …

Die Agenda

9:00-12:00
Java EE 7 und GlassFish Server 4 – Schnelleinstieg
WebLogic Server 12.1.2 – Product Update

13:00-16:00 Hands-On
HTML5 Coding mit JavaFX und Java EE 7
WebLogic Server 12.1.2 – New Features praktisch ausprobieren

16:00-16:30 Diskussion Java Application Server Plattform Community – Nächste Schritte und Veranstaltungen

Wo und Wann?
Leider müssen wir den für Dezember geplanten Termin in das neue Jahr verschieben. Wir werden die Planung an dieser Stelle und in der XING Gruppe bekanngeben. Hier können Sie sich auch gerne in der Community registrieren. Dann werden Sie regelmäßig über alle Aktivitäten der Community informiert.

Bei Fragen können Sie sich auch gerne per Mail an Michael(dot)Braeuer(at)oracle(dot)com oder Peter(dot)Doschkinow(at)oracle(dot)com wenden.

Written by fmtechteam

23/10/2013 at 15:00

Veröffentlicht in Michael Bräuer, Uncategorized

Session Timeout im BI Publisher

leave a comment »

Wer kennt diese Nachricht nicht, arbeitet man als Entwickler mit dem Oracle BI Publisher und wurde einige Zeit durch ein Gespräch oder Telefonat abgelenkt.

BIP Session Timeout

BI Publisher Session Timeout

War es im BI Publisher 10g noch relativ einfach, diese Zeit heraufzusetzen, gestaltet sich das in der aktuellen Version 11g nicht ganz so einfach.
Ein erster Versuch, den Parameter Session Timeout (in seconds) über die WLS Console in der Konfiguration des Deployments zu ändern bringt jedenfalls nicht das gewünschte Ergebnis.

Session Timeout Configuration

Session Timeout in der WLS Console

Dieser Wert beträgt standardmäßig 3600 (Sekunden). Da der Timeout wesentlich früher zuschlägt, zieht dieser Wert offenbar nicht. Tatsächlich findet man in der Datei web.xml folgende Einstellung (Angaben in Minuten)

<session-config>
  <session-timeout>20</session-timeout>
</session-config>

Offensichtlich kommt die erste Warnung vor dem Timeout 5 Minuten bevor der Benutzer abgemeldet wird.
Die Datei web.xml befindet sich in Abhängigkeit von der installierten Version des BI Publisher an unterschiedlichen Stellen. Man muss aber nicht mühsam danach suchen, da wir die Einstellung ohnehin nicht in der Datei ändern werden.
Stattdessen werden wir einen Deployment Plan erzeugen und den gewünschten Wert dort eintragen.
Es gibt verschiedene Möglichkeiten, einen Deployment Plan zu erzeugen (Oracle JDeveloper, Oracle Enterprise Pack for Eclipse, WLS Scripting Language, WLS Console).
Wir verwenden in diesem Fall die Web Console des WLS (http://host:port/console) und rufen zunächst die Applikation des BI Publisher (bipublisher bzw. xmlpublisher) unter dem Punkt Deployments auf.

BIP Deployment

BI Publisher Deployment

Dann wählen wir einen beliebigen Parameter, z.B. den (wirkungslosen) Session Timeout unter Configuration aus, ändern den Wert und speichern die Änderung ab. Der WLS fordert uns nun auf, einen Deployment Plan unter dem Namen Plan.xml anzulegen.

Deployment Plan

Deployment Plan

Wir akzeptieren sowohl den Namen als auch das Verzeichnis und können danach die Console schließen. Das der WebLogic Server im laufenden Betrieb eine Kopie der Plan.xml vorhält, müssen wir zunächst den Server herunterfahren, bevor wir Änderungen in der Datei vornehmen.
Bevor wir manuelle Änderungen in der Datei Plan.xml vornehmen, sollte unbedingt eine Sicherheitskopie der Datei  erzeugt werden. Sind die Änderungen fehlerhaft, startet in vielen Fällen die Anwendung nicht mehr und wir können notfalls auf die Sicherheitskopie zurückgreifen.

In der Datei Plan.xml sind folgende Ergänzungen vorzunehmen:

  1. In der Sektion <variable-definition>
    <variable>
    <name>NewSessionValue</name>
    <value>150</value>
    </variable>
    

     

  2. In der Sektion <module-override>
    <module-descriptor external="false">
    <root-element>web-app</root-element>
    <uri>WEB-INF/web.xml</uri>
    <variable-assignment>
    <name>NewSessionValue</name>
    <xpath>/web-app/session-config/session-timeout</xpath>
    </variable-assignment>
    </module-descriptor>
    

Da wir direkt im Text ändern, muss sehr sorgfältig auf die korrekte Schachtelung der Tags und die Syntax geachtet werden.
Anschließend kann der WLS wieder gestartet werden. Danach sollte man noch einmal das Deployment der Applikation in der WLS Console auf eventuelle Fehlermeldungen überprüfen.
Im Beispiel ist der Wert auf 150 Minuten gesetzt. Hier wäre es sinnvoll, zunächst mit einem kleinen Wert (z.B. 5 Minuten) zu testen. Taucht nach dieser Zeit das Fenster mit dem Warnhinweis auf, war unser Vorgehen offensichtlich erfolgreich und wir können den Wert hochsetzen.
Ein besonderer Dank geht an unseren Kollegen Michael Fuhr, der  diesen Lösungsvorschlag  entwickelt hat.

<JM>

Written by fmtechteam

15/10/2013 at 17:10

Veröffentlicht in BI Publisher, Jürgen Menge, WebLogic

Änderung des Hostnamens einer FMW Domain inklusive WebTier

leave a comment »

Manchmal kommt es vor, dass eine Fusion Middleware Domain (SOA, BPM, WebCenter, …) umziehen muss und sich der Hostname dadurch ändert. Das kann zum Beispiel notwendig werden, wenn man eine virtuelle Umgebung vervielfältigt bzw. verschiebt, oder man im Rahmen einer Cloudlösung eine neue FMW Instanz auf Basis eines Templates anlegt und im zugrundeliegenden Template ein anderer Hostname konfiguriert wurde.

In der Fusion Middleware Dokumentation ist beschrieben, wie eine solche Änderung der Netzwerkkonfiguration vorgenommen wird. Das betrifft im Wesentlichen

  • ein Umzug der Datenbank mit dem FMW Repository
  • ein Umzug des Nodemanagers
  • ein Umzug der Managed Server
  • ein Umzug der WebTier

Darüber hinaus muss man auch die Registratur der WebTier Instanz im Fusion Middleware Control (EM Website) aktualisieren. Diese Registratur wird vom chgiphost Script nicht angefasst. Der EM spricht den OPMN der Instanz über den in der topology.xml eingetragenen Hostnamen an, was dazu führt, dass entweder ein Fehler beim Starten/Stoppen der Instanz über die EM Website geworfen wird oder im schlimmeren Fall, wenn der alte Hostname noch existiert, der OPMN der alten Instanz angesprochen wird. Man muss also die Registratur der WebTier Instanz auch noch korrigieren. Dazu geht man wie folgt vor.

  1. Aktualisierung <DOMAIN_HOME>/opmn/topology.xml mit dem richtigen Hostnamen
  2. Wechsel ins Verzeichnis <MW_HOME>/<WT_HOME>/instances/<INSTANCE>/bin/
  3. Instanz stopppen,
    ./opmnctl stopall
  4. Instanz aus der Domain deregistrieren (Domain mus gestartet sein),
    ./opmnctl unregisterinstance –instanceName <INSTANCE> –adminHost <DOMAINHOST> –adminPort <ADMIN PORT>
  5. Instanz neu registrieren,
    ./opmnctl registerinstance –adminHost <DOMAINHOST> –adminPort <ADMIN PORT>
  6. Instanz starten,
    ./opmnctl startall
  7. Instanz überprüfen,
    ./opmnctl status

In der EM Website müsste nun die aktualisierte WebTier verwaltet werden können.

Schießlich müssen auch noch, je nach Ausstattung der Domain, diverse Korrekturen in den installierten Anwendungen bzw. FMW Produkten  vorgenommen werden. Im Falle des Content Server sollte man das Setup aller outgoing providers überprüfen und ggf. korrigieren, zum Beispiel für den Inbound Refinery Server. Auch die Konfigurationsparameter HTTServerAddress in der config.cfg des Content Servers bzw. Inbound Refinery Servers muss aktualisiert werden (<DOMAIN_HOME>/ucm/cs/config/config.cfg, <DOMAIN_HOME>/ucm/ibr/config/config.cfg). Sollte WebCenter Portal (aka WebCenter Spaces) in der Domain vorhanden sein, so muss man auch die Registratur der WebCenter Services ggf. korrigieren (EM Website). Man sollte schließlich auch nicht vergessen, in die httpd.conf des OHS zu schauen und den Hostnamen dort ggf. aktualisieren.

Diese Thematik kann unter Umständen sehr komplex werden. Je komplexer die Domain aufgesetzt ist (Produkte, Clustering, Verteilung usw.), desto aufwendiger wird auch ein solcher Serverumzug.

<DM>

Written by fmtechteam

10/10/2013 at 17:40

Veröffentlicht in BPM, Detlef Müller, SOA, WebCenter, WebLogic