Oracle Fusion Middleware Blog

Deutsche Informationen rund um Oracle Fusion Middleware

Archive for the ‘Jürgen Menge’ 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>

Written by fmtechteam

23/03/2016 at 16:12

Installation des Oracle BI Publisher 12c

leave a comment »

Der Post beschreibt in kurzer Form die Installation des Oracle BI Publisher 12c (12.2.1) im Standalone-Modus, d.h. ohne weitere Komponenten der Oracle BI Suite. Dies ist dann sinnvoll, wenn der BI Publisher als Reporting-Lösung in Verbindung mit Anwendungen (z.B. Oracle Forms, Oracle ADF) eingesetzt werden soll. Die folgende Beschreibung setzt Kenntnisse des Oracle BI Publisher voraus. Neueinsteigern wird empfohlen, sich zunächst auf den BI Publisher zu informieren und danach die offizielle Dokumentation zu Rate zu ziehen.

Installationsprozess

Der Installationsprozess folgt dem allgemeingültigen Vorgehen bei der Installation von Komponenten der Oracle Fusion Middleware 12c.

  1. Benötigt wird auf dem Rechner ein aktuelles 64-bit JDK (Version 8).
  2. Im ersten Schritt wird die WebLogic Server Infrastructure 12.2.1 installiert. Die verwendete Java-Version muss auf das JDK 8 verweisen.
  3. Im nächsten Schritt werden die benötigten Software-Komponenten in ein Oracle Home installiert. Wenn man später die zahlreichen Beispiel-Reports nutzen will, sollte man bei der Auswahl der zu installierenden Komponenten die Option „BI Platform with Samples“ auswählen.
  4. Im dritten Schritt erfolgt die Konfiguration des BI Publishers, d.h. die WLS Domain wird einschließlich der Server und ihrer Konfiguration erzeugt. Entsprechen die Ergebnisse nicht den Wünschen, kann dieser Schritt wiederholt werden, indem die Domain komplett gelöscht und neu erzeugt wird.
    Während der Konfiguration müssen in einer Repository-Datenbank mehrere Schemata erzeugt werden. Dies kann man mit Hilfe des Repository Creation Utility (RCU) entweder vor dem Aufruf der Konfiguration oder innerhalb des Konfigurationsprozesses tun. Das Utility RCU kann aus dem Verzeichnis $ORACLE_HOME/oracle_common/bin aufgerufen werden.
    Will man später die Beispiel-Reports nutzen, muss während der Konfiguration die „Sample App Lite“ ausgewählt werden.

Ergebnisse der Installation

Im Ergebnis der Installation werden der Node Manager, der WLS Admin Server und Managed Server angelegt. Als Security-Modell ist „FMW Security“ voreingestellt. Eine erste Anmeldung ist mit den Daten des Administrators möglich.

