Oracle Fusion Middleware Blog

Deutsche Informationen rund um Oracle Fusion Middleware

Archive for the ‘Forms’ Category

Nachdem sich der Staub gelegt hat – Oracle Forms 12c

leave a comment »

Im Oktober 2015 ist das neue Release 12c von Oracle Forms und Reports erschienen (12.2.1). Es ist Zeit für eine Zusammenfassung der wichtigsten Neuerungen und Erfahrungen.
Die wesentlichen Neuerungen sind im Forms Services Deployment Guide beschrieben.

Für das Deployment auf dem Client (Desktop) gibt es jetzt 4 Optionen:

  • Java Applet im Browser (wie in den bisherigen Versionen)
  • JNLP eingebettet in HTML
  • Java WebStart
  • Standalone (Forms Standalone Launcher)

Dies ist deshalb wichtig, weil die meisten Browser künftig das Netscape API (NPAPI) zur Integration von Java und Flash über Plug-Ins nicht mehr unterstützen werden.

Die Installation von Oracle Forms und Reports 12c erfordert die Fusion Middleware Infrastruktur und damit eine Datenbank zur Speicherung von Schema-Informationen. Die notwendigen Schemata werden mit Hilfe des Repository Creation Utility (RCU) angelegt und speichern unter anderem Informationen zur Authentifizierung (Oracle Platform Security Services).
Hier bei ist zu beachten, dass die Lizenzen für die Internet Developer Suite, den Internet Application Server (Enterprise Edition) und die WebLogic Server Suite eine limitierte Lizenz für die Nutzung der Datenbank enthalten. Lediglich für die Lizenz „Forms and Reports“ ist eine zusätzliche Datenbank-Lizenz erforderlich. Kunden können dafür eine bereits lizensierte Datenbank nutzen oder müssen eine zusätzliche Lizenz erwerben.

Neben der offiziellen Dokumentation zur Installation gibt es zwei Installationsbeschreibungen für Forms und Reports 12c in deutscher Sprache:

Nicht vergessen sollte man die Tatsache, dass in den Release Notes von 12.2.1 Oracle Reports als „deprecated“ gekennzeichnet wurde. Anwender von Oracle Reports sollten sich daher rechtzeitig Gedanken machen, wie bestehende Oracle Reports-Anwendungen abgelöst werden können. Oracle Forms 12c bietet als Alternative die native Integration des Oracle BI Publisher an.

<JM>

Advertisements

Written by fmtechteam

23/03/2016 at 16:12

Stabiler Betrieb von Oracle Forms-Applikationen mit Deployment Rule Sets (DRS)

with one comment

