Forms-Applikation via Webstart bzw. JNLP im Microsoft Edge Browser direkt starten

Heute habe ich eine sehr interessante Frage im Oracle-Forms Forum gesehen. Jemand wollte seine Forms-Applikation im Microsoft Edge-Browser direkt aufrufen.

Bisher dachte ich, so nicht möglich, weil das eigentlich nicht gehen sollte. Applets werden von den neueren Browsern sowieso geblockt. Der Ersteller wollte die Applikation auch nicht per FSAL starten, sondern Webstart und JNLP verwenden.

Mit Webstart und HTTP-Protokoll geht das nur mit einem Zwischenschritt, indem mal das JNLP-File auf dem Client abspeichern und dann per Doppelklick starten kann.

Ein Schritt zuviel dachte der Anwender zu Recht. Die Lösung fand derjenige selbst, indem man einfach das Aufrufprotokoll im Browser ändert. Von HTTP zu JNLP und nach einem Klick auf Öffnen wird die Applikation direkt gestartet. Es kann aber gut sein, dass dann auf dem Client die Dateiendung JNLP mit dem Programm Java Web Launcher verknüpft sein muss.

Ich nehme stark an, dass das mit neueren JDK Versionen nicht mehr funktionieren wird. Bereits in JDK 11 ist Java Web Start nicht mehr enthalten. Also sicher ein Wechsel zu FSAL nötig. Das wird meiner Meinung nach auch die bislang einzige supportete Aufrufmöglichkeit werden.

Das Verfahren mit JNLP als Protokoll im Aufruf klappt übrigens auch in Google Chrome und Internet Explorer.

Cheers

Forms 12c - neue Erkenntnisse mit JNLP und dem Standalone Launcher

Hallo zusammen,

die letzten Tage und Wochen haben wieder neue Erkenntnisse mit den neuen Forms 12c Deployment Optionen gebracht, die es wert sind veröffentlicht zu werden. Ein Community Mitglied hat gesagt, das zeigt die Abgrenzung zwischen Webstart und der Standalone Methode. Von ihm habe ich auch den Lösungshinweis bekommen, wie man mit Webstart verschiedene Zertifikatsquellen einbindet und verarbeitet.

Die erste große Erkenntnis ist: Standalone läßt die Ausführung nicht signierter Jar-Files zu, ob das ein Bug ist, müßte man Michael Ferrante bzw. den Oracle Support fragen. Diese Vermutung bestand seit gestern nach mehreren Fach-Gesprächen über Forms und Java mit dem Community Mitglied.

Als Basis dient meine VM mit Forms 12.2.1.1.0 und bestehenden Sample-Aufrufen. Dafür habe ich aus einem Jar-File die Signatur entfernt.

Nach dem Austausch der Datei in der formsweb.cfg und dem Löschen des Java-Caches hat die Anwendung unerwartet dennnoch gestartet. Der Aufruf war so:

Beim Versuch aus der frmall.jar das Zertifikat zu entfernen, startet die Anwendung nicht mehr.

Diese Versuche laufen zwar nicht auf dem letzten offiziellen Patch, aber dort erwarte ich nichts anderes erstmal. Entweder ein Bug oder ein Feature mit Risiken, neben dem Problem das Cachings der Jar-Files also schon nicht unerheblich. Da macht Webstart doch bislang weniger Mühe.

Zweites Thema des heutigen Postings ist auch direkt die WebstartVariante zum Starten, denn theoretisch hat man mindestens 2 verschiedene Zertifikate, wenn man neben den Standard Oracle Forms Jars auch selbstentwickelte, gekaufte oder freie Jars hat. Diese Dateien müssen dann ja zum Betrieb mit dem Weblogic mit einem offiziell gültigen Zertifikat ausgestattet sein und verschiedene Zertifikate lassen sich nicht zusammen in einer JNLP-Datei einbinden, da muss man doch tricksen.

Der Trick ist recht einfach: pro Zertifikat von einer Trusted Certificate Authority muss eine JNLP-Datei existieren, die dann von der Haupt-JNLP Datei aufgerufen wird. Also bei 3 verschiedenen Zertifikaten auch 3 einzelne  JNLP Dateien.

 Hier ein Beispiel einer Haupt-JNLP Datei, die auf andere JNLP-Dateien verweist:

Und hier ein Ausschnitt aus extensions_1.jnlp:

So lassen sich auf einfache Weise komplexe Strukturen verflachen und auf einzelne Dateien auslagern. Standardmäßig liegen die anderen JNLP-Dateien auch in /forms/java, das kann man aber sicher auch wieder auf andere Folder verbiegen.

