Le rapport des ventes doit être prêt chaque matin avant l’arrivée des équipes. Les ordres de transport doivent se traiter toutes les cinq minutes, week-end compris. Personne ne lance ces traitements à la main : ce sont des jobs SAP qui s’en chargent, en arrière-plan, sans interruption.
Que vous en créiez ou non, vous en dépendez tous les jours. Ce guide couvre l’essentiel côté key user : le cycle de vie d’un job, la création propre dans SM36, et la surveillance dans SM37.
- Un job SAP exécute en arrière-plan une succession de steps : programmes ABAP (standard ou Z), commandes externes ou programmes externes.
- Deux transactions suffisent :
SM36pour créer,SM37pour surveiller. - Le cycle de vie compte 6 statuts : Scheduled, Released, Ready, Active, Finished, Canceled.
- La start condition déclenche le job : immédiat, date et heure, après un job, après un event, ou au changement de mode d’exploitation, avec périodicité.
- Premier réflexe sur un job en erreur : ouvrir le job log dans SM37, il contient presque toujours le message exact.
Un job SAP, à quoi ça sert vraiment
Un job est une exécution en arrière-plan : le système déroule, sans aucune interaction utilisateur, une succession d’étapes préconfigurées, les steps. Chaque step exécute un programme ABAP (standard ou spécifique Z), une commande externe ou un programme externe au système. Dans l’immense majorité des cas réels, ce sont des programmes ABAP.
La puissance du job vient de sa planification : une fréquence (chaque jour, chaque semaine, chaque mois) et un horaire précis. C’est ce qui transforme un traitement lourd en automatisme nocturne : exécuté à trois heures du matin, il tourne plus vite et ne gêne personne.
Et c’est pourquoi le sujet concerne les key users autant que les administrateurs : vos extractions du matin, vos interfaces, vos relances arrivent par des jobs. Savoir les lire dans SM37, c’est savoir répondre à « pourquoi le rapport n’est pas sorti ? » sans ouvrir de ticket.
Le cycle de vie d’un job : 6 statuts à connaître
Chaque job traverse un cycle de statuts, et chaque statut raconte quelque chose de précis.
| Statut | Ce que ça signifie | Ce que ça implique pour vous |
|---|---|---|
| Scheduled | Le job est défini, mais sans condition de démarrage validée | Il ne partira jamais tel quel : il attend d’être planifié puis released |
| Released | La start condition est posée, le job attend son heure | Tout est normal : il démarrera au moment prévu |
| Ready | L’heure est arrivée, le job attend un work process disponible | S’il y reste longtemps, le système est chargé |
| Active | Le job s’exécute en ce moment | Patience ; la Duration se compte en direct |
| Finished | Exécution terminée sans erreur | Le résultat (spool, données) est disponible |
| Canceled | Le job s’est interrompu en erreur | Direction le job log, c’est lui qui explique pourquoi |
La nuance la plus utile au quotidien : un job Scheduled n’est pas en attente d’exécution. Tant qu’il n’est pas Released, il est juste défini, et il ne partira jamais. C’est la réponse à un grand classique des tickets du lundi matin.
Créer un job dans SM36, proprement
La création passe par SM36, Define Job. L’écran principal regroupe les données générales et les trois briques du job : la start condition, les steps et la périodicité.

-
1Nommer le job
Respectez la convention de nommage de votre société : c’est par le nom que vous le retrouverez dans SM37.
-
2Choisir la classe
A, B ou C : c’est la priorité d’accès aux ressources. C est la valeur courante ; A se réserve aux traitements critiques.
-
3Définir les steps
Le bouton Step ajoute chaque étape : le programme ABAP avec sa variante, dans l’ordre d’exécution voulu.
-
4Poser la start condition
Immédiat, date et heure, après un autre job, après un event ; cochez la périodicité pour un job récurrent.
-
5Régler spool et notification
Spool List Recipient envoie la sortie d’impression à un destinataire ; E-Mail Notification prévient à la fin du job.
-
6Sauvegarder
Le job passe en Scheduled puis Released si la condition est complète : vérifiez son statut dans SM37.
Voici à quoi ressemblent les steps une fois définis : ici deux programmes ABAP exécutés l’un après l’autre dans le même job.