Oracle Forms-Anwendungen laufen seit vielen Jahren als Java Applet im Browser und benötigen dazu das Java Plug-In im Browser.
Anwender von Oracle Forms stehen vor dem Problem, dass sie nicht in der Lage sind, ihre Anwendungen mit jedem Update des Java Runtime Environments (JRE) zu testen. Zwar gibt es inzwischen die Möglichkeit, neue Java-Versionen als Early Access Releases vorab zu testen (z.B. https://jdk7.java.net/download.html). Dies gilt aber nicht für Security Updates, die ohne Vorankündigung veröffentlicht werden und eventuelle Seiteneffekte in den Forms-Anwendungen verursachen.

Forms-Anwender stecken gewissermaßen in einem Dilemma zwischen Sicherheit (was das Einspielen der aktuellen Security Patches erfordert) und Stabilität (was die Nutzung gründlich getesteter Java-Versionen erfordert). Eine Lösung liegt in der Nutzung der Java  Deployment Rule Sets (DRS), die seit dem JDK 7 Update 40 zur Verfügung stehen. Sie bieten u.a. die Möglichkeit, durch Regeln das Ausführen bestimmter Anwendungen mit bestimmten Java-Versionen festzulegen. Diese Lösung ist insofern auch akzeptabel, da Forms-Applikationen typischerweise im Intranet laufen und hier die Bedrohung durch Sicherheitslücken kaum gegeben ist. Für alle anderen Anwendungen kann die Nutzung der aktuellsten Java-Version oder sogar ein Blockieren der Ausführung festgelegt werden. Deployment Rule Sets können in Verbindung mit Java Applets und WebStart-Anwendungen eingesetzt werden.

Informationen zu den Deployment Rule Sets findet man an folgenden Stellen:
http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/deployment_rules.html
https://blogs.oracle.com/java-platform-group/entry/introducing_deployment_rule_sets
https://blogs.oracle.com/java-platform-group/entry/deployment_rule_set_by_example

Die Regeln werden in einer XML-Datei (ruleset.xml) festgelegt und zur Ausführungszeit sequentiell abgearbeitet. Neben der Festlegung bestimmter Versionen der JRE können mit Hilfe von Regeln u.a. auch Warnungen unterdrückt sowie die Ausführung von Anwendungen blockiert werden.

Es folgt eine Beschreibung der wesentlichen Schritte zum Einrichten eines Deployment Rule Sets (DRS) zum Ausführen einer Forms-Applikation mit einer bestimmten festgeschriebenen Version der JRE. Da ich nicht auf ein kommerzielles Zertifikat zurückgreifen konnte, entstand der größte Aufwand bei der Erstellung und Einbindung eines eigenen Zertifikats. Auf dem Arbeitsplatz muss eine aktuelle Java-Version (JRE > Java 7 Update 40) installiert sein, die das DRS erkennt und ausführt. Diese startet dann eine zweite Java-Version (dies kann auch eine JRE 6 sein), mit der die Forms-Applikation ausgeführt wird.

  1. URL oder Hash Sign der Anwendung ermitteln, für die eine Regel festgelegt werden soll. Im Falle von Oracle Forms wäre dies z.B. die folgende URL: http://jmenge-de.de.oracle.com:7001/forms/frmservlet.
  2. Anlegen einer Datei ruleset.xml zum Beispiel mit folgendem Inhalt:
    <ruleset version="1.0+">
      <rule>
        <id location="http://jmenge-de.de.oracle.com:7001/forms/frmservlet" />
        <action permission="run" version="1.7.0_25"/>
      </rule>
      <rule>
        <id />
        <action permission="block" />
      </rule>
    </ruleset>
    

    Die Regeln bewirken, dass die Forms-Anwendungen (URL) immer mit der Version 1.7.0_25 ausgeführt werden. An dieser Stelle kann aber auch eine ältere Java-Version (JRE 6) aufgerufen werden.
    Alle anderen Anwendungen (Applets, Java WebStart) werden durch die zweite Regel blockiert.

  3. Die Datei ruleset.xml muss in ein jar-Archiv mit dem Namen DeploymentRuleSet.jar gepackt werden. Dies erfolgt mit dem Befehl:
    jar -cvf DeploymentRuleSet.jar ruleset.xml
    Wichtig ist, dass sich alle Dateien im gleichen Verzeichnis befinden. Die Datei ruleset.xml darf nicht mit einer Pfadangabe im Archiv stehen.
  4. Als nächstes muss das jar-Archiv signiert werden. Das erforderliche Zertifikat kann von einer Certificate Authority (CA) angefordert oder selbst erstellt werden.
    Eine Anleitung zur Signierung mit einem eigenen Zertifikat findet man hier:
    https://blogs.oracle.com/java-platform-group/entry/self_signed_certificates_for_a
    Das signierte jar-Archiv kann anschließend mit dem Befehl
       jarsigner -verify DeploymentRuleSet.jar
    überprüft werden.
  5. Das jar-Archiv muss in ein bestimmtes Verzeichnis auf dem Desktop des Endanwenders kopiert werden. Bei einem MS Windows-System heißt dieses Verzeichnis:
    <Windows Directory>\Sun\Java\Deployment
    und wird in der Regel neu anzulegen sein.
    In der Java Console (Tab Security) kann man jetzt überprüfen, ob das Deployment Rule Set auch tatsähchlich erkannt wurde.
    JavaConsole
  6. Zum Testen muss man jetzt nur noch die Forms-Anwendung übr die festgelegte URL aufrufen.
    Zunächst wird die aktuelle (d.h. sicherste) Version der JRE gestartet. Diese interpretiert das Deployment Rule Set und ruft auf Grund unserer definierten Regel eine ältere (getestete) Version des JRE auf. Dies kann man sehr gut im System Tray von MS Windows erkennen, da nach erfolgreicher Ausführung dort zwei Java-Icons zu sehen sind.
    SystemTray
    Schlägt der Aufruf fehl, geben die Fehlermeldungen einen Hinweis auf die Ursache (z.B. Can not verify self-signed DeploymentRuleSet.jar.).

Wir haben damit erreicht, dass die internen Forms-Anwendungen mit einer stabilen und getesteten Version der JRE ausgeführt werden. Rufen die Anwender eine andere Anwendung (Applet, Java WebStart) im Browser auf, wird die aktuellste Version der JRE verwendet oder wie in unserem Beispiel die Ausführung blockiert.
Die Verwendung der Deployment Rule Sets ist in Verbindung mit Oracle Forms-Anwendungen offiziell supported.

<JM>

 

Written by fmtechteam

07/05/2014 at 11:54

Veröffentlicht in Forms, Java, Jürgen Menge

Eine kurze Historie des Java Plug-Ins für Forms

leave a comment »

Wird Oracle Forms als Web-Applikation ausgeführt, wird für die Interaktion mit dem Anwender ein Applet ausgeführt, das ein Java Plug-In im Browser benötigt.
Bis einschließlich Forms 10g wurde als Java Plug-in vor allem der Oracle JInitiator verwendet, der auf dem JDK 1.3 basierte.
Warum Oracle ein eigenes Plug-In bereitstellte, lag vor allem daran, dass es im Java Plug-In von Sun noch einige Bugs gab, die vor allem die Ausführung der Forms-Applikationen stark beeinträchtigte.
Mit der Übernahme des Unternehmens Sun durch Oracle ergaben sich bessere Voraussetzungen, diese Probleme zu beheben. Mit Forms 11g wurde deshalb die Weiterentwicklung des JInitiators eingestellt.

In der Entwicklung des Java Plug-Ins (ehemals Sun, jetzt Oracle)  hat es einige deutliche Zäsuren gegeben.
Ab der Version 1.5.0_06 ist eine dynamische Versionierung möglich. Dies vereinfacht die Administration einer Anwendung, da nicht mehr eine bestimmte Version des Plug-Ins auf dem Client, sondern nur eine Mindestversion gefordert wird. Eine Einschränkung nach oben, d.h. auf ein bestimmtes Release (z.B. JDK 6)  ist über das Family Feature möglich. Siehe dazu folgendes Dokument.
Mit der Version 1.6.0_10 wurde  das Next Generation Plug-In veröffentlicht, dass weitgehende Änderungen mit sich brachte. So laufen die Applets in einer eigenen Java Virtual Machine (JVM) unabhängig vom Prozess des Browsers. Mit Hilfe des Parameters java_version können so innerhalb eines Browsers unterschiedliche Java-Versionen ausgeführt werden. Allerdings muss beachtet werden, dass u.a. dieser Parameter nicht zur Anwendung mit Oracle Forms-Applikationen supportet ist und deshalb auch in der Forms-Dokumentation nicht erwähnt wird. Eine Beschreibung des neuen Verhaltens kann in diesem Dokument nachgelesen werden.
Die letzte größere Veränderung kam mit zunehmenden Sicherheits-Problemen des Java Plug-Ins im Browser. Die Firma Oracle verkündete mit der Version 1.7.0_21 verschärfte Sicherheits-Maßnahmen für künftige Updates, die u.a. die notwendige Signierung aller Applets, ein Tool zum automatischen Entfernen älterer Versionen und erweiterte Warnungen (Alerts) betreffen. Nachzulesen sind diese Erweiterungen in diesem Dokument.
Gerade die zunehmenden Warnungen (Alerts) bei den Anwendern stellen den Administrator von Forms-Anwendungen in Unternehmen vor neue Herausforderungen.

Noch ein wichtiger Hinweis zum Support:
Wird eine bestimmte Version des JDK (und damit auch des Plug-In) in einem Oracle-Produkt verwendet, gelten die Support-Fristen des übergeordneten Produktes (z.B. Oracle Forms), selbst wenn der offizielle Support für die entsprechende Version des JDK ausgelaufen ist (siehe dazu die Note 1557737.1 vom Oracle Support). So ist es auch zu erklären, dass es über den Oracle Support noch Updates für eine bereits abgelaufene Version des JDK geben kann.
So können zum Beispiel nur Kunden mit einem gültigen Wartungsvertrag das JDK 6 Update 51 über MyOracle Support  beziehen (Note 1439822.1).
<JM>

Written by fmtechteam

29/07/2013 at 19:24

Veröffentlicht in Forms, Java, Jürgen Menge

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 ,

Oracle Forms und das JDK

leave a comment »

Seit Oracle Forms als Web-Applikation (Applet) im Browser der Anwender läuft, wird für die Ausführung ein Java Plug-In benötigt. Bis einschließlich Forms 10g konnten die Kunden den Oracle JInitiator verwenden, der auf Version 1.3 des Java Development Kit (JDK) basierte.
Spätestens mit der aktuellen Version 11g von Forms kommt ausschließlich das Java Plug-In von (ehemals) Sun zum Einsatz. Für Forms-Kunden ist daher die Zertifizierung dieses Plug-Ins für bestimmte Browser und Browser-Versionen wichtig (das Betriebssystem des Clients spielt für die Zertifizierung keine Rolle mehr).
Nachlesen kann man diese im offiziellen Zertifizierungs-Dokument für die Oracle Fusion MIddleware 11g Release 1 bzw. 11g Release 2.
Hier findet man zum gegenwärtigen Zeitpunkt die Aussage, dass für das Release 1 ab Forms 11.1.1.6 die Java-Version ab 1.7.0_04 unterstützt wird. Für das Release 2 gibt es noch keine Zertifizierung von Java 1.7, was aber sicher nur eine Frage der Zeit ist.
Der Standard-Support (Premier Support) für das JDK 1.6 läuft im Dezember 2013 aus (siehe Oracle FMW – Lifetime Support Policy).
Dies ist nicht zu Verwechseln mit dem Terminus „End of Life (EOL)“ für das JDK 1.6. Dieser Zeitpunkt wird bereits im November 2012 erreicht und besagt, dass es keine weiteren öffentlichen Updates für das JDK 1.6. mehr geben wird.
Kunden, die Produkte der Oracle Fusion Middleware (wie z.B. Oracle Forms) einsetzen, brauchen sich deshalb jedoch nicht zu beunruhigen, da das JDK als Teil eines übergeordneten Produktes dessen Supportzyklus folgt. Nachzulesen ist dies in der Oracle Support Note 952075.1.

Noch ein Nachtrag aus aktuellem Anlass:
Das Datum des „End of Life (EOL)“ wurde auf den Februar 2013 verlängert. Nähere Informationen findet man hier.

 

<JM>

Written by fmtechteam

19/07/2012 at 19:51

Veröffentlicht in Forms, Jürgen Menge

Tagged with , ,

Neues Statement für die Oracle Tools erschienen

leave a comment »

Es gibt eine aktualisierte Version des Statement of Direction (SOD) für die Oracle Tools. Oracle Forms und Report werden Bestandteil der Oracle Fusion Middleware 12c sein. Gleichzeitig werden Alternativen für diese Technologien aufgezeigt, d.h. Oracle ADF und APEX für Forms und BI Publisher für Reports.

<JM>

Written by fmtechteam

15/03/2012 at 22:08

Veröffentlicht in ADF, BI Publisher, Forms, Jürgen Menge, Reports

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