Posts mit dem Label Installation werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Installation werden angezeigt. Alle Posts anzeigen

Freitag, 11. Mai 2018

Forms 12c, Reports und Weblogic in Docker - diesmal mit Windows 10

Heute möchte ich meine Reihe mit der Oracle Middleware und Docker fortsetzen. Doch diesmal wähle ich Windows 10 Professional als Host aus, denn dafür ist Docker mittlerweile auch verfügbar.

Wichtig ist, nach der Installation von Docker im Menü auf die Linux Container zu wechseln, statt mit den Windows Containern zu arbeiten.


Wenn das kleine Walfisch-Icon (Docker) dann weiß ist und sich nicht mehr bewegt, ist Docker erfolgreich gestartet.





Zusätzlich kann man auch in der DOS-Box fragen, ob der Befehl docker nun verfügbar ist.


Am Anfang des Probierens habe ich mich gefragt, wie komme ich denn nun beim Weblogic Docker Images gebaut, welches normalerweise mit

sh buildDockerImage.sh -v 12.2.1.3 gestartet wird. Klassische Linux Befehle in einer Windows DOS-Box wie soll das gehen? Im Endeffekt gar nicht, denn ich habe die Docker Images von Linux exportiert und dann im Anschluß in Windows importiert. Das geht so:

## auf Linux:
docker save  -o /mnt/hgfs/D/formsreports12.2.1.3.tar localhost/oracle/myformsreports:12.2.1.3

## auf Windows:
docker load --input D:/formsreports12.2.1.3.tar
und ein docker images zeigt sie dann auch erfolgreich an.


Die nächste Transformation fand in den Environment-Variablen statt:
## auf Linux:
  export DC_ORCL_PORT=1521
  export DC_ORCL_OEM_PORT=5500
  export DC_ORCL_SID=frdb
  export DC_ORCL_PDB=frpdb
  export DC_ORCL_SYSPWD=Oracle12c
  export DC_ORCL_HOST=${DC_HOSTNAME}

## auf Windows:
 SET DC_DESIRED_HOSTNAME=myformsserver
 SET DC_ORCL_PORT=1521
 SET DC_ORCL_OEM_PORT=5500
 SET DC_ORCL_APEX_PORT=8080
 SET DC_ORCL_SID=ORCLCDB
 SET DC_ORCL_PDB=ORCLPDB1
 SET DC_ORCL_SYSPWD=oracle
 SET DC_ORCL_HOST=%DC_DESIRED_HOSTNAME%

zusätzlich habe ich mir einen festen Hostnamen ausgedacht, der auch in den Properties konfiguriert ist. In dem Zusammenhang sei gesagt, dass das Mounten von Volumes auf Windows mit dem späteren Docker Container nicht funktioniert hat, was sicherlich an irgendwelchen Rechten liegt. So werden also im Gegensatz zum Linux Host die späteren Domain-Informationen alle innerhalb des Docker Containers gespeichert. Dies ist natürlich vom Zugriff her nicht so komfortabel wie auf dem Linux Host, wo er Volume-Mount keine Probleme gemacht hat.

Im File für docker-compose habe ich auch einige Anpassungen vorgenommen, dort wird z.B. auch direkt der Hostname des neuen Containers auf den gewählten aus dem Properties-File gesetzt und ich habe noch einige weitere Environment-Variablen erzeugt, die später den Umgang mit der Domäne etwas vereinfachen.

Hier der Inhalt meines docker-compose Files:
version: "3.0"

