Aller au contenu
Tutos SAP

Job SAP : le guide key user pour SM36, SM37 et le cycle de vie

Comprendre les jobs SAP : cycle de vie en 6 statuts, création propre dans SM36 (start conditions, classes A/B/C), surveillance SM37 et lecture du job log.

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.

À retenir en 30 secondes
  • 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 : SM36 pour créer, SM37 pour 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.

StatutCe que ça signifieCe que ça implique pour vous
ScheduledLe job est défini, mais sans condition de démarrage validéeIl ne partira jamais tel quel : il attend d’être planifié puis released
ReleasedLa start condition est posée, le job attend son heureTout est normal : il démarrera au moment prévu
ReadyL’heure est arrivée, le job attend un work process disponibleS’il y reste longtemps, le système est chargé
ActiveLe job s’exécute en ce momentPatience ; la Duration se compte en direct
FinishedExécution terminée sans erreurLe résultat (spool, données) est disponible
CanceledLe job s’est interrompu en erreurDirection le job log, c’est lui qui explique pourquoi
Les six statuts du cycle de vie d’un job : de Scheduled à Finished, ou Canceled en cas d’erreur.

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é.

Écran SM36 Define Job avec Job Name, Job Class, statut Scheduled et les boutons Start condition, Step et Job wizard
SM36 Define Job : nom, classe, puis les boutons Start condition et Step qui construisent le job.
  1. 1
    Nommer le job

    Respectez la convention de nommage de votre société : c’est par le nom que vous le retrouverez dans SM37.

  2. 2
    Choisir 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.

  3. 3
    Définir les steps

    Le bouton Step ajoute chaque étape : le programme ABAP avec sa variante, dans l’ordre d’exécution voulu.

  4. 4
    Poser 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.

  5. 5
    Régler spool et notification

    Spool List Recipient envoie la sortie d’impression à un destinataire ; E-Mail Notification prévient à la fin du job.

  6. 6
    Sauvegarder

    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.

Liste des steps d'un job SAP avec deux programmes ABAP exécutés séquentiellement
Les steps du job : chaque ligne est un programme exécuté à son tour, avec sa variante.
Les conventions de nommage ne sont pas du zèle

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.

Écran de sélection Simple Job Selection de SM37 avec filtres sur nom de job, utilisateur, dates et statuts
Simple Job Selection : filtrer par nom, utilisateur, période et statuts avant d’afficher la liste.

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.

Liste Job Overview de SM37 avec les colonnes JobName, Status, Start date, Duration et Delay, statuts Finished en vert
Job Overview : statuts, horaires, Duration et Delay de chaque exécution, avec les actions Release, Spool, Job log et Step.

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 ressources background ne sont pas infinies

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.

Partager

À lire ensuite

Tutos SAP

ABAP debugger : le guide du consultant fonctionnel pour lire un programme SAP

Dump SAP, champ au mauvais montant, programme opaque : l'ABAP debugger en lecture. 4 accès, navigation F5 à F8, breakpoints et watchpoints, écran par écran.

Michael Antoine Michael A. 11 min de lecture
Carrière SAP

SAP Learning Hub : avis, prix et faut-il vraiment payer pour pratiquer ?

SAP Learning Hub vaut-il le coup en 2026 ? Avis produit : éditions actuelles, prix réel, système d'entraînement, certification et validité d'un an, et verdict par profil.

Michael Antoine Michael A. 13 min de lecture
Carrière SAP

S/4HANA vs ECC : les différences clés pour votre carrière SAP

Quelle différence entre SAP ECC et S/4HANA ? Les différences clés expliquées simplement, le jargon décodé, la fin de maintenance d'ECC et ce que cela change pour votre carrière SAP.

Michael Antoine Michael A. 13 min de lecture
Tutos SAP

Valorisation séparée SAP MM : concept et configuration

La valorisation séparée dans SAP MM : catégorie contre type, configuration dans OMWC, activation sur la fiche article et impact sur le prix moyen mobile.

Michael Antoine Michael A. 18 min de lecture