Debug RFC destination system

[joan_ayala]

Hi,

debugging production system A, I call an RFC function module in production system B, but instead of starting debugging system B, it continues debugging next step of system A.

I don't know why this is happening, I can debug both systems A and B separately, but when calling B from A, I cannot debug system B.

My user in system A is: des005

My user in system B is: des005

The passwords are not the same.

Thanks in advance

[Sandeep_Kumar]

Put a break-point in the target system for RFC call or what you can try is put an while endwhile statement at the starting of rfc call in remote system and debug it.

[joan_ayala]

I tried putting 2 breakpoints:

- break des005.

- break-point.

But it doesn't stop. It seems that there must be a configuration parameter of the system, allowing debugging from another system or not.

[Former Member]

Hi,

Put an external breakpoint in system B and make sure you have a session open in system B.

Thanks,

Wenonah

[Sandeep_Kumar]

Check St22 if there are any runtime errors for this rfc ...

[joan_ayala]

How can I put an external breakpoint in 4.6 C ?

[joan_ayala]

Yes, something is appearing ST22, but I do not understand it at all. The error says:

The termination occurred in the ABAP/4 program "SAPLCJWB " in

"%_CTL_OUTPUT".

The main program was "SAPLCJWB ".

The termination occurred in line 37

of the source code of program "<SYSINI> " (when calling the editor 370).

[Sandra_Rossi]

Joan, to complete Uwe's answer, it's valid for synchronous RFC, but you didn't tell us what kind of RFC it is, i.e. how is the CALL FUNCTION statement? (because if it's asynchronous, you won't be able to debug (without external break-points which don't exist in 4.6C), and transactional RFC calls occur later at COMMIT WORK, and anyway it's finally an asynchronous call...)

Could you paste the whole CALL FUNCTION statement please?

[uwe_schieferstein]

Hello Joan

Your SAP user in the RFC system B is irrelevant but who is the RFC user defined in the RFC destination that you use to go to system B. Check the RFC destination and whether this RFC user is of type "Dialog". If not then you cannot debug in the remote system.

If the RFC destination is not suitable you may create an additional RFC destination to system B without RFC user. In this case the logon for system B will show up where you can enter your User name and password. Then you can continue debugging in the remote system. However, take care of the fact that the authorizations may be different for you and the RFC user.

Regards

Uwe

[joan_ayala]

The RFC user defined in the RFC destination is: des005

and all mentioned users are of type "Dialog". I don't want the logon for system B to be showed up.

My RFC is like this:

                    call function 'ZRFC_UPDATE_PROJECTE' destination 'EDURFC'
                      exporting
                        i_projecte       = lwa_projecte
                      tables
                        o_messtab        = it_messtab
                      exceptions
                        no_exist_pepampl      = 1
                        system_failure        = 2
                        communication_failure = 3
                        others                = 4.

[uwe_schieferstein]

Hello Joan

Here is my recommendation to facilitate debugging:

DATA:
  ld_rfcdest     TYPE rfcdest.

  ld_rfcdest = 'EDURFC'.

call function 'ZRFC_UPDATE_PROJECTE' destination ld_rfcdest
                      exporting
                        i_projecte       = lwa_projecte
                      tables
                        o_messtab        = it_messtab
                      exceptions
                        no_exist_pepampl      = 1
                        system_failure        = 2
                        communication_failure = 3
                        others                = 4.