Gerade kam die Entwarnung von Frank Hoffmann und dem Test mit Version 12.2.1.2.0. Da ist es so, wie es sein soll und Standalone (fsal) bricht mit Fehler bei der Nicht-Signierung ab:

Puh, dann hat Oracle hier nachgebessert und alles ist hier wieder beim letzten Patch ok.

Viel Spass beim Ausprobieren mit den neuen Deployment Optionen und vielleicht noch mehr Erenntnissen wünscht

Holger

Forms 12c - Webutil Konfiguration

Nachdem die Windows VM mit Forms 12c und Reports nun läuft und konfiguriert ist, hat noch ein spannender Teil gefehlt. Die Konfiguration von Webutil, welches doch viele Forms Anwender gerne verwenden. Webutil ermöglicht es den neueren Forms Web Versionen auf den Client des Anwenders zuzugreifen und Client-Funktionalitäten auszuführen, die normalerweise durch die Kobination JRE/Applet unterbunden sind.

Die WebUtil Core Features (alles, was man sonst selbst in Java Beans nachbauen müßte)

• Text_IO: Read and write text files on the client machine.
• Tool_Env: Read client side variables
• C API on the client:  Interface with client side C.
• Host: Run Host commands on the client machine
• OLE2:  Integrate with client side OLE (e.g. Word and Excel)
• Enhanced Host commands: Host command can now call back into Forms!
• Browser functions: Integrate with the browser.
• File transfer: Move from between the client, application server and database.
• Client machine information:  Read information from the client machine
• READ/WRITE_IMAGE_FILE: Read and write client side images
• Get_File_Name: Use a file selection dialog on the client machine         

Der größte Teil der Webutil-Funktionalität ist bereits vorkonfiguriert, doch sind noch einige Schritte nach der Forms-Installation durchzuführen. Das wichtigste zuerst; man muß ein Zusatzpaket herunterladen und einbinden jacob.jar (Java COM Bridge). Zu Forms 12c passt die jacob-Version Jacob 1.18-M2, die gibt es hier zum Download. JACOB is a JAVA COM Bridge that allows you to call COM Automation components from Java. It uses JNI to make native calls into the COM and Win32 libraries. JACOB runs on x86 and x64 environments supporting 32 bit and 64 bit JVMs.

Enthalten sind hauptsächlich 3 wichtige Dateien:

• jacob.jar
• jacob-1.18-M2-x64.dll
• jacob-1.18-M2-x86.dll

nötige Schritte bei der Konfiguration:

• Signieren der Datei jacob.jar mit einem gültigen Zertifikat und in das Verzeichnis ORACLE_HOME/forms/java kopieren (dort ist schon die bereits signierte Datei frmwebutil.jar)
• Kopieren der Datei jacob-1.18-M2-x86.dll in das Verzeichnis ORACLE_HOME/forms/webutil/win32 und jacob-1.18-M2-x64.dll in ORACLE_HOME/forms/webutil/win64
• bei Bedarf, falls eine C-dll Datei auf dem Client aufgerufen werden soll, Kopie von ffisamp.dll aus dem Demo-Test in den Unterordner ORACLE_HOME/forms/webutil//win32
• Anpassen der Konfigurationsdatei webutil.cfg
  Darin kann konfiguriert werden, ob Webutil Fehler und Meldungen geloggt werden sollen. Ebenfalls läßt sich ein- und ausschalten, ob der Dateitransfer gestattet ist. Als nächstes läßt sich einstellen, in welches Verzeichnis die benutzten DLL-Files auf den Client kopiert werden. Und es wird konfiguriert, welche DLL's Webutil verwendet. Falls diese nicht in /win32 und/oder /win64 liegen und die angegebene Größe in Bytes nicht zu tatsächlichen Größen passt, gibt es später Fehlermeldungen beim Aufruf der Forms-Anwendung.
• Einspielen eines Datenbank-Packages webutil_db mit dem Skript (ORACLE_HOME/forms/create_webutil_db.sql) und Erstellen eines Public Synonyms dafür

Hier der Eintrag der Webutil-Beispiel Konfiguration in der formsweb.cfg

# Sample configuration for deploying WebUtil. Note that WebUtil is
# only installed with the Forms Builder and is also available for download
# from OTN.
[webutil]
WebUtilArchive=frmwebutil.jar,jacob.jar
WebUtilLogging=off
WebUtilLoggingDetail=normal
WebUtilErrorMode=Alert
WebUtilDispatchMonitorInterval=5
WebUtilTrustInternal=true
WebUtilMaxTransferSize=16384
baseHTML=webutilbase.htm
baseHTMLjpi=webutiljpi.htm
archive=frmall.jar
lookAndFeel=oracle
form=webutil_demo.fmx

