Code Snippets für Binding Layer
Wer mit Oracle ADF entwickelt, wird relativ schnell zu einem Punkt kommen, wo er in einer Backing Bean programmatisch auf den Binding Layer zugreifen muss. In Edwin Biemond’s Blog findet man eine Sammlung von Code Snippets, die für bestimmte Aufgaben nützlich sind.
<JM>
Webcenter Spaces Skinerweiterungen
WebCenter Spaces ist ja bekanntlich eine ADF 11g Anwendung und kann, wie im Whitepaper “ExtendingWebCenter Spaces” beschrieben, mit eigenem Navigationsmodell, eigenem Layout (Shell), mit eigenen Skins, eigener Resource Palette (Business Repository) usw. erweitert werden. Beim Customizing von WebCenter Spaces werden die Änderungen in ein eigenes Web Application Archive gepackt und zur Spaces Anwendung hinzudeployt. Somit kann durch einfaches Undeployment des eigenen WARs der ursprünglichen Zustand von Spaces wiederhergestellt werden. Das bedeutet also, dass auch ein eigenes Skin nur über das “CustomWebCenterSpacesWAR” erstellt und der Spaces Anwendung hinzugefügt werden kann.
Man definiert also zuerst ein Skingrundgerüst, am besten durch Kopieren eines in der Customizing App vorhandenen Skins und fügt es der Spaces Anwendung wie im Whitepaper beschrieben bei. Hinweis: Bitte achten Sie genau auf die Reihenfolge und die Zeitpunkte des Stoppens und Startens des Managed Servers für Spaces.
Die Herausforderung ist nun, aus den umfangreichen ADF Faces UI Komponenten die in Spaces verwendeten herauszufinden und gezielt in einem eigenen Skin zu verändern. Dazu kann der Blogeintrag “ADF Faces Stylesheet rückverfolgen” als Anleitung dienen. Hier wird beschrieben, das man über die web.xml der Applikation die CSS Komprimierung deaktivieren sollte, um die verwendeten Stylesheetklassen zu erkennen und dann auf den Skineintrag schließen zu können. In unserem Falle bedeutet dies, die web.xml der Spaces Anwendung zu bearbeiten und nicht in der “CustomWebCenterSpacesWAR”.
Hier die Vorgehensweise in der Übersicht. Man muß nun das webcenter.ear Archiv finden, öffnen, das darin enthaltene webcenter.war öffnen und dort die web.xml mit dem entprechenden Parameter wie im o.g. Blogeintrag beschrieben ändern. Anschließend alle Archive wieder einpacken und das webcenter.ear updaten.
- Webcenter.ear finden
Hierzu geht man am besten auf die WLS Konsole des AdminServers und klickt auf Deployment. In der Liste der deployten Anwendungen geht man zum Eintrag webcenter, wählt den Eintrag an und klickt auf updaten.

Dort sieht man dann den Pfad des Archivs, z.B. . D:\Oracle\Middleware\Oracle_WC1\archives\applications\webcenter.ear

Bitte die Seite so stehen lassen. Hier wird dann später das Update erfolgen.
- Archiv auspacken und Web.xml bearbeiten
In dem angegebenen Pfad finden Sie dann das webcenter.ear. Bitte machen Sie eine Sicherheitskopie davon. Packen Sie das EAR File aus (zum Beispiel mit Zip). Dann finden Sie darin das webcenter.war.

Packen Sie das webcenter.war File aus und Sie finden dann im Pfad WEB-INF die web.xml. Bearbeiten Sie diese.

