In wich tables are saab protocolls stored?

[martin_bschen]

I log my programm via logpoints and can view the protocolls via transaction saab. Where are the protocols stored?

[fabianlupa]

Afaik they are not accessable (propably stored in binary).

Logpoints are only designed to be used for test purposes in the transaction SAAB. There is no API for importing the logged data, which means that logpoints are not suitable for general logging purposes.

https://help.sap.com/http.svc/rc/abapdocu_751_index_htm/7.51/en-US/index.htm?file=abaplog-point.htm

If you really want to you can try a SQL trace with ST05 but I doubt it will find anything, as LOG-POINTS are propably executed "at kernel level" outside of traceable SAP LUWs.

[horst_keller]

This answer is correct.

There are XSTRINGs in internal format in system tables. Not foreseen for external use.

[pokrakam]

A lot of things are not intended for external use. AFAIK even BOPF started out as an SAP-internal framework 🙂

I'm guessing that the OP's reason may be the same as my bugbear: an incredibly useful tool, but the log reading interface is painful. Run something, umpteen clicks to see result. 12 more to compare it to the last run.

I usually copy/paste into Excel because it's easier, have thought about writing a utility myself to list a single log point's output in an ALV table but hasn't made it high enough on my priority list yet. Run app, refresh log data, see each run's result in one table line. Much simpler.

Suggestion for SAP: something like a layout where you can navigate to the log point of interest in one screen area and then have the results of various subkeys in tabular format would be grand. I know one challenge is that the contents can change from one entry to the next, but that could be easily handled as a 'can't display mixed structures' error or something like that.

Edit: And just to stress: I fully support the help's info that they are for testing. I have always used them as temporary testing/debugging helper data, not a general-use log.

[pokrakam]

Look at the SRTM* tables, SRTM_DATA / SRTM_DATAX are the ones you're after, the others provide the metadata (subkeys etc).

As Fabian said, the content is serialised. I haven't tried it, but I suppose it should be easy enough to debug SAAB to work out how to extract the data.

[vonglan]

I have written a "development monitor job" report that uses the following code to check for new SAAB log entries:

* Select all Z checkpoint groups with the Sub IDs
    SELECT srtm_test~testid, test_id, subid, subkey
      FROM srtm_test JOIN srtm_sub ON srtm_test~testid = srtm_sub~testid
      WHERE test_kind = 'I'
        AND test_id LIKE 'Z%'
      INTO @DATA(wa_sub).


* Select all log entries, complete with fields (in time range)
      SELECT d~trigid, trigoffset, subid, ddate, dtime, counter, progname, t~progid, t~trigname
        FROM srtm_datax AS d JOIN srtm_proc AS t ON d~trigid = t~trigid
                             JOIN srtm_prog AS p ON t~progid = p~progid
        WHERE concat( CAST( ddate AS CHAR( 8 ) ), CAST( dtime AS CHAR( 6 ) ) ) >= @i_from
          AND concat( CAST( ddate AS CHAR( 8 ) ), CAST( dtime AS CHAR( 6 ) ) ) <= @i_to
          AND subid = @wa_sub-subid
        INTO @DATA(wa).

        cl_aab_tool=>get_prot_detail_info(
          EXPORTING
            selected_entry = VALUE #( kind       = 'D'
                                      testid     = wa_sub-testid
                                      subid      = wa_sub-subid
                                      progid     = wa-progid
                                      trigid     = wa-trigid
                                      trigoffset = wa-trigoffset )
          IMPORTING
            source         = DAT(include)
            source_line    = DATA(line)
            prog_date      = DATA(prog_date)
            fields         = DATA(fields) ).