If you cannot debug using RFC destination "EDURFC" then I recommend to define a dummy RFC destination (e.g. "SysB" which just contains the technical details of the remote system.

Set a break-point at the CALL function statement and then overwrite LD_RFCDEST with the dummy RFC destionation.

The login popup will appear and if you are allowed to do debugging in the remote system you should be able to do so.

Regards

Uwe

[joan_ayala]

Hi,

I created the dummy RFC destination in 2 ways:

- With Trusted System = NO --> I got system failure when executing the RFC

- With Trusted System = YES --> The debugging did not go into system B, and no popup to introduce login and password was shown. The execution continued in next step of system A.

[Sandra_Rossi]

Try as Uwe said: define your RFC destination without user name and password.

[joan_ayala]

that's what I did Sandra.

[Sandra_Rossi]

please paste the dump (respect 2500 char. max)

[joan_ayala]

if you refer to the ST22 dump, I have to say that I am getting no dump nor entry in ST22.

Probably I had a confusion when I wrote about the ST22 dump in a previous post.

[Sandra_Rossi]

you may retrieve a description of the error using MESSAGE keyword:

DATA msg TYPE c LENGTH 80.
CALL FUNCTION func DESTINATION dest 
    ... 
    EXCEPTIONS 
        SYSTEM_FAILURE = 1 MESSAGE msg 
        COMMUNICATION_FAILURE = 2 MESSAGE msg.

[joan_ayala]

ok Sandra, if you mean the 'system failure' produced when I use the dummy RFC destination with Trusted System = NO, this is the message stored in variable 'msg':

"User is locked. Please notify the person responsible"

[Sandra_Rossi]

Could you tell me how is it possible that SAP tries to log with a (locked) user if you removed this user from the RFC destination? (you told me it was removed but it's not)

I guess you have the solution now.

[joan_ayala]

I removed the user and password from the RFC destination !!!

I don't know why this is happening.

[Sandra_Rossi]

It must be because you declared the RFC destination as trusted (so it tries to connect with the same user (whatever password is), it won't work if the user is locked as is your case).

Well, as you have the solution, you have to simply ask the admins to unlock your user in target system.

if you want to "untrust" the RFC destination, use SMT1 in source system, and SMT2 in target system.

[SuhaSaha]

Hi,

- With Trusted System = YES --> The debugging did not go into system B, and no popup to introduce login and password was shown. The execution continued in next step of system A.

I just read the SAP F1 documentation on "trusted system" & interestingly SAP says:

"If this system is registered as a Trusted System in the target system, then you can execute RFCs in the target system without specifying a password explicitly."

>

> I removed the user and password from the RFC destination !!!
> I don't know why this is happening.

May be you should read the "troubleshooting" section of this documentation: [http://help.sap.com/saphelp_nw04/helpdata/en/8b/0010519daef443ab06d38d7ade26f4/content.htm]

Edited by: Suhas Saha on May 3, 2010 11:47 PM

[Sandra_Rossi]

> May be you should read the "troubleshooting" section of this documentation: [http://help.sap.com/saphelp_nw04/helpdata/en/8b/0010519daef443ab06d38d7ade26f4/content.htm]

More exactly at this close address [http://help.sap.com/saphelp_nw04/helpdata/en/22/042671488911d189490000e829fbbd/frameset.htm]

[joan_ayala]

I appreciate very much your help, but I really think it must be a system configuration issue (something like that the system called by the RFC connects doesn't accept debugging when coming from an RFC).

And I think that because I have the exactly same scenario in my Development systems, and I

can debug the system called by the RFC.

All my previous posts were about my Production systems.

[Sandra_Rossi]

Make sure the user is not locked in target system in production and that it is dialog or service (simply log in), and that it has debug authorizations (try /H directly there). By the way, if you use trusted RFC, then password is not checked.

If it's not the issue, then I think the admins should run RFC trace. Here are notes that can help you:

Note 65968 - ABAP debugging authorizations

Note 300208 - Single step debugging of RFC calls: says that user must be dialog or service to be able to debug

Note 905364 - Authorizations for single step debugging of RFCs

Note 176277 - Generating RFC trace information

Note 532918 - RFC trace generation scenarios

Note 878962 - RFC tracing for ABAP-to-ABAP communication

[joan_ayala]

Finally I managed to debug using the classic debugger in the system that calls the RFC.

You can see that here:

Note 868830 - Cannot debug an RFC in a HTTP session

[Sandra_Rossi]

Joan, thx for the feedback.

Just to be sure to understand, you mean that you were connected on the system A using web server (webgui), for example web dynpro, and you added an external breakpoint in system A just before call to RFC function module. Then pressing F5 didn't work.

I did a test and found that it depends on the ICF service option "GUI connection": if it is set to "Yes", step into will work, and if it is set to "no" (or not specified), it will work only as explained in the note you mentioned.

[joan_ayala]

Sandra,

that's exactly my case. But I checked my ICF configuration for my webdynpro application, and both in Development and Production systems, the "GUI connection" is set to "Not specified"...