Debugging RFC FM when cannot put break point in the FM

[hagit]

Hello experts,

The scenario is:

There is a Z program.

The user type, which runs the Z program, is defined as Dialog user in SU01 (Logon data tab)

THE Z program calls FM - ALSM_EXCEL_TO_INTERNAL_TABLE

ALSM_EXCEL_TO_INTERNAL_TABLE calls in a deeper step to FM -DP_GET_STREAM_FROM_FRONT (step 12)

FM DP_GET_STREAM_FROM_FRONT calls RFC FM DP_GET_CLIENT_TABLE45A

When I press F5, it does not enter the function DP_GET_CLIENT_TABLE45A , but jumps to the next line (162)

How can I debug the RFC FM?

I cannot put external break point in the RFC FM because I cannot display it via SE37.

Thank you in advance

Hagit

[hagit]

Hello experts,

The scenario is:

There is a Z program.

The user type, which runs the Z program, is defined as Dialog user in SU01 (Logon data tab)

THE Z program calls FM - ALSM_EXCEL_TO_INTERNAL_TABLE

ALSM_EXCEL_TO_INTERNAL_TABLE calls in a deeper step to FM -DP_GET_STREAM_FROM_FRONT (step 12)

FM DP_GET_STREAM_FROM_FRONT calls RFC FM DP_GET_CLIENT_TABLE45A

When I press F5, it does not enter the function DP_GET_CLIENT_TABLE45A , but jumps to the next line (162)

How can I debug the RFC FM?

I cannot put external break point in the RFC FM because I cannot display it via SE37.

Thank you in advance

Hagit

[Dominik_Tylczynski]

Hello hagit

You can't debug the DP_GET_CLIENT_TABLE45A function in ABAP debugger as the function is not implemented in ABAP. It's not even created in SE37. Notice that DP_GET_STREAM_FROM_FRONT calls DP_GET_CLIENT_TABLE45A using RFC destination SAPGUI. So I think DP_GET_CLIENT_TABLE45A is delivered with SAP GUI and implemented in C++

Best regards

Dominik Tylczynski

[hagit]

3a9e4ce873a94034b33dc62b0ce600ee Thank you for your answer.

So there is no way to debug the function?!

[Sandra_Rossi]

hagit The function exists only in SAP GUI (maybe compiled from language C?). There's no way to debug it except if you have the source of SAP GUI software (SAP proprietary software so you shouldn't have the source code).

[Dominik_Tylczynski]

hagit Even if you somehow debugged the function and found an issue, what would you do with that? You can't fix it by yourself as you don't have SAP GUI source code and you are not able to fix it. Your best course of action is first to update SAP GUI to the latest version, second open SAP support ticket if updating doesn't help.

[hagit]

3a9e4ce873a94034b33dc62b0ce600ee and sandra.rossi thank you for your comments.

