ABAP - Dump erzeugen

Inhaltsverzeichnis

• Einleitung
• Erzeugung
• Inline
• Exception
• Auswertung
• Information
• Zugriff 
• Bereiche
• Vollständiges Beispiel
• Fazit

In diesem Artikel schauen wir uns an, wie du in deinem Code einen Abbruch erzeugst und wie dieser dir beim Finden der Fehler helfen kann.

 

Einleitung

Ein Dump stellt normalerweise ein schwerwiegendes Problem im System dar, denn eine Programm oder eine Verarbeitung ist abgestürzt, was vielleicht an Fehlern im Code liegt oder an nicht bedachten Fällen im System. Ein Dump erzeugt gleichzeitig ein Log, welches wir auch nutzen können, um Analysen durchzuführen und den Fehler zu finden. In manchen Situationen macht es deshalb Sinn, proaktiv einen Fehler zu erzeugen, um später die Analyse zu vereinfachen oder auf Probleme im System hinzuweisen.

 

Erzeugung

Für die Erzeugung von Dumps gibt es ein Statement, das wir einfach verwenden können. Schauen wir uns dazu zwei verschiedene Use Cases an.

 

Inline

Wollen wir einen Fehler inline erzeugen, können wir das über das Statement RAISE SHORTDUMP tun. Dabei müssen wir eine Exception-Instanz an das Statement übergeben, um den Dump zu erzeugen. In diesem Fall können wir auch inline die Exception generieren, während wir den Dump auslösen wollen. Über das Keyword NEW und den Namen der Exception generieren wir eine neue Instanz und übergeben diese direkt an das Statement. Ab dieser Stelle wird dann auch der Kurzdump erzeugt und das Programm beendet.

RAISE SHORTDUMP NEW cx_sy_zerodivide( ).

 

Exception

Haben wir eine bestehende Exception, können wir diese auch direkt verwenden, um den Kurzdump zu erzeugen und diese ins Protokoll zu übernehmen. Dies macht vor allem Sinn, wenn wir an Stellen kommen, wo wir vielleicht gar nicht mehr reagieren können oder wo es einfach keinen Sinn mehr macht, das Programm weiterlaufen zu lassen. Nehmen wir den einfachen Fall, dass wir zum Beispiel eine neue UUID erzeugen wollen: In diesem Fall ist immer ein TRY/CATCH nötig, um eine Exception abzufangen. Doch sollte diese Exception geworfen und keine UUID erzeugt werden, sollte eigentlich das komplette Programm beendet werden, da hier ein Sichern nicht mehr möglich ist. In so einem Fall können wir dann die abgefangene Exception nehmen und direkt damit einen Kurzdump auslösen.

TRY.
    DATA(new_uuid) = cl_system_uuid=>create_uuid_x16_static( ).

  CATCH cx_uuid_error INTO DATA(error).
    RAISE SHORTDUMP error.
ENDTRY.

 

Neben der UUID könnte ein typischer weiterer Fall sein, wenn wir zum Beispiel ein Application Log schreiben wollen, die Instanziierung aber gar nicht möglich ist. Damit würde es keinen Sinn mehr ergeben weiterzumachen, da wir auch keine Fehlerlogs oder Sonstiges schreiben können. Grundsätzlich könnten wir vielleicht noch eine Mail erzeugen, aber ein Dump ist natürlich sehr auffällig im System.

Ein zweiter Fall ist der Application Job. Wird im Application Job eine Exception ausgelöst, erhalten wir oft keine weiteren Informationen im Protokoll. Deshalb wissen wir nicht genau: Wieso wurde die Exception ausgelöst und was ist der Inhalt der Meldung? Hier könnten wir zum Beispiel einen Dump im System erzeugen und damit den Kontext des aktuellen Application Jobs einsehen.

 

Auswertung

Schauen wir kurz noch auf den Bereich der Auswertung und wie du die Dumps im System lesen kannst, um weitere Informationen daraus entnehmen zu können.

 

Information

Bist du in den ABAP Development Tools für Eclipse angemeldet und hast deine Feed-Reader eingestellt, erhältst du eine Information in Form eines Pop-ups im unteren rechten Bereich deiner IDE. Hier hast du die Möglichkeit, direkt in das Protokoll zu springen oder, in manchen Fällen, wenn er gerade erst erzeugt wurde, sogar den Debugger zu starten, um dir den Fehler noch einmal im Detail anzuschauen.

 

