Oracle Fusion Middleware Blog

Deutsche Informationen rund um Oracle Fusion Middleware

Archive for the ‘Appserver’ Category

Monitoring von Oracle Forms-Applikationen mit Real User Experience Insight (RUEI)

leave a comment »

Werden Oracle Forms-Applikationen in Unternehmen eingesetzt, gibt es ein starkes Interesse des IT-Betriebs zu erfahren, wann die Antwortzeiten der Applikation bei den verteilten Endbenutzern (z.B. Niederlassungen im Ausland, regionale Filialen) ein akzeptables  Maß überschreiten. Der Betrieb erfährt häufig erst davon, wenn sich die Frustration der Anwender über Beschwerden entlädt, da die zentralen IT-Systeme (Datenbank, Application Server) scheinbar normal funktionieren.

Mit Oracle Real User Experience (RUEI) ist es möglich, den kompletten Netzwerkverkehr zwischen zentraler IT und den Arbeitsplätzen der Anwender mitzuschneiden und so auszuwerten, dass Abweichungen vom regulären Betrieb und deren Ursachen rasch erkannt werden können. RUEI kann für Forms- aber auch beliebige andere  Web-Anwendungen eingesetzt werden. Der folgende Post beschreibt die Besonderheiten beim Einsatz mit Oracle Forms-Anwendungen.

Wie setze ich RUEI auf ?
Oracle RUEI wird als dedizierter Server im Netzwerk über Port-Spiegelung oder ein TAP so angeschlossen, dass der komplette Netzwerkverkehr zwischen dem Applikations-Server und den Endbenutzern aufgezeichnet werden kann.
Eine grafische Admin-Oberfläche ermöglicht die Konfiguration des RUEI-Servers. Zunächst werden die zu überwachenden Netzwerk-Ports und die Art der Applikation festgelegt.
Im Falle von Oracle Forms-Applikationen sind dies der HTTP-Port des Application Servers (z.B. 9001).

RUEI PortsFür den ausgewählten Port muss das verwendete Protokoll eingestell werden. Für aktuelle Forms-Appplikationen wird dies normalerweise HTTP im Forms Servlet Mode sein.

RUEI ProtocolsAls nächstes muss der Typ der Applikation festgelegt werden. Da RUEI sich historisch zunächst auf die Oracle E*Business Suite konzentriert hat, werden Oracle Forms-Applikationen als spezielle Instanzen der E*Business Suite betrachtet und müssen folglich unter dem Menü-Punkt Suites => New Suite eingerichtet werden.

Image

