Deployment von ADF-Applikationen auf den Oracle WebLogic Server

Transkript

1 Deployment von ADF-Applikationen auf den Oracle WebLogic Server Andreas Koop TEAM GmbH Paderborn Schlüsselworte: Deployment, Application Development Framework (ADF), Oracle JDeveloper, Oracle Fusion Middleware, Oracle WebLogic Server, Apache Ant, WebLogic Scripting Tool (WLST) Einleitung Nach dem Erwerb von BEA Systems durch Oracle löst der WebLogic Server den Oracle Application Server als strategische Plattform ab. Innerhalb der Fusion Middleware fungiert der WebLogic Server somit als leistungsfähige Integrations- und Laufzeitumgebung für Enterprise-Applikationen. In diesem Vortrag präsentiert der Referent Best Practices und Erfahrungen bei der Bereitstellung von ADF-Applikationen auf den Oracle WebLogic Server 11g. Von der Installation der Basissoftware über die notwendigen Konfigurationsschritte bis hin zum Deployment im Cluster werden die essentiellen Tätigkeiten beleuchtet, bestehende Hürden und deren Lösungen aufgezeigt. Dabei beschränkt sich der Vortrag nicht nur auf das Deployment von ADF 11g Faces Rich Client Applikationen, sondern gibt auch eine Empfehlung für das Deployment von ADF Webanwendungen. Das Deployment wird in verschiedenen Phasen des Softwareentwicklungsprozesses betrachtet, da sich ein einziges Deploymentverfahren z.b. per Ant-Skript nicht immer in allen Phasen als geeignet herausstellt. Es werden Vor- und Nachteile der jeweiligen Verfahren diskutiert und eine Empfehlung ausgesprochen. Einen wichtigen Teil der Bereitstellung bildet die Anwenderauthentifizierung und - autorisierung einer ADF-Applikation. Am Beispiel von OpenLDAP als Security-Provider werden die notwendigen Konfigurationsschritte erläutert. Außerdem wird aufgezeigt, welche Schritte notwendig sind, um innerhalb der ADF-Applikation Meta Data Service (MDS) zur persistenten Speicherung benutzerspezifischer UI-Einstellungen zu nutzen. Bereitstellung der WebLogic Server Laufzeitumgebung Installation WebLogic Server Software Bevor eine ADF-Applikation bereitgestellt werden kann, muss zunächst die Oracle WebLogic Server Software (nachfolgend mit WLS abgekürzt) installiert werden. In dieser Phase gibt es

2 bereits mehrere Möglichkeiten und damit aber auch gleichzeitig eine potentielle Fehlerquelle mehr. Welche Variante ist für ADF-Applikationen geeignet, welche sollte man vermeiden? Dieser Frage wollen wir zu Beginn nachgehen. Variante 1: WebLogic Server 11g Installer plus ADF-Laufzeitumgebung Die naheliegende Vorgehensweise ist sicherlich, die Installation mittels Oracle WebLogic Server-Installer. Ist die Installation einmal durchgeführt, wird man jedoch feststellen, dass bei der Erstellung einer WLS-Domäne die ADF-Bibliotheken fehlen. Diese müssen im 2.Schritt entweder mittels JDeveloper11g- oder dem Application Development Runtime-Installer nachinstalliert werden. Variante 2: JDeveloper 11g Installer Da der JDeveloper 11g inkl. WebLogic Server ausgeliefert wird, liegt es nahe, dieses Installationspaket für die Installation heranzuziehen. Die Vorgehensweise ist recht simpel: Installer starten, JDeveloper bei der Auswahl der zu installierenden Komponenten deaktivieren und wie gewohnt durch den Wizard klicken. Empfehlung: Falls die Laufzeitumgebung für ADF-Applikationen mit möglichst geringem Aufwand und ausschließlich für ADF eingerichtet werden soll, empfiehlt sich Variante 2. Möchten Sie das neue Fusion Middleware Control nutzen, benötigen man in jedem Fall den Application Development Runtime-Installer. Sollte kein X-Server auf dem Installationsrechner vorhanden sein, lässt sich der WebLogic Server übrigens auch im silent -Modus installieren. Erstellung einer Domäne für ADF11g-Applikationen Nach der Installation der WebLogic Server Software muss zunächst eine WebLogic Domäne erstellt und mit Oracle JRF erweitert werden (siehe Abb. 1). Die Konfiguration wird mit Hilfe des Configuration Wizards erstellt und lässt sich über MW_HOME/wlserver_10.3/common /bin/config.{cmd sh} starten. Abb. 1:Erstellung WebLogic Domäne für ADF Applikationen Oracle JRF steht Java Required Files und stellt alle notwendigen Bibliotheken für den Betrieb von ADF11g-Applikationen in einer WLS-Domäne zur Verfügung.