Nacharbeiten und Besonderheiten der Version 12c

  1. Zunächst empfiehlt sich die Einrichtung eines Super Users im Security Tab des BI Publishers, der unabhängig von den verschiedenen Security-Modellen für die Anmeldung genutzt werden kann.
    Stellt man danach das Security-Modell auf „BI Publisher“ um, können nach einem Restart des Servers Benutzer direkt über das User Interface des BI Publisher eingerichtet werden.
  2. Es fällt auf, dass der Speicherort des BI Publisher Repositories nicht mehr über das User Interface geändert werden kann. Auch eine Trennung zwischen dem Reports- und dem Admin-Teil des Repositories ist so nicht mehr möglich.
    Will man dennoch das Repository an einem anderen Speicherort verwenden, so kann man dies in der Datei
    $DOMAIN_HOME/config/fmwconfig/bienv/core/bi-environment.xml
    durch die Änderung des Parameters <bi:singleton-data-directory> erreichen (siehe http://docs.oracle.com/middleware/1221/biee/BIESG/cluster.htm#BIESG9273).
    Wird diese Datei nicht gefunden, können folgende JVM-Parameter (z.B. in der setDomainEnv.sh) gesetzt werden:

    DXDO_FONT_DIR={path_to_font_directory}/fonts
    Dxdo.server.config.dir={path_to_bip_repository}
    Dxdo.server.resource.type=file
    Dxdo.obischema=false

    Ich habe eine relativ einfache Lösung durch die Verwendung von symbolischen Links gewählt und konnte damit auch Reports- und Admin-Teil des Repositories voneinander trennen.

<JM>

Written by fmtechteam

13/01/2016 at 21:02

JDeveloper 12c, ADF und die Datenbank-Abhängigkeiten

leave a comment »

Bei der Entwicklung und dem Deployment von ADF-Applikationen stößt man immer wieder auf das Thema, dass es zwingende Abhängigkeiten zur Datenbank gibt. Im JDeveloper 12.1.x und 12.2.x wird beim Start des eingebetteten WebLogic Servers zugleich eine Derby Database gestartet, die auf den Port 1527 horcht. Die Derby Database ist ein Teil der WebLogic Server-Installation. Im Blog Post Derby DB lässt sich nicht starten .. wird beschrieben, wie man das Problem lösen kann, das durch fehlende Rechte (Java Policy) beim Start entsteht. Allerdings ist es auch möglich, den Start gänzlich zu unterdrücken, indem man in der Datei setDomainEnv.sh des eingebetteten WebLogic Servers nach dem String „DERBY_FLAG“ sucht und die entsprechende if-Schleife komplett auskommentiert. Man findet diese Datei im Verzeichnis DefaultDomain/bin unter dem Systemverzeichnis des installierten JDevelopers.

Eine weitere Abhängigkeit zu einer Datenbank besteht beim Deployment von ADF-Applikationen in der Version 12c.  Die Abhängigkeit betrifft in diesem Fall die Fusion Middleware Infrastruktur, konkret die Oracle Platform Security Services (OPSS). Sie benötigen für den Betrieb im Cluster eine Datenbank, die beim Anlegen einer JRF (Java Require Files) Extended Domain zwingend erforderlich ist. Die Certification Matrix für das jeweilige Release der Fusion Middleware 12c gibt an, welche Datenbanken und welche Versionen dafür zum Einsatz kommen können.

Duncan Mills hat in seinem Blog Setting up a standalone WebLogic 12c install for ADF Without a Database  beschrieben, wie man diese Anforderung in einer Entwicklungs- oder Test-Umgebung umgehen kann.
Mit dem neuen Release 12.2.1 der Oracle Fusion Middleware ist es nun möglich, eine sogenannte Restricted JRF Domain anzulegen, die keine Abhängigkeit mehr zu einer Datenbank für OPSS aufweist.

<JM>

Written by fmtechteam

12/11/2015 at 13:33

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

Tagged with ,

Dem Android Emulator unter Linux Beine machen

leave a comment »

Die Langsamkeit des Android Emulators beim Testen von Apps ist bekannt und kostet dem Entwickler Zeit und Nerven. Neben dem Projekt Genymotion, das eine virtuelle Maschine mit Android unter VirtualBox bereitstellt, gibt es Möglichkeiten, die Arbeit des Emulators unter MS Windows bzw. Linux zu beschleunigen.
Hier kurz eine Beschreibung der notwendigen Schritte, um unter Ubuntu eine signifikant schnellere Arbeitsweise des Emulators zu erreichen:

  • Dazu muss der Prozessor der Maschine Hardware Virtualization unterstützen und diese im BIOS aktiviert sein.
    Zur Überprüfung das folgende Kommando ausführen:
    egrep -c ‘(vmx|svm)’ /proc/cpuinfo
    Das Ergebnis muss eine Zahl sein, die größer als 0 ist.
  • Die folgenden Packages müssen installiert werden:
    qemu-kvm, libvirt-bin, ubuntu-vm-builder, bridge-utils
  • Der aktuelle Benutzer muss den Gruppen kvm und libvirtd hinzugefügt werden.
  • Im Android SDK die System Images für Intel x86 Atom installieren:

Android SDK

  • Eine virtuelle Maschine (AVD) auf Basis des Intel Atom System Image definieren und starten.

Intel Atom AVD

Es gibt eine wesentliche Einschränkung zu beachten:
Es können nicht zwei Anwendungen gleichzeitig laufen, die KVM nutzen. So können beispielsweise nicht VirtualBox und eine Android AVD auf Basis des Intel Atom System Image gleichzeitig laufen.

<JM>

Written by fmtechteam

21/09/2015 at 21:17

Generierung von REST Clients mit verschiedenen IDEs (JDeveloper, Eclipse, NetBeans)

leave a comment »

In der Welt mobiler Anwendungen erfolgt der Zugriff auf Daten und Funktionen im Backend zumeist über RESTful Services, die die Nachrichten im kompakten JSON-Format austauschen. Im Gegensatz zu SOAP-Services, bei denen sich die WSDL-Beschreibung als Standard durchgesetzt hat, gibt es für RESTful Services mit JSON noch keinen etablierten Standard. Erste Ansätze existieren mit WADL (Web Application Description Language) und RAML (RESTful API Modeling Language).
Wie können nun die verschiedenen IDEs im Oracle-Umfeld mit existierenden REST/JSON-Services umgehen und aus den zur Verfügung stehenden Informationen einen REST-Client generieren, der beispielsweise anschließend in einer mobilen Anwendung verwendet werden kann, um mit dem REST Service zu kommunizieren. Für die Entwicklung der mobilen Anwendungen soll das Oracle Mobile Application Framework (MAF) eingesetzt werden.

Oracle JDeveloper 12.1.3

Sofern der REST Service die Nachrichten im XML-Format austauscht und dafür ein XSD Schema existiert, kann der Web Service Data Control Wizard im JDeveloper verwendet werden, um ein Data Control für den Web Service zu generieren. Sollen die Daten dagegen im JSON-Format ausgetauscht werden, muss der Client unter Verwendung des REST Service Adapters manuell in Java programmiert werden. Anschließend kann aus dem Service Object ein POJO Data Control generiert werden. Dieses Vorgehen ist ausführlich in einem Tutorial auf OTN beschrieben.

Oracle Enterprise Pack for Eclipse 12.1.3.4 (OEPE)

Alternativ zum Oracle JDeveloper kann auch OEPE eingesetzt werden, um mobile Applikationen auf Basis des Oracle Mobile Application Frameworks (MAF) zu entwickeln. In OEPE gibt es einen REST Service Editor, der auch für REST-JSON Services die notwendigen Artefakte automatisch generiert, ohne dass es eine Beschreibung des RESTful Services gibt.
Dazu praktiziert der Wizard einen interessanten Ansatz:

  • Im ersten Schritt (Tab REST Client) wird zunächst der Service „erforscht“, indem der Service wiederholt unter Angabe der URL, von Header-Informationen und Query Parametern aufgerufen wird und die Ergebnisse angeschaut werden. In dieser Phase werden keine Ergebnisse gespeichert.
  • Hat man die Struktur verstanden, kann mit Hilfe der Funktion „Import the REST Client Information“ eine erste Beschreibung des Service im XMI-Format (XML Model Interchange) erstellt werden. Diese wird im Tab REST API sicht- und editierbar. Alle Änderungen werden unmittelbar in der XMI-Beschreibung persistiert.
  • Im letzten Schritt „Artifact Generation“ wird aus der XMI-Beschreibung des Service ein Java Client generiert.
    Aus dem Service Object kann anschließend wie im JDeveloper ein POJO Data Control erzeugt werden.
OEPE REST Service Editor

OEPE REST Service Editor

Dieses Vorgehen ist in zwei Blog Posts ausführlich beschrieben:
https://blogs.oracle.com/oepe/entry/introduction_to_rest_service_editor
https://blogs.oracle.com/oepe/entry/introduction_to_the_rest_service

NetBeans 8.0.2

Im Unterschied zu den zwei vorhergehenden IDEs können mit NetBeans keine mobilen Applikationen auf Basis von Oracle MAF erstellt werden. Trotzdem war es interessant, die Möglichkeiten von NetBeans zu erkunden.
Wurden die REST Services mit NetBeans z.B. als annotierte Java-Klassen erstellt, kann ein REST Service Client dafür generiert werden. NetBeans bietet nach der Installation eine Reihe populärer Services (von Amazon, Delicious, Flickr, Google, ..) an, die jeweils durch eine WADL-Datei beschrieben sind.

NetBeans - Services

NetBeans – Services

Hier können eigene Services (SOAP oder REST) hinzugefügt werden, zu denen eine WSDL- oder WADL-Datei angegeben werden muss. Ist eine WADL-Datei für den Service hinterlegt kann anschließend mit Hilfe des RESTful Java Client Wizard der client-seitige Code generiert werden.
Das Vorgehen ist in diesem Tutorial und in diesem Video beschrieben.
Fehlt eine WADL-Beschreibung des Service müsste man diese vorab erstellen. Dieses Wiki beschreibt einige mögliche Ansätze und Werkzeuge zur Generierung einer WADL-Datei.

<JM>

Written by fmtechteam

13/04/2015 at 15:00

Social Login mit OAuth im Mobile Application Framework (MAF) 2.0.1

leave a comment »

Mit der Version 2.0.1 des Oracle Mobile Application Frameworks entwickelte Anwendungen können folgende Verfahren zur Authentifizierung des Anwenders verwenden:

  • HTTP Basic
  • Mobile-Social
  • OAuth
  • Web SSO.

Die Authentifizierung kann dabei lokal (gegen den Credential Store auf dem Gerät), remote (gegen einen Login Server) oder hybrid (lokal, wenn remote nicht zur Verfügung steht) erfolgen.
Eine Beschreibung der Verfahren findet man in der Dokumentation.

Die Authentifizierung mittels HTTP Basic ist relativ unspannend und soll daher hier nicht beschrieben werden.
Interessanter ist dagegen eine Authentifizierung und Autorisierung auf Basis von OAuth 2.0 gegen einen Security Provider. Der Anwender authentifiziert sich in diesem Fall mit einem gültigen Account gegenüber einem Security Provider (z.B. Google). Ist die Authentifizierung erfolgreich, erhält die Anwendung ein Access Token vom Security Provider, mit dem sie sich beim Backend Service anmeldet. Dieses Verfahren ist im aktuellen Release von Oracle MAF nur gegenüber dem Oracle Access Manager Mobile & Social (OAMMS) möglich. OAMMS könnte dann als Vermittler zu den Providern (Google, etc.) fungieren. Direkte Verbindungen zu Google, LinkedIn oder Facebook sind noch nicht möglich, es sei denn man verwendet JavaScript-Bibliotheken für OAuth, um selbst die Tokens zu manipulieren oder verwendet server-seitige Logik, die als Web Service zur Verfügung gestellt werden könnte.
<JM>

Written by fmtechteam

29/10/2014 at 08:24

Veröffentlicht in Jürgen Menge, MAF

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