En bref
Migrer vers HANA ne suffit pas pour gagner en performance. Il faut refondre le code ABAP selon le paradigme Code-to-Data : déléguer agrégations, jointures et calculs à la base HANA via les CDS Views et les AMDP. Bien appliqué, ce changement de paradigme divise les temps de traitement par 10 à 100 sur les programmes critiques. Cet article explique quand utiliser CDS, quand utiliser AMDP, quand garder de l'ABAP, et comment mesurer les gains.
Beaucoup d'entreprises ont migré vers la base de données HANA en espérant des gains de performance magiques. Pourtant, certains rapports spécifiques mettent toujours des heures à tourner. La raison est simple : l'infrastructure a changé, mais le code ABAP, lui, est resté coincé dans les années 2000.
Le problème : un ABAP conçu pour les bases relationnelles classiques
Le vieux réflexe ABAP consistait à rapatrier massivement les données de la base vers le serveur d'application via des tables internes, puis à les traiter en boucle (LOOP AT ... INTO ...). Avec une base de données classique (Oracle, DB2, MaxDB), où la base était optimisée pour la persistance et le serveur d'application pour le calcul, cette répartition avait du sens.
Avec HANA, c'est exactement l'inverse. La base est conçue pour le calcul en mémoire massivement parallèle (colonnes, compression, vectorisation). Continuer à rapatrier des millions de lignes pour les traiter en ABAP, c'est utiliser une Ferrari pour aller chercher le pain à pied.
Le paradigme Code-to-Data (Code Pushdown)
Le paradigme Code-to-Data consiste à déplacer le calcul vers la donnée plutôt que l'inverse. En pratique :
- Déléguer les agrégations (
SUM,AVG,COUNT) à la base ; - Faire les jointures côté base via Open SQL avancé ou CDS Views ;
- Filtrer le plus tôt possible (clause
WHEREprécise) pour réduire le volume retourné ; - N'utiliser le serveur d'application que pour la logique métier complexe non exprimable en SQL.
C'est exactement ce que SAP appelle aussi Code Pushdown.
Les armes du Code-to-Data : CDS Views et AMDP
Deux technologies natives ABAP permettent d'appliquer ce paradigme.
CDS Views (Core Data Services)
Les CDS Views sont des vues riches définies au niveau du dictionnaire ABAP (DDIC) mais exécutées par HANA. Elles dépassent largement les anciennes vues de base de données :
- Calculs mathématiques intégrés (
CASE, conversions, formules) ; - Annotations sémantiques qui pilotent le comportement Fiori (UI, Search, Analytics) ;
- Associations entre entités (équivalent jointure mais navigable par les clients) ;
- Vérifications d'autorisations via Access Controls (DCL) ;
- Conversions de devises et d'unités intégrées ;
- Exposition automatique en OData V4 via annotation, base du modèle RAP.
Une CDS View est consommable directement en ABAP via Open SQL (SELECT FROM zcds_view), mais aussi par Fiori Elements, par les rapports analytiques, et par les API externes.
AMDP (ABAP Managed Database Procedures)
Quand la logique dépasse les capacités déclaratives des CDS Views (besoins de boucles, de variables intermédiaires, de procédures complexes), les AMDP prennent le relais. Une AMDP est une méthode de classe ABAP dont le corps est écrit en SQLScript (langage natif HANA, dérivé du SQL standard).
L'avantage clé : le développeur reste dans le monde ABAP (transport, autorisations, debug intégré) tout en exécutant du code natif HANA, donc avec des performances maximales.
Quand utiliser quoi ?
| Besoin | Technologie recommandée |
|---|---|
| Lecture, jointure, agrégation de tables standard, exposition OData | CDS View |
| Calcul complexe, boucles, transformation de données massives | AMDP en SQLScript |
| Logique métier nécessitant des appels à des modules fonctions, BAPI, événements | ABAP classique avec Open SQL optimisé |
| Rapport analytique avec drill-down, filtres dynamiques | CDS View analytique + Fiori Analytical Page |
| Transformation de masse pour interface batch | AMDP ou CDS Table Functions |
Anti-patterns à éviter sur HANA
Refondre du code ABAP pour HANA, c'est aussi désapprendre certains réflexes :
- Le
SELECT *systématique. HANA est en colonne. Sélectionner uniquement les champs utiles divise drastiquement le volume retourné. - Les
SELECTen boucle (« nested loops »). Remplacer parFOR ALL ENTRIESou mieux, par une CDS View avec association. - Le tri en ABAP après lecture. Utiliser
ORDER BYcôté base. - Les agrégations manuelles en ABAP avec compteurs et accumulateurs. Préférer
SUM, GROUP BYen SQL. - Les vues classiques (SE11) pour les nouveaux développements. Toujours préférer les CDS Views.
Outils de mesure et de tuning
L'optimisation HANA est une démarche scientifique : on mesure, on optimise, on remesure. Trois outils sont incontournables :
- Transaction
SAT(ABAP Runtime Analysis) : profiling complet d'un programme, qui identifie les goulots d'étranglement. - Transaction
ST05(Performance Trace) : trace des accès base de données, identifie les requêtes lentes ou redondantes. - HANA Plan Visualizer (PlanViz) dans Eclipse : analyse visuelle d'un plan d'exécution SQL côté HANA, indispensable pour optimiser une AMDP complexe.
La règle d'or : avant tout chantier d'optimisation, mesurer la baseline. Sans baseline, le gain n'est qu'une affirmation marketing.
Cas Criteo : optimisation des flux interco
Lors d'une mission pour Criteo (adtech, publicité programmatique), l'optimisation de processus lourds liés aux flux intercompanies et l'automatisation associée ont permis une réduction des opérations manuelles estimée à 400 jours/homme cumulés. La refonte a combiné :
- Des CDS Views pour les états de rapprochement multi-sociétés ;
- Des AMDP pour les calculs de réconciliation complexes (rapprochements n vers m) ;
- Une simplification des batchs nocturnes : ce qui prenait 4 heures en ABAP séquentiel s'exécute en moins de 15 minutes en Code-to-Data.
Sur HANA, la performance n'est pas un sujet d'infrastructure. C'est un sujet d'écriture du code.
Méthodologie de migration vers le Code-to-Data
Refondre tout son code n'est ni nécessaire ni réaliste. Une approche pragmatique en quatre étapes :
- Identifier le top 20. Lister les programmes les plus consommateurs de ressources (transaction
STADou outils SAP EarlyWatch). - Mesurer la baseline. Profiler chaque programme cible avec SAT/ST05 sur un volume de production représentatif.
- Refondre par lot. Reprendre 3 à 5 programmes par sprint, avec validation des gains avant passage au lot suivant.
- Capitaliser. Documenter les patterns réutilisables (templates de CDS Views, classes AMDP utilitaires).
Questions fréquentes
Faut-il être en S/4HANA pour utiliser CDS et AMDP ?
Non. Les CDS Views et les AMDP sont disponibles dès SAP NetWeaver 7.40 SP05 sur base HANA, donc bien avant S/4HANA. Tout client en ECC sur HANA peut déjà appliquer le paradigme Code-to-Data.
Quelle formation pour un développeur ABAP qui veut maîtriser le Code-to-Data ?
Comptez environ 5 jours de formation initiale (CDS Views, AMDP, SQLScript de base) suivis de 2 à 3 mois d'application encadrée sur des cas réels. La courbe d'apprentissage est réelle mais accessible à tout développeur ABAP confirmé.
Le Code-to-Data fonctionne-t-il avec d'anciens programmes en Module Pool ?
Les techniques s'appliquent à toutes les couches d'accès aux données. On peut introduire des CDS Views et des AMDP dans des programmes existants (Module Pool, Reports, BAdI) sans tout réécrire.
Peut-on appeler une AMDP depuis du SQL classique ?
Oui via les CDS Table Functions, qui exposent une AMDP comme une vue interrogeable en Open SQL. C'est utile pour combiner la puissance d'une procédure et la simplicité d'une CDS View.
Quels gains de performance peut-on espérer concrètement ?
Sur des programmes mal écrits initialement, les gains atteignent fréquemment un facteur 10 à 100. Sur du code déjà optimisé en Open SQL, les gains se situent entre 2 et 5. La règle : plus le code initial est mauvais, plus le gain est spectaculaire.
Vos rapports Z prennent trop de temps à s'exécuter sur HANA ?
Demander un tuning de performance