Remote-Debugging mit dem SQL Developer und Application Express

Heute widmen wir uns einem allgemeinen, für den Entwickler jedoch recht wichtigen Thema: Debugging. Wer Anwendungen erstellt, kommt früher oder später in die Situation, dass die Anwendungsprozesse nicht ganz so funktionieren, wie sie sollen. Manchmal ist die Fehlersuche leicht, manchmal schwieriger. Heute erfahren Sie, wie Sie PL/SQL-Code, der von Application Express-Anwendungen ausgeführt wird, mit dem Oracle SQL Developer debuggen können. Wir wollen uns jedoch nicht mit dem "Normalfall" begnügen, in welchem das Debuggung aus dem SQL Developer heraus gestartet wird. Vielmehr wird der PL/SQL-Code aus Application Express heraus gestartet - das Debugging findet dann im SQL Developer statt.

SQL Developer

Der SQL Developer ist die SQL- und PL/SQL-Entwicklungsumgebung von Oracle. Das Werkzeug kann kostenlos aus dem Oracle Technet heruntergeladen werden und bietet dem Entwickler wertvolle Hilfe beim Programmieren mit der Oracle-Datenbank.

Abbildung 1: Oracle SQL Developer

Vorbereitungen

Damit das Remote-Debugging mit dem SQL Developer funktioniert, müssen einige Voraussetzungen gegeben sein. Stellen Sie zunächst sicher, dass das Parsing-Schema, in welchem Ihre Anwendung läuft, das Systemprivileg DEBUG CONNECT SESSION hat. Das Schema, unter dem die Application Express-Sessions ablaufen (normalerweise APEX_PUBLIC_USER) benötigt das Privileg DEBUG ANY PROCEDURE. Natürlich können Sie das DEBUG-Privileg auch an nur einzelnen Prozeduren vergeben (GRANT DEBUG ON COMMUNITY.MY_PROCEDURE to APEX_PUBLIC_USER).

Wenn Sie PL/SQL-Code direkt als Prozesstext in Application Express hinterlegen, kann dieser nicht mit dem SQL Developer debuggt werden; der Code muss dazu als PL/SQL-Funktion, -Prozedur oder -Package hinterlegt werden. Dies ist jedoch ohnehin zu empfehlen; die Logik sollte komplett in Packages hinterlegt werden - die Application Express-Anwendung ruft diese dann nur noch auf.

Das Beispiel

Als Beispiel dient ein Bericht. Recht häufig ist es nötig, die SQL-Abfrage eines Berichts durch PL/SQL zusammensetzen zu lassen. Und genau dies tut auch das heutige Beispiel. Anhand eines Tabellennamens sollen alle VARCHAR2-Spalten selektiert werden. Der Tabellenname wird aus einer Auswahlliste ausgewählt. Erstellen Sie also eine Application Express-Seite mit einer HTML-Region und einer Auswahlliste. Die Auswahlliste erhält den Namen P1_TABLENAME und basiert auf einer dynamischen Werteliste mit folgender SQL-Abfrage (Vergessen Sie nicht die Schaltfläche Go zum Absenden der Auswahl):

select TABLE_NAME d, TABLE_NAME r from USER_TABLES order by 1

Die Ausgangsseite sollte dann in etwa wie folgt aussehen:

Abbildung 2: Ausgangssituation: Eine Seite mit Auswahlliste

Der Bericht soll nun (wie bereits beschrieben) alle VARCHAR2-Spalten der ausgewählten Tabelle darstellen. Zunächst wird also eine PL/SQL-Funktion zum Generieren der SQL-Abfrage benötigt. Lassen Sie im SQL Workshop folgendes Skript laufen.

create or replace function generate_sql (
  p_tablename in USER_TABLES.TABLE_NAME%TYPE
) return varchar2
is
  v_sql varchar2(32767) := '';
begin
  v_sql := 'select ';
  for col in (
    select column_name from user_tab_columns
    where table_name = p_tablename and data_type = 'VARCHAR2'
  ) loop
    v_sql := v_sql || col.column_name ||', ';
  end loop;
  v_sql := substr(v_sql, 1, length(v_sql) - 2);
  v_sql := v_sql || ' from ' || p_tablename;
  return v_sql;
end;
/

Legen Sie nun den Bericht wie in Abbildung 3 darstellt an. Achten Sie darauf, Generische Spalten bei Spaltenüberschriften auszuwählen. Als SQL-Abfrage hinterlegen Sie einfach ...

begin
  return generate_sql(:P1_TABLENAME);
end;

Abbildung 3: Bericht erstellen: Die SQL-Abfrage wird von der PL/SQL-Funktion GENERATE_SQL erzeugt

