01-08-2016 2:07 PM
Hi,
I want to debug an workflow method (ABAP OO) via t-code SM66 but every time I click the "Debugging" button and confirm with "Yes", I get an authorization error. The t-code SU53 shows me two failed authorization checks:
- Authorization object S_DEVELOP: Activity '02'; Object type 'DEBUG';
- Authorization object S_DEVELOP: Activity '90'; Object name ' '; Object type 'DEBUG'; P_GROUP ' ';
This also applies to t-code SM50.
Why do I need Activity '02' for debugging via SM66? I do not need to change any local variable during debugging so it is not really necessary.
Is there an SAP Note for this or another way to debug this kind of task?
01-08-2016 2:15 PM
SAP introduced this in about release 4.7 "Enterprise". So it is intentional, I am pretty sure, that debugging foreign work processes is classed as change mode being the correct authorization level to check.
The same applies to debugging background jobs in SM37.
Only external break-points and RFC debugging seem to have been spared the stricter check. That might however also be your solution -> change WF-BATCH to SERVICE type user, set a break-point in your own application and then switch to the system debugger and F5 into the WORKFLOW destination.
Cheers,
Julius
01-08-2016 2:15 PM
SAP introduced this in about release 4.7 "Enterprise". So it is intentional, I am pretty sure, that debugging foreign work processes is classed as change mode being the correct authorization level to check.
The same applies to debugging background jobs in SM37.
Only external break-points and RFC debugging seem to have been spared the stricter check. That might however also be your solution -> change WF-BATCH to SERVICE type user, set a break-point in your own application and then switch to the system debugger and F5 into the WORKFLOW destination.
Cheers,
Julius
01-08-2016 3:08 PM
The user who executes the workflow in the background is not the user WF-BATCH. It is another user with user type 'C' (communication) according to t-code SU01.
What do you mean with system debugger?
01-08-2016 3:11 PM
Which ever user it is in the RFC connection then. Normally it is WF-BATCH.
You can debug RFC calls if the user in the correction is authorized for debugging (display) and is SAPGui capable for the debugger to attach to it.
Set your break-point ahead of the call function func destination. Enter /HS in the ok-code, hit enter and F5 -> single steps into the RFC debugger (and the connection context).
Cheers,
Julius
01-11-2016 8:13 AM
Could you please tell me the function or method where I should set a break-point?
The workflow will be triggered via event (tcode SWEC event linkage for change documents).
01-11-2016 3:21 PM
The call itself will be either FM SWF_EVT_HANDLER_START_INTERNAL or more likely SWW_WI_EXECUTE_INTERNAL_RFC (depending on scenario). That is the one you want to either externally debug OR set a break-point for yourself in the calling program and then switch to system debugger as described before.
Side note: as this sort of this is not an everyday occurrence and switching the RFC user in the Workflow connection to SERVICE temporarily is dangerous (depending on it's authorizations...), would it not be easier to have an emergency access procedure to temporarily grant yourself some more powers and debug it from SM66.
What I am describing above has actually been more a workaround to debug the workflow anyway as the RFC user and not really the best solution tailored onto to authorizations that you need temporarily.
However if the RFC user has ACTVT 02 and 70 then you are home and dry to go to SM66 as the RFC user instead... in that case you can set your break-point where ever you want to as all you want is a session back from the destination.
Just my opinion.
Cheers,
Julius
01-15-2016 8:24 AM
As a general question and not relating to workflows: I can debug into a RFC function module call (the current user SY-UNAME is WF-BATCH in this case). However, the break-points set by my user will not be reached. How can I activate them for the RFC user?
Side note: If I enter /HS in the ok-code and hit enter, it displays "Function is not possible".
01-15-2016 8:40 AM
Set your break-point before the call. Enter /HS immediately before the call and single-step into the RFC call. You do not need to enter /HS again and cannot because OK-code commands are blocked within the RFC system debugger.
If you want to stop at a break-point within the RFC call, then set an external user break-point before hand for WF-BATCH. It should stop there if it reaches it.
But there is another little "dirty trick"... when you are displayed the message that the function is not possible, then display the message and navigate to the technical properties of the message by double-clicking it, then via the options go to "Other object" and select transaction SM66 -> F8.
Now you can debug normally in SM66 as WF-BATCH, assuming WF-BATCH is sufficiently authorized and is debugging it's own workflow.
Cheers,
Julius
01-19-2016 2:42 PM
Unfortunately, I am not allowed to change the user type of WF-BATCH to SERVICE. I have hoped that there is another way to enabled RFC debugging from SM66 or any other transaction without the authorization of debug and replace.
01-19-2016 3:10 PM
Then I think the only option left is to use the workflow trace if you can reproduce whatever the problem is, or to temporarily arrange for the debugging access with option to replace.
Note that ABAP debugging with actvt 02 can also be restricted to the object name which you are allowed to debug.
System debugging with actvt 01 however cannot.
Cheers,
Julius