Hat man dies alles getan, ist Webutil fast schon einsatzbereit. Als weitere Forms-Module liefert Oracle eine webutil.pll und webutil.olb mit. Am einfachsten packt man diese 2 Module in das Verzeichnis, dass der Variable FORMS_PATH entspricht und kompiliert die webutil.pll einmal durch und generiert ggf. das webutil.plx.

Zum Testen, ob alles richtig eingestellt ist, liefert Oracle ein Forms webutil_demo.fmb zum Testen, erhältlich unter dem folgenden Link. Damit kann geprüft werden, ob die Webutil-Basis Funktionen richtig laufen.

 

unter Forms 10g geht die Uhrzeitermittlung noch korrekt

Hinweise / Auffälligkeiten:
Warum die Maske bei der Time Zone Europe/Berlin 18:13 Uhr ausspuckt, obwohl es erst 16:13 Uhr ist, ist mir noch rätselhaft. Was auch unter der Version 12c nicht bei mir funktioniert hat, ist die Demo im Reiter Browser, um eine Message an den Browser zu senden (liegt vielleicht daran, dass keine Statusleiste im Browser ist). Sonst lief die Demo-Version sehr gut bei mir. Hinzukommen können auf Nicht-Windows Umgebungen Fehlermeldungen bei nicht richtig gesetzten Berechtigungen auf Verzeichnissen für den Application Server, damit der Datei-Upload/-download funktioniert.

Nachtrag vom 4.7.2016, dank einer Antwort von Frank Hoffmann via Twitter
Es muss bedingt durch eine Änderung im Forms Patch 12.2.1.1 (change im Time zone Support) in der default.env eine Umgebungsvariable gesetzt werden:
FORMS_DATETIME_LOCAL_TZ=GMT
 
Bis bald wieder sagt
Holger

Forms Modernisierung - ein möglicher 3-Wege Plan

Gestern hat es wieder ein Webinar zum Thema Forms Modernisierung mit Mia Urman gegeben: "Looks do Count! Why does my EBS look so 90s?" Davon darf ich wieder Screenshots teilen und möchte ein paar Worte zu sagen. Der Hintergrund ist klar: mach das Aussehen deiner Forms Applikation schön, mit einer grauen Maus gewinnen wir keinen Schönheitspreis!

Eins ist aber klar: die getätigten Investitionen und Business Logik sollen erhalten bleiben. Vielleicht geben wir aber dem Anwender die Möglichkeit, eine Forms-Applikation für das Back Office zu benutzen und eine mobile Variante für unterwegs (hybride Ansätze).

alte und neue Oberflächen im Überblick ©Auraplayer

und kein neues Phänomen mehr heute Agilität ©Auraplayer

Meinen heutigen Beitrag habe ich "einen möglichen 3-Wege Plan" genannt. Was ich damit andeuten will, erkläre ich gleich. Es werden 3 Alternativen beschrieben, wie man vorhandene Forms Legacy Applikationen modernisieren kann, durchaus auch mischbar.

1. Nutzung des neuen Release Forms 12c

Forms 12c ist seit Oktober 2015 auf dem Markt und bietet mit dem neuen Feature Custome Color Schemes genug Möglichkeiten zur individuellen Gestaltung der Benutzeroberfläche.

Custome Color Schemes ©Auraplayer

2. Nutzung von Java Beans und PJC
Wem der vorhandene Funktionsumfang und UI Controls nicht ausreicht, kann sich durch die Schaffung von eigenen Java Bwans und Pluggable Java Components seine Oberfläche fast beliebig selbst erweitern und verschönern. Hier sei auf das LAF Projekt von Francois Dégrelle verwiesen und ebenso auf den Post vom DOAG Regionaltreffen. 

neue UI Controls bauen ©Auraplayer

viel Java Unterstützung in Forms ©Auraplayer

3. Exponieren und Nutzung von Webservices
Nächster Weg ist Forms Funktionalitäten als Webservices bereitzustellen, die dann beispielsweise aus mobilen Applikationen aufgerufen werden können. Der Vorteil: die Business Logik bleibt unverändert in Forms erhalten und keine Anpassung im Quellcode ist von Nöten. Denn das folgende Bild zeigt, die Veränderung geht weiter. Neue Paradigmen entstehen und alles vernetzt sich: Internet of Things, Bring your own device, Going Mobile, jede Information von überall verfügbar...

