Ich war's nicht! Fehler & Ursachensuche in APEX Peter Raganitsch FOEX GmbH Österreich Schlüsselworte APEX, Fehler, Debug, Logging, Nachforschung. Einleitung Wenn mal was nicht so klappt wie man sich das vorstellt, dann ist guter Rat oft teuer. Das muss aber nicht sein. Mit ein paar einfachen Bordmitteln kann man schnell herausfinden, was so alles im Hintergrund passiert und warum das Ding nicht das tut, was man gerne möchte. Debugging Spricht man von Fehlern in Computersoftware bzw. dem Auffinden derselben, dann spricht man typischerweise von Debugging. Dazu erstmal eine Definition des Begriffes Debugging aus Wikipedia: Debugging is the process of finding and resolving bugs or defects that prevent correct operation of computer software or a system. Debugging tends to be harder when various subsystems are tightly coupled, as changes in one may cause bugs to emerge in another. Quelle: Wikipedia: https://en.wikipedia.org/wiki/debugging Diese allgemeine Beschreibung wird im Falle von Oracle Application Express zur bitteren Wahrheit, denn Oracle APEX ist ein zusammengesetztes System. Die Summe der Teile Oft wird APEX nur als System gesehen, in der Fehlersuche wird dann oft deutlich, dass dieses System aus vielen einzelnen Teilen besteht. Als wichtige Teile können folgende genannt werden: Datenbank APEX Netzwerk Browser Damit wird deutlich sichtbar, dass eine tiefgreifende Fehlersuche unbedingt alle Teil-Systeme abdecken muss. Wenn der Fehler in einem Teil-System lokalisiert wurde, können die anderen erstmal beruhigt ausser Acht gelassen werden. Das soll natürlich nicht heissen, dass dort keine anderen Fehler versteckt sein können. Manche Fehlertypen treten erst bei einer bestimmten Kombination der einzelnen Systeme auf, soll heissen erst wenn beispielsweise Datenbank 12c auf APEX 5.0 mit einem langsamen Netzwerk auf einen Internet Explorer 11 trifft.
Vorgehensweise bei der Fehlersuche Aufgrund der Vielzahl an Teilsystemen, aus denen sich Oracle APEX zusammensetzt, ist es erstmal wichtig herauszufinden WO der Fehler auftritt. Dazu kann man sich am Top-Down-Ansatz orientieren und beginnt ganz oben bei APEX zu suchen und hantelt sich durch die verschiedenen Systeme wie Browser und Netzwerk bis zur Datenbank vor. Neben dem WO ist auch noch das WAS und WER interessant. Denn ist der Fehler erstmal in einem bestimmten Bereich lokalisiert, gilt es weiters herauszufinden WAS die Ursache des Fehlers ist. Ein Fehler der in der Oberfläche (WO) auftritt, kann durchaus in einem anderen Bereich ausgelöst worden sein, Beispielsweise durch eine ungünstige Verschachtelung von Regionen (WAS). Die Frage nach dem WER bedeutet nicht nur, dass man versucht einen Sündenbock zu finden. Viel wichtiger ist es den zuständigen Personen die Auswirkung von WO und WAS zu erläutern. Wie bei vielen Dingen im Leben ist auch bei der Fehlersuche die Vorbereitung sehr wichtig. Hier bedeutet es, möglichst viele Informationen in der Hand zu haben, wenn eine Fehlersituation auftritt. Dazu kann man sich der Instrumentalisierung schon in der Entwicklungsphase bedienen. Los geht die Fehlersuche Als allgemein gültiges Kochrezept lässt sich die Fehlersuche immer mit Aktivierung des APEX Debug beginnen. Dazu klicken sie in der APEX Developer Toolbar auf Debug oder fügen in der URL an der 5. Position YES ein. Der zweite Schritt ist sodann die Aktivierung der Javascript Konsole ihres Browsers. Dort werden allfällige Javascript Fehler und Debug-Informationen von Dynamic Actions angezeigt. APEX Debug Oracle Application Express bietet als Einstieg zur Fehlersuche eine sogenannte Debug Funktion an. Streng genommen handelt es sich dabei um ein klassisches Logging, wie man es auch von anderen Tools, wie Beispielsweise log4j kennt. APEX Debug unterstützt (seit Version 4.2) mehrere verschiedene Log Levels: Level Beschreibung 1 Error Kritische Fehler 2 - Warning Weniger kritische Fehler 4 Info Default Level, wenn Debug ohne Angabe von Levels aktiviert wird. Zeigt alle normalen Debug-Informationen 5 App Enter Applikation: Meldungen zum Aufruf von Prozeduren 6 App Trace Applikation: Andere Meldungen innerhalb von aufgerufenen Prozeduren 8 Engine Enter APEX Engine: Meldungen zum Aufruf von internen Prozeduren 9 Engine Trace APEX Engine: Andere interne Meldungen Siehe dazu auch die Erklärung in der APEX Dokumentation, APIs, APEX Debug: https://docs.oracle.com/cd/e59726_01/doc.50/e39149/apex_debug.htm#aeapi29184 Bevor APEX Debug aktiviert werden kann, muss eine von diesen beiden Voraussetzungen erfüllt sein: 1. In der Applikations-Definition ist Debugging erlaubt 2. Oder es handelt sich um eine Entwickler-Session (erkennbar durch den Developer Toolbar)
Ist eine dieser Voraussetzungen erfüllt, so kann APEX Debug über die URL im Browser aktiviert werden. Dazu wird an der 5. Position innerhalb der URL entweder YES oder LEVEL1..LEVEL9 eingegeben. Beispiel: Normale URL einer ausgeführent Anwendung: http://apex.oracle.com/ords/f?p=171:1:3457588657568::::: Mit aktiviertem Debug: http://apex.oracle.com/ords/f?p=171:1:3457588657568::level6::: Handelt es sich um eine Entwickler-Session, so kann der Debug zusätzlich über die Developer- Toolbar aktiviert werden, allerdings wird dort standardmäßig nur YES (entspricht LEVEL4) gesetzt. Will man einen anderen Level aktivieren, so ist ein Eingriff in die URL ohnehin nötig. Oracle APEX stellt uns zu diesem Zweck mit dem PL/SQL Package APEX_DEBUG aber auch ein API zur Verfügung. Mit Hilfe von APEX_DEBUG.ENABLE kann der Debug programmatisch jederzeit aktiviert werden, unabhängig von der Einstellung Debugging in der Applikations- Definition. Durch die Aktivierung des APEX Debug werden nun pro Seiten-Aufruf, pro Seiten-Speichern und pro AJAX-Call (z.b. Filtern im Interactive Report oder Aufruf einer Dynamic Action) ein eigener Debug- Log in der Datenbank eingetragen. Zu jedem Debug Log (auch Debug View or View Identifier genannt) gibt es dann eine beliebige Anzahl von Detail-Einträgen. Dieses Konzept lässt sich mit einzelnen Log-Dateien und deren Inhalt vergleichen. Anzeige der APEX Debug Logeinträge Um das zuvor aktivierte Debugging auswerten zu können, muss man sich nun die erstellten Log- Einträge ansehen. Hierzu gibt es wieder eine Reihe von Möglichkeiten. Die bequemste Art ist im Entwicklermodus auf View Debug in der Developer Toolbar zu klicken, dort wird man dann auf die Debug-Übersicht weitergeleitet, die alle Einträge zur aktuellen Applikation und Seite enthält.
Debug Übersicht aus der Developer Toolbar heraus. Alle Debug-Einträge, auch von anderen APEX Sessions, kann man sich im Application Builder unter Tools Debug Messages anzeigen lassen. Damit kann man beispielsweise einen Anwender bitten den Debug in der URL zu aktivieren und sich so dessen Meldungen ansehen.
Auf einem gesicherten Produktionssystem wird es aber aller Wahrscheinlichkeit nach keinen Application Builder geben, da man dort aus Sicherheitsgründen die Runtime-only-Version von APEX installieren sollte. In diesem Fall hilft man sich mit einer Abfrage auf die View APEX_DEBUG_MESSAGES weiter:
Der Informationsgehalt aller 3 Methoden ist der selbe, schlussendlich gehen alle auf die Daten der View APEX_DEBUG_MESSAGES los. Hier ist es wichtig anzumerken, dass die Debug-Einträge nur für einen sehr begrenzten Zeitraum aufgehoben werden. Dieser Zeitraum lässt sich über die APEX Instanz-Administration nach Bedarf anpassen. Will man, aus welchen Gründen auch immer, die Debug-Meldung für einen sehr langen (oder unendlichen Zeitraum) aufheben, empfiehlt es sich die Meldungen in eine eigene Tabelle herauszukopieren, damit die APEX Verarbeitung nicht durch eine unnötig grosse Tabelle beeinträchtigt wird. Wichtige Informationen im Debug Log In den Debug Log Einträgen finden sich je nach eingestelltem Log-Level sehr viele unterschiedliche Informationen. Nicht alle sind vielleicht auf den ersten Blick interessant, deswegen ist es auch wichtig den richtigen Log-Level zu wählen. Geht man immer auf Level 9, so wird man von unzähligen APEX internen Meldungen überschwemmt, die zumeist nicht interessant sind. Grundsätzlich ist der Log von oben nach unten, in einer zeitlichen Ablaufreihenfolge zu lesen und gibt einen Überblick, was alles beispielsweise in einer Seitenverarbeitung durchgeführt wurde. Dies beginnt beim Initialisieren des Session-Kontext, setzen der NLS Parameter aufgrund der Applikationseinstellungen und geht über das Lesen des Session-State und der Seiten-Einstellungen bis hin zur Verarbeitung des auf der durchgeführten Seite definierten Prozesse und Regionen.
Zusätzlich zu der Informationen WAS durchgeführt wurde, sieht man auch wieviel Zeit seit dem letzten Log-Eintrag (also der Zeile davor) verstrichen ist. Mit dieser Information kann man ganz einfach sehen, wo am meisten Zeit verbraucht wird und dann gezielt diese Verarbeitung oder Abfrage versucht zu tunen. Debug-Meldungen im Browser Bisher haben wir APEX_DEBUG kennengelernt, welches alle Vorgänge mitprotokolliert. Allerdings sind dies nur jene Vorgänge, die in der Datenbank stattfinden. Seit APEX 4.0 gibt es aber Dynamische Aktionen, welche direkt im Browser ausgeführt werden. Will man zu diesen Dynamischen Aktionen Log-Meldungen erhalten, so ist in erster Linie wiederum der APEX Debug Modus zu aktivieren. Im zweiten Schritt öffnet man dann die Javascript Konsole des Browsers, wo man dann Zusatzinformationen zum Ablauf der Dynamischen Aktionen sehen kann:
Mehr Information zum Thema Mehr Information zum Thema Fehlersuche mit einer Menge praktischer Beispiele können sie in der dazugehörigen Präsentation sehen.
Kontaktadresse: Peter Raganitsch FOEX GmbH Aspettenstrasse 48 A-2380 Perchtoldsdorf, Österreich Telefon: +43 (0) 1-373 3639 E-Mail peter.raganitsch@tryfoexnow.com Internet: www.tryfoexnow.com