SPM 5.3 Table logging

[Former Member]

Hi there,

we have some problems with logging some changes within Firefighter.

Business Object changes seem to be logged (case 1), but no information about customizing or direct table changes can be found in the FF log (case 2 and 3).

1) transaction KS02 change some master data -> old value/new value is logged and found in FF log = OK

2) in transaction OKB9 make modifications to cost centre -> only transaction, but no detailed change in the log = WHY?

3) create entry in table T030H/ view V_T030H via transaction code SM30 -> again, only the transaction is logged, not the table that is modified = WHY?

- We have set profile parameter rec/client correctly and restarted.

- The changed tables have checkbox "Log data changes" (SE11) set to yes.

- The background job /VIRSA/ZVFATBAK has been running and finished.

- The changes for test case 2 can even be found in the change log, but not in FF log.

Have we missed something? Is it possible to log this data?

What is the exact difference between test case 1 (business data logging) and table change documents? Which would be more recommended to use with Firefighter and why? Or is a mixture of both good enough?

Thanks a lot,

Daniela

[Former Member]

This is because the log is a different one, and dependent on whether it is active at all.

It is not controlled by the FF functionality, but rather by a system profile parameter (rec/client) and the transport profile (recclient) and individual table technical settings (transaction SE13).

You should however be able to get the table name from the transaction or the screen program of the maintenance dialog, and then you can use transaction SCU3 directly to evaluate the logs at the time when the transaction was used.

Cheers,

Julius

[Former Member]

Hi Julius,

thanks for your reply!

Just to make sure from what you're saying:

SPM / the Firefighter application is not able to collect the data from the change documents?

(As I said, the changes are written and visible)

Do customers accept to only see SM30 and no information of what table has been changed and how?

Wouldn't this be a no go for SPM, to collect the data manually from different sources in the SAP system?

Let alone not being informed about this if you only receive the usage report by email.

Regards,

Daniela

[Former Member]

No, that is certainly not what I am saying.

It is only the navigation from the Java system's SPM log to the ABAP system's table change log which is not integrated. It is not the same log. It is also not a file.

If a FF ID uses SM30 for a period of 10 minutes, then for those tables which have maintenance dialogs and customizing views, you can see the logs in transaction SCU3.

The logs are there if you configure your system correctly (search OSS for "recclient"). It is just your "one click does all" expectation which doesn't work that way.

The same goes for FB01 or FB03 for example. Which journal entry did the FF ID display or post? --> You need to look in the journal, or in the object history.

Cheers,

Julius

[Former Member]

Hi Julius,

we are not working with the JAVA side yet, just on ABAP, either way SPM collects only the data from its own tables.

Of course you can get all information in different places of the R/3, but the client expects to have one screen to overview all changes (tables/objects marked critical) performed when logged on with a Firefighter ID.

This is not the case - do you agree?

I was just saying it is sad you cannot configure SPM to collect the data of the 10 minutes the user performed changes as a Firefighter from those change logs (and I said from the beginning, they ARE there).

Thanks,

Daniela

[Former Member]

Daniela,

You will find that the SPM log works off of the key tables CDHDR and CDPOS. The change logging is only available when these tables capture the changes.

You will therefore find that some changes are not captured by the SPM Logs and should not discount having to check the standard logging methods which Julius suggests for gap analysis.

The SPM logs should at least give you the pointers of where to look though.

Simon

[Former Member]

The FF logs use the application statistic collectors for the log data. These were by design intended for performance monitoring (reponse times) and application usage statistics at an aggregated level. The security audit log (SM19) is actually the correct tool for this, but by default it is not active. By default the SM30 table change log is not active either. You need to know what you are doing and pro-actively turn on what you want to have logged, in which system, which client, and for which user, table, etc.

Transaction STAD gives you more details form the statistics for a while and is very popular, but then aggregates the lot and translates certain events into symbolic transaction names which are not the real ones so that everything executed in the background, everything called remotely via RFC, etc are all lumped together into one aggregated entry.

The SPM logs also have jobs which you need to setup, and these extract what they can from that user before the translation and aggregation is performed.

If your audit log is not turned on for special events and the table log is not active on the instance and transport file, and you don't know about them... then you have bigger problems than "just" a missing navigation button from the SPM log.

> but the client expects to have one screen to overview all changes (tables/objects marked critical) performed when logged on with a Firefighter ID.

Probably some sales person gave them this impression in a demo, starting only "forbidden" transaction SA38 and then submitted a report and calling that "everything"...

As Simon said, you can find the entry points from this log if you are fast enough. But to drill down you might even need to look beyond the system boundaries, let alone this one log.

Cheers,

Julius