Logo Oracle Deutschland   Application Express Community
APEX 4.1 Early Adopter zum Online-Testen freigegeben
APEX 4.1 Early Adopter ist da

APEX 4.1 Early Adopter ist da


Erscheinungsmonat APEX-Version Datenbankversion
Juni 2011 ab 4.1 (EA2) ab 10.2

Es ist soweit: APEX 4.1 Early Adopter steht zum Testen auf http://tryapexnow.com/ bereit. Im Gegensatz APEX 4.0, welches eine Fülle neuer Features mitbrachte, ist APEX 4.1 eher als Maintenance Release anzusehen; der Fokus liegt auf der Abrundung und Vervollständigung der in APEX 4.0 eingeführten Neuerungen. Als ersten Einblick haben wir im folgenden eine kleine Auswahl interessanter Neuerungen zusammengestellt. Eine vollständige Auflistung der neuen Features ist unter "http://apex.oracle.com/pls/apex/f?p=52663:1" verfügbar.

  1. Verbesserungen beim Error-Handling
  2. Verbesserungen für APEX-Formulare
  3. Tabellarische Formulare
  4. EA2: Excel-Upload für den Endanwender
  5. Verschiedene, nützliche neue Features

Verbesserungen beim Error-Handling

Auf das verbesserte Error-Handling bei den DML-Prozessen der APEX-Formulare haben Entwickler lange gewartet. Bislang leitete APEX bei einem Fehler im Prozess auf eine neue Fehlerseite um - das Layout dieser Seite lässt sich nur schwer beeinflussen. APEX 4.1 bietet für onSubmit-Prozesse nun ein neues Attribut Error Message Display Location an (Abbildung 1).

Neues Prozessattribut: "Error Message Display Location"

Abbildung 1: Neues Prozessattribut: "Error Message Display Location"

Standardmäßig ist es für neue Prozesse auf Inline with Notification eingestellt, was dazu führt, dass die Fehlermeldung wie die einer APEX-Validierung angezeigt wird (Abbildung 2).

Die Datenbank-Fehlermeldung wird inline angezeigt

Abbildung 2: Die Datenbank-Fehlermeldung wird inline angezeigt

Darüber hinaus kann auf Seiten- oder Anwendungsebene eine Error-Handling-Funktion eingetragen werden; als Entwickler kann man die aufgetretenen Fehler also bspw. in eine eigene Tabelle protokollieren lassen oder die Fehlermeldung verändern. Das könnte für das Beispiel in Abbildung 2 wie folgt aussehen: Im SQL-Workshop spielt man das folgende SQL ein.

create or replace function my_error_handler (
 p_error in apex_error.t_error 
) return apex_error.t_error_result is
  v_er apex_error.t_error_result;
begin
  v_er := apex_error.init_error_result ( p_error => p_error );
  if p_error.ora_sqlcode = -1438 then
    v_er.message := 'Es wurde ein zu langer Wert eingegeben - Bitte überprüfen Sie Ihre Angaben.';
  else
    v_er.message := p_error.message;
  end if;
  return v_er;
end;

Navigieren Sie danach zu den Seitenattributen und dann zum Bereich Error Handling. Stellen Sie die erzeugte Funktion MY_ERROR_HANDLER dort als Error Handling Function ein. Wenn Sie möchten, können Sie auf den Notification Text nach Ihren Wünschen anpassen (Abbildung 3).

Einrichten der "Error Handling Function"

Abbildung 3: Einrichten der "Error Handling Function"

Das Ergebnis kann sich sehen lassen - APEX 4.1 macht den Umgang mit Datenbank-Fehlermeldungen doch wesentlich leichter. Und in der PL/SQL-Prozedur für das Error-Handling kann man natürlich "alles machen, was man will" ... Wer mehr zu Thema wissen möchte, schaut am besten in Patrick Wolfs Blog nach. Dort finden sich weitere Erklärungen und Beispiele.

Anwendungsseite mit "umgeschriebener" Fehlermeldung

Abbildung 4: Anwendungsseite mit "umgeschriebener" Fehlermeldung

Zurück zum Anfang des Artikels

Verbesserungen für APEX-Formulare

Möchte man mit APEX ein Formular auf eine Tabelle ohne Primärschlüssel erstellen oder hat der Primärschlüssel mehr als zwei Spalten, so hatte man in der Vergangenheit ein Problem - entweder erstellte man das Formular manuell (was den Zeitaufwand erhöhte) oder man musste einen einfacheren Primärschlüssel finden (was Änderungen am Datenmodell bedeutete). APEX 4.1 bietet einen einfachen Ausweg an: Es kann die datenbankinterne ROWID in Formularen (und übrigens auch in tabellarischen Formularen) verwenden (Abbildung 5).

