RFC can't set AUDITLEVEL for detail in rz15

[richard_gray]

I'm doing BC-XOM testing.  After establishing an RFC connection, the code calls BAPI_XMI_LOGON, and BAPI_XMI_SET_AUDITLEVEL before continuing on with the SXMI_XOM_* functions of the BC-XOM callback interface.  All calls work, but for unknown reasons, either AUDITLEVEL is not being set or logged messages aren't being displayed in rz15.  All that appears in rz15 are the 'Setting audit level to 3' (or whatever level I'm requesting) and 'Logging off interface XOM' messages.  The XOM logon and all the other XOM function calls do not appear.

I'm testing against a Suse 11 Linux 720 NPL Testdrive system using the NWRFC libraries 721 Patch 38.  I've tried calling from both the SUSE system itself and an external HP-UX Itanium system.  We also have an ancient Windows minisap 7.01 NSP trial system.  It does the same thing, except it catches the BAPI_XMI_LOGON's in addition to setting auditlevel and logging off.

This feels like there is some setting on these systems that is not set correct.  I'm lazy (and not at all SAP savvy) so used the supplied NPL DEVELOPER/NSP BCUSER super user accounts for the RFC and XMI logons.  I have screen captures of audit level 3 working nicely with with the old N4S Linux trial system that we used until SAP dropped it.  Rz15 shows all functions.  That was with the classic RFC library, but running the classic library against the current systems makes no difference.

Here's a debug of the RFC calls, using a routine which is based on code from helperFunctions.c which was with the NWRFC SDK Advanced Topics articles.  Nesting is indicated by periods instead of tabs.   Rfc_invoke is my wrapper function around RfcInvoke.  It checks both rc and RFC_ERROR_INFO's code field.   I can get the rfc developer trace output too.

Mon Jan 11 18:20:39 2016 calling BAPI_XMI_LOGON ---------------------------

Mon Jan 11 18:20:39 2016 BAPI_XMI_LOGON rfc_invoke returned rc 0 code 0

Mon Jan 11 18:20:39 2016 IMPORT entries:

Mon Jan 11 18:20:39 2016 .EXTCOMPANY, RFCTYPE_CHAR[16:16]:PlusTechnologies

Mon Jan 11 18:20:39 2016 .EXTPRODUCT, RFCTYPE_CHAR[16:7]:OM PLUS

Mon Jan 11 18:20:39 2016 .INTERFACE, RFCTYPE_CHAR[3:3]:XOM

Mon Jan 11 18:20:39 2016 .VERSION, RFCTYPE_CHAR[10:3]:0.1

Mon Jan 11 18:20:39 2016 EXPORT entries:

Mon Jan 11 18:20:39 2016 .structure RETURN

Mon Jan 11 18:20:39 2016 ..TYPE RFCTYPE_CHAR[1:0]:

Mon Jan 11 18:20:39 2016 ..ID RFCTYPE_CHAR[20:0]:

Mon Jan 11 18:20:39 2016 ..NUMBER RFCTYPE_NUM[3:3]:000

Mon Jan 11 18:20:39 2016 ..MESSAGE RFCTYPE_CHAR[220:0]:

Mon Jan 11 18:20:39 2016 ..LOG_NO RFCTYPE_CHAR[20:0]:

Mon Jan 11 18:20:39 2016 ..LOG_MSG_NO RFCTYPE_NUM[6:6]:000000

Mon Jan 11 18:20:39 2016 ..MESSAGE_V1 RFCTYPE_CHAR[50:0]:

Mon Jan 11 18:20:39 2016 ..MESSAGE_V2 RFCTYPE_CHAR[50:0]:

Mon Jan 11 18:20:39 2016 ..MESSAGE_V3 RFCTYPE_CHAR[50:0]:

Mon Jan 11 18:20:39 2016 ..MESSAGE_V4 RFCTYPE_CHAR[50:0]:

Mon Jan 11 18:20:39 2016 ..PARAMETER RFCTYPE_CHAR[32:0]:

Mon Jan 11 18:20:39 2016 ..ROW RFCTYPE_INT[4:1]:0

Mon Jan 11 18:20:39 2016 ..FIELD RFCTYPE_CHAR[30:0]:

Mon Jan 11 18:20:39 2016 ..SYSTEM RFCTYPE_CHAR[10:0]:

Mon Jan 11 18:20:39 2016 .SESSIONID, RFCTYPE_CHAR[24:24]:C0A8EA2A255C569438C70046

Mon Jan 11 18:20:39 2016 calling BAPI_XMI_SET_AUDITLEVEL ---------------------------

Mon Jan 11 18:20:39 2016 BAPI_XMI_SET_AUDITLEVEL rfc_invoke returned rc 0 code 0

Mon Jan 11 18:20:39 2016 IMPORT entries:

Mon Jan 11 18:20:39 2016 .AUDITLEVEL, RFCTYPE_NUM[1:1]:3

Mon Jan 11 18:20:39 2016 EXPORT entries:

Mon Jan 11 18:20:39 2016 .structure RETURN

Mon Jan 11 18:20:39 2016 ..TYPE RFCTYPE_CHAR[1:0]:

Mon Jan 11 18:20:39 2016 ..ID RFCTYPE_CHAR[20:0]:

Mon Jan 11 18:20:39 2016 ..NUMBER RFCTYPE_NUM[3:3]:000

Mon Jan 11 18:20:39 2016 ..MESSAGE RFCTYPE_CHAR[220:0]:

Mon Jan 11 18:20:39 2016 ..LOG_NO RFCTYPE_CHAR[20:0]:

Mon Jan 11 18:20:39 2016 ..LOG_MSG_NO RFCTYPE_NUM[6:6]:000000

Mon Jan 11 18:20:39 2016 ..MESSAGE_V1 RFCTYPE_CHAR[50:0]:

Mon Jan 11 18:20:39 2016 ..MESSAGE_V2 RFCTYPE_CHAR[50:0]:

Mon Jan 11 18:20:39 2016 ..MESSAGE_V3 RFCTYPE_CHAR[50:0]:

Mon Jan 11 18:20:39 2016 ..MESSAGE_V4 RFCTYPE_CHAR[50:0]:

Mon Jan 11 18:20:39 2016 ..PARAMETER RFCTYPE_CHAR[32:0]:

Mon Jan 11 18:20:39 2016 ..ROW RFCTYPE_INT[4:1]:0

Mon Jan 11 18:20:39 2016 ..FIELD RFCTYPE_CHAR[30:0]:

Mon Jan 11 18:20:39 2016 ..SYSTEM RFCTYPE_CHAR[10:0]:

Suggestions would be greatly appreciated!

Rich

[Ulrich_Schmidt]

Hi Rich,

can you run the same program once against the old N4S system and once against the new one? This will show us, where we need to look at for trouble-shooting:

a) If the program does not work in both cases, the problem is probably on external (C/C++ program) side. So we can take a closer look there, capture an RFC trace (and perhaps compare with the old librfc32 based program that still worked ok).