Starten Sie die Seite nun und probieren Sie es mit einigen Tabellen aus.

Abbildung 4: Ein dynamischer Bericht

Das Debugging

So weit so gut. Als nächstes erfahren Sie, wie Sie diesen Bericht bei Problemen debuggen können. Starten Sie zuerst den SQL Developer, verbinden Sie sich mit dem Parsing Schema Ihrer Application Express-Anwendung und suchen Sie unter Funktionen die soeben erzeugte PL/SQL-Funktion generate_sql. Wenn Sie den SQL Developer das erste Mal benutzen, müssen Sie zu Beginn eine Connection zur Datenbank einrichten; tun Sie dies, indem Sie im Strukturbaum das Kontextmenü für Connections und dort New Connection auswählen.

Abbildung 5: Die PL/SQL-Funktion GENERATE_SQL im SQL Developer

Mit einem Klick auf den Bleistift können Sie den Code editieren.

Abbildung 6: PL/SQL-Code bearbeiten

Wenn Sie links neben einer Zeile klicken, wird diese als Breakpoint für das Debugging markiert - sie erscheint rot hinterlegt.

Abbildung 7: Festlegen eines Breakpoints für das Debugging

Klicken Sie nun auf das "Compile"-Symbol mit dem schwarzen Pfeil; dadurch wird die Funktion mit Debug-Informationen neu kompiliert.

Abbildung 8: Funktion "mit Debug" neu kompilieren

Nun geht es daran, den Remote-Debugger einzurichten. Suchen Sie dazu im Kontextmenü nach Ihrer Datenbankverbindung, rufen Sie mit der rechten Maustaste das Kontextmenü auf und wählen Sie Remote Debug aus. Im darauf folgenden Dialog wählen Sie einen freien TCP/IP-Port aus und geben Sie den Namen bzw. die IP-Adresse des Rechners, auf dem der SQL Developer läuft, an (merken Sie sich die Angaben). Klicken Sie abschließend auf OK.

Abbildung 9: Remote-Debugger einrichten

Daraufhin erscheint unten rechts im Run Manager der Hinweis, dass der SQL Developer einen Listener für das Remote-Debugging gestartet hat.

Abbildung 10: Der Listener für Remote-Debugging wurde gestartet

Wechseln Sie nun wieder zu Application Express. Um die SQL-Funktion vom SQL Developer aus debuggen zu können, muss Application Express diesen über das Netzwerk kontaktieren. Ändern Sie den PL/SQL-Aufruf in der Berichtsdefinition wie folgt:

declare
  v_sql varchar2(32767);
begin
  dbms_debug_jdwp.connect_tcp('192.168.2.1', 4200);
  v_sql := generate_sql(:P1_TABLENAME);
  dbms_debug_jdwp.disconnect;
  return v_sql;
end;

Speichern Sie den Bericht ab und starten Sie die Seite. Sie werden nun feststellen, dass der Browser nun wartet. Dies ist logisch, denn im SQL Developer wartet der Debugger beim von Ihnen festgesetzten Breakpoint auf Ihre Reaktion. Sie können nun durch Klick auf die einzelnen Icons schrittweise durch die Funktion durchgehen und dabei alle Variablen (Bereich Data unten rechts) im Blick behalten.

Abbildung 11: Remote-Debugging mit dem SQL Developer

Sie können sogar, indem Sie im Bereich Data auf einer Variable die rechte Maustaste klicken und Modify Value auswählen, den Inhalt einer Variablen im laufenden Betrieb ändern. Dies ist nützlich bei komplexeren Schleifen, wenn Sie nicht alle Durchläufe einzeln verfolgen möchten.

Remote-Debugging mit dem SQL Developer kann die Fehlersuche ganz massiv beschleunigen; Sie müssen nicht mehr, wie in SQL*Plus, die Application Express-Umgebung simulieren. Ebenso ist es nicht mehr nötig, Debugging-Tabellen oder ähnliche Bildschirmausgaben zu implementieren. Sie können sogar soweit gehen, den Aufruf von DBMS_DEBUG_JDWP.CONNECT_TCP an ein Application Express-Element zu binden und das Debugging so dynamisch ein- und ausschalten. Remote-Debugging ist übrigens nicht nur mit Application Express, sondern auch aus anderen Entwicklungsumgebungen heraus (Java, .NET, PHP, ...) möglich.

Wenn Sie den SQL Developer noch nicht kennen, schauen Sie ihn sich ruhig noch ein wenig genauer an. Application Express und der SQL Developer ergänzen sich sehr gut: Während Sie die Geschäftslogik in PL/SQL-Packages mit dem SQL Developer kodieren, erstellen Sie die Oberfläche mit Application Express.

Zurück zur Community-Seite