Programs can be scheduled to run in the background. Scheduled jobs or background tasks are performed at set times and usually in a repetitive manner, e.g. to "host" an interface that runs every hour. But such job can also be scheduled to run once and immediately, so you don't have to wait for your report to run. How this works, why it should be done, how it's done and understanding batch job scheduling is explained here. A mixture of batch job related short-topics:
Background jobs can be scheduled through SM36
- which is used in all SAP implementations. Alternatively a background job can be scheduled from a report or by an Abap report. Batch job scheduling has it's limitations. Hence: the Batchjob scheduler was introduced.
A report on reports, time-management style. This report shows what jobs were started and stopped in an hour-by-hour overview for a single day. This reveals valuable insight on the system's busy times and total run time. How many hours were consumed by all of yesterday's batch jobs ? A simple but very effective bit of tooling. Why doesn't SAP have this ? I'm sure they do have something like this, just haven't found it yet.
Using messages as progress indicators for batch jobs You may have had a look at the job log for a background job, which lists the messages issued by the program running in the background. When you would like to use this in your own programs, simply issue type "S" (Skip) messages that indicate the program's progress.
These are some lessons learned about background jobs - that could avoid you having to learn the same lesson the hard way. Poor performance and finding input files..
When a task is running it will show in the SM50
process overview, whether it's a dialog task executed by the end user or background task scheduled automatically. SM50
reveals the process overview for the application server you are logged on to. Would you like to widen the search ?
A background job can be used to cover many requirements. A practical mini-guide to the options (the power) available...
Batch jobs can be an interesting approach where the following features can be utilized:
- The TIME_OUT issue is no issue (see background jobs - lessons learned)
- Allowing a background job to perform a task for which authorization is an important issue: the user that schedules a background job can be a maintenance-type user, super-user or even non-dialog user. This means there is no need to authorize an end user for the tasks that can be performed in the background.
An interresting approach to tackling performance problems - is executing steps as background tasks. Parallel processing or starting new tasks can be done from a dialog task as well as a background task. Here's how it works, and here's also why you should NOT do this.