die schöne neue Welt ©Auraplayer

nochmal alte und neue Welt ©Auraplayer

Ergänzungen zu diesen Möglichkeiten gibt es sicher noch deutlich mehr. Andere Fahrpläne könnten sein: erstmal die Datenbank Version hochheben auf 12c und dann die Forms Version mitnehmen. Oder als Beispiel ein System aus der Firma: es gibt eine mächtige Forms Applikation klassisch im Back Office, gestartet mit Java Runtime. Parallel dazu läuft nun eine App für das Handy (ohne Java versteht sich), realisiert mit APEX. Beide nutzen aber nur 1 Schittstelle und weitere APEX-Module sollen entstehen, aber in friedlicher Koexistenz mit Forms. Denn auch hier gilt, sehr viel Geld und Know-How steckt darin und soll erhalten bleiben.

Nachlese 1. DOAG Regionaltreffen NRW (Forms Community) 2016, Thema Modernisierung von FORMS

Am Donnerstag Abend 18.02.2016 fand in Viersen bei der sensis GmbH das 1. DOAG Regionaltreffen NRW (Forms Community) 2016 statt. Das Thema der Veranstaltung war: Modernisierung von FORMS. Das Format ist wie folgt: eine kurze Begrüßung und Vorstellung der DOAG (Deutsche Oracle Anwender Gruppe) und des Veranstalters, 2-3 kurze Vorträge á ca. 20-25 Minuten und zum Abschluß ein kleines Mahl mit Zeit zum Networken bzw. die Referenten fragen.

Angereist bin ich mit meinem Kollegen Gerd Volberg, teilgenommen haben ca. 20 Personen aus dem DOAG-Umfeld mit Bezug zu Forms, davon waren 4 ehemalige Kollegen, die man gerne auf so einer Veranstaltung auch wiedertrifft. Sprüche wie "Die IT-Welt ist ein Dorf" und "Du schon wieder" runden diese gemütliche Atmosphäre ab.

Begrüßungsfolie ©sensis

Die Themen des Abends waren:

• Webstart - Aufbau JNLP-Datei - Generierung der JNLP aus der DB
• sensis LaF (sensis Look and Feel) - Neues Menüsystem (auch Forms kann Metro) - Neue Optik (auch Forms kann Flach) - Fenster im Focus (Zugriff auf die Fensterklasse) - Tabellen mit alternierenden Farben (Zeilen) - Integrierter Druck (Direkt und Vorschau)
• Flexmode - Spalten verschieben, vergrößern, verkleinern

Hauptmotivation der sensis Leute Forms zu modernisieren, waren die graue Standardoberfläche von Forms-Masken und Anregungen zur Optimierung der Benutzerfreundlichkeit der Software, z.B. ein anderes Icon als das Java-Tassen-Icon, Ränder und Struktur der Forms-Elemente und wie gesagt die Masken-Farben. Klasse fand ich, dass zum Start der Applikation Java Webstart benutzt wird, das in Forms 11 noch gar nicht offiziell von Oracle supported ist, erst mit dem neuen 12er Release ist das gegeben. Aber um unabhängig vom Java-Plugin im Browser zu sein, eine gangbare Option.

2. großes Thema war die Gestaltung von neuen und andersartigen Forms-Elementen für eine Maske, beispielsweise flache Elemente ohne Rand, Buttons mit Bildern drauf und Elemente mit noch mehr Informationen. Das bietet Forms standardmäßig nicht an, sondern muss durch Pluggabe Java Components nachimplementiert werden. Wie das funktioniert, hat Francois Degrelle mit seinem Open-Source Framework "look and feel" vorgemacht. Wem das nicht ausreicht, kann sich die Sourcen anschauen, verändern und nach seinen Bedürfnissen anpassen und später in Forms weiterverwenden. So hat die Sensis es hinbekommen, das Einstiegsmenü so aussehen zu lassen, als wäre es eine Art Windows 8 - Metro Oberfläche mit Kacheln. Das hat mir sehr gut gefallen, besonders weil es wieder die Integration von Java in Forms zeigt.

Menü alt ©sensis

Menü neu ©sensis

Vortrag 3 hat sich mit Tabellen-Darstellungen beschäftigt, die an Excel angelehnt sein sollten. d.h.  Spalten verschieben, vergrößern, verkleinern auch in Gruppen. Dafür hat Francois Degrelle auch schon Sourcen bereit gestellt, die auch wieder auf Kundenwünsche modifiziert wurden, diesmal aber alles mit Hilfe von PL/SQL. Alle diese Anpassungen haben mit 2 Personen 1 Mannjahr gebraucht, dafür haben sie viel an der GUI-Darstellung der Applikation verändert.

