Debogage ABAP Cloud : Outils et techniques 2025

Le debogage dans ABAP Cloud est different de celui dans Classic ABAP. Ce guide vous montre les nouveaux outils et techniques.

Qu’est-ce qui est different dans ABAP Cloud ?

NE fonctionne PLUS

• Commande de debogage /h
• Debogueur SAP GUI (SE38, SE80)
• Instruction BREAK-POINT
• Debogage Dynpro
• Acces direct a la BD dans le debogueur

Nouveaux outils

• Debogueur ADT (Eclipse)
• Console ABAP (cl_demo_output)
• Feed Reader (Jobs en arriere-plan)
• Application Log (BAL)
• SQL Trace (Performance)

1. Debogueur ADT (Outil principal)

Demarrer le debogueur

Methode 1 : Definir un point d’arret

1. Dans ADT : Double-cliquez sur le numero de ligne - Point d’arret (point bleu)
2. Executez le programme (F9 ou Preview)
3. Le debogueur s’arrete au point d’arret

Methode 2 : Run As - ABAP Application (Debug)

1. Clic droit sur la classe/programme
2. Debug As - ABAP Application

Disposition du debogueur

┌─────────────────────────────────┐
│  Code (ligne actuelle marquee)  │
├─────────────────────────────────┤
│  Variables (valeurs des var.)   │
├─────────────────────────────────┤
│  Breakpoints (tous les points)  │
├─────────────────────────────────┤
│  Call Stack (historique appels) │
└─────────────────────────────────┘

Raccourcis les plus importants

Inspecter les variables

METHOD calculate.
  DATA(lv_a) = 5.
  DATA(lv_b) = 3.
  DATA(lv_result) = lv_a + lv_b.  " Point d'arret ici

  " Dans l'onglet Variables :
  " lv_a = 5
  " lv_b = 3
  " lv_result = 8
ENDMETHOD.

Modifier les variables :

1. Clic droit sur la variable - Change Value
2. Entrez la nouvelle valeur
3. Continuez le debogage avec la valeur modifiee

Watchpoints

S’arrete quand la variable change :

1. Clic droit sur la variable - Toggle Watchpoint
2. Le debogueur s’arrete a chaque modification

Points d’arret conditionnels

S’arrete uniquement si la condition est remplie :

1. Clic droit sur le point d’arret - Breakpoint Properties
2. Condition : lv_id = '12345'
3. S’arrete uniquement quand lv_id a cette valeur

2. Console ABAP (Sortie pendant le developpement)

Au lieu de WRITE ou des sorties de debug :

METHOD process_data.
  " Sortie simple
  cl_demo_output=>display( 'Debut du traitement' ).

  " Afficher une variable
  cl_demo_output=>write( |ID Client : { lv_customer_id }| ).

  " Afficher une table
  cl_demo_output=>write( lt_customers ).

  " Sortie finale
  cl_demo_output=>display( ).
ENDMETHOD.

Sortie :

• Apparait dans l’onglet Console dans ADT
• A utiliser uniquement en developpement !
• En production : utiliser Application Log

Avantages :

• Plus rapide que le debogueur
• Pour les structures de donnees complexes
• Reste dans le log (defilement possible)

3. Logging avec Application Log

Pour le code productif :

METHOD process_order.
  TRY.
      " Creer un log
      DATA(lo_log) = cl_bali_log=>create_with_header(
        header = cl_bali_header_setter=>create(
          object      = 'ZORDERS"
          subobject   = 'PROCESS"
          external_id = |Order { iv_order_id }|
        )
      ).

      " Message d'information
      lo_log->add_item(
        item = cl_bali_free_text_setter=>create(
          severity = if_bali_constants=>c_severity_information
          text     = |Traitement de la commande { iv_order_id }|
        )
      ).

      " Traitement...

      " Message de succes
      lo_log->add_item(
        item = cl_bali_free_text_setter=>create(
          severity = if_bali_constants=>c_severity_status
          text     = 'Commande traitee avec succes"
        )
      ).

      " Enregistrer le log
      cl_bali_log_db=>get_instance( )->save_log( log = lo_log ).

    CATCH cx_bali_runtime INTO DATA(lx_error).
      " Gestion de l'erreur
  ENDTRY.
ENDMETHOD.

Consulter le log :

• Transaction SLG1 (Classic)
• Application Fiori : “Application Logs”

Niveaux de severite :

• c_severity_error - Erreur (rouge)
• c_severity_warning - Avertissement (jaune)
• c_severity_information - Info (bleu)
• c_severity_status - Statut (vert)

4. SQL Trace (Debogage de performance)

Probleme : Trouver les SELECT lents

Activer SQL Trace

Dans ADT :

1. Run - Run Configurations
2. Onglet Trace Requests
3. Activer SQL Trace
4. Executer le programme

Analyser la trace

La console SQL s’ouvre :

SELECT * FROM kna1
  Duration: 1.2s  NON OK - LENT !
  Rows: 1,000,000

SELECT name1 FROM kna1
  WHERE kunnr = '12345"
  Duration: 0.001s  OK - Rapide
  Rows: 1

Optimisation :

• Eviter SELECT *
• FOR ALL ENTRIES avec table vide
• Champs explicites
• WHERE sur les champs indexes