3 Folgende grundsätzliche Einstellungen der so erstellten Domäne sind empfehlenswert 1. Logging-Einstellung der Server-Instanzen: Aktivierung von Redirect stdout logging enabled. Mit dieser Konfiguration werden auch evtl. vorhandene System.out.println-Ausgaben protokoliert und unterliegen z.b. dem Log- Rotating. 2. Aktivierung der WebLogic Diagnostic Framework-Extension über die Preferences>Extensions: Aktivierung von diagnostics-console-extension. Mit Hilfe dieser Extension lassen sich detaillierte Informationen und Auswertungen zu nahezu allen WebLogic Server-Laufzeitmetriken beobachten. Deployment von ADF11g-Applikationen Das Deployment von ADF11g-Applikationen kann auf unterschiedliche Arten erfolgen. In diesem Abschnitt werden die wichtigsten Methoden und deren Einsatzgebiet aufgezeigt. Erstellung eines Deploymentprofils Bevor ein Deployment durchgeführt werden kann, benötigt man ein gültiges Deployment- Profil. In der Regel wird vom JDeveloper bereits ein WAR- und EAR-Profil automatisch erstellt. Anpassungen können jedoch jederzeit nachträglich vorgenommen werden. Die Deploymentprofile lassen sich im JDeveloper 11gR1 wie folgt bearbeiten WAR: Application (Menu)>Project Properties>Deployment EAR: Application (Menu)>Application Properties>Deployment Empfehlung: Eine automatisierte Erstellung eines WAR. Dies ist mit geringem Aufwand realisierbar. Mit dem JDeveloper lässt sich ein Ant-Skript für die Tasks compile, deploy generieren und somit einfach in ein Continous Integration System einbinden. Hinweis: Ein Ant-Task für die Erstellung des EAR muss leider noch manuell erstellt werden. Konfiguration der ADF11g-Domäne Nun gilt es die mit ADF11g-Bibliotheken ausgestattete WLS-Domäne für das Deployment vorzubereiten. In der Regel müssen folgende Vorbereitungen getroffen werden. Anlage einer JDBC Datenquelle Es wird empfohlen die ADF-Applikation im JDeveloper so zu konfigurieren, dass die Datenbankverbindung über ein JNDI-Lookup stattfindet. Bei der Verwendung von ADF Business Components wird das Applikationsmodul entsprechend konfiguriert. Der Standardname für die Datenquelle ist jdbc/connectionds. Der Vorteil dieser Vorgehensweise ist, dass ein und dieselbe Applikation ohne Konfigurationsänderungen auf der Entwicklungs-, Test-, und Produktionsumgebung bereitgestellt werden kann. Dadurch wird das Deployment sicher im Bezug auf mögliche Konfigurationsfehler. Bei erstmaligem Aufsetzen eines Testsystems für eine ADF11g-Applikation ist die Konfiguration über die Administration Console zu empfehlen. Nach Anmeldung und

