‎2005 Nov 15 6:18 PM
Hi All,
Is there any way i can debug a FM called in "background task as separate unit" ? What is the difference if i call in background task and in update task? I think both gets triggered by a commit statement.
Regards,
Hari.
‎2005 Nov 15 6:25 PM
If calling in Update Task, then it runs in an UPdate Work process, if you call in background task, it is running in a background task.
The update task is a little special though.
REad on.....
CALL FUNCTION
Variant 3
CALL FUNCTION func IN UPDATE TASK.
Additions:
1. ... EXPORTING p1 = f1 ... pn = fn
2. ... TABLES p1 = itab1 ... pn = itabn
Effect
Flags the function module func for execution in the update task. It is not executed at once, but the data passed with EXPORTING or TABLES is placed in a database table and a subsequent COMMIT WORK then causes the function module to be executed by the update task. Update function modules must be flagged as such in the Function Builder
The return value is not set.
Addition 1
... EXPORTING p1 = f1 ... pn = fn
Effect
Values of fields and field strings specified under EXPORTING are passed from the calling program to the function module. In the function module, the formal parameters are defined as import parameters. In the interface definition, default values must be assigned to all import parameters of the update function module.
Addition 2
... TABLES p1 = itab1 ... pn = itabn
Effect
TABLES passes references to internal tables. All table parameters of the function module must have values.
Note
With update function modules, both import parameters and exceptions are ignored when the call is made.
Administration transaction
Related
COMMIT WORK, SET UPDATE TASK LOCAL
‎2005 Nov 15 6:22 PM
Hi Harikrishna,
I don't think one can debug an FM in a background mode.
AFAIK, a for an update task, a separate thread runs to process, in parallel with the called program.
Program execution doesn't wait for the control to get back from the Update task.
REgards,
Ravi
‎2005 Nov 15 6:25 PM
If calling in Update Task, then it runs in an UPdate Work process, if you call in background task, it is running in a background task.
The update task is a little special though.
REad on.....
CALL FUNCTION
Variant 3
CALL FUNCTION func IN UPDATE TASK.
Additions:
1. ... EXPORTING p1 = f1 ... pn = fn
2. ... TABLES p1 = itab1 ... pn = itabn
Effect
Flags the function module func for execution in the update task. It is not executed at once, but the data passed with EXPORTING or TABLES is placed in a database table and a subsequent COMMIT WORK then causes the function module to be executed by the update task. Update function modules must be flagged as such in the Function Builder
The return value is not set.
Addition 1
... EXPORTING p1 = f1 ... pn = fn
Effect
Values of fields and field strings specified under EXPORTING are passed from the calling program to the function module. In the function module, the formal parameters are defined as import parameters. In the interface definition, default values must be assigned to all import parameters of the update function module.
Addition 2
... TABLES p1 = itab1 ... pn = itabn
Effect
TABLES passes references to internal tables. All table parameters of the function module must have values.
Note
With update function modules, both import parameters and exceptions are ignored when the call is made.
Administration transaction
Related
COMMIT WORK, SET UPDATE TASK LOCAL
‎2005 Nov 15 6:43 PM
Hi,
In case you have not deleted the completed background Job, you can try this out..
1. In SM37 display the completed Job you want to debug
2. Select the job and type in 'JDBG' in the command window and hit enter..
just want to let you know there is a way to debbug the backgrond job..
Good Luck,
Suresh Datti
‎2005 Nov 15 9:06 PM
Hi All ,
Thanks for the replies. I do usually debug back ground jobs using these procedures. But in this case this FM is called in Background task from an user exit. How do i get the process id for this? Also i dont think i can see this through SM37.
Regards,
Hari
‎2005 Nov 15 9:10 PM
‎2005 Nov 15 9:19 PM
Hi Rich,
This is what i tried to do. But this FM changes details on a PO and is called from an exit called during the PO creation. It does a BDC to update the same PO. So if i try to run it in the same process it would lock me out. I am getting an error in the BDC and wanted to analayse that.
Regards,
Hari.
‎2005 Nov 15 9:23 PM
Try this. Run in your program in debugging up to the point of the call. In another session, run transaction SM50. Now execute the function module call and switch to SM50 screen. See if your function module execution is seen there under the type BGD. Select that and in the menu, 'Program/Session>Program>Debugging'.
If your function module really runs fast, then there is no way you can do this. It has to run atleast for a couple of seconds for you to do this.
Srinivas
‎2005 Nov 15 9:32 PM
Thanks. Its very quick, but i guess i can do some thing. Put in a conditional endless loop in the FM.
do.
if variable = 'X'.
exit.
Endif.
enddo.
In debug change the condition so that it exits. I hope this will work.
Regards,
Hari.
‎2005 Nov 15 9:37 PM
Yes if the function module in question is custom one, then you can do that.
Message was edited by: Srinivas Adavi
Let us know how it goes and if it works, please don't forget to close.
‎2005 Nov 15 10:04 PM
Yes! It did work. Once again thanks for all the responses.
Regards,
Hari.
How do i close this message?
Message was edited by: harikrishnan balan
‎2005 Nov 15 10:06 PM
‎2005 Nov 15 10:09 PM
‎2005 Nov 15 6:39 PM
Hi,
When you call the FM in background task, then a process id will be created for it. So then go to SM66 and Identify the process id then placing the cursor on the process ID press the debugging button. If you have authorization then you can debug it.
Thanks
Giridhar