Freitag, 28. April 2017

Forms 12c und FRM-91135 auf Linux - wenn der Forms Builder nicht aufgeht

Hallo zusammen,

heute möchte ich über die Lösung des Incidents FRM-91135 auf Linux berichten. Die komplette Weblogic Suite inkl. Forms und Reports ist installiert und läuft. Nur der Forms Builder geht nicht auf und sagt frech:

FRM-91135: fatal error: message file FMC <language> .msb not found

Das Thema hatte ein Kollege auch neulich von mir, aber auch noch nichts gefunden. Und was ist der einfache Grund? Das Oracle Home ist nicht richtig gesetzt. Das kommt daher, dass auf der gleichen VM noch die Datenbank für das Repository installiert ist.

Vorher ist das ORACLE_HOME: ORACLE_HOME=/u01/app/oracle/product/12.2/db_1

Also setzen wir das ORACLE_HOME doch mal richtig:
export ORACLE_HOME=/home/oracle/Oracle/Middleware/Oracle_Home

und dann rufen wir den Forms Builder auf im Ordner: /home/oracle/user_projects/domains/forms_domain/config/fmwconfig/components/FORMS/instances/forms1/bin

./frmbld.sh &



Ja prima und dann funktioniert es endlich, wie schön.

Viele Grüße
Holger

Montag, 20. März 2017

Forms - mit PL/SQL alle Datensätze eines Blocks in eine PL/SQL-Tabelle laden

Während meines jetzigen Projektes hatte ich schon öfter folgende Aufgabe zu lösen: wie bekomme ich denn alle Records eines Datenblocks in eine PL/SQL-Tabelle ? Um damit z.B. andere Berechnungen durchzuführen, Plausibilitäten darüber laufen zu lassen oder andere Listen zu füllen.

Nachdem ich das ein paar Mal gemacht habe, wollte ich mein Vorgehen dabei zum Besten geben.
Wenn man den gesamten Code noch in ein Forms-Package steckt, ist die PL/SQL-Tabelle auch von anderen Codestellen anzusprechen und zu benutzen.

Dafür bastel ich mehr zu allererst einen Record, mit allen Feldern, die ich brauche und darauf basierend eine PL/SQL-Tabelle und eine konkrete Instanz der entsprechenden Speicherstruktur:

   TYPE mein_Record_T IS RECORD (
    Feld1         VARCHAR2(250),
    Feld2         NUMBER := 0,
    Feld3         VARCHAR2(5)
    );

TYPE meine_PLSQLTabelle_T IS TABLE OF mein_Record_T INDEX BY PLS_INTEGER;

meineKonkrete_PLSQLTabelle meine_PLSQLTabelle_T;

Und nun kann ich alle Datensätze des Blocks durchlaufen und in der Objekt-Struktur abspeichern:

  PROCEDURE Fuelle_meine_PLSQLTabelle(meinBlock_I IN VARCHAR2) IS
    meinIndex_V              NUMBER;
  BEGIN
    GO_BLOCK(meinBlock_I);
    FIRST_RECORD;
    LOOP
      meinIndex_V := meineKonkrete_PLSQLTabelle.COUNT;
    
      IF TRIM(NAME_IN(meinBlock_I || '.Feld1')) IS NOT NULL THEN
        meineKonkrete_PLSQLTabelle(meinIndex_V).Feld1 := NAME_IN(meinBlock_I || '.Feld1');
        meineKonkrete_PLSQLTabelle(meinIndex_V).Feld2 := NAME_IN(meinBlock_I || '.Feld2');
        meineKonkrete_PLSQLTabelle(meinIndex_V).Feld3 := NAME_IN(meinBlock_I || '.Feld3');
      END IF;
      
      EXIT WHEN :SYSTEM.LAST_RECORD = 'TRUE';
      NEXT_RECORD;
    END LOOP;     
  END Fuelle_meine_PLSQLTabelle;

Dieses Konstrukt konnte ich nun schon ein paar Mal gebrauchen, um mir das Leben mit Daten aus den Datenblöcken zu vereinfachen. Denn ich musste immer alle Daten haben, um damit z.B. andere Daten bewerten zu können. Wenn natürlich die Datenblöcke viele Daten enthalten, dauert der ganze Fetch entsprechend länger. Davon ist meine Maske aber nicht betroffen, und so helfen diese paar Zeilen Code mir ungemein.

Schöne Grüße
Holger

Mittwoch, 1. März 2017

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

Donnerstag, 19. Januar 2017

Einige Einblicke vom DOAG Forms Day am 18.01.2017 in Berlin - Das Treffen der Gefährten