services:
  #
  #  The Oracle DB Definition
  #
  frdb:
    image: oracle/database:12.1.0.2-ee
    network_mode: "bridge"
    ports:
      - "${DC_ORCL_PORT}:1521"
      - "${DC_ORCL_OEM_PORT}:5500"
      - "${DC_ORCL_APEX_PORT}:8080"
    environment:
      - ORACLE_SID=${DC_ORCL_SID}
      - ORACLE_PDB=${DC_ORCL_PDB}
      - ORACLE_PWD=${DC_ORCL_SYSPWD}
    container_name: frdb

  #
  #   The Forms & Reports Servers
  #   
  myfrfmw:
    image: ${DC_REGISTRY_FR}/oracle/${DC_FR_PREFIX}formsreports:${DC_FR_VERSION}
    hostname: ${DC_DESIRED_HOSTNAME}
    network_mode: "bridge"
    container_name: myfrfmw
    command: /bin/bash -c "sleep 5s; /opt/oracle/dockertools/crDomain.sh"
    ports:
      - "${DC_ADMINPORT}:${DC_ADMINPORT}"
      - "${DC_FORMS12C_MS_PORT}:${DC_FORMS12C_MS_PORT}"
      - "${DC_REPORTS12C_MS_PORT}:${DC_REPORTS12C_MS_PORT}"
      - "${DC_OHS_LISTENPORT}:${DC_OHS_LISTENPORT}"
      - "${DC_NM_PORT}:${DC_NM_PORT}"
    environment:
      - SCRIPT_HOME=${DC_SCRIPT_HOME}
      - INT_ORACLE_HOME=${DC_INT_ORACLE_HOME}
      - WL_HOME=${DC_WL_HOME}
      - WLST_HOME=${DC_WLST_HOME}
      - MW=${DC_MW}
      - DOMAIN_BASE=${DC_DOMAIN_BASE}
      - APPLICATION_BASE=${DC_APPLICATION_BASE}
      - APP_VZ=${DC_APP_VZ}
      - FORMS12C=${DC_FORMS12C}
      - FADS12C=${DC_FADS12C}
      - REPORTS12C=${DC_REPORTS12C}
      - WEBTIER12C=${DC_WEBTIER12C}
      - OHS_COMPONENTNAME=${DC_OHS_COMPONENTNAME}
      - OHS_LISTENPORT=${DC_OHS_LISTENPORT}
      - OHS_SSLPORT=${DC_OHS_SSLPORT}
      - TEMPLATE=${DC_TEMPLATE}
      - DOMAIN_NAME=${DC_DOMAIN_NAME}
      - AS_NAME=${DC_AS_NAME}
      - ADM_USER=${DC_ADM_USER}
      - ADM_PWD=${DC_ADM_PWD}
      - ADMINPORT=${DC_ADMINPORT}
      - ADMINPORTSSL=${DC_ADMINPORTSSL}
      - AS_HOST=${DC_AS_HOST}
      - FORMS_MS_NAME=${DC_FORMS_MS_NAME}
      - FORMS12C_MS_PORT=${DC_FORMS12C_MS_PORT}
      - REPORTS_MS_NAME=${DC_REPORTS_MS_NAME}
      - REPORTS12C_MS_PORT=${DC_REPORTS12C_MS_PORT}
      - REPORTS_IN_FORMS=${DC_REPORTS_IN_FORMS}
      - REP_SERVER=${DC_REP_SERVER}
      - REP_SERVER_NAME=${DC_REP_SERVER_NAME}
      - REP_TOOLS_NAME=${DC_REP_TOOLS_NAME}     
      - NM_LISTENADDRESS=${DC_NM_LISTENADDRESS}
      - NM_TYPE=${DC_NM_TYPE}
      - NM_PORT=${DC_NM_PORT}
      - NM_USERNAME=${DC_NM_USERNAME}
      - NM_PWD=${DC_NM_PWD}
      - DBUSER=${DC_DBUSER}
      - DBPWD=${DC_DBPWD}
      - DBROLE=${DC_DBROLE}
      - COMPONENTPWD=${DC_COMPONENTPWD}
      - SCHEMA_PREFIX=${DC_SCHEMA_PREFIX}
      - DB_HOST=${DC_DB_HOST}
      - DB_PORT=${DC_DB_PORT}
      - DB_SERVICE=${DC_DB_SERVICE}
      - DB_OMF=${DC_DB_OMF}
      - DB_USER_PW=${DC_DB_USER_PW}
      - PWDFILE=${DC_PWDFILE}
      - TNS_ADMIN=${DC_DOMAIN_BASE}/${DC_DOMAIN_NAME}/config/fmwconfig
      - FORMS_INSTANCE=${DC_DOMAIN_BASE}/${DC_DOMAIN_NAME}/config/fmwconfig/components/FORMS/instances/forms1/bin  
      - FORMS_WEBCFG=${DC_DOMAIN_BASE}/${DC_DOMAIN_NAME}/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_12.2.1/config
      - DOMAIN_DIR=${DC_DOMAIN_BASE}/${DC_DOMAIN_NAME}
      - DOMAIN_DIR_BIN=${DC_DOMAIN_BASE}/${DC_DOMAIN_NAME}/bin  
      - NLS_LANG=AMERICAN_AMERICA.AL32UTF8      
      - FORMS_WEBUTIL=${DC_DOMAIN_BASE}/${DC_DOMAIN_NAME}/config/fmwconfig/components/FORMS/instances/forms1/server   

