Is there a way to debug a call transaction that is executing in the background? I have a process that works in mode 'A' but isn't working in background. In my debug settings, I tried checking the "Always process requests synchronously" checkbox but that doesn't seem to work.
Mike
4 Answers
-
Former MemberPosted on Dec 08, 2004 at 03:28 AMWhen you say "Debug a Call Transaction", what are you exactly looking for ?
a) Do you want to debug that transaction ?
b) Do you want to check whether each value of the field in that transaction is getting populated properly ?
Let us know, perhaps we can help better.
Regards,
Subramanian V.
Add a comment
-
Posted on Dec 08, 2004 at 08:17 AM
I'm afraid you cannot really debug in mode 'N', but you can try CALL TRANSACTION with addition OPTIONS FROM ctuparams, where ctuparams must be a variable of DDIC type CTUPARAMS. In ctuparams you can set display mode, update mode, and also the flag NOBINPT = 'X'. With this flag set the transaction will think it runs in online mode, that is variable sy-binpt will be cleared for this transaction. The matter is that some transactions change their screen sequence depending of the flag sy-binpt.
Hope this helps.
Add a comment
-
Former MemberPosted on Dec 08, 2004 at 08:32 AM
Hi mike,
What you can do, (not the nicest way but it works nevertheless). If you can edit the transaction insert the following statement:
data: x(1) type c.
while sy-uname = 'your userid here' and x is initial.
endwhile.
using transaction sm50 You can now debug it because it's in an endless loop.
Not the prettiest way, but workable as a last resort. Then again I didn't mention this 😊
Add a comment
-
Posted on Dec 08, 2004 at 02:41 PM
Thanks all. I was hoping with 4.7 I might have some new debugging options. This is one of those really tricky Call Transactions with message pop-ups (where we really should be using a bapi anyway). The CTUPARAMS method still doesn't show me why I'm failing in background. I suppose I'll have to try the sm50 method.
Add a comment
Add a comment