Fügen Sie zwischen dem letzen Tag für <context-param> und dem ersten Tag für <resource-ref> den <Context-param> für die CSS Dekomprimierung ein, also zum Beispiel so:
<context-param>
<param-name>
CpxFileName
</param-name>
<param-value>
oracle.webcenter.webcenterapp.bindings.DeploymentDataBindings
</param-value>
</context-param>
<!-- Customize Skin-->
<context-param>
<description>Disable CSS Compression</description>
<param-name>org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION</param-name>
<param-value>true</param-value>
</context-param>
<resource-ref>
<res-ref-name>
jdbc/WebCenterDS
</res-ref-name>
<res-type>
javax.sql.DataSource
</res-type>
<res-auth>
Container
</res-auth>
</resource-ref>
- Archive einpacken
Packen Sie als erstes wieder das WAR Archiv zusammen, z.B. mit Zip. Achten Sie bitte dabei auf Beibehaltung der originalen Verzeichnisstruktur. Packen Sie anschließend wieder das EAR mit dem so geänderten WAR Archiv zusammen. Achten Sie bitte darauf, dass das EAR File im o.g. Pfad liegt und das alte EAR überschrieben wird, in unserem Beispiel D:\Oracle\Middleware\Oracle_WC1\archives\applications\webcenter.ear
- Webcenter Anwendung updaten
Sollte der Managed Server für Spaces nicht laufen, so starten Sie ihn bitte vor dem Update der Anwendung. Kehren Sie zur oben geöffneten Seite in der WLS Console (Update Webcenter Anwendung) Maske und klicken Sie nun auf “Finish”. Damit wird dann Ihre Webcenter Spaces Anwendung redeployt und Sie finden nun im Source Code der Spaces Seite die nicht komprimierten CSS Klassen vor.
Verfahren Sie nun, wie im bereits oben referenzierten Blogeintrag beschrieben, fort, um Ihren Spaces Stylesheet zu definieren.
<DM>
Installation von Oracle Fusion Middleware 11g – Forms & Reports
Seit dem 2. Juli 2009 ist das neue Release der Oracle Fusion Middleware 11g verfügbar. Da sich seitdem die Fragen zur Installation von Forms & Reports 11g auf einem Entwicklerarbeitsplatz häufen, sind die wesentlichen Informationen und Schritte in diesem Papier zusammengestellt.
Das Papier ist keine offizielle Produkt-Dokumentation von Oracle und soll den Oracle® Fusion Middleware Installation Guide for Oracle Portal, Forms, Reports and Discoverer 11g Release 1 (11.1.1) lediglich ergänzen.
<JM>
Oracle Fusion Middleware 11g mit Forms und Reports verfügbar
Seit Anfang Juli steht das neue Release der Oracle Fusion Middleware zum Download im Oracle Technet. Für Entwickler, die mit Oracle Forms und Reports arbeiten, ergeben sich daraus eine Reihe von Veränderungen:
- Forms und Reports bringen eine ganze Reihe neuer Funktionen mit
- Die Test- und Ablaufumgebung für Forms & Reports 11g ist der Oracle WebLogic Server.
- Für die Installation von Forms, Reports, Portal und Discoverer auf einem Entwickler-Arbeitsplatz gibt es kein spezielles Installations Package mehr. Entwicklungs- und Laufzeit-Umgebung werden mit dem gleichen Package installiert und unterscheiden sich nur in der Auswahl der Komponenten. Eine Installationsbeschreibung für einen kompletten Forms/Reports-Entwicklungs-Arbeitsplatz findet man hier.
- Der Oracle Designer ist nicht Bestandteil der Fusion Middleware 11g. Wer ihn benutzen will, benötigt weiterhin die Oracle Internet Developer Suite 10g Release 2. Für die Datenmodellierung und das Datenbank-Design steht aber mit dem SQL Developer Data Modeler seit Kurzem eine Alternative zur Verfügung.
<JM>
JDeveloper Extension für WebCenter & SOA 11g
Seit 01. Juli ist das Release 11g zum Download auf OTN verfügbar. Die JDeveloper Studio Edition enthält diesmal nicht die Erweiterungen für WebCenter und SOA. Diese müssen über das Updatecenter geladen werden. Wer dies nicht aus dem JDeveloper heraus tun möchte oder kann, oder wer dies in mehreren JDeveloper Installationen tun möchte, kann auch die Extensions hier runterladen und dann offline über die Updatefunktion einspielen. Die Erweiterungen findet man zum Download auf http://www.oracle.com/technology/products/jdev/101/update/fmw_products.xml
Hier eine kurze Anleitung für das Online Update.