b) If it works in one case and does not work in the other case, then we need to look at the backend. Either something has changed in the new SAP release, or the new system is customized differently?! But in this case we (ABAP Connectivity) will probably not be able to help you: our field of expertise is the RFC communication layer, but I have no idea, how these XOM function modules work and what needs to be done on backend side in order to make them work. (You will probably have to open a support ticket for BC-XOM in that case.)

Best Regards, Ulrich

[richard_gray]

Hello Ulrich,

Alas, the N4S virtual machines were retired when SAP stopped renewing trial licenses for them.  (I just realized that I have one taking up gigs on my laptop, but again, I have no way to re-license it.)

I will get RFC traces from both current testdrives.  Client side, right?  The NPL system is from spring of 2013.  The Windows minisap NSP system is ancient.  Neither has ever been patched, so it's possible there is a Note out there which matters. That's a bit hard to believe given these are systems intended for testing.  Some parameter being set on the host side seems a possibility.   I actually do have a current (Dec 2015) minisap system installed on my workstation.  I was going to use it in the current round of testing, but then decided not to because my main interest was the    and that article seemed to be written against the older version.  So for lack of time and knowledge, I went with the older system.  However, I will wake it up and  test this rz15 problem against that system too.

Thanks!

Rich

[Ulrich_Schmidt]

PS: one idea that just came to my mind: do these XOM functions require a COMMIT WORK via BAPI_TRANSACTION_COMMIT at the end? That would explain, why they don't throw any exception despite the changes not getting persisted...

Regards, Ulrich

[richard_gray]

I have no knowledge of these XOM functions requiring a COMMIT WORK via BAPI_TRANSACTION_COMMIT.   Would I code that after the audit level set??