4 Navigation zu Services>JDBC>Data Sources hat man im Handumdrehen die notwendige Datenquelle erstellt. Wichtig ist die Vergabe des korrekten JNDI-Namens. Der Name muss bei Verwendung von ADF BC und Standardeinstellungen jdbc/connectionds entsprechen. Best Practice: Um wiederkehrende Aufgaben über die Administration Console zu automatisieren, empfiehlt sich die Aufzeichnung jeglicher Konfigurationsschritte zu einem WLST-Skript. Die Skripte lassen sich einfach auf Kundenmaschinen übertragen und erleichtern die Installation und Konfiguration auf dem Zielsystem ungemein. Anlage eines MDS-Repositories/-Partition Mit Release von JDeveloper 11gR1 ist es möglich, ADF11g-Applikationen mittels Meta Data Service (MDS) zu personalisieren. D.h. zum Beispiel, dass benutzerspezifische UI- Einstellungen wie z.b. die Breiten von Tabellenzellen oder die Sichtbarkeit von einzelnen Spalten persistent zu einem Benutzer abgespeichert werden können. Jeder Anwendungsbenutzer kann sich somit die Oberfläche an seine Bedürfnisse anpassen. Damit dieses problemlos auch außerhalb der Entwicklungsumgebung funktioniert, müssen jedoch noch nachfolgende Vorkehrungen getroffen werden. Beim Einsatz des Oracle Enterprise Manager 11g ist die Konfiguration recht einfach, da für die MDS-Konfiguration eine entsprechende Funktion zur Verfügung steht. Kommt der Oracle EM 11g jedoch nicht zum Einsatz, muss das Repository und die Partition manuell angelegt werden. Folgende Schritte sind dafür notwendig 1. Erstellung der Verzeichnisse für das MDS-Repository und die Partition. Z.B. /u01/app/oracle/mds-repo1/part1 2. Konfiguration eines Persistent FileStore über die Administration Console > Services > Persistent Stores. Wichtig hierbei ist, dass der Name des FileStores mit mds- beginnt und auf das zuvor angelegte Verzeichnis verweist. Ansonsten wird es nicht als gültiges MDS-Repository beim Deployment erkannt. Anlage eines Authentication-Providers Dieser Schritt ist notwendig, wenn die Applikation nicht öffentlich ist, sondern über eine Authentifizierung verfügt. Zwar kann während der Entwicklungsphase der eingebettete LDAP-Server des WLS dienen, in der Praxis wird man um die Anbindung an einen unternehmensweit eingesetzten LDAP-Server nicht herumkommen. In einem ADF11g-Projekt von TEAM ist ein OpenLDAP-Server als Authentication-Provider zum Einsatz gekommen. Die Konfiguration ist recht simpel, man muss jedoch beachten, dass der Default-Authenticator zuvor auf SUFFICIENT gestellt werden sollte. Ansonsten ist eine Anmeldung als weblogic-benutzer an der Administration Console nicht mehr möglich! Empfehlung: Mapping von Applikationsrollen auf Unternehmensbenutzer/-gruppen ist derzeit nur unter umfangreichen Konfigurationen möglich, die man auf diversen Blogs findet. Falls also möglich ist ein 1:1 Mapping zu empfehlen. Bei diesem Ansatz ist zu beachten, dass es

5 unter Umständen nicht möglich sein wird, mehrere Applikationen in einer Domäne zu installieren, da ein Security-Realm für die gesamte Domäne und nicht pro Applikation gilt. Hinweis: Bei einem Anonymous-Connect müssen folgende Felder einfach leer bleiben: Principal, Credential, Confirm Credential. Das funktioniert. Deployment aus dem JDeveloper 11g Dieses Verfahren kommt zum Einsatz, wenn in kürzester Zeit eine Preview-Version der Applikation auf einem Remote WLS bereitgestellt werden muss. Grundsätzlich ist es ein einfaches und unkompliziertes Verfahren. Das Deployment wird über das Menu Application>Deploy><EAR-Profil>>to>New Connection angestoßen. Einfach die Verbindungsinformationen zum WebLogic Server eingeben und schon wird die ADF-Applikation bereitgestellt. Falls MDS zum Einsatz kommt, wird das Deployment mit folgendem Dialog (Abb. 2) unterbrochen Abb. 2: Auswahldialog MDS-Repository/-Partition Wurde in der WLS-Domäne wie in Abschnitt zuvor erläutert ein MDS-Repository inkl. einer Partition erstellt, so steht das Repository zur Auswahl und das Deployment kann fortgeführt werden. Vorteil: Schnell, keine Vorarbeit notwendig Nachteil: Keine Integrationsmöglichkeit in einen automatisierten Build-Management-Prozess Einsatz: Preview, Entwicklung, Notfall Deployment über die Administration Console Nach Erstellung und Auslieferung der EAR-Datei, kann diese wizardgesteuert über die Administration Console bereitgestellt werden. Der Wizard wird nach Anmeldung an der