Gestartet wird zunächst wieder einmal die Datenbank-Instanz, die als Repository dienen soll und im Anschluß dann der Weblogic-Server, der zunächst automatisch die Forms/Reports-Domäne erzeugt.

docker-compose -f myfrfmw-docker-compose.yml up -d myfrfmw
docker logs myfrfmw -f

Alles in allem nicht wirklich schwer das Prozedere und mit etwas Transfer-Arbeit verbunden. Natürlich gut und hilfreich, dass Docker den Ex- und Import von Images anbietet; auch plattformübergreifend.

Bis bald
Holger

Freitag, 8. Dezember 2017

Forms 12c, Reports und Weblogic in Docker - nun wirklich lauffähig

Heute möchte ich beschreiben, wie man Forms 12c, Reports und Weblogic in Docker zum Laufen bringt. Das war schon länger ein Wunsch von mir und Dirk Nachbar (http://dirknachbar.blogspot.de) hat dafür großartige Vorarbeit geleistet, unterstützt von Robert Crames (http://robertcrames.blogspot.ch) und Jan-Peter Timmermann (https://jan-peter.me).

Warum denn Docker wird man sich vielleicht fragen? Die einfache Antwort lautet: weil Docker toll ist und man nicht immer wieder eine neue VM mit Forms aufzusetzen braucht. Außerdem sind automatisierte Builds und das Bereitstellen einer Umgebung ohne viele manuelle Aktivitäten einfach besser.

Mein Setup sieht so aus:
  • Laptop mit Windows 7
  • darauf eine VM mit Ubuntu 17.10
  • und in Ubuntu läuft Docker
Die Ubuntu-Maschine und der WLS-Docker Container teilen sich Verzeichnisse, in denen die erstelle WLS-Domäne liegt. So kann direkt von Ubuntu aus die Domäne verändert und konfiguriert werden. Ein paar weitere Vorarbeiten sind noch zu leisten, wie z.B. User oracle und Gruppe oinstall anzulegen. Auf meinem Ubuntu mußten noch die Versionen von docker und docker-compose upgegradet werden, denn die aktuellen Versionen aus dem Software-Repository waren nicht mehr ganz aktuell.


Die Installationsschritte sind im Prinzip genau wie bei einer Installation von Forms/Weblogic auf einem Host. Man braucht im Einzelnen:
  • eine Datenbank für das Repository (entweder Docker oder Host)
  • einen Weblogic im Docker
  • eine Repository Installation
  • eine Forms/Reports Weblogic Domäne

Hier für dieses Beispiel habe ich alles in 2 Docker-Images installiert und bin der Anleitung von Dirk aus seinem Github gefolgt.

1. Aufbau des Datenbank Images (gefordert wird eine Standard oder eine Enterprise Installation für das Repository)
Hierfür habe ich einen Git Clone des offiziellen Oracle Docker Githubs gemacht und mittels ./buildDockerImage.sh -v 12.2.0.1 -e ein Image der Enterprise Edition gebaut.


Nach dem erfolgreichen Erstellen wird dieses Image z.B. hiermit gestartet:
docker run --name oracle12-ee -p 1521:1521 -p 5500:5500 -p 8080:8080 -e ORACLE_PWD=neuesPasswort -v /opt/oracle/oradata:/u01/app/oracle/oradata oracle/database:12.2.0.1-ee

2. Aufbau des Weblogic Images
Dieser Teil beginnt mit dem Git Clone von Dirks Github Repository und hat mehrere Schritte.
Zuerst erfolgt der Build des OracleLinux:latest mit dem Oracle JDK 8u151. Dafür muss man das JDK 8u151 tar.gz in den Ordner OracleJava/java-8 legen und ein
./buildDockerImage.sh machen.

Danach gibt es ein oracle/serverjdk Image. Anschauen kann man sich die vorhandenen Images mit dem Command: docker images


Nun wechselt man ins Verzeichnis OracleFMWInfrastructure/dockerfiles und erstellt ein Weblogic Abbild. Dafür muss man vorher noch bei Oracle die entsprechende Weblogic-Zip-Datei fmw_12.2.1.3.0_infrastructure_Disk1_1of1.zip herunterladen und in OracleFMWInfrastructure/dockerfiles/12.2.1.3 ablegen.
Mit ./buildDockerImage.sh -v 12.2.1.3 wird der Build gestartet und am Ende kommt ein Oracle WebLogic Server Infrastructure 12.2.1.3.0 heraus.


Letzter Abschnitt ist das Erweitern des WLS-Infrastructure Images mit den Forms und Reports Sourcen (Wechsel ins Verzeichnis OracleFormsReports/dockerfiles und Ablage der Installations-Dateien fmw_12.2.1.3.0_fr_linux64.bin und fmw_12.2.1.3.0_fr_linux64-2.zip im Unterordner OracleFormsReports/dockerfiles/12.2.1.3. Mit ./buildDockerImage.sh -v 12.2.1.3 wird der Image-Build gestartet.


Am Ende hat man dann ein Image localhost/oracle/formsreports TAG: 12.2.1.3

3. Jetzt geht es ans Konfigurieren der Domain. Dafür hat Dirk im Verzeichnis OracleFormsReports/samples eine Konfigurationsdatei setenv.sh vorbereitet, die die nötigen Umgebungsvariablen setzt (hier ein Auszug).

Diese Datei muss entsprechend angepasst werden; sehr wichtig sind die Eintragungen im #Repository Connect für den Connect des RCU gegen diese Datenbank. Da bin ich zuerst in eine Falle gelaufen und habe für DC_DB_HOST die falsche IP angegeben, dann hat die Erstellung der Domain nicht funktioniert.
Mit ifconfig auf dem Docker Host gibt es ein Netzwerk namens docker0 und unter der inet stehen sollte eine IP stehen. Diese ist die richtige für den DB Container.

Nun kann mit dem Erzeugen der WLS-Domäne und Start des Admin-Servers begonnen werden (vorher sollte die DB aber gestartet sein). Die Variablen aus setenv.sh werden gemerkt, exportiert und vom docker-compose genutzt.

source ../setenv.sh
docker-compose up -d frfmw; docker logs frfmw -f

Wenn man Ende ein <BEA-000365> <Server state changed to RUNNING.>
steht, ist alles gut verlaufen.

Nun kann im Browser der Enterprise Manager mit der URL http://localhost:7001/em aufgerufen werden.

Hierin können nun die Managed Server MS_FORMS und MS_REPORTS gestartet werden.


Wenn man dann auch noch von der Ubuntu-VM die Ports entsprechend forwarded, kann man im Client im Browser auch die Forms-Testseite aufrufen:
http://localhost:9001/forms/frmservlet


Was kann man noch machen?

Einen zuvor erstellten Reports-Server starten

Da die Konfigurationsdateien der Domain alle in einem Verzeichnis auf dem Docker Host zugänglich sind, kann man sie dort auch bequem bearbeiten und die Änderungen sind persistiert (z.B. default.env, formsweb.cfg, rwserver.conf, httpd.conf und andere).

Man kann auch das neue FADS mit dem Forms 12.2.1.3.0 nutzen, siehe dazu auch ins readme-File von Dirk.

Tja was soll ich sagen, ich bin erstmal sehr begeistert von dieser Variante. Denn nach einem Neustart des Ubuntus kann man die Datenbank und den WLS Admin Server mit 2 einzelnen docker Befehlen wieder starten und die Umgebung ist wieder da. Hier ist es auch von Vorteil, dass die o.g. Herren die ganze Domänen-Erstellung gescriptet haben und man ohne GUI auskommt. Von Oracle gibt es dafür bislang keinen Support, was nicht heißt, dass man es nicht trotzdem machen und versuchen soll.

Viele Grüße
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, 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