I brought up that more recent minisap system, SAP Netweaver ABAP Trial 7.02 SP11 Win 64 bit Version on my workstation.   As with the other, ancient, minisap, rz15 was showing only the Logon, Set Audit Level and Logoff calls. But then I selected Period: All instead of Today for time range selection. Lo and behold, it displays Logon/Audit/Logoff as before, but also picked up RMG and Device Reconfigurations. I went back to the Suse NPL system and it does the same thing (although I've yet to see it display Logon.)  So rz15 seems to be hiding information that must actually be getting recorded into the XMI log.  (Is there a place where we can view the raw log, without rz15??)   Still, this seems to be far from what I got on the older N4S system

VS what I got on the old N4S system.  (There were two RFC clients accessing, so double traffic.)

Interesting, the language here is Log level changed to 2, vs Setting Audit Level to 3...   It smells like I'm still missing a setting or two on the server. 

I'm also having trouble finding proper debugging for the server side.  There are references to the the "RFC developer trace" in various documents, but I'm not quite sure where that gets enabled and displayed.   Are we talking System > Utilities > Performance Trace with RFC selected?   I used that in the test cycle below.  I'm not sure that's the right thing.   Developer Trace - Tools for Monitoring the System - SAP Library describes using SM50 and SM51, but I've been unable to get dev_rfc files to appear in  /usr/sap/NPL/SCS00/work .  Some do in  /usr/sap/NPL/DVEBMGS42/work , but they look more like database transactions.  I can't make anything useful out of them.

Attached is a test cycle of  RfcOpenConnection,  BAPI_XMI_LOGON, BAPI_XMI_SET_AUDITLEVEL, SXMI_XOM_DEVICES_QUERY, SXMI_XOM_RMGS_QUERY,  SXMI_XOM_JOBS_CALLBACK, BAPI_XMI_LOGOFF and  RfcCloseConnection.   The attached client.txt is my debug followed by the rfc trace files generated by the rfc library.   server.txt is the server side Performance Trace with RFC & Buffer Traces selected.   Finally, RZ15:

I'm still missing where the disconnect is between these RFC functions executing and the XMI log...

Thanks!

Rich

[richard_gray]

Hi Ulrich,

I added a BAPI_TRANSACTION_COMMIT after the BAPI_XMI_SET_AUDITLEVEL, but it seemed to make no difference.  The WAIT argument should be a non-space to cause it to wait for the commit, right?   I used "X".

Thu Jan 21 17:04:45 2016 BAPI_XMI_SET_AUDITLEVEL > sles11sap_NPL_42 OK

Thu Jan 21 17:04:45 2016 IMPORT entries:

Thu Jan 21 17:04:45 2016 .AUDITLEVEL, RFCTYPE_NUM[1:1]:3

Thu Jan 21 17:04:45 2016 EXPORT entries:

Thu Jan 21 17:04:45 2016 .structure RETURN

Thu Jan 21 17:04:45 2016 ..TYPE RFCTYPE_CHAR[1:0]:

Thu Jan 21 17:04:45 2016 ..ID RFCTYPE_CHAR[20:0]:

Thu Jan 21 17:04:45 2016 ..NUMBER RFCTYPE_NUM[3:3]:000

Thu Jan 21 17:04:45 2016 ..MESSAGE RFCTYPE_CHAR[220:0]:

Thu Jan 21 17:04:45 2016 ..LOG_NO RFCTYPE_CHAR[20:0]:

Thu Jan 21 17:04:45 2016 ..LOG_MSG_NO RFCTYPE_NUM[6:6]:000000

Thu Jan 21 17:04:45 2016 ..MESSAGE_V1 RFCTYPE_CHAR[50:0]:

Thu Jan 21 17:04:45 2016 ..MESSAGE_V2 RFCTYPE_CHAR[50:0]:

Thu Jan 21 17:04:45 2016 ..MESSAGE_V3 RFCTYPE_CHAR[50:0]:

Thu Jan 21 17:04:45 2016 ..MESSAGE_V4 RFCTYPE_CHAR[50:0]:

Thu Jan 21 17:04:45 2016 ..PARAMETER RFCTYPE_CHAR[32:0]:

Thu Jan 21 17:04:45 2016 ..ROW RFCTYPE_INT[4:1]:0

Thu Jan 21 17:04:45 2016 ..FIELD RFCTYPE_CHAR[30:0]:

Thu Jan 21 17:04:45 2016 ..SYSTEM RFCTYPE_CHAR[10:0]:

Thu Jan 21 17:04:45 2016 BAPI_TRANSACTION_COMMIT > sles11sap_NPL_42 OK

Thu Jan 21 17:04:45 2016 IMPORT entries:

Thu Jan 21 17:04:45 2016 .WAIT, RFCTYPE_CHAR[1:1]:X

Thu Jan 21 17:04:45 2016 EXPORT entries:

Thu Jan 21 17:04:45 2016 .structure RETURN

Thu Jan 21 17:04:45 2016 ..TYPE RFCTYPE_CHAR[1:0]:

Thu Jan 21 17:04:45 2016 ..ID RFCTYPE_CHAR[20:0]:

Thu Jan 21 17:04:45 2016 ..NUMBER RFCTYPE_NUM[3:3]:000

Thu Jan 21 17:04:45 2016 ..MESSAGE RFCTYPE_CHAR[220:0]:

Thu Jan 21 17:04:45 2016 ..LOG_NO RFCTYPE_CHAR[20:0]:

Thu Jan 21 17:04:45 2016 ..LOG_MSG_NO RFCTYPE_NUM[6:6]:000000

Thu Jan 21 17:04:45 2016 ..MESSAGE_V1 RFCTYPE_CHAR[50:0]:

Thu Jan 21 17:04:45 2016 ..MESSAGE_V2 RFCTYPE_CHAR[50:0]:

Thu Jan 21 17:04:45 2016 ..MESSAGE_V3 RFCTYPE_CHAR[50:0]:

Thu Jan 21 17:04:45 2016 ..MESSAGE_V4 RFCTYPE_CHAR[50:0]:

Thu Jan 21 17:04:45 2016 ..PARAMETER RFCTYPE_CHAR[32:0]:

Thu Jan 21 17:04:45 2016 ..ROW RFCTYPE_INT[4:1]:0

Thu Jan 21 17:04:45 2016 ..FIELD RFCTYPE_CHAR[30:0]:

Thu Jan 21 17:04:46 2016 ..SYSTEM RFCTYPE_CHAR[10:0]:

However when I dug into my notes to see what the transaction was to let me see the description of a function (se37), I noticed that se16 was useful for setting XMILOGLEVEL in the TSPOPTIONS table to 2 for testing.  In the back of my head, there's been a feeling of a missed setting somewhere.  This is it.  Once I made the change and bounced SAP, the XMI log had the desired detail.

This satisfies my immediate need, but I'm left wondering why the audit level still cannot be set.  That's valuable in the field.   I think the question is still unsolved.

Thanks!

Rich

[martin_vierling]

Hi,

I suppose it is because parameter XMILOGLEVEL=1 is not set in table TSPOPTIONS.
Please note that you need to restart system after change.
Adjusting the AUDITLEVEL has no effect to XOM event-messages.

See also blogs:
http://scn.sap.com/docs/DOC-10306
http://scn.sap.com/docs/DOC-14113
Regards
Martin

[richard_gray]

>Adjusting the AUDITLEVEL has no effect to XOM event-messages.

So would I take your answer to mean that AUDITLEVEL is pretty much useless?  (Is that the answer for this thread??)  Is it good for anything??

I'm wondering where the impetus to set AUDITLEVEL even came from.  It is not a requirement of the BC-XOM testing procedure.  I suspect that when we first did callback, we were urged to set this.  But what's the point, given it has no effect on XOM event messages??   I'm kind of tempted to take it out.

Thanks Ulrich & Martin for your responses to my questions!

Rich

[martin_vierling]

>>So would I take your answer to mean that AUDITLEVEL is pretty much useless?  (Is that the answer for this thread??)  Is it good for anything??

I can't tell for other utilization for XMI. But for XOM AUDITLEVEL is not used to get THAT information you intend to get.

[Ulrich_Schmidt]

Hi Rich,

just for completeness (though I think it won't add new insights to the original question): with "RFC developer trace" that is mentioned above, they probably mean the one that you can activate in transactions SM50 and SM04?! In "SM50 -> Administration -> Trace -> Active Components" you select the component "Abap Proc." (which includes RFC) and a trace level like 2, and in SM04 you can then start the trace for a selected user session (so you have to first call RfcOpenConnection(), stop in the debugger right after that, switch to SAPGui/SM04, find the user session that got created during RfcOpenConnection(), activate the trace, switch back to the debugger and continue the C program...). Make sure to reset the trace when you are done...

The trace is written to the standard work process traces (so not into dev_rfc.trc). But I'm not sure, whether it will be helpful for "application level problems"?!

Best Regards, Ulrich