The situation now is that sometimes when a user enters text, the text, which is uploaded into SAP is not the same as it was entered (it has extra #). The user is not aware of this. Except if he fetches this data via another report and tries to export it to excel. My aim was to identify the exact condition which adds the # and to add this condition to the Z program, which uploaded the excel file to SAP. When the condition is met, then the data will not be uploaded, and a message will be displayed to the user. If I could debug the function, then I might find the condition.

As you said the FM cannot be debugged.So I thought of another solution. (See in my comment to Sandra’s answer)

Thank you

Hagit

[matt]

You've got two other related questions.

https://answers.sap.com/questions/13726898/how-to-debug-buttons-code-in-cl-salv-tablefactory.html

https://answers.sap.com/questions/13734094/single-step-f5-does-not-go-into-method-cl-gui-fron.html

It looks like these were steps on the way to where you are now. What actually is it that you're trying to achieve with all this debugging of standard SAP? What is your actual problem?

[Sandra_Rossi]

It's part of SAP GUI Control Framework. Is there any issue with it?

[hagit]

matthew.billingham Thank you for your answer.

We have a Z program, which uploads an excel file to the SAP. It calls the FM ALSM_EXCEL_TO_INTERNAL_TABLE.

We have another Z program that fetches data from sap including the data that was uploaded from the excel file. The program creates ALV by cl_salv_table=>factory. When a user pressed the ‘Export’ button and then pressed ‘spreadsheet’ an error was displayed:

After pressing yes , another error was displayed:

Removed Part: /xl/sharedStrings.xml part with XML error. (Strings) Illegal xml character. Line 3, column 141703.

Removed Records: Cell information from /xl/worksheets/sheet1.xml part

I noticed that the FM puts a # as the separator between columns (It put the # in an internal table). But in one record with the data uploaded from the original Excel, the FM put a # in the data itself. (For example, the original data was 'aaa bb ccc 2020_08_03-07_40' it became 'aaa bb ccc 2020#_08_03-07_40'). This record caused the above error.

My goal is to understand why the SAP standard put # in the middle of the data. Which character makes SAP think it's the end of the column. (And later I can tell the user not to insert this character into the original Excel file.)

After debugging I came to conclusion that DP_GET_CLIENT_TABLE45A is responsible for it. Therefore I want to debug DP_GET_CLIENT_TABLE45A.

Could you please help?

Hagit

[hagit]

sandra.rossi Thank you for your comment.

What is SAP GUI Control Framework?

Please see my comment to matthew.billingham Could you please help?

[Sandra_Rossi]

Control Framework is all OLE controls that SAP has provided for improving the old SAP GUI, and that you can use via the classes CL_GUI_ALV_GRID, CL_GUI_TEXTEDIT, etc. Well documented in the SAP Library (and in the forum).

[Sandra_Rossi]

As it's a bug in the standard, it's probably fixed by a SAP note that you may install. If not, just contact SAP support, they will look into it.

[Sandra_Rossi]

NB: DP_GET_CLIENT_TABLE45A corresponds to "SAP Data Provider" in the SAP Library. It's one of the most technical topics, people usually don't need it, it's used internally by other SAP GUI Controls.

[hagit]

sandra.rossi Thank you for your comment.

I did not find SAP note, which fix the bug. Could you please help me to find it (if exists)

Thanks in advance

[Sandra_Rossi]

I can't search in SAP notes for you because I don't have the details. Note that I find many notes about "CLIPBOARD_IMPORT".

Anyway, as I said, you can still contact SAP Support.

One simple way is to install the latest SAP GUI version, because Control Framework is made of 2 parts, one in the ABAP backend, one in the SAP GUI, and see whether it solves the issue.

You said that one issue was about the character #. There can be 2 reasons:

• either ABAP is converting the encoding of a character from one code page to another and the character doesn't exist in that code page so # is used,
• or ABAP displays a non-printable character as #. You must look at the hex value (debugger) to know which exact character it is.

Possibly the hyphen character is not the classic character. To quickly troubleshoot, you may test your program once with classic characters and once with this special character.

[hagit]

sandra.rossi Thanks for your answer

In the debugger after the call to FM DP_GET_CLIENT_TABLE45A

The hex value of the character (2) before the inserted # is 3200

The hex value of the character (_) after the inserted # is 5F00

(The hex value of # is 1F00)

In the second line of the excel file I typed the same characters (i.e. ‘2_’) and it has the same hex value. (but after FM DP_GET_CLIENT_TABLE45A # is not inserter between 2 and #)

Thanks

Hagit

[hagit]

sandra.rossi

In the second line of the excel file I typed the same characters (i.e. ‘2_’) and it has the same hex value. (but after FM DP_GET_CLIENT_TABLE45A # is not inserter between 2 and #)

Thanks

Hagit

[Sandra_Rossi]

You still want to investigate on the hard side, although you'd better first try with the latest SAP GUI version, just to see if the fix is NOT ABAP, then open a ticket at SAP Support.

I can deduce from the hex values that your server CPU is little endian. So 1F00 is character U+001F "information separator one" or "unit separator".

I found no information, neither in the Web, nor in SAP notes, why such a character would be added.

For information, concerning the Excel error, the character U+001F must be encoded _x001F_ (and same for any "non-XML character") in the zipped file sharedStrings.xml inside the XLSX file. I see in the method ADD_SHAREDSTRING of class CL_SALV_BS_OFFICE2007_BASE that there's no such encoding for special characters, and I couldn't find any note to fix that (but could have been done as part of a release - SP0).

Answer these questions for yourself (because only SAP can help), but only after you have tried with SAP GUI and contacted SAP support:

• Is the character U+001F actually in the Excel file or is it Excel/ABAP copy/paste which adds this weird character? To answer that question: create a very simple Excel file with only one cell, which contains the value 2_ (that you type manually), and very simple ABAP program calling ALSM_EXCEL_TO_INTERNAL_TABLE, does it still happen? Do the same by copy/paste the cell value instead of typing manually.
• Do you use a remote desktop? (Citrix or anything else / maybe there's an error with the clipboard)

To conclude, there are 3 possible root causes:

• Your Excel file contains the unexpected character U+001F -> remove it
• Or SAP bug in reading the clipboard (due to your configuration? what about other configurations)
• There is a SAP bug in ADD_SHAREDSTRING of class CL_SALV_BS_OFFICE2007_BASE which doesn't encode correctly the non-XML characters (like U+001F)

NB: with SAP GUI 7.70 SP3 and ABAP 7.56 SP0, the Excel error still occurs:

TYPES: tt_scarr TYPE STANDARD TABLE OF scarr WITH EMPTY KEY.
DATA(table_scarr) = VALUE tt_scarr( ( carrid = 'LH' carrname = 'Lufthansa' && cl_abap_conv_in_ce=>uccp( '001F' ) ) ).
cl_salv_table=>factory(
  IMPORTING
    r_salv_table   = DATA(salv)
  CHANGING
    t_table        = table_scarr ).
DATA(xstring) = salv->to_xml( if_salv_bs_xml=>c_type_xlsx ).
PERFORM write_bin_file USING 'C:\temp\text.xlsx' xstring.

(I don't provide WRITE_BIN_FILE as it's classic programming - don't forget to save as format 'BIN')

[hagit]

sandra.rossi thank you for your answer.

My Excel file contains the unexpected character.

As mentioned before, the FM is called with RFC destination ‘SAPGUI’

In SM59 I notice that for ‘SAPGUI ‘destination it is defined that # will be inserted when conversion errors occur.

sm59

Maybe this is the reason why # is inserted instead of the unexpected character.

In SM59 It is not possible to change the SAPGUI destination properties. Therefor my solution was in the step of loading the Excel file. In the Z program the code identifies illegal XML characters and avoids loading the file in the case they are exist in the file.

identify illegal XML characters

Thank you

Hagit

[Sandra_Rossi]

Thank you for the feedback!

There's no problem with the destination "SAPGUI" in SM59.

The actual problem is the one I told you, and you agreed in fact: the error was due to the input Excel file which contained the character U+001F, and standard ALV XLSX export is buggy, it generates an invalid Excel file if a cell contains the character U+001F.

[Dominik_Tylczynski]

I do agree, if the conclusion is that AVL XLSX export is buggy, a SAP Support ticket needs to be opened to address the issue.