<DM>
Nativer, asynchroner BPEL Prozeßaufruf vom Oracle Service Bus (OSB)
Der Oracle Service Bus (OSB) kann BPEL Prozesse nicht nur über SOAP sondern auch nativ durch Verwendung von RMI aufrufen, hier also mittels den Oracle Application Server Boardmitteln “opmn” oder “ormi”.
Um diese Integration zu erreichen, sollte folgende, aktuelle SW eingesetzt werden:
- Oracle Service Bus 10gR3 (10.3.0)
- Oracle SOA Suite 10.1.3.4 MLR7 oder höher
Des Weiteren müssen im OSB noch aktuelle JAR Files aus der SOA Suite ausgetauscht und ein Umgebungsparameter geändert werden, um folgenden Fehler zu vermeiden:
- com.evermind.server.rmi.RMIConnectionException: Disconnected: javax.xml.namespace.QName; local class incompatible: stream classdesc serialVersionUID
Unten genannte JAR-Files sollten im OSB Installationsverzeichnis in der Datei /osb_10.3/lib/transports/bpel10gtransport.ear aus der SOA Suite Installation ersetzt werden:
- aus $ORACLE_HOME/bpel/lib/orabpel.jar
- aus $ORACLE_HOME/bpel/lib/orabpel-common.jar
- aus $ORACLE_HOME/bpel/lib/xmlparserv2.xml
- aus $ORACLE_HOME/j2ee/home/oc4jclient.jar
Zusätzlich muss im OSB Installationsverzeichnis unter /user_projects/domains/osb_domain/bin in der Datei setDomainEnv.sh folgende Zeile ersetzt werden:
- JAVA_PROPERTIES=”-Dplatform.home=${WL_HOME} -Dwls.home=${WLS_HOME} -Dweblogic.home=${WLS_HOME} “
- durch
- JAVA_PROPERTIES=”-Dplatform.home=${WL_HOME} -Dwls.home=${WLS_HOME} -Dweblogic.home=${WLS_HOME} -Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0″
Nun kommen wir zur eigentlichen Konfiguration des Oracle Service Bus, um nachfolgende Abbildung zu realisieren.

Vorausgesetzt wird, dass ein asynchroner BPEL Prozeß schon existiert. In der OSB Entwicklungsumgebung “Workshop for WebLogic 10gR3″ sollte eine Verbindung zum OSB Server, also zum WLS, aufgebaut werden. Durch betätigen der rechten Maustaste im Tabwriter “Server” wird eine Verbindung erzeugt.

Als nächstes wird ein “Oracle Service Bus Configuration Project” angelegt, siehe nachfolgende Abbildung. In diesem OSB Configuration Project wird ein OSB Project erzeugt mit 4 Folderinhalten: proxy services, business services, WSDLs und credential (OSB Configuration Project markieren und über rechte Maustatste OSB Project und anschließend 4 mal im OSB Project Folder auswählen).

Für die Kommunikation zwischen OSB und dem BPEL Prozeß wird die WSDL des BPEL Prozesses in den Folder WSDLs importiert. Dazu den Folder WSDL markieren, rechte Maustaste drücken und über Import, Oracle Service Bus – Resources from URL, die entsprechende BPEL WSDL URL angeben.

Nun werden im Folder “business services” zwei Business Services angelegt. Zum Einen ein Service für die Kommunikation zum BPEL Prozeß, hier BPELAsync.biz genannt und zum Anderen ein Business Service für die Kommunikation mit der Queue, der den BPELCallback beinhaltet, als BPELAsyncCallback.biz bezeichnet.



Die Konfiguration für den TabWriter “BPEL 10g Transport” (Art des Services, Callback Adresse, Credentialinformationen) wird später vorgenommen.
Der zweite Business Service BPELAsyncCallback wird nun konfiguriert. Das Anlegen erfolgt wie beim ersten Business Service. In diesem Business Service muss nun der Callback Port vom BPEL-Prozess aufgenommen und der weitere Transport zur Queue konfiguriert werden. Die Konfiguration der Queue und der ConnectionFactory einschließlich JMS Server wurde zuvor im WLS vorgenommen und wird hier nicht näher beschrieben.


Im TabWriter “JMS Transport” in obiger Abbildung muss noch der Destination- und Message Typ angegeben werden: Queue und Text.
Jetzt können für die beiden Business Services die zugehörigen Proxy Services im Folder proxy_services erzeugt werden, die das Weiterleiten zum Business Service bewerkstelligen. Hierzu wird der jeweilige Business Service markiert und mit der rechten Maustaste wird unter Oracle Service Bus der Proxy Service mittels “Generate Proxy Service” erstellt (ohne Abbildung). Anschließend werden weitere Transportkonfigurationen vorgenommen.