Ja ja jetzt kommt der erste Beitrag in 2017 in meinem Blog, ein sehr ausführlicher Beitrag zum 1. DOAG Forms Day am 18.01.2017 in Berlin in den Geschäftsräumen von Oracle Berlin. Diese Veranstaltung zum gegenseitigen Austausch der Oracle Forms Anwender wurde auf dem Dev Camp 2016 erfunden und hat jetzt gestern stattgefunden. Vorweg es waren über 60 Teilehmer da, Bombe. Und jemand aus den USA würde sagen: All the german Forms Gurus are on stage.

Bevor es morgens losging, habe ich noch ein bisschen Tourist gespielt und mir 2 Sehenswürdigkeiten angeschaut: das Brandenburger Tor und den Reichstag, die lagen quasi am Weg.


Jetzt kommen wir aber zur Agenda des Tages, die mit zahlreichen Vorträgen ausgefüllt war. Ziel der Veranstaltung war ein Austausch zwischen Oracle und den Anwendern, Wissensvermittlung und Networking zum Thema Forms.

Die besten Sätze vorweg: für die nächsten 8 Jahre ist der Support und die Weiterentwicklung von Forms sicher gestellt, danach steht vielleicht ein großer Umbruch bevor :-)

Der erste Vortrag von Frank Hoffmann beschäftigt sich mit der Frage, wie man Forms fit für die nächsten 20 Jahre machen kann. Er vergleicht dabei irgendwie sehr passend, Forms und seine Entwickler (Jünger) mit vielen Gestalten aus dem Film "Herr der Ringe". Die Message ist klar: die Technik ist ausgereift, robust und die Entwickler sind oft ab 50 Jahren aufwärts. Es fehlt also die neue Generation junger Entwickler, die den Job fortsetzen. Und Forms soll ja nicht das "neue" COBOL werden.




Nummer 2 kam von Jan Peter Timmermann mit dem Thema "Forms und Reports 12c Installation und Administration" mit vielen spannenden Skripten und Tipps zur Installation der Infrastruktur.

Nächster Slot war Mark Eichhorst mit Tipps zur Oberflächen-Modernisierung bei Forms vor allem mit PJCs und Java Beans. Damit lassen sich natürlich sehr schöne Sachen machen, siehe auch meinen Beitrag zum hübschen System der Firma Sensis.


Nach der Mittagspause zeigte uns Jürgen Menge, wie man Teile einer Forms-Anwendung Mobil machen kann, mit Tools wie Auraplayer und den Cloud-Services von Oracle. Wichtig: Nicht die gesamte Anwendung kommt in die Cloud, sondern sinnvolle Teile, die durch bestimmte Use-Cases identifiziert werden müssen. Aber es geht!

Danch kam auch ein spannendes Thema von Stephan La Rocca: Die Zukunft des Reporting, da ja Oracle Reports offiziell abgekündigt ist. Es gibt offiziell von Oracle als Empfehlung den BI Publisher, ein anderes Open Source Tool ist JasperReports. Das Tool gibt es nicht und schon gar nicht eine automatische Migration der vorhandenen Reports, meist ist eine aufwändige Neu-Implementierung nötig. Aber auch sein Fazit: muss es ein neues Tool sein oder sollte man nicht seine komplette Reporting-Strategie in Zeiten der Digitalisierung neu überdenken.


Vorletzte Session kam von Friedhold Matz: Entwicklung eines Frameworks in Forms 12c - Light Version. Das soll bald auch noch online gestellt werden.


Der letzte Teil war mit einer der wichtigsten, initiiert von Gerd Volberg: Wie geht es mit der Forms Community weiter? Dafür setzten wir uns nach einer kurzen Einführung in einen Kreis und diskutierten zusammen.


Was bereits von Gerd, Frank und Jürgen eingerichtet wurde:
  1. der Forms 12 Demo Server https://forms12c.de mit einigen Demos
  2. das DOAG Github für Forms: https://github.com/Doag/Forms
  3. die Community-Seite https://community.oracle.com/community/other-languages/deutsche-oracle-entwickler-community/forms-developer-community
In den Demos sollen demnächst alle Interessierten Demos bereitstellen, was mit Forms 12 alles gemacht werden kann, ähnlich wie bei der APEX-Community. Denn jeder sucht mal etwas, hat eine Frage und kann auch Input bei Fragestellungen geben. Damit der Wissensaustausch auch weiter voran schreiten kann.

Aus meiner Sicht war dieser Tag ein voller Erfolg, der hoffentlich 2018 wiederholt wird. Vielleicht auch noch ein 2. mal in diesem Jahr in Verbindung mit ein paar Report-Themen. Man konnte sehr viel mitnehmen und es wurde offen über viele Themen geredet.

Danke an Berlin, die DOAG und die 3 Vorreiter Gerd, Frank und Jürgen.

Viele Grüße
Holger

Freitag, 6. Januar 2017

2 wichtige Tasks: Reports 12c Server löschen und Start des Admin Servers reparieren

