Création d’un « JOB » SAP : quelle bonne pratique ?

Définition « JOB » SAP

Avant de vous parler de la bonne pratique que je souhaite vous partager, nous allons tout de même revenir rapidement sur la définition d’un JOB dans SAP !

Un JOB permet d’automatiser une tâche ou une succession de tâches de façon régulière.

Il existe des jobs « fonctionnels », par exemple : on peut imaginer que tous les jours à heure fixe, on souhaite créer automatiquement les bons de préparations suite aux prises de commande du matin ! Et hop, une tâche de moins pour le responsable préparation 🙂

Il existe aussi des jobs « techniques » : vider les spools régulièrement par exemple pour éviter un engorgement.

Bien évidemment, il y a d’autres possibilités mais nous avons le principale pour une compréhension générale !

Utilisateur et Job : bonne pratique

Lors de la création d’un job donc 🙂 , il faut absolument penser long terme et sécurité ! En effet, vous créez un job aujourd’hui ….. et il sera utile pendant longtemps. Certainement des années. Or si un jour l’utilisateur qui exécute ce programme est « désactivé » … plus de job ! C’est une première raison pour utiliser un « user batch » comme on dit dans le jargon SAPien ! Un « user batch » est un utilisateur « technique » créer uniquement pour exécuter des jobs, programmes, connexion avec l’exterieur, ….

La deuxième raison est de l’ordre de la sécurité ! On va gérer des autorisations bien spécifiques pour ces utilisateurs. Il n’ y aura pas d’effet de bord en cas de modifications de rôles.

En pratique : Transaction SM37

Via la transaction SM37, on va pouvoir piloter les JOBS.

Il y a deux notions :

# L’auteur du JOB : cela peut être vous ou quelqu’un d’autre. Peu importe, cela n’a pas d’incidence sur l’exécution du job lui même.

SAP SM37 auteur job

# L’utilisateur dans l’étape du JOB. C’est ici qu’il est préconisé d’y mettre un « user batch ».

JOB SAP user batch

Et surtout n’oubliez pas ! Si vous avez apprécié cet article, inscrivez-vous à la Newsletter pour être informé des prochains articles !

Un commentaire

  1. Bonjour;
    Un Job pourrait être créé, par un utilisateur, via l’exécution en arrière plan d’une transaction, par exemple la liste des commandes client, sans pour autant utiliser SM36 ou SM37. Bien sûr on verra les écrans des ces dernières transactions pour définir les attributs du job.

    Dans ce cas, comment l’utilisateur pourrait-il voir l’état de son job, arrêter son job, le supprimer ou voir les résultats générés (Spool) cela sans la possibilité d’altérer les jobs des autres utilisateurs..

    Nous n’avons pas réussi, à aujourd’hui, via les autorisations et les rôles à mettre cela en place. Auriez-vous une idée ?

    Merci pour votre aide toujours appréciable
    Cordialement

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *