Je suis régulièrement sollicité pour résoudre des problèmes de performance sur des reports ou des interfaces.
En premier lieu, j'analyse les requêtes SQL, puis je vérifie la manière dont l'algorithme de traitement des données est implémenté.

Parmi les erreurs les plus classiques, on retrouve la gestion des boucles imbriquées. Prenons un exemple.
Nous voulons lister des données imputation de commande d'achat.
Une première table interne t_ekko contient les données d'en-tête (1000 commandes). Une seconde t_epko contient les données de poste (10 postes par commande = 10 000 postes). Une 3e t_ekkn contient les données imputations (2 imputations par poste = 20 000 imputations).
La manière simple (et anti performante) d'écrire le traitement serait :

LOOP AT t_ekko.
  LOOP AT t_ekpo WHERE ebeln = t_ekko-ebeln.
    LOOP AT t_ekkn WHERE ebeln = t_ekko-ebeln AND ebelp = t_ekpo-ebelp.
*     traitement imputation
    ENDLOOP.
*   traitement poste
  ENDLOOP.
* traitement commande
ENDLOOP.

Si cette syntaxe est rapide à écrire et simple à relire, elle présente l'inconvénient majeur que le LOOP AT txx WHERE fait un "full scan" de la table interne. Chaque ligne sera lue par le moteur pour voir si elle correspond aux critères WHERE.
Ainsi pour un report sur 1000 commandes, ayant chacune 10 postes avec 2 imputations, la table t_ekkn (20 000 entrées) est parcourue 10 000 fois, soit 200 millions de lignes lues !

Pour ce genre de tables, la lecture peut etre synchronisée entre les 3 tables via l'utilisation d'index

DATA : l_index_ekpo TYPE i,
       l_index_ekkn TYPE i.

SORT t_ekko BY ebeln.
SORT t_ekpo BY ebeln ebelp.
SORT t_ekkn BY ebeln ebelp.

LOOP AT t_ekko.
  LOOP AT t_ekpo FROM l_index_ekpo.
    IF t_ekpo-ebeln > t_ekko-ebeln.
      l_index_ekpo = sy-index.
      EXIT.
    ELSEIF t_ekpo-ebeln < t_ekko-ebeln.
       CONTINUE.
     ELSE.
       LOOP AT t_ekkn FROM l_index_ekkn.
         IF t_ekkn-ebeln > t_ekko-ebeln
        OR ( t_ekkn-ebeln = t_ekko-ebeln AND t_ekkn-ebelp > t_ekpo-ebelp ).
          l_index_ekpo = sy-index.
          EXIT.
        ELSEIF t_ekpo-ebeln < t_ekko-ebeln
        OR ( t_ekkn-ebeln = t_ekko-ebeln AND t_ekkn-ebelp < t_ekpo-ebelp ).
          CONTINUE.
        ELSE.
*         traitement imputation
        ENDIF.
      ENDLOOP.
*     traitement poste
    ENDIF.
  ENDLOOP.
* traitement commande
ENDLOOP.

Grâce aux index, chacune des 3 tables n'est parcourue qu'une seule fois, minimisant ainsi au maximum le travail de lecture du moteur ABAP. (soit 30 000 lignes lues pour t_ekkn [Les 2 lignes d'imputations + la première ligne d'imputation du poste suivant])
Néanmoins cette solution présente l'inconvénient d'être assez indigeste (peu lisible) et peut facilement introduire des bugs si elle est mal maitrisée. De plus, il faut que les 3 tables soient triées selon le même axe, ce qui n'est pas forcément possible dans tous les cas.

Aussi il existe une méthode intermédiaire, largement utilisée par SAP. Il s'agit de faire une recherche de la première ligne répondants aux critères, puis une lecture directe par index.

DATA : l_index_ekpo TYPE i,
       l_index_ekkn TYPE i.

SORT t_ekpo BY ebeln.
SORT t_ekkn BY ebeln ebelp.