6 Administration Console über den Punkt Deployments>Install initiiert. Die EAR-Datei kann direkt über die Web-Oberfläche hochgeladen werden oder manuell auf dem Dateisystem zur Verfügung gestellt werden. Vorteil: Schnell, keine Vorarbeit notwendig Nachteil: Keine Integrationsmöglichkeit in einen automatisierten Build-Prozess, Administration Console muss aktiv sein, manuell, fehleranfällig Einsatz: Preview, Entwicklung, Notfall Deployment mittels Ant-Skript Nahezu jeder Entwickler ist mit dem Build-Werkzeug in der Java-Welt vertraut. Die WebLogic Server Software liefert alle notwendigen Ant-Task aus, um EAR-Dateien bereitzustellen. Das Ant-Skript könnte z.b. so aussehen: <taskdef name="wldeploy" classname="weblogic.ant.taskdefs.management.wldeploy"/> <taskdef resource="net/sf/antcontrib/antlib.xml"> <classpath> <pathelement location="${ant.lib.folder}/lib/ant-contrib.jar"/> </classpath> </taskdef> <target name="deploy-app"> <wldeploy action="deploy" source="${env.prj_customer}-${env.prj_name}.ear" name="${env.prj_customer}-${env.prj_name}" user="${env.wls_domain_admin}" password="${env.wls_domain_password}" adminurl="${env.wls_domain_admin_url}" targets="${env.prj_target_server}" remote="true" upload="true" /> </target> Das Ant-Skript sollte möglichst wiederverwendbar sein. Daher werden alle parametrierbaren Konfigurationsmöglichkeiten aus der Umgebung geladen. Vorteil: Flexibel, einfach in einen automatisierten Build-Prozess integrierbar Nachteil: Passwort im Klartext(?), Änderung der MDS-Konfiguration unmöglich(?) Einsatz: Entwicklung, Testsystem Hinweis: Eine umfangreiche Sammlung diverser Ant-Tasks zum Starten, Stoppen des WLS, Anlegen von Domänen, JDBC-Datenquellen ist unter zu finden. Deployment mittels WLST-Skript WLST steht für WebLogic Scripting Tool und ist das primäre Administrations- und Konfigurationswerkzeug des WebLogic Servers (zumindest war es bei BEA so). Jede

7 denkbare Konfiguration ist mittels WLST umsetzbar, so auch das Deployment von Applikationen. Ein WLST-Skript für das Deployment einer MDS-fähigen ADF11g- Applikation sieht z.b. wie folgt aus: deploy_app.py: MDS-Konfiguration für WLS aktualisieren import os app_name = os.environ['prj_customer']+'-'+os.environ['prj_code'] app_location = os.environ['prj_home']+'/deploy/'+app_name+'.ear' print '[INFO] updating MDS config for '+ app_location archive = getmdsarchiveconfig(fromlocation=app_location) archive.setappmetadatarepository(repository= 'mds-repo1',partition= 'part1', type='file', path='/u01/app/oracle/mds-repo1') archive.save() deploy_app.py: Deployment und Applikationsstart connect() deploy(app_name, app_location, targets= Cluster1 ) startapplication(app_name) disconnect() Vorteil: Flexibel, einfach in einen automatisierten Build-Prozess integrierbar, skriptgesteuerte Konfigurationsänderungen an der WLS-Domäne möglich, Admin-Passwort kann verschlüsselt werden. Nachteil: WLST ist möglicherweise unbekannt, Lernprozess erforderlich. Einsatz: Integrationssystem, Produktion Hinweis: Das Admin-Passwort kann mittels storeuserconfig() nach Anmeldung über WLST am Admin-Server. Alle weiteren Anmeldungen funktionieren ohne Angabe des Passworts. Deployment im Cluster Für das Deployment im Cluster inkl. Ausfallsicherheit müssen einige wenige zusätzliche Konfigurationen vorgenommen werden. Applikationskonfiguration Insgesamt sind drei Konfigurationsanpassungen notwendig, um die ADF11g-Applikation für das Deployment im Cluster vorzubereiten: weblogic.xml: Anpassung des Deskriptors <session-descriptor> <invalidation-interval-secs>60</invalidation-interval-secs> <persistent-store-type>replicated_if_clustered</persistent-store-type> </session-descriptor>