Un préfixe d’équipe ou de module dans le nom du job (par exemple un code service suivi du traitement) rend SM37 filtrable en une saisie. Six mois plus tard, quand il faudra retrouver qui a créé quoi, la convention fera la différence entre deux minutes et une demi-journée.
Pour débuter, le Job wizard de SM36 guide pas à pas les mêmes choix. Et si votre besoin est d’automatiser une saisie de masse plutôt qu’un rapport, c’est souvent une session batch input que le job exécutera.
Start conditions : déclencher le job au bon moment
La start condition est le déclencheur. Cinq modes couvrent tous les besoins :
- Immediate : le job part dès la sauvegarde.
- Date/Time : démarrage à une date et une heure précises, le mode du rapport quotidien.
- After job : le job démarre quand un autre job se termine, pour chaîner des traitements dépendants.
- After event : le job attend un événement système ou applicatif, déclenché par un autre processus.
- At operation mode switch : démarrage au basculement de mode d’exploitation du système.
La périodicité s’ajoute à la condition Date/Time : quotidien, hebdomadaire, mensuel ou intervalle libre. C’est elle qui transforme une exécution en automatisme : le job se replanifie tout seul après chaque exécution, et le cours public Scheduling Background Jobs en détaille les variantes côté officiel.
Surveiller ses jobs dans SM37
La transaction SM37, Job Overview, commence par un écran de sélection : nom du job (les jokers * sont permis), utilisateur créateur, plage de dates, et les statuts à inclure.

La liste qui s’affiche concentre l’essentiel de la surveillance : le statut de chaque job, sa date et son heure de démarrage, sa Duration et son Delay, tous deux exprimés en secondes.

Deux lectures valent de l’or. La Duration d’abord : suivez-la dans le temps sur un job récurrent, une dérive régulière annonce un volume qui grossit ou un programme qui se dégrade. Le Delay ensuite : c’est le temps d’attente entre l’heure prévue et l’exécution réelle. Un delay qui grimpe signale un système chargé à cette heure-là, ou une fenêtre de planification mal choisie.
Job log : quand le job se passe mal
Statut Canceled ? Le premier réflexe s’appelle job log : sélectionnez le job dans SM37 et ouvrez son log. Il contient le déroulé de l’exécution, les messages émis par les programmes et, dans la grande majorité des cas, le message d’erreur exact qui a interrompu le traitement.
Les réflexes du key user sur les jobs
Quelques habitudes distinguent une gestion de jobs sereine d’une collection d’incidents.
- Choisissez la fenêtre d’exécution en connaissance de cause : la nuit pour les traitements lourds, jamais l’heure de pointe métier.
- Réservez la classe A aux traitements réellement critiques : c’est une priorité d’accès aux ressources, pas un badge d’importance.
- Vérifiez le spool des jobs qui impriment ou génèrent des listes : un job Finished avec un spool en erreur est un faux succès.
- Passez en revue périodiquement vos jobs récurrents : les jobs orphelins, dont plus personne ne lit le résultat, consomment des ressources pour rien.
Les jobs s’exécutent sur des work processes background, en nombre limité sur chaque système. Un job lourd lancé en pleine journée, qui plus est en classe A, monopolise ces ressources au détriment de tous les autres traitements. Si un job peut attendre la nuit, faites-le attendre la nuit.
Le job SAP est l’un de ces fondamentaux transverses qui rendent service dans tous les modules : une fois SM36 et SM37 apprivoisées, vous savez automatiser un traitement, lire son état et diagnostiquer son échec. Et quand le job log ne suffit pas, le diagnostic passe la main à un profil technique : notre guide de l’ABAP debugger documente l’outil qu’il dégainera.
FAQ : vos questions sur les jobs SAP
Quelle est la différence entre SM36 et SM37 ?
SM36 (Define Job) sert à créer et planifier un job : nom, classe, steps, start condition et périodicité. SM37 (Job Overview) sert à surveiller : retrouver les jobs, lire leurs statuts, leur Duration, leur Delay et leur job log.
Que signifient les statuts Scheduled, Released et Active d’un job SAP ?
Scheduled : le job est défini mais sans condition de démarrage validée, il ne partira pas tel quel. Released : la condition est posée, le job attend son heure. Active : il s’exécute en ce moment. Le cycle complet ajoute Ready (en attente d’un work process), puis Finished ou Canceled.
Quelle classe de job choisir entre A, B et C ?
La classe définit la priorité d’accès aux ressources background. C est la classe courante pour la majorité des traitements, B une priorité intermédiaire, et A se réserve aux jobs réellement critiques dont le retard a un impact métier direct.
Comment planifier un job périodique dans SAP ?
Dans SM36, posez une start condition Date/Time puis cochez l’exécution périodique et choisissez la fréquence : quotidienne, hebdomadaire, mensuelle ou un intervalle libre. Après chaque exécution, le système replanifie automatiquement l’occurrence suivante.
Pourquoi mon job SAP reste en statut Released et ne démarre pas ?
Released signifie que l’heure prévue n’est pas encore arrivée, ou que la condition (event, job précédent) ne s’est pas encore produite. Si l’heure est passée et que le job reste Ready, c’est que le système attend un work process background disponible : regardez le Delay grimper dans SM37.