Background Jobs and Their Classification

Download as doc, pdf, or txt
Download as doc, pdf, or txt
You are on page 1of 6

Background jobs and their classification

Maintained by

Date: 13-Jul-2009 Version: 0.0

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

IN MCKESSON, WE MAINLY USE EXTERNAL COMMANDS/EXTERNAL PROGRAMS TO RUN SCRIPTS.

Background Processing Tasks:

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.

Administering background jobs

Monitoring background 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.

Different type of jobs:


Usually, we monitor 3 types of jobs in McKesson.

1.) User Jobs 2.) Support Jobs 3.) Maestro Jobs


User jobs are those which are executed on request of particular user only. User might request for support job or Maestro job also based on the requirement. Jobs which are created in SAP and are executed without using any external scheduler are called support jobs. These jobs are used to perform the regular processed in the system. For Maestro jobs, we use the external scheduler called MAESTRO. Maestro coordinates and automates production scheduling of mission-critical applications, systems and networks and ensures consistent operation of the distributed processes that effect service delivery. Procedure to create MAESTRO job in McKesson: 1. Fill the attached form to request for a job.

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

You might also like