Der aus den einzelnen Eingaben konstruierte Filter legt fest, welche Nachrichten anschließend aufgezeichnet werden. Hier muss man darauf achten, dass die Filterbedingung nicht zu eng (z.B. http://*myform.app:9001/forms/frmservlet) definiert wird, da der eigentliche Netzwerkverkehr einer Forms-Applikation über das Forms Listener Servlet (../forms/lservlet/) vermittelt wird.

Wie funktioniert die Aufzeichnung ?
Nach der Konfiguration sollten Forms Session, die der Filter-Bedingung entsprechen aufgezeichnet werden. Dies kann man überprüfen, indem man sich in der Admin-Oberfläche von RUEI die Collector Statistics anschaut. Einen exakteren Einblick erhält man, indem man sich als User moniforce  am RUEI-Server anmeldet und in das Verzeichnis /var/opt/ruei/processor/data/<host>/http/<datum>/proc2/ navigiert. In diesem Verzeichnis wird pro Minute eine Archiv-Datei (*.gz) angelegt, die sämtliche Nachrichten (Request/Response) im jeweiligen Zeitraum enthält. Bereits an der Größe der Dateien ist erkennbar, ob Forms-Nachrichten im Netz ausgetauscht wurden. Entpackt man die Archive, kann man sich die Nachrichten in einem Text-Editor genauer anschauen.

Welche Besonderheiten sind bei Forms-Applikationen zu beachten ?
Hier muss man sich daran erinnern, dass bei Forms-Applikationen Meta-Daten in verschlüsselten HTTP-Paketen übertragen werden. RUEI ist durch die Festlegung der Forms-Applikation als Suite vom Typ EBS in der Lage, die Forms-Nachrichten zu entschlüsseln und aufzuzeichnen. Der Beginn einer Forms Session wird durch einen entsprechenden Kommentar von RUEI in die Nachricht geschrieben. Alle weiteren Nachrichten, die zur selben Session gehören, werden standardmäßig durch die jsessionid identifiziert und zugeordnet. Dies ermöglicht später im Rahmen der Auswertung die komplette Verfolgung einer Session. Der beim Login verwendete Benutzer wird aus der Standard-Login-Maske von Forms entnommen. Wird an Stelle des Standard-Login eine eigene Maske verwendet, kann das Feld angegeben werden, in dem der Benutzername erfasst wird.

Wie können die aufgezeichneten Forms-Sessions ausgewertet werden ?
Die aufgezeichneten Daten werden mit einem geringen Zeitverzug von wenigen Minuten in ein Data Warehouse (Oracle) geladen und können nach verschiedensten Kriterien (Dimensionen) aufbereitet und ausgewertet werden.
So bietet es sich an, für Forms-Applikationen ein spezielles Dashboard mit vordefinierten Tabellen und Diagrammen anzulegen, das dem Betrieb einen aktuellen Überblick über den Zustand der Forms-Applikationen gibt.
Durch die Auswahl der Dimensionen im linken Bereich und dem Setzen von Filtern können passgenaue Auswertungen, wie z.B. über die Häufigkeit des Aufrufs bestimmter Module erstellt werden.

RUEI AuswertungDurch die lückenlose Aufzeichnung aller Forms-Nachrichten können einzelne Sessions im Detail verfolgt werden. Die Page Load Time gibt einen Hinweis darauf, wie lange bestimmte Aktionen beim Anwender gedauert haben. Durch das Setzen von Schwellwerten können Benachrichtigungen (Alerts) beim Überschreiten kritischer Werte ausgelöst werden.

RUEI SessionWelche Forms-Versionen werden durch RUEI unterstützt ?
Grundsätzlich können auch Forms-Applikationen älterer Versionen mit RUEI überwacht werden. Allerdings wurden mit Forms 11g, Release 2 zwei interessante Erweiterungen implementiert, die die Arbeit mit RUEI wesentlich vereinfachen (Release Notes):

  1. Durch das Setzen der Umgebungsvariable FORMS_RUEI_SEND_FORM_NAME=true in der Datei default.env (oder einer eigenen *.env-Datei) wird jeder Forms-Nachricht der Name des Forms-Moduls mitgegeben. Damit ist eine eindeutige Zuordnung der Forms-Objekte (z.B. Windows) zu den Forms-Modulen möglich.
  2. Mit dem Forms Build-In message() können im Parameter user_response zwei Konstanten (RUEI_BEGIN, RUEI_END) mitgegeben werden. Diese werden dem Benutzer nicht angezeigt, aber in den aufgezeichneten Nachrichten vermerkt. Auf diese Weise ist es möglich, Beginn und Ende von bestimmten Vorgängen (z.B. fachlichen Transaktionen) zu markieren und einer Auswertung durch RUEI zur Verfügung zu stellen.

RUEI Begin<JM>

Written by fmtechteam

27/05/2013 at 15:49

Veröffentlicht in Appserver, Forms, Jürgen Menge, RUEI

Tagged with ,

WebLogic Server 10.3 – Production vs. Development Mode

leave a comment »

Beim Erstellen einer WebLogic Domain wird durch eine Einstellung im Template festgelegt, ob die Domain im Production oder Development Mode angelegt wird.
Im Production Mode müssen Konfigurationsänderungen in zwei Schritten durchgeführt werden. Eine Änderung bewirkt eine Sperre (Lock & Edit) der Konfiguration, die Änderungen müssen dann explizit bestätigt werden (Release Configuration), damit sie wirksam werden und die Sperre gelöst wird. Außerdem werden im Production Mode die Versionierung und das Side-by-Side-Deployment unterstützt.
Im Development Mode sind Änderungen nach dem Bestätigen sofort wirksam (View changes and restarts).

Eine Umstellung von Development Mode auf Production Mode ist problemlos in der Console des WLS möglich.
Development Mode

Im umgekehrten Fall ist das nicht ganz so einfach, denn die WLS Console erlaubt den umgekehrten Weg nicht. Eine solche Situation tritt z.B. ein, wenn der Installer eines Produktes automatisch die Domain im Production Mode angelegt hat. Dies kann auf einer Entwicklermaschine störend sein, da u.a. Konfigurationsänderungen von außen (z.B. über den Oracle JDeveloper)  nicht ohne zusätzlichen manuellen Eingriff durchgeführt werden können.
Für die Umstellung von Production Mode in Development Mode gibt es mehrere Möglichkeiten, die in der Oracle Support Note Converting a Weblogic Server domain from Production Mode to Development Mode [ID 1124118.1] beschrieben sind:

  1. Öffnen der Datei config.xml unter <MIDDLEWARE_HOME>/domains/<DOMAIN_NAME>/config
    Änderung des Attributs production-mode-enabled auf false, d.h.
    <production-mode-enabled>false</production-mode-enabled>
  2. Mittels WLST Script DomainMBean.isProductionModeEnabled auf true setzen (Doc)
    WLST Script ausführen und danach WLS neu starten
    cd $ORACLE_HOME/common/bin
    ./wlst.sh
    connect(‚username‘,’password‘,’Adminserver:port‘)
    edit()
    startEdit()
    get(‚ProductionModeEnabled‘)  /* 0 = false 1= true
    set(‚ProductionModeEnabled‘,’False‘)
    save()
    activate()
    exit()

Alternativ können die Server mit der Kommandozeilen-Option -Dweblogic.ProductionModeEnabled=false gestartet werden. Allerdings reflektiert die Console diesen Zustand nicht.

<JM>

Written by fmtechteam

13/05/2012 at 17:30

Veröffentlicht in Appserver, Jürgen Menge

Tagged with , ,

Oracle Process Accelerators verfügbar

leave a comment »

Die ersten beiden Oracle Process Accelerators (PAs), Travel Request Management und Document Routing & Approval,sind jetzt verfügbar. Oracle Process Accelerators sind ablaufbereite, horizontale Prozesse, die in vielen Unternehmen vorkommen.

Oracle Process Accelerators sind Geschäftsprozesse auf Basis der Oracle BPM Suite 11g. Die PAs werden strengen Tests unterzogen und können out of the box eingesetzt werden. Sie können aber auch verändert und erweitert werden, um den Kundenanforderungen gerecht zu werden.

Weitere Informationen zu den Oracle Process Accelerators sind zu finden unter den folgenen Adressen :
OTN : http://www.oracle.com/technetwork/middleware/bpm/learnmore/processaccelerators-1609559.html
Oracle.com : http://www.oracle.com/us/technologies/bpm/process-accelerators/overview/index.html

Zugriff auf PAs
Aktuelle Oracle BPM-Kunden und andere Interessenten können den Zugriff auf die PAs (einschließlich der Installations-Dateien und der vollständigen Dokumentation) über folgenden Kontakt erhalten: oracle_process_accelerators@beehiveonline.oracle.com

<Gert Schüßler>

Written by fmtechteam

03/05/2012 at 14:18

Veröffentlicht in Appserver, BPM, Gert Schüßler

Tagged with , ,

Side by Side Deployment von BPM Formularen (Webapplikationen)

leave a comment »

In einer BPM Suite 11g Roadshow kam die Frage auf, wie können mehrere Applikationsversionen von BPM Formularen nebeneinander existieren. Neue Clientanfragen sollen mit der neusten Version von Formularen und derzeit laufende Anfragen mit der existierenden (vorherigen) Version arbeiten. Im WebLogic Server gibt es schon seit vielen, vielen Jahren die Möglichkeit eine solche Koexistenz mit dem Feature „Side by Side Deployment“ zu erreichen. Was muss gemacht werden, damit die Applikation diese Funktionalität nutzen kann?

Als erstes muss im Manifest.mf File der Applikation (liegt im EAR File) ein Eintrag für die Versionierung vorgenommen werden: WebLogic-Application-Version: v1, wobei v1 irgendeine Versionsbezeichnung ist. Im JDeveloper wird über den Menüpunkt File->New->General->File  eine neue Datei mit irgendeinem Namen (hier im Beispiel MANIFEST.mf) welches die Endung mf haben muss, angelegt. Wichtig: beim Speichern der Manifestdatei muss der Cursor in einer neuen Zeile und nicht direkt hinter v1 stehen, ansonsten wird der letzte Eintrag nicht übernommen.

Im JDeveloper muss nun für die Formularapplikation ein Deployment Profile für ein EAR File angelegt werden. Dieses ist in der Regel vorhanden.

Nun wird das zuvor erzeugte Manifestfile dem EAR File hinzugefügt, indem das EAR File editiert wird.

Damit bei einem Redeploy der Applikation die vorherige, aktive Session nicht gelöscht wird, muss in der weblogic.xml Datei der Parameter save-sessions-enabled auf true gesetzt werden:

Nun kann die Applikation über den Menüpunkt Application->Deploy auf den WLS verteilt werden. In der WLS Console ist zu erkennen, dass die Applikation versioniert ist.

Nach dem erneuten Deployment der geänderten Applikationsversion können nun mehrere Versionen dieser Applikation (Formulare) nebeneinander existieren. Bestehende Sessions arbeiten mit der alten Version weiter, neue Anfragen bekommen  die neue Version präsentiert. Hier die Anwendung der Version 1. Es ist zu erkennen, dass hier unten links das Feld Produktname fehlt:Anwendungsversion 2 zeigt den Produktnamen, d.h. alle neuen Clientrequests bekommen diese neue Version angezeigt:

In der WLS Console ist schön zu erkennen, dass die alte Version 1 im Moment noch aktiv ist, da eine aktuelle Session noch offen ist, d.h. das alte Formular ist noch in Bearbeitung.

Wenn die Session beendet wird und es sind keine weiteren Formulare mit der Version 1 in Bearbeitung, dann wird die Version 1 inaktiv und auf Retired gesetzt.

<Kersten Mebus>

Written by fmtechteam

03/04/2012 at 12:41

Veröffentlicht in ADF, Appserver, BPM, JDeveloper, Kersten Mebus, SOA

Data Sources für ADF-Applikationen im JDeveloper

leave a comment »

Entwickelt man im Oracle JDeveloper ADF-Applikationen mit Hilfe der ADF Business Components benötigt man eine Verbindung zur Datenbank. Diese Verbindung kann im Application Module (Configuration) entweder als JDBC URL oder als JDBC Data Source eingetragen werden.

Seit dem Release 11.1.2 des Oracle JDeveloper wird als Default eine JDBC Data Source mit dem Namen java:comp/env/jdbc/<conn>DS verwendet.
Wenn bei den Application Properties die Option Auto Generate and Synchronize weblogic-jdbc.xml with Descriptors during Deployment auf ON gesetzt ist, wird die Data Source als applikations-spezifische Data Source im WebLogic Server deployed und dort auch in der Console sichtbar.

Application Deployment Properties
Der große Nachteil besteht darin, dass bei jedem Test/Deployment der Applikation der Connection Pool für diese Data Source gestoppt und gestartet wird, was jedesmal mehr als eine Minute dauert.
Dieses Problem ist in der Note 1332498.1 – Undeploying ADF Application Takes > 60 Sec. When Using Application Level JDBC Datasource beschrieben.

Jetzt gibt es zwei Möglichkeiten, um damit umzugehen:

  1. Die Data Source als globale Data Source über die Console im WebLogic Server einrichten und bei den Application Properties die Option Auto Generate and Synchronize weblogic-jdbc.xml with Descriptors during Deployment auf OFF setzen.
  2. Die JDBC URL beim Application Module als alternative Methode für die Verbindung zur Datenbank verwenden.

Hier noch ein Auszug aus dem Oracle® Fusion Middleware Fusion Developer’s Guide for Oracle Application Development Framework:

„When you deploy to Oracle WebLogic Server, by default, the application-specific data source is not packaged with the application and Oracle WebLogic Server is configured to find a global data source named jdbc/applicationConnectNameDS using the look upjava:comp/env/jdbc/applicationConnectNameDS. Therefore, by following this naming convention, you enable a single data source connection name to work correctly when running the application in JDeveloper using an application-specific data source or when running on the deployed standalone server using a global data source.“

<JM>

Written by fmtechteam

23/01/2012 at 14:24

Veröffentlicht in ADF, Appserver, Jürgen Menge

Script zum Überprüfen der WebLogic Server Basic-Lizenz

leave a comment »

Kunden, die in der Vergangenheit den Oracle Application Server für den Betrieb ihrer Forms/Reports-Applikationen erworben haben, können mit der aktuellen Version der Oracle Fusion Middleware 11g den WebLogic Server nutzen. Um diesen Upgrade zu ermöglichen, wurde ein Lizenzkonstrukt mit dem Namen „WebLogic Server Basic“ geschaffen, das einen äquivalenten Funktionsumfang des WebLogic Server bereitstellt.

Konkret heißt dies, dass bestimmte Features des WebLogic Servers mit dieser Lizenz nicht genutzt werden dürfen. Welche das genau sind, ist in dieser Dokumentation detailliert beschrieben. Um nun überprüfen zu können, ob nach der Installation des WebLogic Servers gegen keine diese Beschränkungen verstoßen wird, gibt es vom Oracle Support ein Script (Python), das die Installation überprüft und mögliche Verstöße auflistet. Dieses Script und die Verwendung sind in der Note 885587.1  beschrieben.
Allerdings weist die aktuelle Fassung des Scripts noch einige Unzulänglichkeiten auf. So werden nach einer Standard-Installation der Oracle Fusion Middleware 11g Forms/Reports folgende Verstöße aufgelistet:

  1. Application reports/forms version 11.1.1.2.0 uses version 11.1.1.2.0
  2. Diagnostics framework system resource is being used:  Module-FMWDFW
  3. PubSub server

Aktuell gibt es nur für die Punkte 2 und 3 einen Lösungsansatz:

  1. Deinstallation des Frameworks FMWDFW über die WebLogic Server Console
  2. Uncheck des PubSub servers bei der Installation des WebLogic Servers

Vermutlich wird es in Kürze eine aktualisierte Version des Scriptes geben.

<JM>

Written by fmtechteam

07/11/2011 at 22:07

Veröffentlicht in Appserver, Forms, Jürgen Menge, Reports

Installation der ADF Runtime 11.1.2

leave a comment »

In einem früheren Post ging es bereits einmal um das Thema Deployment von ADF-Applikationen auf einem Stand-alone WebLogic Server. Nachdem die neue Version von ADF 11.1.2 verfügbar ist, tritt erstmals die Situation auf, dass es nicht zeitgleich eine korrespondierende Version des WLS dafür gibt.
Zunächst noch einmal das Prinzip:

  • jede Applikation, die mit Oracle ADF entwickelt wurde, benötigt die gleiche Version der ADF-Runtime auf dem WebLogic Server
  • in einer WLS Domain kann jeweils nur eine Version der ADF Runtime installiert sein.

Für die Version ADF 11.1.2 ist die Installation der ADF Runtime etwas komplizierter, da wir auf die Version 10.3.5 des WLS zurückgreifen müssen. Nach anfänglichen Problemen fand ich eine Beschreibung in zwei Posts von Timo Hahn:
http://tompeez.wordpress.com/2011/06/25/upgrading-wls-10-3-5-with-adf-runtime-11-1-2-0-0-sherman-patch/
http://tompeez.wordpress.com/2011/06/29/follow-up-upgrading-wls-10-3-5-with-adf-runtime-11-1-2-0-0-sherman-patch/

Hier kurz zusammengefasst die notwendigen Schritte:

  • Voraussetzung ist die Installation der ADF Runtime 11.1.1.5
  • Installation des Patches 12611176 mit OPatch (ADF Runtime Libraries)
  • Installation des Patches 12556632 mit OPatch (Enterprise Manager)
  • Ausführen eines WSLT-Kommandos im Offline-Modus (upgradeADF ‚<domain>‘) aus dem Verzeichnis <MW_Home>/oracle_common/common/bin

Das Ganze ist in der offiziellen Support Note 1328698.1 und in den Release Notes für ADF 11.1.2 beschrieben.

<JM>

Written by fmtechteam

26/07/2011 at 20:08

Veröffentlicht in ADF, Appserver, Jürgen Menge