5. Feed Reader (Jobs en arriere-plan)

Probleme : Deboguer les jobs en arriere-plan

Configuration

1. Demarrer le job (Application Fiori / SM37)
2. Dans ADT : Window - Show View - Feed Reader
3. Entrer l’URL du feed :

   https://<system>/sap/bc/adt/runtime/traces/abaplogs

Sortie

Le Feed Reader affiche :

• Sorties de console
• Application Logs
• Erreurs d’execution

Mises a jour en direct pendant l’execution du job !

6. Strategies de debogage sans debogueur

Strategie 1 : Tests unitaires

Au lieu de deboguer : ecrire un test

METHOD test_calculate_discount.
  " Given
  DATA(lv_amount) = 1000.

  " When
  DATA(lv_discount) = zcl_pricing=>calculate_discount( lv_amount ).

  " Then
  cl_abap_unit_assert=>assert_equals(
    act = lv_discount
    exp = 100
    msg = |Attendu 100, obtenu { lv_discount }|  " Info de debug !
  ).
ENDMETHOD.

Avantage : Reproductible, automatise

Strategie 2 : Assertions defensives

METHOD process_order.
  " Verifier la precondition
  ASSERT iv_order_id IS NOT INITIAL.

  " Logique metier
  DATA(lv_customer) = get_customer( iv_order_id ).

  " Verifier la postcondition
  ASSERT lv_customer IS BOUND.
ENDMETHOD.

En production : ASSERT est ignore (actif uniquement en mode Debug)

Mieux pour la production : Exceptions

IF lv_customer IS NOT BOUND.
  RAISE EXCEPTION TYPE zcx_customer_not_found.
ENDIF.

Strategie 3 : Framework de logging

Wrapper de logging personnalise :

CLASS zcl_logger DEFINITION.
  PUBLIC SECTION.
    CLASS-METHODS log
      IMPORTING iv_level TYPE string DEFAULT 'INFO"
                iv_text  TYPE string.
ENDCLASS.

CLASS zcl_logger IMPLEMENTATION.
  METHOD log.
    " En Dev : Console
    IF sy-sysid = 'DEV'.
      cl_demo_output=>write( |[{ iv_level }] { iv_text }| ).
    ELSE.
      " En Prod : Application Log
      " ... Code BAL ...
    ENDIF.
  ENDMETHOD.
ENDCLASS.

" Utilisation
zcl_logger=>log( iv_level = 'DEBUG"
                 iv_text  = |Traitement du client { lv_id }| ).

7. Scenarios de debogage frequents

Scenario 1 : Exception dans RAP

Probleme : La validation echoue, mais pourquoi ?

METHOD validateIsbn.
  READ ENTITIES OF zi_book IN LOCAL MODE
    ENTITY Book
      FIELDS ( Isbn )
      WITH CORRESPONDING #( keys )
    RESULT DATA(lt_books).

  LOOP AT lt_books INTO DATA(ls_book).
    " Sortie de debug
    cl_demo_output=>write( |Verification ISBN : { ls_book-Isbn }| ).

    IF strlen( ls_book-Isbn ) <> 13.
      cl_demo_output=>write( 'ISBN invalide - longueur incorrecte' ).

      APPEND VALUE #( ... ) TO reported-book.
    ENDIF.
  ENDLOOP.

  cl_demo_output=>display( ).
ENDMETHOD.

Scenario 2 : La vue CDS renvoie des donnees incorrectes

Strategie :

1. Console SQL : Interroger directement la vue CDS
2. Data Preview : Dans ADT clic droit sur la vue - Open With - Data Preview
3. Verifier les tables source : Les donnees brutes sont-elles correctes ?

Scenario 3 : Probleme de performance

Procedure :

1. Activer SQL Trace
2. Identifier les SELECT lents
3. Console ABAP : Journaliser les timestamps

DATA(lv_start) = cl_abap_context_info=>get_system_time( ).

" Operation lente
SELECT ... INTO TABLE lt_data.

DATA(lv_end) = cl_abap_context_info=>get_system_time( ).
cl_demo_output=>write( |Duree : { lv_end - lv_start } microsecondes| ).

8. Bonnes pratiques de debogage

A FAIRE

1. Points d’arret avec parcimonie (pas 50 !)
2. Points d’arret conditionnels pour les grands ensembles de donnees
3. Tests unitaires au lieu de deboguer en direct
4. Logging dans le code productif
5. SQL Trace pour la performance

A NE PAS FAIRE

1. Deboguer en production (uniquement en dernier recours !)
2. Laisser BREAK-POINT dans le code
3. Sortie console en production
4. Utiliser le debogueur comme seul outil

9. Vue d’ensemble des outils

Resume

Workflow de debogage ABAP Cloud :

1. Ecrire des tests unitaires
   ↓ (si le test echoue)
2. Utiliser le debogueur ADT
   ↓ (probleme de performance ?)
3. Activer SQL Trace
   ↓ (en production ?)
4. Analyser Application Log

Changement de mentalite :

• Classic ABAP : Debogueur d’abord
• ABAP Cloud : Tests d’abord, Logging, puis Debogueur

Voir aussi :

• Tests unitaires ABAP
• Optimisation des performances ABAP Cloud
• Tutoriel RAP Partie 3 : Bonnes pratiques

Bon debogage !