ROWID anstelle eines Primärschlüssels in Formularen nutzen

Abbildung 5: ROWID anstelle eines Primärschlüssels in Formularen nutzen

Wird die ROWID verwendet, fragt APEX (logoischerweise) auch nicht mehr nach, ob für neue Zeilen eine Sequence, ein Trigger oder eine Funktion verwendet werden soll.

APEX-Formulare verwenden einen Checksummenalgorithmus zur Erkennung von konkurrierenden Zugriffen auf die gleiche Tabellenzeile. Wenn ein anderer Nutzer die gleiche Tabellenzeile zwischenzeitlich geändert hat, schlägt der vom APEX-DML-Prozess durchgeführte Checksummenvergleich fehl und es wird eine Fehlermeldung ausgelöst. APEX 4.1 erlaubt nun, eine eigene Tabellenspalte für den Versionsvergleich anzugeben (Abbildung 5) - dies geht allerdings nur in "normalen" Formularen, tabellarische Formulare bieten dieses Feature (noch) nicht an.

Optimistische Locking anhand der Spalte "MY_VERSION_COLUMN" durchführen

Abbildung 6: Optimistische Locking anhand der Spalte "MY_VERSION_COLUMN" durchführen

Zurück zum Anfang des Artikels

Tabellarische Formulare

Nochmals erhebliche Verbesserungen finden sich bei tabellarischen Formularen. So ist es in APEX 4.1 möglich, Validierungen zu hinterlegen, die für jede Zeile des tabellarischen Formulars ausgeführt werden (Abbildung 7).

Validierung für tabellarisches Formular hinterlegen

Abbildung 7: Validierung für tabellarisches Formular hinterlegen

Auch wird es erheblich einfacher, eigene PL/SQL-Prozesse für tabellarische Formulare zu schreiben. Musste man bislang umständlich mit den APEX_APPLICATION.G_FXX-Arrays hantieren, geht das nun viel eleganter. Zunächst wird bereits beim Erstellen des Prozesses selbst festgelegt, dass auf einem tabellarischen Formular gearbeitet wird (Abbildung 8).

Prozess für tabellarisches Formular erstellen

Abbildung 8: Prozess für tabellarisches Formular erstellen

Im Quelltext können die Spaltennamen des tabellarischen Formulars direkt per Doppelpunkt-Syntax verwendet werden.

begin
  insert into emp1 (empno, ename, mgr, job, sal, hiredate, comm, deptno)
  values (:EMPNO, :ENAME, :MGR, :JOB, :SAL, :HIREDATE, :COMM, :DEPTNO);
end;

Und auch Bedingungen können hinterlegt werden - diese werden entweder einmalig oder pro Zeile geprüft.

Bedingung für "tabellarischen Prozess" hinterlegen

Abbildung 9: Bedingung für "tabellarischen Prozess" hinterlegen

Alles in allem ist die Unterstützung für tabellarische Formulare mit APEX 4.1 doch einen ganzen Schritt nach vorne gekommen.

Zurück zum Anfang des Artikels

Excel-Upload für den Endanwender

Hierauf haben APEX-Entwickler lange gewartet: APEX bietet nun eine Komponente an, mit der Endanwender Tab- oder Kommaseparierte Dateien in Tabellen hochladen können. Für den Entwickler stand diese Möglichkeit schon im allerersten Release der HTML DB bereit - APEX 4.1 macht das auch für den Endbenutzer möglich.

Klicken Sie hierzu in einer bestehenden Anwendung in der Developer Toolbar auf Create bzw. Erstellen und wählen Sie dann Neue Seite aus. Daraufhin sehen Sie den in Abbildung 10 dargestellten Dialog.

Neuer Seitentyp "Data Loading"

Abbildung 10: Neuer Seitentyp "Data Loading"

Klicken Sie auf Data Loading. Sie werden anschließend durch einen mehrseitigen Dialog geführt, in dem Sie die Upload-Seiten für den Endanwender konfigurieren.

  • Es wird festgelegt, in welche Tabelle die Daten importiert werden sollen (EMP). Dazu muss eine eindeutige Spalte bestimmt werden (EMPNO).
  • Sie können Lookup-Tabellen festlegen.
  • Es können einfache Datentransformationen hinterlegt werden - so können Sie die Leerzeichen aus den hochgeladenen Daten entfernen (Trim) oder die Daten in Upper- bzw. Lowercase umwandeln.
    Hinterlegen von Datentransformationen

    Abbildung 11: Hinterlegen von Datentransformationen

