Forms 11g Alert Prozedur

Ich möchte hier eine Prozedur zur Ausgabe von Alert - Messages in Oracle Forms mit folgenden Merkmalen vorstellen:

• Einfache Textausgabe, ohne Parameterzwang:

      

• Textausgaben mit parametrierten Textersetzungen:

          

• Textdefinitionen in dem definierten Textkatalog der Prozedur, Zugriff über Textlabel oder Index und parametrierter Textersetzung, der Textkatalog ist beliebig erweiterbar:

           

          In der Demo Form wird z.B. beim Versuch des ENTER_QUERY der Katalogtext 
          per generiertem Textlabel aus dem ON-ERROR Trigger ausgegeben.

• Die parametrierte Textersetzung kann natürlich auch auf interne Katalogdefinitionen angewendet werden:      

      

• Die Parametrierung des Alert Titels und eines vordefinierten Alerts ist ausserdem möglich.

• Forms begrenzt die Textlänge eines Alert Textes auf max. 200, in dem Fall des Längenübertrages werden von der Prozedur die Texte gesplittet in aufeinander folgende Alerts ausgegeben.

Die Alert Prozedur ist hier dargestellt:

Wenn man in den Jahren die verschiedensten Alert Prozeduren, die eigentlichen nur der Ausgabe einer Textnachricht dienen sollten, gesehen hat, möchte man irgendwann auch seine eigene Variante vorstellen.;-)

Das Demo:

  steht nun für Forms 11g als Download bereit.

Forms11g - Procedure-Block mit dynamischem SQL in der Datenbank definiert

Häufig möchte man zwischen verschiedenen Tabellen einfach nur schnell navigieren oder beispielsweise Ausgabemengen für Reports bzw. Excel zusammenstellen. Eine Variante besteht darin, dass man die Datenquelle eines Blockes als SQL-Source definiert und das Statement dynamisch verändert. Hierbei ist jedoch die Steuerung im Modul integriert, bei jeweiligen Änderungen müssen die SELECTS im Modul nachgepflegt werden.

Eine andere Möglichkeit besteht darin, die Definition in der Datenbank, in einer Definitionstabelle und etwas PL/SQL - Code generisch zu verwalten:

Es wird eine statische Typdefinition für max. 5 Tabellenspalten mit dem Datentyp VARCHAR2(250) angewendet:



Den dynamischen PL/SQL - Block habe ich wie folgt implementiert:



Der Forms-Block wird als Procedure - Block definiert:



Die 5 Tabellen-Items sind im Forms-Block definiert:



Die Parameter des Procedure-Blockes müssen natürlich identisch zu den Procedure-Parametern der PL/SQL-Procedure sein:

Ein kleines Demo zeigt die Anwendung.

Somit kann man in der Datenbank die Definition der Formsapplikation quasi direkt steuern:

Eine "Database driven Forms Application" ;-) .


Ich hoffe, es hilft weiter.

Forms 11g - JDAPI mit Jython

Für eine programmatische Bearbeitung von Forms - Modulen ist das Oracle Forms API sehr gut geeignet, z.B. zur:

• Einführung eines einheitlichen Layouts: Visuelle Attribute, Farben, GIF's, Fenstergrößen etc.
  


• Versionspflegen: Vergabe von Versionsnummern, Historisierung u. Zuweisungen von Libraries
  


• Generierung von Template-Modulen / -Komponenten für spezifische Applikationsthemen


• Generierung von speziellen Modulen für Hilfe-Funktionen u. Textpflege in der Datenbank


• Generierung von Systemdokumentationen


• Strukturanalyse des PL/SQL - Codes u. Überprüfung von Style Guides u.a. mehr.

Das JDAPI ist nun die Java-Version des Forms API, wobei die eigentlichen C- Schnittstellen mittels Wrapper-Klassen verwendet werden. Da es für die JDAPI-Anwendung einige Beispiele gibt, habe ich mich u.a. für diese Java-Variante entschlossen.

Jython ist das Python für Java, d.h. basiert auf der JVM. Damit erschliesst sich die Java-Welt und man kann Verarbeitungsaufgaben natürlich auch mit Datenbankzugriffen zur permanenten Speicherung kombinieren. Das Weblogic Scripting Tool (WLST) basiert auf Jython, über weitere Anwendungen möchte ich in späteren Blog-Einträgen berichten.

Eine gute IDE-Basis für Jython und für Python allgemein ist Eclipse. Ich habe mir das Eclipse Classic und Jython Version 2.5.1 installiert, die Forms 11g R2 JDAPI findet man unter: D:\oraforms\Oracle_FRHome1\jlib\frmjdapi.jar .