Willkommen im Jahr 2017, wieder zur Stelle. Die Themen aus dem letzten Jahr sind wieder auf dem Schirm. Begrüßung durch 2 nicht funktionierende Komponenten im Fusion Middleware Stack.

Zuerst will der Admin Server auf meiner VM nicht mehr starten und es kommt folgende Meldung:

Ups, da ist wohl das Kennwort eines Schemas auf der Datenbank abgelaufen. Und tatsächlich....

Also schnell mal wieder die Kennwörter geändert und erneut geprüft.


Danach sind die User wieder freigeschaltet und der Admin Server startet auch wieder.

Das zweite Thema war die Frage eines Kunden, wie er einen Reports Server unter 12c wieder löschen kann. Dafür habe ich dann eine kleine Anleitung mit WLST erstellt und zeige sie hier gleich:

Das Löschen ist ähnlich dem Erzeugen eines Servers. Wichtig: vor dem Löschen muß der Reportsserver gestoppt sein.

Todos:

  1.   das Weblogic Scripting Tool starten mit   /oracle/product/12.2/Oracle/Middleware/Oracle_Home/oracle_common/common/bin/wlst.sh
      2.   bei WLST anmelden :   connect('weblogic','welcome1', 't3://localhost:7001')
            … das Passwort muß natürlich das jeweilige verwendete sein 
  
      3.    den Reports Server löschen:
             deleteReportsServerInstance(instanceName='my_repsrv2',machine='AdminServerMachine')
             … der instanceName muß dann dem ReportsServer entsprechen

Das Verfahren ist ähnlich wie beim Erstellen eines ReportsServers, nur habe ich es noch nicht wirklich beschrieben gefunden.

Einen guten Start in 2017 wünscht
Holger




Donnerstag, 22. Dezember 2016

Beheben von REP-52003 unter Linux mit Reports 12c

Des öfteren habe ich schon nach einer erfolgreichen Forms und Reports Installation unter Linux folgenden Fehler zu Gesicht bekommen:  REP-52003: Lesen von Reports-Vorlage /u01/app/oracle/product/12.1.0.2/db_1/reports/templates\showenv.htm nicht erfolgreich


Dabei ist Reports natürlich korrekt installiert, aber leider in einem anderen Verzeichnis. Auf der Maschine ist noch eine lokale Datenbank-Instanz vorhanden, die natürlich das ORACLE_HOME vorgibt und anders setzt als das MIDDLEWARE_HOME.

Als Lösung dafür erachten sich meiner Meinung nach 2 Ansätze.
  1. Setzen des richtigen ORACLE_HOME z.B. in einem Shell-Skript zum Starten der Umgebung
    export ORACLE_HOME=/home/oracle/Oracle/Middleware/Oracle_Home
  2. im angegebenen Verzeichnis /u01/app/oracle/product/12.1.0.2/db_1 einen symbolischen Link auf das korrekte Verzeichnis von Reports setzen (als root)

    ln -s /home/oracle/Oracle/Middleware/Oracle_Home/reports /u01/app/oracle/product/12.1.0.2/db_1/reports




Damit ist wieder ein kleineres Problemchen rund um die Oracle Software recht leicht zu beheben, vielleicht bekommen ja auch andere Anwender diesen Fehler. So weit für dieses Jahr alles geschrieben auf diesem Wege und bis nächstes Jahr.

Der Holger

Donnerstag, 8. Dezember 2016

Forms 12c Installation unter Oracle Linux 7.2 uhi uhi

Nachdem ich im letzten Projekt mit einem kompletten Team bei einer Forms 12c Installation unterwegs war, durfte ich nun das erste mal selbst eine Installation eines Systems vornehmen. Im Juni hatten wir mit dem Kunden einen Workshop durchgeführt und besprochen, wie wir denn das Upgrade planen und mit welchem System wir das machen wollen.

Vor knapp 2 Monaten kam dann die Beauftragung und in dieser Woche sollte die Einrichtung des Systems dann passieren. Mein Kollege Borys, der im Januar mit dabei war, ist jetzt woanders eingesetzt und so kam der Ball zu mir und ich durfte das System installieren.

Die Hardwarekonfiguration sieht so aus:
Betriebssystem: Oracle Linux 7.2
RAM: 16 GB
CPU: eine 4 Core CPU
Platte: 120 GB
Software: Weblogic Server 12.2.1.2 und Forms/Reports 12.2.1.2

Im Workshop waren wir noch bei der Empfehlung Forms/Reports 12.2.1.1, aber in der Zwischenzeit ist ja der neue Patch erschienen, den wir dann auch direkt installieren wollten. Zum Zeitlichen: es waren 5 Tage für die Installation eingeplant mit ordentlich Puffer. Ich selbst wollte eigentlich in 2 Tagen durch sein, aber es zeigte sich: das System hatte seine Eigenheiten und wir haben viel recherchiert und dabei auch ordentlich Puffer verbraucht. Und dank der Hilfe von Borys haben wir auch alle kritischen Stellen in den Griff bekommen. Dazu kommen noch viele Überlegungen des Kunden und auch ein noch nicht fertiges System beim Beginn der Installation.

