‎2013 Apr 30 7:34 PM
Hello,
I'm creating a batch input for a transaction that is set and executed via code inside of another transaction, this is that whenever certain conditions are fulfill. In a bigger context there's a transaction that must be executed on background without the user noticing it's execution and to solve it I made this:
v_jobname = 'JOB_NAME'.
* We create the JOB
CALL FUNCTION 'JOB_OPEN'
EXPORTING
* delanfrep = ''
* jobgroup = ''
jobname = v_jobname
sdlstrtdt = sy-datum
sdlstrttm = sy-uzeit
IMPORTING
jobcount = v_jobcount
EXCEPTIONS
cant_creat_job = 1
invalid_job_data = 2
jobname_missing = 3.
IF sy-subrc = 1.
* Error handling
ENDIF.
* Setting the parameters and select options
SUBMIT YCXREBMMPURES000_INFORMEPAGO
WITH S_BUKRS IN s_bukrs
WITH S_BUDAT IN s_budat
WITH S_BLART IN s_blart
WITH S_BELNR IN s_belnr
WITH S_LIFNR IN s_lifnr
WITH S_KTOKS IN s_ktoks
USER sy-uname
VIA JOB v_jobname
NUMBER v_jobcount
AND RETURN.
IF sy-subrc <> 0.
* Error handling
ENDIF.
* Closing the Job
* starttime-sdlstrtdt = sy-datum + 1.
* starttime-sdlstrttm = '220000'.
CALL FUNCTION 'JOB_CLOSE'
EXPORTING
* event_id = it_starttime-eventid
* event_param = it_starttime-eventparm
* event_periodic = it_starttime-periodic
jobcount = v_jobcount
jobname = v_jobname
* laststrtdt = it_starttime-laststrtdt
* laststrttm = it_starttime-laststrttm
* prddays = 1
* prdhours = 0
* prdmins = 0
* prdmonths = 0
* prdweeks = 0
* sdlstrtdt = it_starttime-sdlstrtdt
* sdlstrttm = it_starttime-sdlstrttm
strtimmed = v_starttimeimmediate
* targetsystem = v_host
EXCEPTIONS
cant_start_immediate = 1
invalid_startdate = 2
jobname_missing = 3
job_close_failed = 4
job_nosteps = 5
job_notex = 6
lock_failed = 7
others = 99.
IF sy-subrc <> 0.
* Error handling
ENDIF.
As you can see I set the SO and the parameters using the same values the user entered on the selection screen this is because the program we call via background is the program itself, I mean when the program that is executed in background is the same related to the transaction being executed by the user, obviously the execution of the program is different in case it's running on background or online (by using sy-batch).
I found on the web that this would work but even the job is created, as it appears when checking SM36, the results that are supposed to be saved on a transparent table are not there. The problem is that I can't debug the program while being executed on background and find what the problem is and I'm not even sure it's been executed correctly.
So the main questions are:
Should this code work as it is?
How can I debug or check the execution of the program in background?
PD: This is the link where I found out the examples of the code I'm using: http://www.sapdev.co.uk/reporting/rep_submit.htm
‎2013 May 01 2:08 PM
Jose,
1. Check SM37 instead of SM36. Check the job logs to see if the job ran successfully.
2. To debug the job, use JDBG and check where/why the same fails. Since you said something about updating tables, It might be cuz of lock issues.
3. Add some wait time as suggested by Venkat and then goto SM66 and pick the job for debugging.
4. Check ST22 for any dumps from the job.
Vikram.M
‎2013 May 01 1:52 AM
Hi Jose,
For your First question we need to know these details.
What is the Transaction you want to call? What is the Program name?
For your second question,
There are several methods to debug a Background Job. One Example is as follows (More Technical)
1. Put a WAIT UP TO 30 Seconds in the Program after JOB_OPEN.
2. Execute the Program and Goto SM37.
3. Select your job and Click on the Application Servers in SM37
4. It will show list of Servers, Now Select the Server and Click on Processes (Black Screw Symbol)
5. Now Select your Program process and fromt he Menu you will find option Debug.
Hope this helps..
‎2013 May 01 2:36 AM
Hi Jose,
Try the transactioin JDBG. Its for Background Job debugging. Should help you understand where its failing.
Cheers,
Arindam
‎2013 May 01 2:08 PM
Jose,
1. Check SM37 instead of SM36. Check the job logs to see if the job ran successfully.
2. To debug the job, use JDBG and check where/why the same fails. Since you said something about updating tables, It might be cuz of lock issues.
3. Add some wait time as suggested by Venkat and then goto SM66 and pick the job for debugging.
4. Check ST22 for any dumps from the job.
Vikram.M
‎2013 May 02 9:35 PM
Thanks for all of your answers,
Like most of you suggested I used the transaction JDBG to debug the job and found the problem was when inserting information to the transparent table. Let me describe the problem, hoping it helps some one else, I was using the structure that is available when a transparent table is declared via "TYPES" as a work area and then when inserting to the table it seems the system was trying to insert all the information to the structure instead of the transparent table, I just created another work area and it worked perfectly.
Greetings and thanks again.