Author: Andrea Olivieri
Supported Releases: SAP ECC 6.0
Submitted: 20 September 2010
Code is presented in below pages:
- Job Steps Analysis - Get Report Name & Variant Name from periodic Scheduled Jobs
- Save Variant Data
- Variant Catalog Creation
General Flow and Pre-requisites
During a spin-off project of an Italian company in the automotive industry, the customer asked me to identify all the programs variants (of scheduled jobs) containing a defined value of company code ( i.e 'A001') in the selection screen.
In previous upgrade projects, basically for target release 4.70, I used a specific ASU tool, the restore variant tool,which allowed me to use the old variants again in the new release.
So I asked myself why should I have to implement a program from scratch if there is a standard one out there that does everything I need ?
So starting from the ASU variant restore tool, I cloned the source code of the following standard programs:
- RASUVCAT: Creates a catalog of all variants
- RASUVSAV: Storage of variant information
Since the goal is to identify job's variants containing the value A001 of the company code, I divided the process in the following operational steps:
- Get the program name and variant name from batch jobs
- Create Variant Catalog (For the specified program names)
- Save the variant Data (only parameters of type BUKRS)
Function Groups ASU2,ASU4 as well as the DDIC Tables TASUVCAT, TASUVEXT, TASUVSVD and TASUNSVO should exist in the system
How It Works
1 - Job Steps analysis (Optional)
I focused exclusively on programs scheduled as periodic jobs, so I implemented an additional ABAP program which reads the job definitions of all jobs with the following states:
After that, from the related steps, gets the following information:
- Job name,
- Program name,
- Variant name
The output is a raw list.
Copy and paste the column program name from the output list in the selection screen parameter Report(s) of the Variant Catalog Creation program. The snippet of the job steps analysis program could be found here.
2 - Variant Catalog Creation (Mandatory)
Due to performance reasons, first of all you have to create the variant catalog; it's better to restrict the selection to certain reports. is filled .
As result, after the program update run, the TASUVCAT table.
The variant catalog program works in "Delta Mode"; this means that only the variants that were not taken into account during the previous run are cataloged again. The snippet could be found here.
3 - Save Variant Data
Starting from the variant catalog, the current variant data and attributes are stored in both tables TASUVSVD and TASUVSVO.
The TASUVSVD table contains the variant data and TASUVSVO contains the technical field descriptions (TVARV variables, protected fields, and so on).
The program saves only the values of the parameters related to a data element with domain bukrs. The program checks following condition:
The snippet could be found here.
4 - Get The results
You can get the results immediately by the transaction SE16 (table TASUVSVD)
Create, Schedule and release Job in program
This program is useful for create the transaction variant and run in background processing.
This program will create the transaction variant for a program.
New session will be opened using JOB_OPEN function module.
Program will be submit with variant for background schedule.
Author: Chaitanya Raju
Submitted: Dec. 14 2007
Description: For some background update jobs, you might want to stop the user from submitting the jobs twice.
Author: Sujeet Mishra
Description: This program is to Check Background Jobs are Scheduled Correctly or Not??
Note : Program has not any maintained Text Element, so please Maintain text instead of Hard coding it as in below Program, This Program is just a sample template for Reference.
Author: Sreekumar Hariharan
For faster results, we often execute programs in parallel using background jobs. Even though this might be a good idea in terms of processing efficiency, on many occasions this results in high utilization of the system resources and non-availability of background work processes for other key custom operations.
The below technique provides a controlled and conservative approach towards multiple/parallel job generation. With this technique, we can set a maximum utilization percentage and hence always reserve some work processes for other operations. The attributes like utilization threshold and delay can be input as a Parameter/ Select-option in the program or can be maintained in selection variable table TVARVC or a custom table, but to keep it simple I am going to use this as constants in the program.
The key function that we use in this method is TH_GET_WPINFO which returns the details of the active work processes in the system. The function takes as input 2 optional parameters SRVNAME (Application server) and WITH_CPU. If the job processing has to be limited to a specific server on the system, these parameters can be used to limit the query and later submit the job to the specific server group. But if no restrictions need to be imposed in terms of servers, these can be left blank. The function returns the list of work processes in the system and is similar to SM50 screen (except for the fact that SM50 shows the work processes only from the server on which user is logged on to). Based on this information, we can determine the total and available work processes and the background work process utilization level. Based on the percentage, we can either generate the next job or wait for predefined amount of time and try again.