8 Diese Konfiguration aktiviert die HTTP-Session-Replikation. adf-config.xml: Anpassung des ADF-Config-Deskriptors <adf-controller-config xmlns=" <adf-scope-ha-support>true</adf-scope-ha-support> </adf-controller-config> Die ADF-spezifische Konfiguration sorgt dafür, dass Wertänderungen im Page- und View- Scope repliziert werden. Ferner sollten die Applikationsmodule für die Ausfallsicherheit konfiguriert werden über: Pooling and Scalability> Aktivierung Failover Transaction State Upon Managed Release Empfehlung: Zum Testen eines Serverausfalls empfiehlt sich die Ausgabe von System.getProperty("weblogic.Name") innerhalb einer JSP. Proxy-Konfiguration Konfiguration Zugriff über einen Apache HTTP-Server mit mod_wl. Nach Installation des entsprechenden Moduls ist folgende Konfiguration zu empfehlen: weblogic.conf: Konfiguration Apache HTTP-Server <Location /adfapp> WebLogicCluster w1s1.com:7003,w1s2.com:7003,w1s3.com:7003 ErrorPage </IfModule> Hinweis: Durch die Konfiguration der Location kann jetzt die entsprechende Applikation im WebLogic Server direkt über Port 80 des Apache HTTP-Server angesprochen werden. Sollte der WebLogic Server unter keinem der angegebenen Server erreichbar sein, so wird auf eine Fehlerseite umgeleitet. Deployment von ADF10g-Applikationen Das Deployment von ADF respektive Applikationen hat sich seit Aug etwas vereinfacht. Oracle bietet dazu das WebLogic SmartUpgrade Werkzeug an. Ein Tutorial samt Installationsanleitung findet sich auf OTN. Allerdings muss man beachten, dass dieses Werkzeug lediglich einen Upgrade-Report erstellt. Die notwendigen Maßnahmen müssen manuell durchgeführt werden. 1. Erstellung einer Domäne für ADF x Applikationen 2. Ausführung des ADF Runtime Installers x 3. Integration des setupadf.sh- in das setdomainenv.sh-skript vor der CLASSPATH-Deklaration.

9 4. Anpassung Deploymentprofil. Folgende Bibiliotheken müssen mit aufgenommen werden: BC4J Oracle Domains, Oracle JDBC, SQLJ Runtime 5. Deployment des neuen EAR in die adf1013_domain. Probleme: Offensichtlich hat der WLS JSP-Compiler Probleme folgenden JSP-Code zu übersetzen: <jsp:directive.include file="/include/header.jspf"/> at line 2: This element may only appear as the root element in the document. Lösung: Eine Lösung ist derzeit nicht bekannt. Troubleshooting Dieser Abschnitt fasst mögliche Fehlerquellen währen des Betriebs von ADF-Applikationen zusammen und zeigt Lösungen auf. Verzögerungen von 5 bis 20 Minuten bei Serverstart Mögliche Ursache: Beim Zugriff auf /dev/random kommt es zu einer blockierenden Leseoperation. Dies kann auftreten, wenn der WebLogic Server auf einem Headless-Server ohne Tastatur und Maus betrieben wird. Exakte Prüfung erfolgt mittels lsof grep /dev/random Liegt eine blockierende Leseoperation vor, so kann dem wie folgt vorgebeugt werden: Lösung: Anpassung der $JAVA_HOME/jre/lib/security/java.security: securerandom.source=file:/dev/./urandom Nicht alle WLST-Kommandos werden erkannt Anfangs sieht es aus, als würden nicht alle WLST-Kommandos funktionieren (z.b. createmetadatapartition) Mögliche Ursache: Die Umgebung für WLST ist nicht korrekt gesetzt. Lösung: Statt der Ausführung des WLST-Skriptes mittels MW_HOME/wlserver_10.3/common/bin/wlst.sh muss das Skript mittels MW_HOME/jdeveloper/common/bin/wlst.sh gestartet werden. Deployment von ADF11g-Applikationen auf eine Managed Server Instanz Ursache: Der Classpath des Managed Servers ist nicht korrekt gesetzt, falls er über den NodeManager gestartet wird. Lösung: Der Classpath muss in der jeweiligen Server-Konfiguration manuell angepasst werden. Zusammenfassung Das Deployment von ADF-Applikationen auf den Oracle WebLogic Server, ist nahezu mühelos durchführbar. Für jede Projektphase existiert ein geeigneter Mechanismus, um die Applikation sicher für die Endanwender bereitzustellen. Sehr stark vereinfacht hat sich die Bereitstellung im Cluster. Mit nur einigen wenigen Konfigurationsschritten kann die Ausfallsicherheit gewährleistet werden.

10 Kontaktadresse: Andreas Koop Dipl.-Informatiker Hermann-Löns-Straße 88 D Paderborn Telefon: +49(0) Fax: +49(0) Internet: