RFC trace filtered on function name?

[Ruediger_Plantiko]

Hi,

is it possible to collect in ST05 only the RFCs of a partical function module?

We are on SAP_BASIS 730, in a BI system, and we want to trace the call stacks of all RFC calls (of any user) of the function module RSAP_DATA_GENERATE. I tried to use the pattern "RSAP_DATA_GENERATE*" as filter for program name, but this didn't work.

How is the impact on the overall system performance?

Is there an alternative? SE30 with "special units"? How about performance in this case?

Regards,

Rüdiger

[yuri_ziryukin]

Hello Rüdiger,

tricky task, but I have a proposal.

Please try to use ST12 in mode User/Tasks. (ST-A/PI 01N SP1).

Switch the trace on for all users for RFC task types with many activations.

When you deactivate the trace after some time you'll get a list of ABAP traces recorded. This screen has a filter on function module. Please try to use this filter to collect only traces of your function module.

Please let me know if it worked.

Yuri

P.S. Greetings from former CRM support member. We worked a little bit together back in 2001 on CRM status management problem messages.

[Ruediger_Plantiko]

Hi Yuri,

thanks your ST12 suggestion.

I forgot to mention, however, that this is an outgoing RFC call. The ST12 dropdown explicitly speaks of "incoming RFC calls", and there is no option for outgoing RFC calls.

Also, it would be nice to have the RFC function name filter work already in effect when the trace is recorded (to avoid massive data volumes). But it seems this is impossible.

We are afraid of the high data volume generated when switching ST05 on in the productive system.

Since we have all the job chains running in the Q system as well, we decided to switch the trace on there.

Kind regards,

Rüdiger

P.S.: Thanks for reminding me on good old CRM 1.0 times. Hope the children "CRM_STATUS_MAINTAIN_OW" et al. grew up properly 🙂

[yuri_ziryukin]

Hello Rüdiger,

true, only incoming RFCs can be traced in this way.

So you want to know where all the calls to "RSAP_DATA_GENERATE" originate from?

Hmm... I'm not 100% sure, but I guess that call stack trace in ST05 works also with RFC trace.

Did you get a proper result in Q-system?

Yuri

[Ruediger_Plantiko]

Hello Yuri,

Did you get a proper result in Q-system?

I can't tell you yet, since I found out that the menu item "Preview results without switching off the trace" doesn't work for RFC trace either  (apparently it works only for SQL trace). I can tell you more next week.

Wishing you a happy weekend,

Rüdiger

[yuri_ziryukin]

Thanks, same to you.

[ManfredMensch]

Hi Rüdiger,

the answer to your first question ("Is it possible to collect in ST05 only the RFCs of a partical function module?") is unfortunately "no". The ST05 UI does not provide this - in fact the kernel API does not offer such a capability. The only filter options that apply to the recording of an RFC trace are those for user, work process number, and transaction xor program.

You mentioned that you want to avoid an alleged massive data volume when recording an RFC trace without filtering for the function module's name. I would not be too concerned about that. First of all, RFC trace records are relatively small - unlike SQL records, they do not contain any information on the variable names and values. But more importantly, the data volume is limited by the number and maximum size of the trace files which is controlled by profile parameters. Once that limit is reached, trace recording overwrites old trace files.

"Display Trace Without First Deactivating" works for all trace types, so you can start analyzing your unrestricted RFC trace while recording continues. And of course you can filter what you want to display.

Best regards,
Manfred.

[Ruediger_Plantiko]

Hello Manfred and Yuri,

thank you for your explanations concerning the data storage of trace files. So there is no need to worry.

"Display trace without first deactivating" works fine for SQL trace, but not for RFC trace on our system (SAP_BASIS 702, Level 10). I just made a test, calling RFC_GET_SYSTEM_INFO and looking at the trace. Without deactivating it, "Display trace without first deactivating" shows an empty list. After deactivating, I find the trace record with "Display trace" as usual.

@Yuri: In the meantime, we found the malefactor. The RFC RSAP_DATA_GENERATE we were looking for, has been issued by the function RSA1_OLTPSOURCE_GET_ALL. Starting this function in single test, the problem could be reproduced. Now, with a reproduceable problem, we can do our usual work and find a solution!

Regards,

Rüdiger

[ManfredMensch]

Hi Rüdiger,

I am glad that you managed to identify the cause of the problem.

Concerning "Display trace without first deactivating": In YI2 (the SAP_BASIS 702 SP system) it works. Maybe the RFC was not yet finished when you pressed "Display trace without first deactivating".

Regards,

Manfred.