Optimisation performance SAP en S/4HANA : méthode projet

En projet SAP, la performance n’est pas un sujet de confort. Elle conditionne la fiabilité des processus, la tenue des SLA, et la perception globale de la solution par le métier. En entretien technique, c’est souvent le point qui sépare un développeur correct d’un consultant senior.

En S/4HANA, les choix d’implémentation se voient immédiatement : HANA amplifie les bons choix (pushdown, requêtes ciblées) et punit les mauvais (boucles, SELECT * et traitements ABAP inutiles).

Les impacts sont souvent mesurables : temps de traitement batch, temps de réponse en transaction, montée en charge, coût d’infrastructure et taux d’erreur. Techniquement, cela se traduit par des requêtes DB mal ciblées, des tables internes surdimensionnées et des parcours de code trop verbeux.

Règle d’or S/4HANA : faire travailler la base. Le code pushdown via CDS Views et Open SQL moderne réduit le volume de données, la latence réseau et la charge applicative.

Flux recommandé
Utilisateur
  |  (filtres UI)
  v
CDS View (projection)
  |  (associations, annotations)
  v
CDS View (interface)
  |  (joins, calculations)
  v
Base HANA
  |  (pushdown, agrégations)

"ABAP 7.50+ : Open SQL ciblé et pushdown
SELECT FROM zso_hdr AS hdr
  INNER JOIN zso_itm AS itm
    ON itm~so_id = hdr~so_id
  FIELDS hdr~so_id,
         hdr~customer,
         SUM( itm~net_amount ) AS net_total
  WHERE hdr~status = @lv_status
    AND hdr~created_on BETWEEN @lv_date_from AND @lv_date_to
  GROUP BY hdr~so_id, hdr~customer
  INTO TABLE @DATA(lt_result).

Dans un projet réel, ce simple pushdown a divisé par 6 un écran de suivi des ventes en remplaçant un traitement ABAP par une agrégation SQL.

• Limiter colonnes et lignes dès le SELECT.
• Privilégier JOINs, GROUP BY et HAVING côté DB.
• Contrôler les index et la sélectivité des conditions.

ABAP 7.50+ offre des syntaxes plus claires, mais la performance se joue sur la structure des tables internes, le tri, et la réduction des boucles.

"Table interne adaptée au besoin
TYPES: BEGIN OF ty_line,
         so_id     TYPE zso_id,
         customer  TYPE kunnr,
         net_total TYPE p LENGTH 16 DECIMALS 2,
       END OF ty_line.

DATA lt_data TYPE HASHED TABLE OF ty_line WITH UNIQUE KEY so_id.

Utiliser une HASHED TABLE avec clé unique évite des READ TABLE O(n) et sécurise les recherches.

• Eviter SELECT dans les boucles, préférer des lectures groupées.
• Utiliser READ TABLE ... BINARY SEARCH sur table triée.
• Réduire la volumétrie avant tout traitement ABAP.

Sur des traitements batch, la mémoire devient souvent le facteur bloquant. Une table interne trop large peut saturer le work process et provoquer des dumps.

• Free explicite des tables volumineuses après usage.
• Eviter les copies inutiles (MOVE-CORRESPONDING sur gros volumes).
• Charger par paquets (PACKAGE SIZE) pour les extractions massives.

"Extraction par paquets
SELECT FROM zso_hdr
  FIELDS so_id, customer, net_total
  INTO TABLE @DATA(lt_hdr)
  PACKAGE SIZE 5000.

  "Traitement
  CLEAR lt_hdr.
ENDSELECT.

L’analyse se fait avec une approche outillée, pas à l’intuition. On commence par isoler le symptôme, puis on affine avec les bons outils.

Workflow d’analyse rapide
Signal utilisateur
  |-> SAT (profil ABAP)
  |-> ST05 (trace SQL)
  |-> SM50/SM66 (WP)
  |-> ST22 (dump)
  v
Synthèse + plan d’action

Voici des scénarios réalistes rencontrés en mission, avec une logique de résolution reproductible.

• SELECT * alors que 5 champs suffisent.
• SELECT dans une boucle sans mise en cache.
• FOR ALL ENTRIES sans contrôle sur table vide.
• Tri côté ABAP quand un ORDER BY suffirait.
• Tables internes standard pour des recherches intensives.

Ces anti-patterns restent les causes principales de ST05 rouge et de SAT saturé.

La performance est un pilier du Clean Core : moins de code custom, plus de standard, plus d’APIs publiées. En S/4HANA, cela passe par ATC, les Released APIs et la conformité ABAP Cloud.

• Limiter les modifications standard pour rester compatible upgrades.
• Utiliser des CDS Views et services exposés par SAP.
• Valider en continu via ATC + SCI.

C’est aussi un argument fort en entretien : vous montrez que la performance est un sujet d’architecture, pas seulement un tuning local.

• Commencer par mesurer : SAT et ST05 avant toute optimisation.
• Pousser le calcul côté HANA via CDS et Open SQL moderne.
• Choisir la bonne structure de tables internes selon l’usage.
• Documenter les gains et sécuriser par ATC/SCI.