Un job en arrière-plan qui se termine avec le statut FINISHED ne signifie pas qu’il a fait ce qu’il devait faire. C’est probablement le point le plus important à comprendre avant de mettre en place une supervision des traitements batch SAP, une distinction que la plupart des configurations d’alerte interprètent mal.
Les jobs en arrière-plan dans SAP représentent un risque métier disproportionné par rapport à l’attention qu’ils reçoivent. Calculs de paie, clôtures financières, MRP, rapprochement de factures, relances… Ces processus s’exécutent silencieusement, souvent la nuit, et le premier signal d’un problème est généralement un utilisateur métier qui demande pourquoi son rapport affiche des données de la semaine précédente ou pourquoi un paiement n’a pas été lancé.
Cet article se concentre sur l’aspect pratique de la supervision des jobs SAP : ce qu’il faut réellement suivre (au-delà des statuts), comment structurer les alertes sans générer de bruit, et où se situent les angles morts les plus fréquents, faciles à corriger une fois identifiés.
Pourquoi les tâches d’arrière-plan SAP posent-elles un problème de surveillance particulier ?
Du point de vue de la surveillance, les tâches d’arrière-plan SAP occupent une place délicate. Comme il ne s’agit pas de transactions interactives, les utilisateurs ne ressentent pas directement leur dégradation, du moins pas immédiatement. Elles s’exécutent selon un calendrier fixe, ce qui fait qu’elles passent facilement inaperçues dans les tableaux de bord en temps réel axés sur les performances des applications. Et elles sont souvent considérées comme un problème résolu grâce à l’existence de SM37.
SM37 est un journal des tâches, pas un outil de surveillance. Il vous indique ce qui s’est passé après coup. Il ne vous indique pas qu’une tâche est actuellement en cours d’exécution avec 45 minutes de retard par rapport à sa durée prévue, qu’une tâche précédente a échoué et a bloqué silencieusement trois processus en aval, ou que le pool de processus de travail en arrière-plan est saturé parce que deux exécutions MRP simultanées ont été planifiées au même moment par des services différents.
Le problème des échecs silencieux
Les tâches en arrière-plan peuvent échouer de deux manières distinctes, dont une seule est évidente.
L’échec évident est celui d’une tâche qui se termine avec le statut ABORTED ou CANCELLED. Ces statuts apparaissent dans SM37, génèrent des messages système et, même avec une surveillance de base, sont généralement détectés assez rapidement.
L’échec moins évident est celui d’une tâche qui s’achève avec le statut FINISHED, mais qui n’a en réalité pas été exécutée correctement. Cela se produit lorsque le programme ABAP lui-même intercepte des exceptions et les consigne dans un fichier spool sans les propager en tant qu’erreur au niveau de la tâche. De l’extérieur, la tâche semble fonctionner correctement. À l’intérieur de la sortie spool, il existe des messages d’erreur d’application qui ne deviennent visibles que lorsqu’une personne inspecte manuellement le journal. Cela ne devient visible que lorsqu’une personne inspecte manuellement le journal, ou lorsque l’entreprise remarque l’anomalie.
Cette catégorie de défaillance nécessite une surveillance qui va au-delà des codes de statut des tâches. Cela implique de parcourir la sortie spool à la recherche de classes de messages d’erreur, de vérifier si une tâche terminée a également produit le résultat métier attendu (une écriture, un rapport, un fichier) et, dans certains cas, de valider les données en aval.
Dépendances entre les chaînes de tâches et défaillances en cascade
La plupart des environnements SAP de production comportent des chaînes de tâches : la tâche B ne démarre qu’une fois que la tâche A s’est terminée avec succès. La tâche C dépend de la tâche B. Dans une configuration bien conçue, ces dépendances sont définies comme des relations prédécesseur/successeur dans SM36. Dans la pratique, de nombreuses chaînes sont gérées de manière informelle : un démarrage programmé à 02h00, considéré comme sûr car la tâche A se termine généralement vers 01h45.
Lorsque le job A prend plus de temps que prévu, ce qui arrive régulièrement en fin de mois lorsque les volumes de données sont plus importants que d’habitude, le job B démarre en retard, le job C démarre en retard, et lorsque les utilisateurs arrivent à 8 h, toute la fenêtre de traitement nocturne a pris du retard. Personne n’a reçu d’alerte car aucun job individuel n’a échoué. Ils ont simplement tourné lentement.
C’est pourquoi la surveillance de la durée est tout aussi importante que celle de l’état. Un job s’exécutant à 180 % de sa durée de référence n’est pas un job ayant échoué. C’est un signal indiquant que quelque chose en aval est sur le point de manquer sa fenêtre.
Éléments à surveiller concrètement dans le cadre de la surveillance des tâches d’arrière-plan SAP
Statut de la tâche : la base de référence, pas le plafond
Le suivi du statut d’achèvement est le minimum requis. Toute configuration de surveillance SAP doit déclencher une alerte en cas d’états « ABORTED » et « CANCELLED » en production, sans exception. La question est de savoir quels autres éléments sont surveillés en parallèle.
ABORTED : la tâche s’est terminée de manière inattendue. Il peut s’agir d’une erreur d’exécution ABAP, d’un conflit de verrouillage, d’un échec d’autorisation ou d’un problème de ressources. Nécessite toujours une investigation, ne se résout jamais de lui-même.
CANCELLED : le job a été arrêté de manière active, soit par un utilisateur, soit par un événement système. Il convient de le distinguer de l’état ABORTED car la cause est différente et la correction à apporter est différente.
FINISHED : le job s’est exécuté jusqu’à son terme. C’est l’état qui crée une fausse confiance. Vérifiez toujours les jobs FINISHED par rapport à leur résultat attendu, et pas seulement à leur état.
READY / RELEASED et jamais démarré : un job bloqué dans la file d’attente car aucun processus de travail en arrière-plan n’était disponible au moment où il devait démarrer. Facile à manquer si vous ne surveillez que les jobs en cours d’exécution et terminés.
En cours d’exécution après la date limite : ce n’est pas un statut SAP, mais sans doute le signal d’exécution le plus important. Nécessite des durées de référence par job pour être détecté.
Durée d’exécution : l’indicateur que la plupart des équipes négligent
Chaque tâche planifiée a une durée attendue implicite, même si cette estimation n’a jamais été officiellement consignée. Un cycle de paie qui prend normalement 90 minutes et qui en est désormais à 3 heures n’est pas une tâche en bonne santé, même s’il finit par aboutir.
La mise en place d’une surveillance de la durée nécessite de savoir ce qui constitue un fonctionnement normal pour chaque tâche. Cela implique de collecter des données historiques d’exécution sur une période représentative, couvrant idéalement les cycles de fin de mois, de fin de trimestre et de fin d’année où les volumes sont plus élevés, et d’utiliser ces données pour définir une limite supérieure raisonnable pour chaque tâche.
Un point de départ pratique : déclencher une alerte lorsqu’une tâche dépasse 130 % de sa durée moyenne sur 30 jours glissants. Cette approche est suffisamment prudente pour éviter les faux positifs lors de pics de volume occasionnels, tout en détectant suffisamment tôt une véritable dégradation pour pouvoir enquêter avant que la fenêtre en aval ne soit manquée.
Certaines équipes négligent la surveillance de la durée car elle nécessite un travail d’instrumentation en amont. Le retour sur investissement est pourtant significatif. Les alertes de durée sont souvent le seul avertissement disponible avant une défaillance en cascade dans une chaîne de tâches. Elles donnent à l’équipe des opérations le temps d’agir plutôt que de réagir.
Disponibilité des processus de travail
Les tâches en arrière-plan partagent un pool de processus de travail en arrière-plan avec toutes les autres tâches exécutées dans la file d’attente par lots. Lorsque ce pool est saturé, que ce soit parce qu’un trop grand nombre de tâches s’exécutent simultanément ou parce qu’une tâche monopolise un processus de travail pendant une durée inhabituellement longue, les nouvelles tâches sont mises en file d’attente au lieu de démarrer.
Surveiller le taux d’occupation des processus de travail en arrière-plan parallèlement à la planification des tâches permet de mieux comprendre pourquoi les tâches démarrent en retard. Une tâche qui ne démarre pas à l’heure prévue est due soit à un problème de configuration de la planification, soit à un problème de disponibilité des processus de travail. La solution est complètement différente dans chaque cas, et vous ne pouvez pas déterminer de quel problème il s’agit sans disposer de ces deux points de données.
Un bon seuil : déclencher une alerte lorsque l’utilisation des processus de travail en arrière-plan reste supérieure à 80 % pendant plus de 10 minutes. Des pics occasionnels sont normaux. Une saturation prolongée signifie qu’il y a un problème au niveau de la planification, de la taille des tâches ou des ressources système disponibles pour le traitement par lots.
Disponibilité des processus de travail
Les tâches en arrière-plan partagent un pool de processus de travail en arrière-plan avec toutes les autres tâches exécutées dans la file d’attente par lots. Lorsque ce pool est saturé, que ce soit parce qu’un trop grand nombre de tâches s’exécutent simultanément ou parce qu’une tâche monopolise un processus de travail pendant une durée inhabituellement longue, les nouvelles tâches sont mises en file d’attente au lieu de démarrer.
Surveiller le taux d’occupation des processus de travail en arrière-plan parallèlement à la planification des tâches permet de mieux comprendre pourquoi les tâches démarrent en retard. Une tâche qui ne démarre pas à l’heure prévue est due soit à un problème de configuration de la planification, soit à un problème de disponibilité des processus de travail. La solution est complètement différente dans chaque cas, et vous ne pouvez pas déterminer de quel problème il s’agit sans disposer de ces deux points de données.
Un bon seuil : déclencher une alerte lorsque l’utilisation des processus de travail en arrière-plan reste supérieure à 80 % pendant plus de 10 minutes. Des pics occasionnels sont normaux. Une saturation prolongée signifie qu’il y a un problème au niveau de la planification, de la taille des tâches ou des ressources système disponibles pour le traitement par lots.
Sortie de spool et erreurs au niveau de l’application
Il s’agit de la couche de surveillance qui comble le fossé entre l’état technique d’un job et le résultat opérationnel réel. La sortie de spool d’un job contient les messages au niveau de l’application générés pendant l’exécution, y compris les messages de type E (erreur) et W (avertissement) que les programmes SAP enregistrent souvent sans interrompre le job.
La surveillance de la sortie spool à grande échelle est plus difficile que celle des codes d’état. Elle nécessite l’analyse de la sortie texte, qui varie selon les programmes, et la définition de ce qui constitue une erreur significative par opposition à un message d’information attendu. Ce n’est pas une mince affaire, mais cela en vaut la peine pour les tâches hautement critiques, telles que la paie, la clôture financière, la planification des besoins (MRP) ou la facturation, où une erreur d’application silencieuse a un impact direct sur l’activité.
Au minimum, définissez une liste de tâches critiques pour lesquelles le statut FINISHED ne constitue pas à lui seul une preuve suffisante d’une exécution correcte. Pour ces tâches, exigez une vérification manuelle ou automatisée de la file d’attente dans le cadre du protocole de surveillance.
Intégrité du calendrier des tâches
Au-delà de la surveillance des tâches individuelles, il est nécessaire de surveiller le calendrier dans son ensemble. Des tâches peuvent être supprimées, reprogrammées ou accidentellement mises en attente par des utilisateurs qui oublient de les réactiver. Le simple fait qu’une tâche ne figure plus dans le calendrier ne constitue pas un état d’erreur. Il n’y a pas lieu de déclencher d’alerte, mais le processus métier qu’elle soutient a cessé de s’exécuter.
Surveiller l’intégrité du calendrier consiste à vérifier périodiquement que les tâches attendues sont bien présentes et planifiées aux heures prévues. Cela est particulièrement important après les actualisations du système, où les tâches de production peuvent ne pas être correctement transférées vers le nouvel environnement, et après les mises à niveau SAP, où les activités de transport peuvent involontairement affecter la planification des tâches.
Référence sur les alertes de tâches en arrière-plan : conditions, seuils et actions
Le tableau ci-dessous présente les principales conditions d’alerte qu’il convient de configurer pour la surveillance des tâches SAP en arrière-plan dans un environnement de production. Les seuils doivent être adaptés au profil spécifique des tâches de chaque environnement. Il s’agit là de points de départ, et non de normes universelles.
Modèles d’alerte efficaces pour les opérations par lots SAP
Segmentez les destinataires de vos alertes
Il arrive étonnamment souvent que les alertes relatives aux tâches d’arrière-plan SAP soient envoyées aux mauvaises personnes. L’échec d’un traitement par lots à 3 h du matin atterrit dans la boîte de réception de l’équipe SAP Basis, où il reste en attente jusqu’aux heures de bureau. Or, il s’agit en réalité du traitement préliminaire de la paie que le service financier doit voir achevé avant 7 h. L’alerte aurait dû être transmise au service financier de garde, et non à l’équipe Basis.
Structurer le routage des alertes en fonction de la criticité des tâches et du responsable métier demande plus de travail en amont qu’une simple boîte de réception commune à toute l’équipe, mais cela élimine les incidents où la bonne personne n’est informée du problème que quatre heures après avoir pu y remédier.
Une approche viable : classer les tâches en trois niveaux. Le niveau 1 couvre les tâches critiques pour l’entreprise avec des délais stricts : paie, clôture financière, rapports légaux. Celles-ci sont immédiatement transmises à la fois à l’équipe des opérations et au responsable du processus métier. Le niveau 2 couvre les tâches importantes mais non urgentes : archivage des données, optimisation des performances. Celles-ci sont transmises à l’équipe des opérations pour être examinées lors des prochaines heures ouvrables. Le niveau 3 couvre les tâches de maintenance et les traitements par lots à faible priorité. Elles sont enregistrées, examinées périodiquement, mais ne font pas l’objet d’alertes actives.
Alertes tenant compte de l’heure
Une même défaillance de tâche survenant à 22 h et à 6 h 30 nécessite des mesures différentes. Un traitement par lots nocturne qui s’interrompt à 22 h a plusieurs heures devant lui avant d’affecter les opérations métier. La même défaillance à 6 h 30, une heure avant que les utilisateurs ne commencent leur journée, nécessite une intervention immédiate.
La configuration de plages horaires dans le routage des alertes est une fonctionnalité de base de la plupart des plateformes de surveillance modernes, mais elle est sous-utilisée. Définir un niveau d’urgence plus élevé pour les tâches qui échouent dans les deux heures précédant le moment où leur résultat est attendu par l’entreprise, par rapport aux échecs survenant au milieu de la nuit, réduit les escalades inutiles en dehors des heures de bureau tout en garantissant que les échecs urgents reçoivent la réponse qu’ils nécessitent.
Évitez de déclencher des alertes pour des symptômes sur lesquels vous ne pouvez pas agir
L’une des raisons les plus courantes pour lesquelles les équipes SAP finissent par ignorer les alertes relatives aux tâches batch est la « fatigue des alertes », due à des conditions qui se déclenchent constamment mais ne nécessitent aucune action. Une alerte de saturation des processus de travail en arrière-plan qui se déclenche chaque nuit pendant la même fenêtre de traitement batch, parce que cette fenêtre a été conçue pour exécuter autant de tâches simultanées, incite les utilisateurs à ignorer les alertes.
Avant d’ajouter une alerte, la question à se poser est la suivante : si celle-ci se déclenche à 3 h du matin, que doit réellement faire la personne qui la reçoit ? Si la réponse est « rien jusqu’au matin » ou « c’est normal », il devrait s’agir d’une entrée de journal, et non d’une alerte. Réservez les alertes aux conditions qui nécessitent une action dans le délai d’urgence que l’alerte implique.
Visibilité sur la chaîne de dépendances
Les alertes individuelles sur les tâches ne permettent pas de savoir si une tâche qui vient d’échouer est un cas isolé ou le premier maillon d’une chaîne de dix processus interdépendants. Les systèmes de surveillance qui visualisent les dépendances entre les tâches indiquent quelles tâches attendent celle qui a échoué, quels sont leurs délais et quel sera l’impact opérationnel en aval. Ce contexte permet à l’équipe opérationnelle d’établir correctement ses priorités.
Sans ce contexte, la réponse par défaut à l’échec d’un travail consiste à le redémarrer et à passer à autre chose. Grâce à ces informations, l’équipe peut constater que le travail ayant échoué est un prédécesseur d’un cycle de clôture financière prévu dans 90 minutes, et ajuster la priorité de l’incident en conséquence.
Bien configurer le système : recommandations pratiques
Commencez par dresser un inventaire des tâches
Avant de configurer un système de surveillance, dressez un inventaire complet de ce qui est réellement planifié en production. Dans la plupart des environnements en service depuis plusieurs années, on trouve des tâches dont personne n’assume pleinement la responsabilité, des tâches créées pour une opération ponctuelle et jamais supprimées, ainsi que des tâches qui font double emploi avec des fonctionnalités désormais déplacées ailleurs.
Un inventaire des tâches n’a pas besoin d’être exhaustif dès le premier jour. Commencez par les tâches qui ont des responsables métier clairement identifiés et des délais d’exécution stricts. Ce sont les tâches pour lesquelles un échec a un impact immédiat sur l’activité et pour lesquelles la surveillance offre le retour sur investissement le plus évident. Partez de là pour élargir votre champ d’action.
Définissez des valeurs de référence avant de configurer des alertes
L’utilisation d’un outil de surveillance dans un environnement SAP sans valeurs de référence génère des alertes intempestives et peu utiles. L’outil ne sait pas ce qu’est un fonctionnement normal ; il se déclenchera donc soit pour tout et n’importe quoi, soit pour rien du tout, selon la manière dont les seuils ont été définis.
Collectez quatre à six semaines de données sur la durée d’exécution des tâches avant de finaliser les seuils d’alerte. Assurez-vous que ces données incluent au moins un cycle de fin de mois, car la durée des tâches batch en fin de mois peut être nettement supérieure aux moyennes quotidiennes et ces pics ne doivent pas déclencher de fausses alertes. Utilisez les données collectées pour définir des seuils de durée par tâche, et non un seuil global unique pour toutes les tâches.
Testez vos alertes avant d’en avoir besoin
La fiabilité des configurations d’alerte qui n’ont jamais été testées est incertaine. Simulez une défaillance d’un processus dans un environnement hors production afin de vérifier que les personnes concernées reçoivent bien l’alerte, que celle-ci contient les informations nécessaires pour leur permettre d’agir, et qu’elle est transmise au système de gestion des incidents approprié avec la classification adéquate. Cette opération prend moins d’une heure et évite de découvrir à ses dépens qu’une configuration d’alerte était erronée lors d’un incident réel en production.
Vérifiez les plannings des tâches après chaque modification majeure
Les mises à jour du système SAP, les versions majeures, les importations de transport qui affectent les objets de planification par lots et les migrations vers S/4HANA sont autant d’éléments susceptibles de perturber la planification des tâches d’une manière qui n’est pas immédiatement perceptible. Il convient donc d’intégrer une vérification des plannings des tâches après chaque modification dans le processus de gestion des changements, afin de s’assurer que les tâches critiques sont bien présentes, correctement planifiées et en état de validation. Cette étape permet d’éviter une catégorie d’échecs silencieux qui, sans cela, ne seraient détectés que lorsqu’un utilisateur métier signale l’absence de résultats.
À quoi ressemble réellement une bonne surveillance des tâches en arrière-plan ?
Un environnement SAP batch bien surveillé présente certaines caractéristiques qui peuvent servir de liste de contrôle pratique.
L’équipe opérationnelle est informée d’un échec de tâche avant même que l’entreprise ne s’en aperçoive. Cela nécessite une surveillance en temps réel avec un système de notification qui alerte les bonnes personnes au moment opportun, et non un journal qui n’est examiné que le lendemain matin.
Les anomalies de durée des tâches sont détectées avant que les délais ne soient dépassés. Cela nécessite la configuration de valeurs de référence et de seuils pour chaque tâche, et non une alerte globale unique qui se déclenche trop tard pour être utile.
Le statut « FINISHED » n’est pas considéré comme la preuve d’une exécution correcte. Les tâches critiques disposent d’une deuxième couche de validation : examen du spool, vérification des sorties ou contrôles des données en aval. Cette couche confirme que la tâche a fait ce qu’elle était censée faire, et pas seulement qu’elle s’est exécutée jusqu’à son terme.
C’est le planning lui-même qui est surveillé, et pas seulement l’exécution de chaque tâche. Les tâches manquantes et les dérives de planning sont détectées avant qu’elles n’aient un impact sur l’activité.
Tout cela ne nécessite ni une équipe nombreuse ni une pile d’outils complexe. Cela nécessite une configuration réfléchie, une responsabilité clairement définie et la prise de conscience que la surveillance des tâches batch n’est pas un problème résolu simplement parce que SM37 existe.
Redpeaks surveille les tâches SAP en arrière-plan en temps réel dans les environnements de production et hors production, avec des durées de référence, des alertes au niveau du spool et une intégration ITSM prête à l’emploi.
Découvrez comment cela fonctionne →
