Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

SM66 Debug authorization for workflow debugging

Former Member
0 Kudos

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?

1 ACCEPTED SOLUTION

Former Member
0 Kudos

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

9 REPLIES 9

Former Member
0 Kudos

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

0 Kudos

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?

0 Kudos

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

0 Kudos

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).

0 Kudos

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

0 Kudos

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".

0 Kudos

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

0 Kudos

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.

0 Kudos

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