Zumindest über die aufgetretenen Issues will ich mal heute berichten.

Nach dem 2. Tag war der Server auf folgendem Stand: Weblogic Server und Forms/Reports installiert, aber der Server war unendlich langsam. Der Start des Weblogic Servers (Admin Server) hat ca. 25 Minuten gedauert, ebenso wie das Speichern der Credentials des Nodemanagers in einer verschlüsselten Datei. Zum Verzweifeln, aber eine der Lösungen kam von Borys. Es war eine Linux-seitige Verschlüsselung aktiviert, die alles verlangsamt hat. Also eine schlechte Basis-Konfiguration des Linux, also diese deaktiviert:

    Configure SELINUX=disabled in the /etc/selinux/config

Die zweite Problemecke kam in der Installation von Java im JDK, das sogenannte urandom-Problem.

Avoiding JVM Delays Caused by Random Number Generation mit der Abhilfe:

1.     Open the $JAVA_HOME/jre/lib/security/java.security file in a text editor.

1.     Change the line:
securerandom.source=file:/dev/random
to urandom:
securerandom.source=file:/dev/urandom

Und schon waren die Laufzeitprobleme weg, und das System war auf einmal sehr schnell. 

Die nächste Besonderheit lag in der Freigabe der nötigen Ports in der Firewall, denn nach der Installation ließ sich die Administrationskonsole nicht auf dem Host-Rechner anzeigen, denn die Ports waren geblockt und mußten freigegeben werden:

·        4443 -> HTTP Server (ohs1) with HTTPS Protocol
·        5556 -> for NodeManager
·        7001-> for Admin Console and Enterprise Manager
·        7777 -> for HTTP Server (ohs1)
·        7779  optional -> Admin Port for HTTP Server
·        9001 -> for Forms Services
·        9002 -> for Reports Services
·        80 optional -> for HTTP Server (alternate port) if port 7777 shoud be forwarded to port 80
·        14021 -> für den Reports Server


Für den Forms Builder und Compiler mußte ein symbolischer Link unter cd /usr/lib64 gesetzt werden, damit diese beiden Tools funktionieren:
ln -s libXm.so.4 libXm.so.3

Damit der Reports Server auch laufen konnte, mußte noch im Verzeichnis $ORACLE_BASE ein symbolischer Link auf $ORACLE_HOME/reports gesetzt werden, denn sonst hat Reports seine Templates in $ORACLE_BASE gesucht, diese liegen aber in $ORACLE_HOME/reports.

Eine der größten Herausforderungen war die Darstellung von kyrillischen Zeichen in den Reports. In der vorigen Installation wurde das durch verschiedenen Mechanismen gelöst, diesmal sollte das eigentlich out-of-the-box gelingen so die Hoffnung. Aber nichts da, es musste auch wieder so gelöst werden.

1. in der rwserver.conf steht ein Eintrag mit der richtigen NLS_LANG:
<envVariable name="NLS_LANG" value ="GERMAN_GERMANY.al32utf8"/>

2. man muß verschieden Schriften in das Verzeichnis $DOMAIN_HOME/reports/fonts kopieren. Diese haben wir vom Ursprungs-System Windows genommen und auf Linux kopiert.

3. muß die Datei uifont.ali mit einem Schriften-Mapping versehen werden:
helvetica..Italic.Bold.. = "arialbi.ttf"
helvetica...Bold..       = "arialbd.ttf"
helvetica..Italic...     = "ariali.ttf"
helvetica.....           = "arial.ttf"
courier..Italic.Bold.. = "courbi.ttf"
courier...Bold..       = "courbd.ttf"
courier..Italic...     = "couri.ttf"
courier.....           = "cour.ttf"
times..Italic.Bold.. = "timesbi.ttf"
times...Bold..       = "timesbd.ttf"
times..Italic...     = "timesi.ttf"
times.....           = "times.ttf"
 

Danach kann der Report auch ordentlich aufgerufen werden. Es gab also ordentlich Stolpersteine bei der Installation, denn Oracle Linux war in seiner Begebenheit ganz anders als das SuSE Linux, wo wir zuletzt die Systeme installiert haben. Damit ist jetzt erstmal das System einsatzbereit, es fehlt noch die Forms-Konfiguration, aber das probiert der Kunde erstmal alleine.

Hier noch das bekannte Forms-Test-Module:
 


Ja ja eine spannende Woche für mich, aber gut verlaufen.

Gruß vom
Holger