Zugriff 

Du öffnest also entweder das Protokoll über den Feed-Reader oder über das Pop-up, über das du die Information eines Dumps erhalten hast. Es wird nun ein neues Objekt in der IDE angezeigt. In der Grundauswahl bekommst du den komprimierten Dump, hier sind bereits wichtige Informationen extrahiert und für dich aufbereitet. Im Grunde musst du nicht so viel lesen. Wir erhalten hier bereits erste Informationen, um welche Exception es sich handelt, in welchem Programm abgebrochen wurde und was der Kontext dazu war.

 

 

Im unteren Teil kannst du dann auch noch in den klassischen Dump wechseln. Dort erhältst du die Informationen aufbereitet, wie sie in der Transaktion ST22 vorherrschen. In der Transaktion kannst du grundsätzlich die Dumps auch immer noch sehen, zumindest solange du auf einem On-Prem oder Private-Cloud System arbeitest. In der unaufbereiteten Form stehen viel mehr Informationen, wenn du einmal in die Tiefe des Fehlers absteigen willst und auf den ersten Blick nicht ersichtlich ist, wo der Dump entstanden ist.

 

Bereiche

Werfen wir noch kurz einen Blick auf die verschiedenen Bereiche, die du innerhalb eines Dumps findest, und wie sie dir helfen können, um an weitere Informationen zu kommen.

• Header Info - Hier bekommst du die Informationen kurz zusammengefasst: was für ein Fehler aufgetreten ist (zum Beispiel ein Runtime Error), ob dieser durch eine Exception ausgelöst wurde, auf welchem System er stattgefunden hat, zu welcher Uhrzeit und auf welchem Server.
• What happened - In diesem Bereich bekommst du meistens einen längeren Text zu lesen, was eigentlich im Grunde passiert ist. In unserem Beispiel: dass ein RAISE SHORTDUMP oder THROW SHORTDUMP ausgelöst wurde, um einen Kurzdump zu erzeugen.
• Error Analysis - In der Fehleranalyse wird kurz darauf hingewiesen, wieso es zum Programmabbruch gekommen ist; in diesem Fall, dass eine Ausnahme ausgelöst wurde.
• Information - Innerhalb der Informationen findest du weitere Details, wo der Abbruch stattgefunden hat: welches Include, welche Methode, welche Zeile.
• Source Code Extract - In diesem Bereich erhältst du einen Codeausschnitt mit der genauen Abbruchstelle und siehst auch den Code außen herum, um zu erkennen, wie er aufgerufen wurde.
• Active Calls - Im Bereich der Active Calls findest du den Aufruf-Stack der verschiedenen Objekte bis zu deinem Objekt, an dem der Abbruch stattgefunden hat. So kannst du sehen, aus welchem Standard du gekommen bist oder aus welchen verschiedenen Klassen deine Implementierung aufgerufen wurde.

 

Vollständiges Beispiel

Hier findest du die vollständige Klasse und die Ressourcen, die wir in unserem Artikel verwendet haben. Du kannst die Klasse in deinem System wiederverwenden, um weitere Einstellungen zu prüfen.

CLASS zcl_bs_demo_dump DEFINITION
  PUBLIC FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    INTERFACES if_oo_adt_classrun.
ENDCLASS.


CLASS zcl_bs_demo_dump IMPLEMENTATION.
  METHOD if_oo_adt_classrun~main.
    RAISE SHORTDUMP NEW cx_sy_zerodivide( ).

    TRY.
        DATA(new_uuid) = cl_system_uuid=>create_uuid_x16_static( ).
        out->write( |UUID: { new_uuid }| ).

      CATCH cx_uuid_error INTO DATA(error).
        RAISE SHORTDUMP error.
    ENDTRY.
  ENDMETHOD.
ENDCLASS.

 

Fazit

Dumps im System sind nicht nur ein Problem, zumindest, wenn sie selten auftreten, sondern können auch genutzt werden, um weitere Informationen, Kontext und Hinweise auf Fehlersituationen bereitzustellen. In der klassischen ABAP-Welt konnte zum Beispiel auch eine Message vom Type X erzeugt werden, um Programme zum Abbruch zu zwingen und einen Dump zu erzeugen. In der modernen ABAP Cloud Welt würden wir hier das Statement RAISE SHORTDUMP einsetzen.

 

Weitere Informationen:
SAP Help - RAISE SHORTDUMP