Background Jobs and Their Classification
Background Jobs and Their Classification
Background Jobs and Their Classification
Maintained by
Definition:
The work unit of the background processing system is the background job, each of which consists of one or more job steps. Jobs and job steps enable us to treat complex tasks as single units. That is, we can schedule several programs needed to complete a particular task as steps within a single job, with the advantage of the job being single logical container for all the steps needed to complete the task. Assume that a particular data transfer with batch input requires starting two programs, an external program to prepare the batch-input session and an internal program to process the session. Creating a job made up of two steps lets us handle the two programs as a single unit. Scheduling that one job schedules both programs. The results of each program's run can be seen in the job log. To ensure that we can flexibly run individual programs, we can set important attributes individually for each job step, too. Each job step can: have its own spool, or output, specifications run under the authorizations of a separate user use a different language
There are two types of job steps: An executable ABAP program Only type 1, or executable, ABAP programs can be used as job steps. Module pools and function groups, which are collections of ABAP modules, are not allowed. The specifications required for an ABAP job step are: ABAP program + Variant + Print and archiving parameters + Language An external command or external program This type of job step allows us to run programs outside the SAP System. External commands are predefined, authorization-protected commands for end users. External programs are unrestricted, directly entered commands reserved for system administrators. The type of external command and external program is unrestricted, meaning that we can use either compiled programs or scripts. Such programs can be run on any computer that can be reached from the SAP System. Parameter passing to non-SAP programs is completely unrestricted except by the predefinition mechanism for external commands. Output of non-SAP programs, particularly error messages, is included in the job's log file. Specifications required for an external command or programs are: o o External command + Type of operating system + (Parameters) + Target host system External program + Parameters + Target host system
The most important administration tasks that we need to perform in relation to SAP background processing are listed below: Task Scheduling background jobs Description Before the actual background processing can start, we must first define and schedule the background jobs. We can use the transaction SM36 for the same The Job Overview (transaction SM37) allows us to administer jobs and is the central area for performing various job monitoring and job administration tasks. These include, for example, repeating, canceling, and deleting jobs. We should regularly check whether the jobs are executed. We can monitor jobs in the following ways: We can call the Job Selection transaction (transaction SM37) and check whether the jobs actually ran without errors. Check if any job is running long. Check out the other run times of the job and then compare if job is running long. Check, if job is reading from Rollback. If yes cancel that job and recover that as per recovery given in spreadsheet. If it is a user job, send an e-mail to user. If it is a support or maestro job, check what all the impacts it can have if it is running from long time. If some other jobs are getting impacted. We can set up job monitoring so that we are automatically notified if a job terminated or a runtime error occurred. With job monitoring, alerts are displayed if one of these errors occurred. If we assign an auto-reaction method to these alerts, we are notified, for example, by SMS or by e-mail if problems occurred during the execution of the jobs.
Troubleshooting
If errors occurred, we need to perform a problem analysis and start troubleshooting. When troubleshooting, it is often advisable to first check in the work process overview (transactions SM50 and SM66) whether the background work processes are still running.
SAP_BATCH_J OB_N AME.doc 2. Create a remedy change request to create this new job. Various steps to create this remedy change request are documented in the attached document
Rem edy Change Request sheet.doc 3. Create a job in SAP. But dont release it. Just create a template.
4. This job should be under SUPPORT ID. 5. Send the properties of this job to Maestro team. Like, Job Id, It is a unique Identifier for the job. SAP Job Name Dependencies, if any Preferred Maestro name Frequency of the job
When the job needs to be run for first time? Maestro will release an instance of the job in SAP. Advantages of Using Maestro: 1.) Criticality: If a job is very critical and we need to take immediate action if something goes wrong with the job, we create a Maestro job as Maestro will generate an alert if job fails. 2.) Dependencies: If job depends upon some files or other jobs on some other system, it is good to create job in Maestro. For example, a.) There is job in ECC and another in SP1. We want to run job in SP1, once ECC job is completed. We can schedule both the jobs on Maestro. It will keep checking ECC job, once it is completed, it will release instance of job in SP1. Such dependencies are easier to maintain in SAP. b.) Now complexity of dependency also matters. In McKesson, we have few jobs which are linked as AR_LBX_PRE_PROCESS
AR_LBX_CHECK
AR_LBX_POSTING
AR_LBX_CLEANUP
AR_STATEMENT_BKORM_CLEANUP
AR_WALMART_STATEMENT_DAILY
AR_WALMART_STMT_BALE_SUBMIT This kind of dependency is easier to maintain in Maestro. 3.) Scheduling: There could be scenario, where a job depends upon a file. If file is not there, job will be failed. But we want to wait for some more time as the file might be delayed. So we can do scheduling like wait till particular time before it gets failed. This kind of scheduling is easy to do in Maestro. 4.) There is no risk of forgetting anything, as Maestro generates the alert if anything goes wrong with some job. 5.) A scenario which is most unlikely to happen, but we have observed that sometimes support jobs gets disappear from SAP. In that case, if it is run by Maestro, instance will not be released and job will be failed at MAESTRO and we will get the alert. So we can take timely action to run the jobs successfully.
NOTE: IT IS OUR RESPONSIBILITY TO GATHER ALL THE REQUIRED INFORMATION. IF THERE IS ANY DOUBT REGARDING WHAT NEEDS TO BE DONE AND WHOM NEEDS TO BE CONTACTED, DO NOT PROCEED TO SCHEDULE THE JOB