Für den Daten-Upload entstehen mehrere Seiten in Ihrer APEX-Anwendung - der Endanwender erhält einen Wizard, durch den er sich durchklicken kann - die Daten werden dabei zunächst in eine APEX-Collection hochgeladen, danach finden etwaige Lookups, Datentransformationen und Validierungen statt - und schließlich werden die Daten im letzten Schritt in die Tabelle geschrieben.

Daten-Upload für den Endanwender - Schritt 1: Copy & Paste

Abbildung 12: Daten-Upload für den Endanwender - Schritt 1: Copy & Paste

Daten-Upload für den Endanwender - Schritt 2: Zuordnung zu Tabellenspalten

Abbildung 13: Daten-Upload für den Endanwender - Schritt 2: Zuordnung zu Tabellenspalten

Daten-Upload für den Endanwender - Schritt 3: korrekte Daten in Tabelle schreiben

Abbildung 14: Daten-Upload für den Endanwender - Schritt 3: korrekte Daten in Tabelle schreiben

Alle hochgeladenen Datensätze bleiben in der APEX-Collection mitsamt Ihrem Status erhalten, so dass eine Weiterbearbeitung möglich ist. Dass die Daten in einer Collection abgelegt werden, eröffnet dem APEX-Programmierer auch noch weitere Möglichkeiten - so kann man anstelle des automatischen APEX-Prozesses auch etwas eigenes bauen. So könnte man komplexere Datentransformationen hinterlegen oder Daten gleich in mehrere Tabellen anstatt nur einer schreiben. Alles in allem ist das ein sehr nützliches Feature, welches sicherlich oft zur Anwendung kommen wird.

Verschiedene, nützliche neue Features

Über das beschriebene hinaus wird bringt APEX 4.1 noch viele weitere nützliche Features mitbringen; meist sind es Verbesserungen im Detail, die in der Praxis jedoch erheblich Aufwand einsparen. Im folgenden seien einige der Verbesserungen aufgezählt:

  • Die in APEX 4.0 eingeführten Dynamic Actions können nun auch bei Klick auf eine Schaltfläche ausgelöst werden.
  • Für das Erstellen neuer Anwendungen gibt es nun die Instant Application; damit wird eine leere "Anwendungshülle" in drei Mausklicks erstellt. Danach lassen sich, wie immer, neue Seiten hinzufügen.
    Erstellen einer Instant Application

    Abbildung 15: Erstellen einer Instant Application

  • Die unterschiedlichen Schaltflächentypen "Region" und "Element" wurden angeglichen. So kann eine "Item"-Schaltfläche nun auch auf eine URL verzweigen - bislang führte dieser Schaltflächentyp zwingend ein Page Submit durch.
  • Für Computations in Interaktiven Berichten stehen nun zusätzlich die Funktionen EXP, POWER und SQRT bereit.
  • Plugin-Entwickler können nun 15 anstelle von bisher 10 Plugin-Attributen festlegen. Außerdem können Plugin-Attribute nun unter anderem auch als Checkbox definiert werden.
  • Ein neuer Plugin-Typ wurde eingeführt - es können nun Plugins für Autorisierungsschemas definiert werden.
  • Möchte man (bspw. für Email) Links zu APEX-Seiten generieren, kann man nun APEX_UTIL.HOST_URL nutzen, um den Hostnamen, den TCP/IP-Port und den APEX-Präfix ( /pls/apex) herauszubekommen.
  • APEX-Listen können nun auch (wie LOVs) dynamisch sein und auf einer SQL-Abfrage basieren.
  • EA2: APEX kann so eingestellt werden, dass die Online-Hilfe nicht mehr vom eigenen APEX-Server, sondern von den Oracle-Servern bezogen wird. Das ist insbesondere bei Updates hilfreich, da die Oracle-Webseiten stets aktuell sind.

Wie schon erwähnt, erhebt diese Liste keinen Anspruch auf Vollständigkeit - APEX 4.1 enthält auch an anderen Stellen noch Verbesserungen und Erweiterungen im Detail. Am besten probieren Sie es auf tryapexnow.com selbst aus. Und wie schon bei APEX 4.0 ist das Entwicklerteam sehr an Ihrem Feedback interessiert. Klicken Sie dazu einfach oben rechts auf den Link Feedback und schreiben Sie uns, was Sie von dem einen oder anderen Feature halten ...

Geben Sie uns Feedback!

Abbildung 16: Geben Sie uns Feedback!

Zurück zum Anfang des Artikels

Zurück zur Community-Seite