01-28-2016 3:22 PM
Hi all,
my aim is to trace the data transfered between .NET and SAP when using SAP NCO (Version 3.0).
So I configured (in the app.config file of the .NET application) a RFC trace directory and the highest RFC trace level (i.e. level 4).
The data transfered between .NET and SAP is now shown as a hexdump in the RFC trace files.
While all other trace information is in readable format, the RFC data itself is shown in a region called "hexdump".
=> My question: How can I display the RFC trace level 4 data hexdump in a readable format?
Thanks in advance.
Regards,
Bernd
01-29-2016 10:25 AM
Hi Bernd,
Bernd Sonderkötter wrote:
=> My question: How can I display the RFC trace level 4 data hexdump in a readable format?
The answer is basically: you can't...
The reason is simply: not all of that data is human readable. For example, RFC header fields that are exchanged between the two communication partners, IEEE 754 floating point numbers, compressed table data - all this is binary data, which is not human readable. It is traced mainly for support reasons, so that an expert in this area will be able to detect problems in this data, e.g. data that got corrupted during transport etc.
Best Regards, Ulrich
01-29-2016 7:23 AM
Hello Bernd,
the "readable format" of the data is on the right side of the hexdump. For analyzing issues it is more important to know the bytes exchanged with the partner than the readable information. Could you explain for what purpose you need the readable format of the data?
Best regards,
Markus
01-29-2016 10:25 AM
Hi Bernd,
Bernd Sonderkötter wrote:
=> My question: How can I display the RFC trace level 4 data hexdump in a readable format?
The answer is basically: you can't...
The reason is simply: not all of that data is human readable. For example, RFC header fields that are exchanged between the two communication partners, IEEE 754 floating point numbers, compressed table data - all this is binary data, which is not human readable. It is traced mainly for support reasons, so that an expert in this area will be able to detect problems in this data, e.g. data that got corrupted during transport etc.
Best Regards, Ulrich
01-29-2016 2:09 PM
Hi Ulrich,
first many thanks for your answer. My intention is to become that expert in this support area so that I will be able to detect problems in the transfered RFC data.
Another point is that I would like to know - if the data is not corrupted - exactly what data is transfered. This is because I do not have access to the SAP application but only to the Microsoft .NET application. Of course, I could log the received RFC data in the .NET application by my own custom code after it is deserialized by the SAP-.NET Connector, but I thought I could trace the data without touching the application?
I guess, there must be an algorithm or a tool to decode and display that data?
Kind Regards,
Bernd
02-01-2016 7:44 AM
Hi Bernd,
if you are mainly interested in the data exchanged with the partner, you can 'or' the trace level with the flag ParameterData, e.g..you want to see level 2 trace plus the function data: RfcTracing.Level2|RfcTracing.ParameterData. When not doing it programmatically, but using app.config for setting the trace level you specify 2|ParameterData in the respective value for trace (general or destination specific).
Best regards,
Markus
02-01-2016 1:40 PM
Hi Ulrich,
since level 4 is the highest trace level, it think it should display the data as well(?)
Level 4 = RemoteFunctionCall,PublicAPI,InternalAPI,RfcData (so logged in dev_nco_rfc.log)
I tested it again, this time in another test system, and to my suprise in this system I get a readable (i.e. with ASCII characters) hexdump in files nco_rfc_NNNNN_NN.trc like this:
06110 | 53393E3C 50545854 313E3C2F 50545854 |S9><PTXT1></PTXT|
006120 | 313E3C50 54585433 3E3C2F50 54585433 |1><PTXT3></PTXT3|
006130 | 3E3C5647 42454C3E 3C2F5647 42454C3E |><VGBEL></VGBEL>|
006140 | 3C2F6974 656D3E3C 6974656D 3E3C4D41 |</item><item><MA|
006150 | 4E44543E 3032303C 2F4D414E 44543E3C |NDT>020</MANDT><|
So the problem - that the hexdump is not readable - does only occur on the customer's system.
Any idea in which case the dump is readable and in which case not?
02-01-2016 1:46 PM
Hi Bernd,
my name is not Ulrich, but I can still let you know why this trace is different: In this case, the parameter type is a different one, so data transfer is different and will therefore be human readable. Please read my previous post in order to understand how to configure the trace level. Tracing the data content in addition is really rarely needed, but when it occurs is flooding the traces. That's why it is not included in level 4, but needs to be added with the additional trace marker ParameterData. Thus, however, it is even possible to add it when not tracing a lot of other things.
Best regards,
Markus
02-01-2016 2:16 PM
Bernd Sonderkötter wrote:
Any idea in which case the dump is readable and in which case not?
Hi Bernd,
sometimes it is simply the size of the data: for certain parameter types (especially tables) there is a threshold below which the data is transferred uncompressed (= human readable). Above that threshold the data is compressed before transmission, and then it's of course no longer human readable.
There are other factors as well, e.g. whether or not the backend system supports the basXML serialization format, etc. But as Markus already explained: if you activate that extra tracing option, the data is traced, before it goes through the serializer, so you always get it in readable format and don't need to worry about these technical details.
Bes Regards, Ulrich
02-01-2016 6:36 PM
Hi Markus,
sorry for the name confusion. I cannot confirm this for the sapnco.dll version 3.x, where the hexdump (= rfc data) is only shown in trace level 4 (as documented in the SAP documentation of the trace level here (under "Level"):
Zielsystem: Register Einstellungen RFC-Client - SAP Plant Connectivity - SAP Library
Configuring 2|ParameterData does not log the hexdump. And I think "ParameterData" is not a valid trace level, it is not documented and seems to have no effect.
Regards,
Bernd
02-01-2016 6:40 PM
Hi Ulrich,
so I think it is the compression or the serialization format which made the hexdump unreadable in level 4.
The ParameterData option does not work, but this is probably due to my custom code which ignores all trace options other than 1 to 4. I must try out this later and will give feedback then.
Thanks so far.
Regards, Bernd
02-01-2016 7:29 PM
As I found out now, probably the ignorance of ParameterData is a problem of my custom code which does not parse all possible trace options:
string traceDirectory = ConfigurationManager.AppSettings.Get("Rfc.TraceDirectory");
if (string.IsNullOrWhiteSpace(traceDirectory))
traceDirectory = ".";
string traceLevelAsStr = ConfigurationManager.AppSettings.Get("Rfc.TraceLevel");
uint traceLevel;
if (!uint.TryParse(traceLevelAsStr, out traceLevel))
traceLevel = RfcTrace.LEVEL2;
else
{
if (traceLevel == 0)
traceLevel = RfcTrace.NONE;
if (traceLevel == 1)
traceLevel = RfcTrace.LEVEL1;
else if (traceLevel == 2)
traceLevel = RfcTrace.LEVEL2;
else if (traceLevel == 3)
traceLevel = RfcTrace.LEVEL3;
else if (traceLevel == 4)
traceLevel = RfcTrace.LEVEL4;
else
traceLevel = RfcTrace.NONE;
}
_destinationConfig = new SapDestinationConfig(traceDirectory, traceLevel);
02-02-2016 8:07 AM
Hi Bernd,
see the API doucmentation of the RfcTrace fields. They refer to RfcTracing enumeration, which lists all supported and allowed tracing options.
In app.config you need to use the enum name without the preceding class name.
Best regards,
Markus