Introduction : le Go-Live, moment de vérité de la Basis
Il y a quelque chose de très particulier dans un Go-Live SAP. Pendant dix-huit mois, les equipes projet debattent de configuration fonctionnelle, de specifications, de tests d'integration. Puis arrive le jour J, et c'est la Basis qui tient le système a bout de bras. Si la couche technique n'est pas taillee pour la charge reelle, tout le reste s'effondre. J'ai vu des projets impeccables au niveau fonctionnel echouer dans les trois premiers jours de production parce qu'un parametre de work process etait mal dimensionne, ou parce qu'un buffer ABAP debordait en continu.
Dans cet article, je reviens sur les dix leviers Basis que je vérifié systématiquement avant chaque mise en production, que ce soit sur S/4HANA Private Cloud Edition, sur On-Premise, ou sur une plateforme hybride avec BTP. Les exemples chiffres viennent de projets reels menes dans l'énergie, la defense et l'industrie sur les dernières années.
Levier 1 : le dimensionnement des work processes
Comprendre les types de WP
SAP distingue six types de work processes : DIA (dialog), UPD (update V1), UP2 (update V2), BTC (batch), SPO (spool) et ENQ (enqueue). Chacun consomme de la memoire, chacun a un role spécifique. Le mauvais reflexe consiste a multiplier les DIA en pensant absorber la charge : cela reduit en fait les performances globales parce que chaque WP ajoute une surcharge memoire significative.
La règle empirique que j'applique est la suivante, pour un serveur d'application de 64 GB de RAM dedies a SAP :
- rdisp/wp_no_dia = 20 à 30 (selon le nombre d'utilisateurs concurrents)
- rdisp/wp_no_btc = 10 à 15 (plus si jobs massifs la nuit)
- rdisp/wp_no_upd = 4 à 6
- rdisp/wp_no_upd2 = 2 à 3
- rdisp/wp_no_enq = 1 (toujours un seul sur le serveur central)
- rdisp/wp_no_spo = 2 à 4
Le piège du ratio DIA/BTC
Chez un gestionnaire de reseau énergétique, le Go-Live avait ete préparé avec 40 DIA et 5 BTC. Des le deuxième jour, la file d'attente batch explosait : les traitements de releve de compteurs prévus pour s'executer entre 23h et 5h debordaient jusqu'à 11h du matin, bloquant les jobs de facturation. La solution a ete de rebasculer vers 25 DIA et 15 BTC après observation fine de la charge reelle dans SM50 et SM66.
La surveillance via SM50 et SM66
SM50 montre les WP du serveur courant, SM66 les WP de tous les serveurs d'application. Pendant les 72 heures après Go-Live, un membre de l'equipe Basis doit monitorer ces transactions en continu, avec un seuil d'alerte a 80% de WP occupes. Au-dela, on bascule immediatement des DIA vers des BTC ou on redemarre les sessions fantomes.
Levier 2 : sizing memoire HANA, la zone critique
Le calcul reel, pas le calcul Quick Sizer
SAP Quick Sizer fournit des estimations basees sur le nombre d'utilisateurs et de documents. Dans la pratique, il sous-estime fréquemment les besoins memoire HANA de 30 à 50% pour des systèmes charges en données historiques. La formule que j'utilise :
- Taille memoire HANA = (taille totale row store + column store après compression) x 2 + 50 GB overhead
Le facteur 2 couvre les besoins de delta store, de processing, et laisse une marge pour les pics. Pour un système S/4HANA avec 4 TB de données compressees, je recommandé au minimum 8 TB de RAM, pas 6 TB comme le suggere parfois Quick Sizer.
Les parametres critiques
- global_allocation_limit : plafond de memoire que HANA peut allouer. A fixer a 90% de la RAM physique sur un serveur dedie.
- statement_memory_limit : plafond par requete. Commencer a 50 GB et ajuster selon les explosions constatees dans M_EXPENSIVE_STATEMENTS.
- PHYS_MEMSIZE cote serveur d'application ABAP : doit être explicite et cohérent avec la RAM disponible, sinon SAP applique des heuristiques dangereuses.
Le cas defense
Sur un projet pour un industriel de la defense, le système S/4HANA 2023 passait en production avec 3 TB de RAM HANA pour 2,1 TB de données. Après deux semaines, les pics de memoire atteignaient 2,9 TB en periode de cloture mensuelle. Nous avons du ajouter 1 TB en urgence pour éviter les out-of-memory sur les requetes de consolidation financiere. Lecon : toujours dimensionner pour le pire mois, pas pour la moyenne.
Levier 3 : les buffers ABAP, souvent oublies
ST02, le tableau de bord indispensable
La transaction ST02 affiche l'état des buffers ABAP : Table buffer, Program buffer, CUA buffer, Screen buffer, etc. La colonne critique a surveiller est "Swaps" : toute valeur croissante indique que le buffer est trop petit et que SAP recharge sans cesse des objets depuis la base.
Les seuils que je me fixe :
- Program buffer hit ratio > 98%
- Table buffer swaps < 1000 par jour
- CUA buffer fill < 70%
Si un seul de ces critères n'est pas respecte, il faut augmenter le parametre correspondant (abap/buffersize pour le program buffer, zcsa/table_buffer_area pour les tables).
L'exemple du program buffer sous-dimensionne
Chez un acteur du BTP, j'ai observe après Go-Live un program buffer a 400 MB avec un hit ratio de 92%. Les utilisateurs se plaignaient de lenteurs sur les transactions métier Fiori. En passant abap/buffersize de 400000 à 1200000 (1,2 GB), le hit ratio est remonte a 99% et les temps de reponse Fiori ont chute de 40%.
Levier 4 : les parametres memoire par session
Les quatre parametres qui comptent
- ztta/roll_area : memoire roll par work process, typiquement 6 500 000 (6,5 MB)
- ztta/roll_extension : extension autorisee, 2 000 000 000 (2 GB) sur un système bien dote
- abap/heap_area_dia : heap max pour un WP dialog, 2 000 000 000
- abap/heap_area_total : heap total pour l'ensemble des WP, 4 000 000 000 à 8 000 000 000
Si abap/heap_area_total est mal calibre, les gros traitements provoquent des TSV_TNEW_PAGE_ALLOC_FAILED, dumps catastrophiques pour les utilisateurs finaux.
La dependance avec PHYS_MEMSIZE
PHYS_MEMSIZE doit refleter la RAM reellement disponible pour l'instance SAP. SAP utilise cette valeur pour calculer automatiquement plusieurs derives. Sur un serveur de 128 GB avec HANA en co-deployment, PHYS_MEMSIZE pour l'instance application ne doit jamais depasser 40 GB, sinon les deux processus se marchent dessus.
Levier 5 : l'analyse ST04 et les requetes coûteuses
Les expensive statements
ST04 sur HANA donne acces a M_EXPENSIVE_STATEMENTS, qui liste les requetes ayant consomme plus de ressources qu'un seuil parametrable. Je mets systématiquement ce seuil a 5 secondes ou 1 GB de memoire traitee dans les premiers jours de production.
Les requetes les plus coûteuses appartiennent souvent a du code custom mal écrit : jointures implicites, SELECT *, absence d'indices sur les colonnes de filtrage. Dans les 48 heures après Go-Live, une chasse systématique aux requetes au-dela de 10 secondes permet souvent de faire chuter la charge CPU HANA de 30%.
Le cas industriel : une requete a 400 secondes
Sur un Go-Live S/4HANA chez un equipementier industriel, ST04 a remonte des le jour 1 une requete Z custom s'executant en 420 secondes, appelee 80 fois par heure. Elle faisait un FULL scan d'une table de mouvements de stock à 90 millions de lignes. Ajouter un index secondaire approprie a ramene le temps a 2 secondes. Sans cette action, le système s'effondrait dans la semaine.
Levier 6 : la gestion des verrous (lock analysis)
SM12 et la detection des verrous orphelins
Les verrous SAP sont gérés par le serveur enqueue. Un verrou orphelin, laisse par un processus interrompu, bloque les autres sessions et provoque des effets en cascade. SM12 permet de lister et supprimer ces verrous. En production, je mets en place un job automatique qui detecte les verrous dormants de plus de 30 minutes et alerte la Basis.
DB01 pour les verrous base de données
Au-dela des verrous SAP, la base peut elle-même avoir des contentions. DB01 sur HANA liste les sessions bloquantes. Lors du Go-Live d'un operateur de reseaux chez un client énergie, nous avons decouvert que les batchs de clearing automatique generaient des locks sur KNA1 qui bloquaient les saisies commerciales. Nous avons du redecouper les traitements en lots plus fins et desynchroniser leurs fenêtres d'execution.
Levier 7 : le planning batch intelligent
Éviter la tempête parfaite
La plus grande erreur que j'observe est de planifier tous les batchs critiques a la même heure, typiquement minuit. Les serveurs d'application explosent pendant 45 minutes, les update tasks s'empilent, les utilisateurs qui se connectent a 6h du matin trouvent un système exsangue.
Ma méthode : etaler la charge sur toute la fenêtre nocturne, en commencant par les jobs courts (20h-22h), puis les jobs moyens (22h-1h), puis les jobs lourds (1h-5h). SM37 et SM36 permettent d'ordonnancer, mais sur des paysages complexes je recommandé un outil externe type Redwood ou SAP Cloud ALM pour la vue consolidee multi-systèmes.
La parallelisation maîtrisée
Les RFC asynchrones et les groupes de serveurs permettent de paralleliser les traitements massifs. Mais attention : multiplier les parallelismes sur un serveur déjà charge aggrave la situation. La règle d'or : ne jamais depasser 60% d'occupation des BTC workers en moyenne.
Levier 8 : l'archivage et la purge
Les tables qui grossissent dangereusement
DBACOCKPIT permet d'identifier les tables a forte croissance. Les candidates classiques : BALHDR (logs applicatifs), EDIDC (IDoc headers), SWW_CONT (workflows), DBTABLOG (logs DB). Sans politique d'archivage, ces tables explosent et les requetes correspondantes s'effondrent.
SAR et les Archive Development Kits doivent être configures AVANT le Go-Live, pas après. J'ai vu un projet chez un acteur de la construction ou BALHDR avait atteint 400 GB en six mois, rendant certaines analyses impossibles. La purge retroactive a pris trois weekends.
Levier 9 : monitoring proactif avec Cloud ALM
Le shift vers le monitoring moderne
Solution Manager est en fin de vie. Cloud ALM est désormais l'outil recommandé par SAP pour le monitoring et l'opérations management. Il agrege les metriques de tous les systèmes (S/4HANA, BTP, SuccessFactors, Ariba) dans un tableau de bord unique.
Avant Go-Live, Cloud ALM doit être configure avec :
- Health monitoring sur tous les systèmes du paysage
- Alerting sur les WP occupes, le CPU HANA, le buffer swap
- Integration events vers l'outil de ticketing (ServiceNow, Jira)
- Dashboards dedies pour le run post Go-Live
Les règles d'alerte critiques
Les seuils que je configure systématiquement :
- CPU HANA > 80% pendant 10 minutes : alerte P2
- Work processes DIA occupes > 90% : alerte P1
- Buffer swap > 100/minute : alerte P3
- Lock wait time > 30 secondes : alerte P2
- Memory growth anormale sur une session : alerte P2
Levier 10 : le plan de War Room Go-Live
Les 72 premières heures
Aucune Basis ne devrait laisser un Go-Live sans supervision pendant les 72 premières heures. La War Room reunit physiquement (ou en visio permanente) :
- Un architecte Basis senior
- Un DBA HANA
- Un développeur ABAP pour le hotfix eventuel
- Un referent Integration Suite si des interfaces critiques sont en jeu
- Un chef de projet cote métier pour prioriser
Chaque heure, un point de dix minutes fait le tour des metriques clés : temps de reponse moyen (SM66), charge CPU HANA, files d'attente BTC, erreurs ST22, IDoc en erreur (WE02). Cette cadence permet d'intercepter les derives avant qu'elles ne deviennent des incidents bloquants.
Le hotfix maîtrise
Le reflexe d'urgence est de patcher en production. C'est souvent une mauvaise idée. Mon principe : tout hotfix doit passer par un transport urgent documente, avec validation ATC minimale, et avec un rollback préparé. J'ai vu un Go-Live gravement aggrave par un hotfix pose dans la panique qui a casse un flux logistique.
Modes de defaillance classiques au jour 1
Après une vingtaine de Go-Live accompagnes, je retrouve les mêmes causes racines dans 80% des incidents :
1. Work processes DIA satures par des sessions fantomes non nettoyées
2. Buffer de programmes ABAP sous-dimensionne après activation de nombreux Z customs
3. Requetes custom non optimisees découvertes sous charge reelle
4. Jobs batch concentres a minuit qui saturent le système
5. Verrous d'enqueue orphelins sur des tables maîtres
6. Out-of-memory HANA sur les cloturations financieres
7. Interface CPI/PI saturee a l'heure de pointe
8. Logs applicatifs non archives qui font exploser les tables de logs
9. PHYS_MEMSIZE mal renseigne après un changement de VM
10. Parametres heap non alignes entre serveurs d'application
Conclusion : la Basis, discipline silencieuse du succès
Dans les retrospectives de projet SAP, on parle rarement de la Basis. C'est pourtant elle qui determine si la solution fonctionnelle, aussi brillante soit-elle, tient la route en production. Les dix leviers que je viens de detailler ne sont pas exhaustifs, mais ils couvrent l'essentiel des causes d'incident que j'ai pu observer en dix ans d'accompagnement de Go-Live complexes.
Mon conseil final : investissez dans votre equipe Basis, avant le projet plutot qu'après l'incident. Un architecte Basis senior expérimenté coûte moins cher que trois semaines d'indisponibilite d'un ERP qui irrigue 15 000 utilisateurs. La Basis n'est pas une commodity : c'est un actif stratégique qui merite le même soin que l'architecture fonctionnelle.