Für den obigen Proxy Service BPELAsync_proxy muss keine weitere Transportkonfiguration vorgenommen werden. Allerdings für BPELAsyncCallback_proxy. Hier muss das Transportprotokoll auf sb gesetzt werden, damit der OSB den BPELCallback empfangen und zum Business Service weiterleiten kann.

Damit die Kommunikation zwischen zwischen OSB und BPEL Prozeß erfolgen kann, muss noch die Service Account Resource angegeben werden. Sie beinhaltet Adminusername und Password der SOA Suite. Hierzu den Folder credential markieren und mit der rechten Maustaste unter New den Eintrag “Service Account” auswählen.

Nun müssen wir noch abschließend, wie ganz oben erwähnt, im Business Service BPELAsync die BPEL10gTransport-Informationen hinterlegen.

Zum Testen des Projektes wird das Projekt zum OSB hinzugefügt. Hierzu unter Servers das Projekt hinzufügen.
Nun den Proxy Service BPELAsync_proxy.proxy im Folder proxy_serves markieren und mit der rechten Maustastenfunktionalität “Run AS, Run on Server” den Testclient mit entsprechende Eintraegen starten. Anschließend kann in der Queue im WLS nachvollzogen werden, dass die Eintraege, manipuliert durch den asynchronen BPEL Prozeß, angekommen sind.
<KM, 05.06.2009>
Das neue Web Service Interface im BI Publisher 10.1.3.4.1
Seit Mitte Mai ist das Release 10.1.3.4.1 des BI Publisher verfügbar und unter der Haube verbirgt sich bereits das neue Web Service Interface des kommenden Release 11.
Der Endpunkt des neuen Interface lautet: http://<host>:<port>/<applikation>/services/PublicReportService_v11?wsdl
Zu den Neuerungen zählen:
- neue und geänderte komplexe Datentypen
- neue und geänderte Operationen.
So gibt es einen neuen Datentyp FileDataSource, mit dem XML-Dateien als Datenquelle für Berichte verwendet werden können.
Eine weitere wichtige Neuerung betrifft die Möglichkeit, anstelle Username/Passwort mit einem Session Token zu arbeiten.
Wer jetzt damit beginnt, die Web Services des BI Publisher zu nutzen, sollte sofort mit dem neuen Web Service Interface einsteigen.
Eine Beschreibung der Funktionalität ist im “New Features Guide – 10.1.3.4.1” zu finden.
<JM>
ADF Faces Stylesheet rückverfolgen
Problem:
Wie finde ich die entsprechende Styledefinition einer UI Komponente in einem ADF Faces Skin, um diese wie gewünscht zu gestalten.
Lösungsvariante 1:
Man kennt die ADF Faces UI Komponenten und schaut in deren Dokumentation, um die notwendigen Stylesheet Klassen in einer eigenen Skindefinition anzugeben.
Lösungsvariante 2:
Man verfolgt den im Browser ankommende Stylesheet zurück bis zur Definition im ADF Faces Skin. Aber wie ?
An dieser Stelle sei nochmal erwähnt, dass ein Skin eine auf CSS 3.0 Syntax basierende Stylesheetdefinition ist. Skins benutzen also CSS, um die Darstellung von ADF Faces und Trinidad UI Komponenten zu definieren.
Für Variante 1 ist die im Blogeintrag vom 11.Februar beschriebene Lösung ein gutes Hilfsmittel. Deshalb behandeln wir nun Variante 2. Als Beispiel dazu dient eine ADF Faces Rel. 11 Anwendung, die mit einem Standard ADF Faces Skin („blafplus-rich“) versehen ist.
Wir wollen nun die CSS Definition für bestimmte Oberflächenelemente ermitteln, um sie wunschgemäß anpassen zu können. Schauen wir zunächst auf den im Browser ankommenden HTML Sourceode und suchen den Link zur Stylesheet Definition, die der Browser umsetzt.
… <link rel=”stylesheet” charset=”UTF-8″ type=”text/css” href=”/HRSystem-ViewController-context-root/adf/styles/cache/blafplus-rich-desktop-f72ien-ltr-gecko-1.9.0.8-cmp.css”>…
Hier erkennen wir, dass dies aber nicht die eigentliche CSS Definition aus dem Skin ist, sondern ein vom ADF Faces Renderer zur Laufzeit generierter Stylesheet. Dabei liest der ADF Faces Renderer die Skindefinition aus und erstellt eine browserspezifische CSS Datei mit dynamischen, komprimierten Klassennamen. Wie schließen wir aber aus den dynamischen CSS Klassen im Browser auf den originär im Skin definierten Style der betreffenden UI Komponente?
Über die Firefox Community gibt es ein paar nützliche Add-Ons, die wir hier gut gebrauchen können. Es empfehlt sich, die Firebug- und die Web Developer – Erweiterungen runterzuladen und zu installieren, falls nicht schon geschehen.
Nach erfolgreicher Installation der Plugins starten wir nocheinmal die ADF Anwendung, um jetzt beispielsweise die Darstellung eines Tabreiters vom Browser bis zur ursprünglichen Definition im Skin zurückzuverfolgen. Dazu klickt man mit der rechten Maustaste auf den Tabreiter und wählt „Inspect Element” aus.
Firebug öffnet sich und stellt im unteren Fenster den HTML Source Code sowie im rechten Fenster die im Browser anliegenden CSS Settings dar.

