Application Express (APEX) ist als Teil der Oracle-Datenbank seit nun mehr als 10 Jahren verfügbar. IT-Landschaften setzen das Framework mittlerweile auch in größerem Stil ein. Stichwort "Enterprise APEX". Welche Aspekte sind für größere APEX-Server von Bedeutung? Wir geben einen Überblick.
Zentraler APEX Entwicklungsserver
Entwickelt Ihr Unternehmen mehrere APEX-Anwendungen, so dürfte es sinnvoll sein, diese auf einem zentralen APEX-Server zu bündeln. APEX bringt mit seinem Workspace-Konzept alles nötige dafür mit.
APEX Workspaces sind voneinander getrennt
Ein APEX-Entwickler arbeitet in seinem Workspace isoliert von allen anderen Workspaces. Administrative Aufgaben, die nur den Workspace betreffen – wie zum Beispiel das Einrichten neuer User-Accounts – kann allein durch den Workspace-Administrator erfolgen. Der zentrale Administrator der Datenbank muss nicht aktiv werden.
Insofern kann die Nutzerverwaltung für einen APEX-Workspace problemlos an einen Projektleiter oder Applikationsverantwortlichen abgegeben werden. APEX-Entwickler müssen bis hin zur aktuellen Version APEX 4.2.5 als User im APEX-Workspace eingerichtet und verwaltet werden. APEX 5.0 wird auch hier eine Menge Vorteile bringen: Für Workspace-Nutzer können Administratoren andere Authentifizierungsverfahren wählen.
So wird es möglich sein, den LDAP- oder "Single Sign On"-Server auch zur Anmeldung an den APEX-Workspaces zu verwenden. Das bislang separate Passwort-Management innerhalb der APEX-Workspaces entfällt dann.
Best Practices
Nicht nur in größeren Unternehmen sind Best Practices gang und gäbe. Meist liegen diese in Form von mehr oder weniger umfangreichen Dokumenten vor – Entwickler sind dann meist aufgefordert, diese Dokumente zu lesen und anzuwenden.
Auch da hilft APEX: Das Framework unterstützt Entwickler bei der Anwendung betrieblicher Best Practices. An erster Stelle steht die Nutzung von Template- oder Referenz-Anwendungen.
Dies sind Anwendungen, die meist von zentraler Stelle erstellt und an alle APEX-Nutzer weitergegeben werden. Die folgende Aufzählung zeigt Beispiele für die Inhalte solcher Template-Anwendungen:
- Themes und Templates zur Abbildung der Corporate Identity
- Wertelisten, die im Unternehmen immer wieder verwendet werden
- Im Unternehmen gewünschtes Authentifizierungsschema (Single Sign On)
- Standard-Autorisierungsschemata (könnten auf LDAP-Gruppen basieren)
Oft werden Template-Anwendungen auch bereits mit Standard-Dialogen oder vorgefertigten Anwendungsseiten für wiederkehrende Anforderungen versehen. Entwickler können somit auf Bestehendem aufbauen. Für die Nutzer hat eine solche Vorgehensweise den Vorteil, dass die APEX-Anwendungen für ähnliche Aufgaben auch ähnlich aussehen. Man findet sich schneller zurecht.
Repositiory & Qualitätssicherung
Den meisten APEX-Nutzern ist bekannt, dass APEX metadatengetrieben ist. Alle Details der entwickelten Anwendungen sind also in den Tabellen des "APEX Repository" abgelegt. Diese Daten lassen sich sehr gut zur Qualitätssicherung nutzen. Denn Qualitätsprobleme wie Formularfelder ohne Hilfetext lassen sich mit Hilfe geschickt formulierter SQL-Abfragen schnell und einfach finden. Die am häufigsten gebrauchten Fälle sind im APEX Advisor enthalten, der bereits im Lieferumfang enthalten ist.
APEX Advisor
Formuliert man eigene Abfragen, so lassen sich diese (im Gegensatz zum Advisor) sogar Workspace-übergreifend ausführen. So zeigt die folgende SQL-Abfrage einem zentralen Administrator, welche Plugins in den verschiedenen APEX-Anwendungen zum Einsatz kommen. Diese Liste kann nun gegen eine vorhandene Whitelist geprüft werden.
SQL> select application_id, name from apex_appl_plugins; |
Welche Plugins werden auf dem APEX-Server eingesetzt?
Das ist nur ein kleiner Ausschnitt der Themen, die für den Einsatz von APEX im größerem Stil, Enterprise APEX, bedeutsam sind. Diese und andere Themen, zu denen in den letzten Jahren viele Erfahrungen gesammelt wurden, sind Inhalte der Oracle-Veranstaltung im Oktober 2014 "APEX 5.0 – Enterprise APEX".
