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:

To execute a program in the background it is has to be scheduled as batch job in standard SAP (Menu: System => Services => Batch jobs, or transaction SM37), or by executing with the option (for reports) Program => Execute in batch.
An ABAP running directly (not in the background) cannot be active for more than approximatly 20 minutes (technical maintenance can set the exact TIME_OUT duration). A TIME_OUT program-dump will stop the ABAP. This mechanism is SAP's way to make sure the end user does not consume to much processor time. TIME_OUT’s are not thrown at programs running as a background job !

Run a report in the background

Whenever you want to run a report in the background, variants become important. A batchjob always needs a variant. However, you might not always notice: when the report is started and the following menu option is chosen: "Program => Exec. in background", the actual variant is simply build up from the information you just entered in the selection screen.

When you plan a batch job, the program name and it's variant will need to be supplied. You will need to take into account the fact that whatever the program defaults can (will) be overwritten by what is supplied by the variant. This means that you need to supply your own values !

Scheduling a batch job from an ABAP

To schedule a batch job from an ABAP the function building blocks JOB_OPEN, JOB_SUBMIT and JOB_CLOSE have to be called (in this sequence). A job is initialised with JOB_OPEN, the SAP system generates a number: JOBCOUNT that is used as the identification for the batch job. JOB_SUBMIT is used to fill in a STEP of a batch job. Such a STEP contains for example an ABAP report with a certain variant. Several STEPs can be entered in a single JOB_SUBMIT. To close and activate a batch job, use JOB_CLOSE.

When batch jobs need to be scheduled without using COMMIT WORK, because it could screw up your processing because it is called via a function module IN UPDATE TASK(yeah, it happened !) there are some alternative functions available: try using JOB_OPEN_ADK, JOB_SUBMIT_ADK and JOB_CLOSE_ADK.

And just to have an easy to use alternative: call function WIZARD_JOB_OPEN, then do a SUBMIT like so:

DATA: lv_jobname  TYPE tbtcjob-jobname 
        VALUE 'Z_ABAP_TRIGGERED_JOB',
      lv_jobcount TYPE tbtcjob-jobcount.

      CALL FUNCTION 'WIZARD_JOB_OPEN'
        EXPORTING
          jobname  = lv_jobname
          jobclass = 'C'
        IMPORTING
          jobcount = lv_jobcount.

      IF not lv_jobcount is initial.
* Submit Request to perform a report
        SUBMIT zg_some_report TO SAP-SPOOL
             DESTINATION sy-pdest
                VIA JOB lv_jobname
                NUMBER lv_jobcount
                WITH p_cheese = 'Maasdammer'
                WITHOUT SPOOL DYNPRO
                AND RETURN.

* Add additional steps here if you need

        CALL FUNCTION 'JOB_CLOSE'
          EXPORTING
            jobname   = lv_jobname
            jobcount  = lv_jobcount
      ENDIF.

If you're looking for an even easier way to schedule your batch job from an ABAP, maybe you should consider the CALL DIALOG statement for dialog module JOB_SUBMIT.

CALL DIALOG 'JOB_SUBMIT' 
  EXPORTING RALDB-REPORT FROM 'ZTESTER' 
            RALDB-VARIANT FROM 'VARIANT'.

or maybe function module SIMPLE_BATCH_JOB_SUBMIT.

The printer destination

Use the structure PRI_PARAMS to fill in all sorts of printer parameters like destination and lay-out. Printer parameters can be passed to JOB_SUBMIT as a parameter. How to collect "standard" user's printer parameters, can be plagiarised from the application SAPLSPRI, printing SAP reports. Mind the routine: GET_PRINT_INFO that calls SET_LAYOUT, SET_FORMAT and SET_DEPARTMENT.

Job class

Not all parameters for a batch job can be entered via JOB_OPEN, JOB_SUBMIT or JOB_CLOSE. For example entering the job class (A, B or C). Use BP_JOB_READ to retreive currently set batch job data. Adjustments can be made directly on this data, for example: JOBHEAD-JOBCLASS = ‘B’. To activate the changes made, call function BP_JOB_MODIFY.

Interesting function modules on batch jobs:

BP_JOBLOG_READ Read the job log (much like SM37)
BP_JOB_COPY, BP_JOB_CREATE, BP_JOB_DELETE, BP_JOB_GET_PREDECESSORS, BP_JOB_GET_SUCCESSORS, BP_JOB_MODIFY, BP_JOB_READ, BP_JOB_SELECT and also JOB_OPEN, JOB_SUBMIT and JOB_CLOSE.

Hanging jobs

It may happen that SAP's administration for scheduled batch jobs contains faults. A job that has been terminated (e.g. via the list of processes) but retaines its status "active", becomes "untouchable". SAP will report 'action not possible due to current status of job' whenever you try something. These jobs can be tackled out with the ABAP RSBTCRPR, an ABAP turning all active statuses into "terminated". Be careful with this ABAP, it will cause active jobs to be terminated.

If you are interested in cleaning the job logs of background jobs that have already done their duty, use report RSBTCDEL - Clean background job logs.

• Prev
• Next