LOOP AT t_ekko.
  READ TABLE t_ekpo WITH KEY ebeln = t_ekko-ebeln
                    BINARY SEARCH
                    TRANSPORTING NO FIELDS.
  IF sy-subrc = 0.
    l_index_ekpo = sy-tabix.
    LOOP AT t_ekpo FROM l_index_ekpo.
      IF t_ekpo-ebeln NE t_ekko-ebeln.
        EXIT.
      ENDIF.
      READ TABLE t_ekkn WITH KEY ebeln = t_ekko-ebeln
                                 ebelp = t_ekpo-ebelp
                        BINARY SEARCH
                        TRANSPORTING NO FIELDS.
      IF sy-subrc = 0.
        l_index_ekkn = sy-tabix.
        LOOP AT t_ekkn FROM l_index_ekkn.
          IF t_ekkn-ebeln NE t_ekko-ebeln OR t_ekkn-ebelp NE t_ekpo-ebelp.
            EXIT.
          ENDIF.
*         traitement imputation
        ENDLOOP.
      ENDIF.
*     traitement poste
    ENDLOOP.
  ENDIF.
* traitement commande
ENDLOOP.

Un peu moins performante que la syntaxe précédente, cette manière est néanmoins un peu plus simple à écrire (et à relire/comprendre).
Le read table binary search est très performant (recherche dichotomique). Pour t_ekkn contenant 20 000 entrées, seulement 14 lignes sont lues pour trouver la bonne entrée. Le moteur va donc lire 170 000 lignes sur t_ekkn au total (14 pour trouver l'imputation + 2 imputations + la première imputation du poste suivant).

Voici la version ECC (a priori compatible 4.7) de mon requêteur open SQL, nommé ZTOAD, publié le 26 octobre 2009.

Peu de changement dans le code, si ce n'est une uniformisation des noms de variables, et un accroissement du taux de commentaires.

Le lien de téléchargement est disponible sur la fiche principale de l’outil : ZTOAD – Requêteur Open SQL

Lorsque l'on développe un programme spécifique et plus particulièrement une interface, intervient le besoin de gérer des messages d'erreur / alerte / succès et surtout de les sauvegarder pour les restituer ultérieurement.

SAP dispose d'un moyen standard pour gérer les logs applicatifs, y compris pour les programmes spécifiques. Composé d'un ensemble de transactions, programmes, fonctions et tables, cette approche permet d'économiser en coût de développement et de se rattacher à une architecture SAP standard, robuste et complète.

La transaction SLG1 (ou directement le programme SBAL_DISPLAY) permet d'afficher le journal d'application. Via des variantes de sélection, le journal pourra être filtré à convenance, répondant ainsi au besoin de reporting usuel de suivi d'interfaces. Le module fonction BAL_DSP_LOG_DISPLAY permet également d'afficher un log, évitant ainsi d'avoir à gérer un rapport d'exécution d'interface.

SLG1 - Affichage du journal d'application

La transaction SLG0 permet de définir ses propres objets / sous-objets.

Pour créer un log dans un programme spécifique, l'usage classique utilise 3 fonctions :

• BAL_LOG_CREATE qui permet d'initialiser le nouveau log.
• BAL_LOG_MSG_ADD qui permet d'insérer les messages, 1 par 1
• BAL_DB_SAVE qui permet de sauvegarder le log en base de données

Les données sont sauvegardées dans les tables BALHDR et BALM
Il est possible d'associer des objets métiers pour chaque message, afin de contextualiser l'erreur.

La fonction APPL_LOG_DB permet d'extraire l'ensemble des données d'un log (pour export vers un autre système ou reporting avancé par exemple).

Enfin la transaction SLG2 (ou directement le programme SBAL_DELETE) permet de supprimer les logs expirés.

SAP fournit une multitude de modules fonctions pour exploiter le journal d'application. Ces fonctions sont toutes préfixée par BAL_*. Afin de faciliter leur utilisation, plusieurs programmes démo sont également livrés par SAP. Ces programmes sont préfixés par SBAL_DEMO_*

Pour plus d'information sur l'utilisation du journal d'application, la documentation est disponible en exécutant le programme SBAL_DOCUMENTATION

Pour exemple, un petit programme qui permet de sauvegarder une entrée dans le journal d'application puis de l'afficher.

* Data pour le log
DATA : s_log_hdr TYPE bal_s_log,
       w_log_hnd TYPE balloghndl,
       t_log_hnd TYPE bal_t_logh,
       s_log_msg TYPE bal_s_msg.

* Ecriture En-tete du log
CLEAR s_log_hdr.
s_log_hdr-object        = 'ZINTERFACE'.
s_log_hdr-subobject     = 'COMMANDES'.
s_log_hdr-extnumber     = 'INT CMD RETOUR PIECE'.
s_log_hdr-aldate_del    = sy-datum + 30. "effacement apres 30j
s_log_hdr-aluser        = sy-uname.
s_log_hdr-alprog        = sy-repid.
s_log_hdr-altcode       = sy-tcode.
s_log_hdr-del_before    = 'X'.

CALL FUNCTION 'BAL_LOG_CREATE'
  EXPORTING
    i_s_log                 = s_log_hdr
  IMPORTING
    e_log_handle            = w_log_hnd
  EXCEPTIONS
    log_header_inconsistent = 1
    OTHERS                  = 2.
IF sy-subrc <> 0.
* error
ENDIF.

* Ecriture d'un message d'erreur
CLEAR s_log_msg.
s_log_msg-msgty = 'E'.
s_log_msg-msgid = 'V1'.
s_log_msg-msgno = '302'.
s_log_msg-msgv1 = '1000125423'. "param : doc number

CALL FUNCTION 'BAL_LOG_MSG_ADD'
  EXPORTING
    i_log_handle     = w_log_hnd
    i_s_msg          = s_log_msg
  EXCEPTIONS
    log_not_found    = 1
    msg_inconsistent = 2
    log_is_full      = 3
    OTHERS           = 4.
IF sy-subrc <> 0.
* error
ENDIF.

* Sauvegarde du log
APPEND w_log_hnd TO t_log_hnd.
CALL FUNCTION 'BAL_DB_SAVE'
  EXPORTING
    i_client         = sy-mandt
    i_t_log_handle   = t_log_hnd
  EXCEPTIONS
    log_not_found    = 1
    save_not_allowed = 2
    numbering_error  = 3
    OTHERS           = 4.
IF sy-subrc <> 0.
* error
ENDIF.

* Affichage du log
CALL FUNCTION 'BAL_DSP_LOG_DISPLAY'
  EXPORTING
    i_t_log_handle       = t_log_hnd
  EXCEPTIONS
    profile_inconsistent = 1
    internal_error       = 2
    no_data_available    = 3
    no_authority         = 4
    OTHERS               = 5.
IF sy-subrc <> 0.
* error
ENDIF.

L'instruction

MOVE-CORRESPONDING A TO B

permet de copier les champs d'une structure A vers les champs d'une structure B, pour peu qu'ils portent le même nom. Les champs de A n'existant pas dans B sont ignorés.

Vous pouvez écrire la même chose en utilisant field symbol et abap objet :

DATA : lo_descr TYPE REF TO cl_abap_structdescr,
       ls_compx type abap_compdescr.
lo_descr ?= cl_abap_typedescr=>describe_by_data( A ).
LOOP AT lo_descr->components INTO ls_compx.
  CONCATENATE 'A-' ls_compx-name INTO lv_fsname.
  ASSIGN (lv_fsname) TO <lfs_component1>.
  CHECK sy-subrc = 0
  CONCATENATE 'B-' ls_compx-name INTO lv_fsname.
  ASSIGN (lv_fsname) TO <lfs_component2>.
  CHECK sy-subrc = 0
  <lfs_component2> = <lfs_component1>.
ENDLOOP.

Et la vous dites : "Waou c'est merveilleux, mais pourquoi irai-je remplacer une ligne de code simple, lisible et éprouvée contre 10 lignes aux performances incertaines ?"

Dans l'exemple simpliste présenté ici cela n'a aucun intérêt. En revanche, quand les structures A et B sont assez larges, et qu'il y a des règles spéciales à appliquer sur certains champs, cela peut s'avérer intéressant : quand vous ne voulez pas écraser un champs de B par son homonyme de A ou que vous voulez mettre un champs de A dans un champs portant un autre nom dans B...

A ne surtout pas utiliser de manière systématique, mais peut être utile lorsque les règles sont complexes ;-)