alte Farben ©sensis

neue Farben ©sensis

Flexmodus in einer Maske ©sensis

Abschließend bleibt zu sagen, es war eine tolle Veranstaltung mit großem Mehrwert und Informationsgewinn. Zu sehen, was mit Java-Erweiterungen auch für Kunststücke in Forms möglich sind, ist sehr beeindruckend. Vor allem, wenn es eine Open Source Basis gibt, die dann noch modifiziert und individualisiert werden kann. Ich empfinde es als Bereicherung, wenn die Forms-Applikation nicht nur robust ist, sondern auch noch schön aussieht. Dafür haben wir sehr gute Anreize an dem Abend erhalten, vielleicht kommen ja noch ein paar Sourcen als Open Source heraus. Denn damit ist die Anwendung noch lange nicht veraltet und die Akzeptanz der Anwender ist gesichert.

Liebe Grüße
Holger

Forms 12c: Installation im Detail (1) - Weblogic Server 12

Nach den ersten Erfahrungen mit dem neuen Forms 12c möchte ich nun dem interessierten Leser die Installation im Detail vorstellen. Das teile ich in mehrere separate Einträge auf.
Beginnen werde ich mit der erforderlichen Weblogic-Installation, ohne die Forms 12 erst gar nicht läuft.

Gegeben ist ein Betriebssystem Windows 7 64 bit und installiertem JDK 8.

Installiert werden soll der Oracle WebLogic Server 12c (12.2.1.0), runtergeladen von
http://www.oracle.com/technetwork/developer-tools/forms/downloads/index.html

Forms 12c: neue Runtimeoptionen für mehr Flexibilität auch ohne Browser

Beim letzten Mal habe ich mich vornehmlich mit der Installation des neuen Forms 12c auseinander gesetzt, die ja doch an der ein oder anderen Stelle sehr geklemmt hat. Heute möchte ich auf 2 neue Runtimeoptionen beim Starten einer Applikation eingehen, bei deinen Oracle auf jeden Fall in Richtung Zukunft geblickt hat.

1. Der Standardfall (Browser mit Plugin)

Der normale Weg sieht klassischerweise vor, die Forms Anwendung aus dem Browser heraus zu starten. Hierbei muss der Browser aber das Java Plugin unterstützen.

http://w7x6412c-rdbms:9001/forms/frmservlet

2. Mit Java Web Start

In der neuen Forms 12c Version ist Java Web Start offiziell als Startmethode zertifiziert und supported. Dabei muss ebenfalls Java auf dem Client installiert sein, der Aufruf geht beispielsweise über

http://w7x6412c-rdbms:9001/forms/frmservlet?config=webstart&form=lab_540&userid=user/passwort@db

Dabei gelten gewisse Einschränkungen:

• keine Java Script Unterstützung, da nicht im Browser laufend
• kein SSO, kein SSO Logout 

3. als Standalone Client (Oracle Forms Stand-alone Application Launcher – FSAL)

Zitat aus der HTML-Seite http://w7x6412c-rdbms:9001/forms/html/fsal.htm

“Overview:
The Oracle Forms Stand-alone Application Launcher (FSAL) offers an alternative way for end-users to run Oracle Forms applications. FSAL offers a browser-less, more client/server-like interface. As a result of not using a browser, FSAL does not use the Java Plugin component of a Java Runtime Environment (JRE) or Java Developer Kit (JDK). All that is required to run FSAL on the end-user machine is a Java installation. This can be either the JDK or the JRE. To determine which Java versions are supported, please contact your administrator.”Ausgehend von der fsal.htm kann man die zugehörige frmsal.jar auf den Client laden.

Also ganz einfach, funktioniert auch ohne Browser! Aber auch wieder mit JDK oder JRE auf dem Client. Der Aufruf geht beispielsweise mit einer Batch-Datei mit folgendem Inhalt:

java -jar C:\Oracle\Middleware\Oracle_Home\forms\java\frmsal.jar -url “http://w7x6412c-rdbms:9001/forms/frmservlet?config=daylightstandaloneapp&form=lab_540&userid=user/passwort@db“

Fazit

Man sieht also, dass der klassische Weg zum Starten eines Forms-Moduls nach wie vor funktioniert. Aber durch den kommenden Wegfall der Plugin-Unterstützung in neueren Bowsern, sah sich Oracle gezwungen zu reagieren und neue Wege zu gehen. Weiter so!

Ciao
Holger, bis bald