Bei der Einrichtung der Jython-IDE ist die PyDev-Interpreter Einstellung wichtig:

Hier sieht man auch, dass sich diese IDE ebenso für Python und IronPython verwenden läßt.

Natürlich sollte man, wie bei Java, die verwendeten Imports inkl. der JAR's definieren:

In dem folgenden Demo wird für das Forms-Modul: employee-3-2.fmb ein Backup-File angelegt und anschliessend in dem vorhandenen Parameter P_VERSION die aktuelle Version inkl. Datum/Zeit eingetragen:

Ein kompakter und verständlicher Code erzeugt mit effektiv nur 12 Zeilen das Ergebnis:

Hier noch die Gesamtsicht auf das Projekt:

Ich hoffe, dass dies weiter hilft.

Forms 11g R2 - Modul ohne Window - Menue bzw. Frame

In Forms 11g Release 2 kann nun mit dem guiMode - Konfigurations-Parameter das Window-Menue und/oder der Window-Frame des Forms-Applets entfernen werden:  ..\user_projects\domains\ClassicFxDomain\ config\fmwconfig\servers\AdminServer\applications\formsapp_11.1.2\config\formsweb.cfg:

[jpi]

..

# Forms applet parameter, valid range [0-3]

guiMode=3

..

Dies kommt natürlich einem Layout mit integrativem Einbetten in HTML, einschliesslich der Interaktionsfähigkeit von Forms mit JavaScript sehr entgegen.

Forms 11g und Reports 11g im Developer-Mode

Der Aufruf von Reports aus Forms 11g Release 2 im Developer-Mode ist recht einfach, hier nun ein vollständiger Demo - Ablauf:

• Start des WebLogic Servers:

• Erstellen eines emp - Demo - Modules im Forms 11g Builder
• Anlegen eines Reports-Objectes:

Das Report-Object heißt hier 'Report6' und der eigentliche Report ist für den

Developer-Mode mit absoluter Pfadangabe 'D:\Forms11g-Workshop\chk_report.rdf' eingetragen.

• Erstellen des Demo - Reports im Reports 11g Builder:

• Test des Reports-Servers:

• Im rwservlet.properties - File wird der Reports - Server Name ermittelt: D:\oraforms\user_projects\domains\ClassicFxDomain\servers\AdminServer\temp\_WL_user\ reports_11.1.2\90rnjo\configuation\rwservlet.properties :

• Erstellen der Reports - Procedur im Formsmodul:

• Test des Report - Startes aus dem Formsmodule mit dem Procedure - Call:

Dieser Ablauf kann ohne Konfigurierung des Forms - bzw. Reports - Servers problemlos nachvollzogen werden.

Viel Erfolg und beste Wünsche für das Neue Jahr

Friedhold

Forms 11g mit Proxy - User

Eine wichtige Neuerung in Forms 11g ist die Möglichkeit des Anmeldens als Proxy - User, ich habe dies in Forms 11g Release 2 (11.1.2.0.0) getestet. Bei dieser Art der Anmeldung muss nur der Proxy - User im LOGON bekannt sein, die jeweiligen Applikations- End User werden sozusagen durchgereicht. Damit kann der Umstellungsaufwand von Client- nach Web- Forms reduziert werden, da die Sicherung der Anmeldung lediglich auf den Proxy - User konzentriert werden muss.

- Anlegen eines Proxy Users:
create user test_proxy identified by test_proxy;

- Freigabe des Proxy- Connects für einen End - User:
alter user scott grant connect through test_proxy;

- Test - Connect:


- Anmeldung im Forms 11gR2 - Developer:


- Implizite Anmeldung im ON-LOGON - Trigger:


- Nachweis des Connect - Status:




D.h. man kann mit get_Application_Property(USERNAME) den Proxy - User Account abfragen, USER liefert nach wie vor den End - User.

Übrigens kann sich der Proxy - User selbst nicht anmelden:


Aus Sicherheitsgründen und besserer, nachhaltiger Wartung sollte ein End - User ohnedies als einziges Recht nur das grant create session erhalten, eigene Objecte wie Synonyme, temporäre Tabellen, Views etc. oder gar PL/SQL - Code sollte er keinesfalls besitzen!
Jegliche Applikationsrechte sollten über Datenbank - Rollen, möglichst nach dem Prinzip der additiven Funktionserweiterung, vergeben werden.

Ich hoffe, dass dies weiter hilft.

Friedhold