Bild 3: Ansicht Firebug Erweiterung in Firefox
Bewegt man nun den Mauszeiger im Source Code Fenster über andere Codpassagen, so wird im oberen Darstellungsfenster die betreffende HTML Komponenten markiert.
Eine schöne Möglichkeit, gleich an Ort und Stelle in der laufenden Anwendung verschiedene CSS Attribute auszutesten, bietet die Web Developer Erweiterung. Mit Ctrl + Shift + E gelangt man in den CSS Editor und sieht nocheinmal den geladenen Stylesheet.

Bild 4: Ansicht Web Developer Erweiterung - Stylesheet Editor
Man kann in dieser Liste Attribute von CSS Klassen verändern und gleich die Auswirkungen auf der Seite sehen.
Über Firebug findet man also die gültige CSS Klasse der betreffenden UI Komponente (hier Tabreiter) und über Web Developer kann man diese gezielt verändern. In unserem Beispiel möchten wir den Text des Tabreiters ShowDetailItem1 rot einfärben. Wir klicken daher im Browserfenster mit der rechten Maustaste auf den Text ShowDetailItem1 und wählen Inspect Element aus. Wir sehen, dass hier die CSS Klasse .xs4 verwendet wird.

Bild 5: Ad-Hoc Änderungen von Stylesheet Attributen im Web Developer
Im CSS Editorfenster links suchen wir nun die CSS Klasse .xs4. p_AFSelected und deren Attribut [color:#000000], welches wir dann auf [color:#FF0000] ändern. Man sieht sofort, dass sich der Text des Tabreiters rot färbt.
Bleibt nur noch die Frage, wie man von der dynamisch erzeugten CSS Klasse .xs4 im Browser auf die tatsächliche Styledefinition im ADF Faces Skin schließt? Dort werden ja die für die jeweilige UI Komponente festgelegten CSS Klassen definiert, die nicht xs4 oder ähnlich heissen, sondern irgendwie den Komponentennamen enthalten. Man muss zuerst in der web.xml der JSF Anwendung die Kompression der CSS Klassen deaktivieren. Damit werden keine dynamischen Klassennamen vom Renderer generiert, sondern die Klassennamen des Skins verwendet. Man öffnet im JDeveloper im Projekt der JSF unter Web-INF die web.xml und fügt unter Context Initialization Parameters einen neuen Parameter org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION mit dem Wert True hinzu.

Bild 6: Einschalten der CSS Dekompression in der web.xml
Nun startet man die Anwendung neu und schaut über Firebug auf den Tabreiter. Die Stylesheet Klasse des Tabreitertextes heißt in unserem Beispiel nun .af_PanelTabbed _tab-text-link (Zur Erinnerung: vorher war der CSS Klassenname .xs4)

Bild 7: dekomprimierte Stylesheet Klassenamen
Auf OTN kann man sich die Skindefinition dieser UI Komponente anschauen und weiß nun, welche Klassen in der CSS Datei des eigenen Skins definiert werden müssen, um ein gewünschtes Layout der Komponente zu erhalten. Man kann aber auch aus aus dem im Browser anliegenden Klassennamen auf die CSS Klasse im Skin schließen, in dem man .af_ mit .af| und dann jedes weitere _ mit :: ersetzt. In gegebenen Beispiel würde man .af_PanelTabbed _tab-text-link mit .af|PanelTabbed ::tab-text-link ersetzen und hätte ohne nachzuschauen den Klassennamen für die eigene Skindefinition.
Wie man eine eigene ADF Faces Skindefinition anlegt, ist in der ADF Faces Doku beschrieben oder in diversen BLOG Postings zu finden.
<DM>
Migration von Oracle Forms nach Application Express (APEX)
Mit der Version 3.2 von Oracle Application Express (APEX) ist ein Converter für Oracle Forms verfügbar. Zunächst müssen die existierenden Anwendungsdateien für den Import in das APEX-Repository vorbereitet werden:
- Konvertieren der binären Forms-Module (fmb, olb, mmb) mit dem Utilty frmf2xml.bat in das XML-Format
- Konvertieren der PL/SQL-Bibliotheken (pll) im Forms Builder oder im Batch in das Textformat (pld)
- Konvertieren der Reports-Module (rdf) im Reports Builder oder im Batch in das XML-Format
Danach können die Dateien in einen APEX-Workspace geladen werden. Interessant sind die vielfältigen Möglichkeiten der Analyse, die dem Entwickler nach dem Laden der Applikation zur Verfügung stehen.
Anschließend kann aus den geladenen Metadaten eine APEX-Applikation generiert werden.
Das Vorgehen ist in einem Dokument an Hand eines Beispiels beschrieben.
Man sollte sich allerdings darüber im Klaren sein, dass mit diesem Schritt keinerlei Integration der Anwendung mit dem Desktop mehr möglich ist, wie sie heute in vielen Forms-Applikationen noch üblich ist (MS Office, lokale Treiber etc.).
Wenn man langfristig über Alternativen zu Oracle Forms nachdenkt, sollte man für größere und komplexe Forms-Anwendungen das Oracle Application Development Framework (ADF) in die engere Wahl ziehen.
<JM>
Aufruf von PL/SQL Stored Procedures in ADF-Anwendungen
Viele Oracle-Anwender haben einen Teil der Geschäftslogik als PL/SQL Stored Procedures in der Datenbank abgelegt. Wie kann man diese Logik weiterhin nutzen, wenn statt Oracle Forms und Reports zukünftig Oracle ADF in der Anwendungsentwicklung zum Einsatz kommt?
Ein gangbarer Weg besteht darin, die Stored Procedure als Web Service zu kapseln und ADF Data Controls für den Web Service zu erzeugen.
Soll das Framework ADF Business Components (ADF BC) eingesetzt werden, so gibt es derzeit keine deklarative Funktionalität, um zum Beispiel ein Entity Object (EO) auf Basis einer Stored Procedure zu definieren. Eine Integration von Stored Procedures ist aber programmatisch möglich.
Die Dokumentation beschreibt dazu zwei Wege:
- den Aufruf von Stored Procedures/Functions mit unterschiedlichen Parameter-Konstellationen (siehe Doc) an beliebiger Stelle im Framework ADF BC.
- den Aufruf von Insert/Update/Delete-Prozeduren, die den Zugriff auf DB-Tabellen kapseln und im Entity Object aufgerufen werden (siehe Doc).
Der im zweiten Weg beschriebene prozedur-basierte Tabellenzugriff wird in vielen Forms-Anwendungen genutzt; häufig wurde dazu der Table API Generator des Oracle Designer eingesetzt. Will man diese Prozeduren weiter verwenden, muss die doDML()-Methode der EntityImpl-Klasse überschrieben werden. Die Dokumentation enthält Beispiele für den Programmcode und beschreibt auch die Möglichkeit, Select- und Lock-Funktionalität hinzuzufügen.
<JM>

