Kunden-Customizingtabellen Änderungen protokollieren

Re: Kunden-Customizingtabellen Änderungen protokollieren

Mit Transaktion SE16n werden Änderungsprotokolle geschrieben. Auswertung mit RKSE16N_CD
Se16n kann einfach über Funktionsbaustein SE16N_INTERFACE für eigene Tabellen im Änderungsmodus aufgerufen werden.
Im Tabellenpflegegenerator kann man selbst entscheiden, ob eine Aufzeichnung im Transportauftrag erfolgen soll, oder nicht: http://www.tricktresor.de/content/index ... 30&aID=366

Re: Kunden-Customizingtabellen Änderungen protokollieren

Hallo,

da Enno ja inzwischen schon erklärt hat, wie man den Pflegedialog sdurch Anpassung des Pflegeobjekts so ändert, dass damit laufende Einstellungen im jeweiligen System möglich sind, ohne dass nach einem Transportauftrag gefragt wird, jetzt noch mal zu den zwei anderen Problemen.


Ob Tabellenänderungen protokolliert werden, wenn das entsprechende Flag in den technischen Einstellungen gesetzt ist, hängt nicht davon ab, ob sie z.B. Customizing-Tabellen oder Anwendungs-Tabellen sind.
(Wenn man im Pflegeobjekt das Flag "laufende Einstellungen" setzen will, muss man dort m.E. auch SYST statt CUST wählen, und ich meine mich zu erinnern, dasss dann dem System die Definition als Customizing-Tabelle nicht gefällt. Edit: Ich habe mich anscheinend falsch erinnert. Um das Flag für laufende Einstellungen zu setzen, muss CUST eingetragen sein.)

Auch die Transaktion, mit der die Änderung erfolgt, ist völlig egal. (SE16, SM30 oder ein selbst gebastelter Report)
Wenn die anderen Bedingungen (s.u.) stimmen, müssen Tabellenänderungen bei UPDATE/INSERT/DELETE auf die Tabelle oder eine View auf die Tabelle geschrieben werden, und es würde schon kriminelle Ändergie dazugehören, wenn sie fehlen...

Damit Tabellenänderungen geschrieben werden, muss der Profile-Parameter rec/client entsprechend gesetzt sein.
(Wenn das Protokollieren von Tabellenänderungen für andere Tabellen mit dem Flag in den technischen Einstellungen funktioniert, darf man aber davon ausgehen, dass er richtig gesetzt ist.

Prüfbar mit Report bzw. Transaktion RSPFPAR.
Ganz Paranoide prüfen die Einstellung noch in jeder einzelnen Instanz, ich glaube aber nicht, dass SAP das mag, wenn man da pro Instanz etwas anderes einstellt.
(Genaueres erfährt man in RZ10 bzw. RZ11)

Die Profile-Parametereinstellung ist Sache der SAP-Basis.
Damit in allen Mandanten protokolliert wird, muss der Parameter den Inhalt ALL haben, ansonsten eine mit Komma getrennte Liste von Mandanten, z.B.: 000,001,066,100
Mandantenunabhängige Tabellen werden m.E. immer protokolliert, wenn der Parameter nicht auf OFF steht.

Damit Tabellenänderungen auch beim Import von Custonizing-Aufträgen in nachfolgende Systeme protokolliert werden (nicht Dein aktuelles Problem, aber dennoch der Vollständigkeit halber erwähnt), muss zusätzlich im Transportprofil des Systems (s. STMS) der Transport-Parameter RECCLIENT entsprechend gesetzt sein.

Sind die Bedingungen erfüllt, werden auf die Tabellenänderungen Deiner Tabellen protokolliert, egal ob Du sie mit SE16, SM30 oder sonst einer Transaktion änderst.

Mach mal einen zweiten Modus auf und schalte dort vor dem Sichern den SQL-Trace ein (in Transaktion ST05).
Unmittelbar nach deinen Customizing-Änderungen solltest Du sehen, dass neue DBTABLOG-Einträge eingefügt werden.
(Die DBTABLOG-Einträge kann man auch mit SE16 anzeigen. Wenn man Datum, Uhrzeit und Tabellenname angibt, sieht man auf jeden Fall, welche Einträge geändert wurden (s. TABKEY) und ob der Satz geändert, eingefügt oder gelöscht wurde.)

Dass Du die protokollierten Änderungen mit Transaktion SCU3 oder OY18 nicht gesehen hast, hat sicher eine andere Ursache.
(Ich nehma an, Du hast die Transaktion richtig bedient und den Tabellennamen korrekt angegeben und auch den Radiobutton auf "Tabelleneinträge" o.ä. gesetzt.)

Bestimmt gab es aber in der Liste mit der Auskunft, dass keine Tabellenänderungsprotokolle gefunden wurden, auch eine Zeile Und danach war Deine Customizing-Tabelle aufgeführt.

Das liegt daran, dass es zu Deinen Tabellen noch keinen TDDAT-Eintrag gab.
Wenn Du den SM30-Dialog für die Tabelle und nicht für eine View auf die Tabelle oder für die Fremdschlüsseltabelle zu einer Tabelle, die Texttabelle ist) generiert hast, gibt es inzwischen auch einen TDDAT-Eintrag.
Dann solltest Du jetzt auch die "alten" Protokolle zu der Tabelle auswerten können.

SAP verhält sich m.E. hier inkonsistent.

Mit SE16 werden Einträge angezeigt, auch wenn es keinen TDDAT-Eintrag zur Tabelle gibt, der festlegt, für welche BEGRU S_TABU_DIS geprüft werden soll.
Aber bei Tabellenänderungsprotokollen stellt das SAP-System sich blöd.

Ich bin jetzt zu faul zum Suchen bzw. Starten des SAP-Systems. Es muss aber auch möglich sein, TDDAT-Einträge ohne SM30-Dialog für eine Tabelle zu erzeugen.
(Entweder SM30-Pflege für TDDAT oder eine View auf TDDAT)

Wenn es einen Pflegedialog für eine View auf Deine Tabelle gibt, würde ich für BEGRU den Wert aus dem TDDAT-Eintrag zu der View übernehmen.
Wenn nicht, tut es vielleicht auch der "BEGRU-Dummy-Wert" &NC&.

Die von SE16N geschriebenen Protokolle haben übrigens nichts mit den Technischen Einstellungen der Tabelle zu tun und werden auch nicht von SCU3 ausgewertet.

Für Massendaten ist die Protokollierung von Tabelleneinträgen weniger geeignet. (s. entspr. OSS-Hinweise.)
Hier sollten eher Änderungsbelege geschrieben werden.
Das passiert aber nicht automatisch, sondern muss programmiert werden.

Frank

Re: Kunden-Customizingtabellen Änderungen protokollieren

chfreise hat geschrieben:Liegt es daran, dass ich dennoch den entsprechenden Verbucher-FuBa aufrufen muss?
Sprich - vor Aufruf der Transaktion den aktuellen Stand der Tabelle in einer internen Tabelle merken und anschließend nochmal und beide interne Tabellen an den Verbucher-FuBa übergeben?

Genau! Du musst noch den Zeitpunkt "Nach Sichern Der Daten" aktivieren und wie beschrieben ausprogrammieren.
Ansonsten, wie von Frank beschrieben, die entsprechenden Systemparameter für die generelle Tabellenänderungsaufzeichnung aktivieren.

Re: Kunden-Customizingtabellen Änderungen protokollieren

Hallo Frank,


ich habe noch eine Nachfrage zu

Das liegt daran, dass es zu Deinen Tabellen noch keinen TDDAT-Eintrag gab.
Wenn Du den SM30-Dialog für die Tabelle und nicht für eine View auf die Tabelle oder für die Fremdschlüsseltabelle zu einer Tabelle, die Texttabelle ist) generiert hast, gibt es inzwischen auch einen TDDAT-Eintrag.
Dann solltest Du jetzt auch die "alten" Protokolle zu der Tabelle auswerten können.

Wir haben unserem Kunden per Transportauftrag die Änderungsprotokollierung zu einer unserer Tabellen aus unserem Namensraum gesendet. Sie ist bei ihm jetzt aktiv, trotzdem sieht er nur die von Dir direkt über diesem Zitat beschriebene Ausgabe der SCU3. Ist Deine zitierte Aussage so zu verstehen, dass die Änderungen sich in der SCU3 nur anzeigen lassen, wenn es auch einen Tabellenpflegedialog für die SM30 gibt? So verstehe ich nämlich die Aussage, dass man mit diesem Dialog auch die "alten" Änderungen finden kann. Ich weiß nicht, ob Du meinen Fragestandpunkt nachvollziehen kannst, deshalb formuliere ich nochmals um:

"Muss ich einen Tabellenpflegedialog generieren, um die Tabellenänderungen auch mit der SCU3 (oder einer anderen Transaktion bzw. einem anderen Programm) ansehen zu können?"

Du kannst davon ausgehen, dass ich die anderen Bedingungen Deines Beitrags geprüft habe, sie sind erfüllt.

Kurzer Hintergrund: Die Tabelle wird während das Programmlaufs über implizite Programmaktionen oder Buttonklicks des normalen Benutzers geändert. Es ist also eigentlich gar keine SM30 sinnvoll. Allerdings kann der Administrator nicht sehen, wer was geändert hat, und manche unserer Kunden wünschen das, weil deren Anwender manchmal nicht richtig handeln. Bei anderen Kunden hat diese Technik bisher aber geklappt.

Bei der Größe der Tabelle (Kategorie Stammdaten) überlege ich mir natürlich, ob wir nicht besser Änderungsbelege schreiben sollten, angesichts der Tatsache, dass SAP immer gleich ganze Abbilder der Tabelle speichert. Aber das löst das kurzfristige Problem dieses einen Kunden natürlich nicht.


Danke für Dein Ohr,
Thomas

PS: Ich bin Dir immer wieder dankbar für Deine ausführlichen Antworten und Kommentare, und damit auch dafür, dass Du so viel Zeit dafür aufwendest. Ich kann davon viel profitieren. Ich betone das deshalb, weil der Fragesteller auf Deinen Beitrag ja nun mal gar nicht eingegangen ist, obwohl er sehr fundiert ist und damit für die Problemlösung ganz hilfreich.

Re: Kunden-Customizingtabellen Änderungen protokollieren

thomy_der_genuss hat geschrieben: Wir haben unserem Kunden per Transportauftrag die Änderungsprotokollierung zu einer unserer Tabellen aus unserem Namensraum gesendet.
Sie ist bei ihm jetzt aktiv, trotzdem sieht er nur die von Dir direkt über diesem Zitat beschriebene Ausgabe der SCU3.

Dann hast Du also diesen Thread über eine Google-Suche gefunden?

Ist Deine zitierte Aussage so zu verstehen, dass die Änderungen sich in der SCU3 nur anzeigen lassen, wenn es auch einen Tabellenpflegedialog für die SM30 gibt? So verstehe ich nämlich die Aussage, dass man mit diesem Dialog auch die "alten" Änderungen finden kann.

Nein, auch ohne SM30-Dialog für die Tabelle oder eine View auf die Tabelle kann man sich Änderungen anzeigen lassen, wenn es einen TDDAT-Eintrag zur Tabelle gibt (und man die S_TABU_DIS-Berechtigung für die in der TDDAT angegebene Berechtigungsgruppe hat).
Meine Antwort bedeutete nur, dass man beim Generieren eines Pflegedialogs für die Tabelle ja auch eine Berechtigungsgruppe angeben muss. Die landet dann in der TDDAT.
In den Transportauftrag werden neben FUGR für den Pflegedialog ... u.a. auch ein Eintrag R3TR TABU TVDIR (mit dem Key für die Tabelle/View, für die der Pflegedialog generiert wird) und eben auch ein Eintrag mit R3TR TABU TDDAT (Key ist wieder Tabellenname/Viewname) aufgenommen.

Die Berechtigungsgruppe ist für die Berechtigungsprüfung auf S_TABU_DIS nötig.

Während SAP für die SE16 bei fehlendem TDDAT-Eintrag einfach gegen die Dummy-Berechtigungsgruppe &NC& prüft, versagt die SCU3 hier.
Das kann man für einen SAP-Standard-Fehler halten.
(Mach doch mal eine Meldung auf. Ich habe meist nicht so viel Zeit dafür, oft eher schlechtere Erfahrungen gemacht, und konzentriere mich daher auf Fälle, die mich mehr stören.)

Als Workaround gibt es bei Tabellen, zu denen es keinen Pflegedialog gibt, aber für die es einen Pflegedialog zu einer View auf die Tabelle gibt, noch die Möglichkeit, nicht über die Tabelle in die SCU3 einzusteigen, sondern über View/Customizing-Objekt.
(Das klappt natürlich nur, wenn der TDDAT-Eintrag zur View mit ins Kundensystem transportiert wurde.)
Dort kann man dann auswählen, dass zusätzlich die Protokolle zu Tabellenänderungen ausgewertet werden sollen.)

Die andere Alternative ist, einen TDDAT-Eintrag für die Tabelle zu basteln und zu transportieren.
Als Berechtigungsgruppe nimmt man entweder &NC& (damit nicht plötzlich User, die die Tabelle vorher per SE16 anzeigen durften, an der fehlenden Berechtigung scheitern).
Oder man nimmt die Berechtigungsgruppe aus dem TDDAT-Eintrag der View, damit die Daten der Tabelle gegen unberechtigtes Lesen genauso geschützt sind wie die View-Daten.

Oder man legt auf sonstige Weise eine Berechtigungsgruppe fest, z.B. eine aus SAP-Standard-Tabellen, die zum gleichen Thema gehören.
Wenn man eine komplett neue Berechtigungsgruppe erfinden muss, wird es schon wieder schwer, weil die ja nicht namensraum-fähig sind.
(Auch so ein Thema, mit dem ich SAP vor ca. 8 Jahren ohne Ergebnis behelligt habe.)
Da läuft man mit Y/Z also Gefahr, Kunden-Berechtigungsgruppen zu überschreiben.
Oder man transportiert die Definition der neuen Berechtigungsgruppe nicht mit zum Kunden.
Dan fehlt dort der Text, oder es wird der vermutlich unpassende Text der Kunden-Berechtigungsgruppe angezeigt.

Ich weiß nicht, ob Du meinen Fragestandpunkt nachvollziehen kannst, deshalb formuliere ich nochmals um:

"Muss ich einen Tabellenpflegedialog generieren, um die Tabellenänderungen auch mit der SCU3 (oder einer anderen Transaktion bzw. einem anderen Programm) ansehen zu können?"

Nein. Der Pflegedialog war eher eine hinreichende Bedingung (weil dann der TDDAT-Eintrag erzeugt wird), kein notwendige.

Frank

Re: Kunden-Customizingtabellen Änderungen protokollieren

Hallo Frank,


genau, ich hab den Beitrag ergooglet, er war fast der erste bei meiner Anfrage. Da er sich so ausführlich mit der Problematik beschäftigt, fand ich es sinnvoll, ihn zu beantworten, weil dann die Thematik "am Stück" zu finden ist.

Ich bin ehrlich gesagt neugierig, wieso Du auf Google schließt, wo ich doch auch im Forum direkt hätte gesucht haben können ...

Inzwischen bin ich mir recht sicher, dass unser Kunde einfach kein S_TABU_DIS auf Tabellen ohne Berechtigungsgruppe hat. Allerdings war der Ansprechpartner heute nicht da. (Ich schätze, die anderen Kunden mit diesem Tabellenprotokollierungswunsch haben an dieser Stelle ihr Berechtigungskonzept nicht entsprechend ausgeprägt, das würde erklären, warum das bei denen nicht aufgetreten ist.) Ich hab ihm drei Vorschläge gemacht, wie er das herausfinden kann. Mal sehen, wenn es das nicht war, dann muss ich wohl nochmal hier nachfragen.

Bei meiner heutigen Suche, die wegen Deiner gut verständlichen Beschreibung schon viel klarer verlief, fand ich dann auch, dass es möglich ist, mit der SE54 ganz regulär Berechtigungsgruppen für Tabellen anzulegen sowie einzelne Tabellen mit Berechtigungsgruppen zu hinterlegen. (Das erzeugt dann wahrscheinlich noch nicht den TDDAT-Eintrag. Muss ich am Montag noch untersuchen.) Wenn ich also mit meiner Vermutung recht habe, dann ist das ein klasse Mittel, das Problem zu umgehen, dass Berechtigungsgruppen nicht namensraumfähig sind. Der Kunde kann sich das dann selbst zurechtlegen. Da die TBRG Tabellenklasse "G" hat, ergibt sich eigentlich nicht mal das typische Problem mit Modifikationen.

Wenn das nicht funktioniert, dann muss ich den TDDAT-Eintrag (mit der vom Kunden gewünschten Berechtigungsgruppe) halt erzeugen und mit einem Transportauftrag hinschicken.

Das Verhalten der Dummy-Berechtigungsgruppe "&NC&" finde ich noch recht obskur: Wenn ich es richtig sehe, pflege ich den TDDAT-Eintrag wirklich mit dem Inhalt "&NC&". Muss der Benutzer dann in seiner Rolle zu S_TABU_DIS ebenfalls "&NC&" gepflegt haben, oder muss es/kann es ein leerer Eintrag sein? (Nachher weiß das nämlich der Berechtigungsadmin beim Kunden auch nicht und ich kann nicht mal antworten ... Gut, könnte man auch ausprobieren.)

Ich schreib übrigens zwar gelegentlich Meldungen an SAP, wir haben aber das Problem, dass wir selbst SAP nicht produktiv im SAP-Sinne einsetzen, weshalb manchmal unsere Anfragen recht stiefmütterlich behandelt werden, gerade wenn es sich um "vermeintliche" Fehler im SAP-System handelt. Wenn wir bei Supportfällen auf Fehler im SAP-Coding stoßen, dann formulieren wir die Anfrage zwar, bitten dann aber den betroffenen Kunden, diese Anfrage abzusetzen.


Ich danke Dir,
Thomas

Re: Kunden-Customizingtabellen Änderungen protokollieren

Hallo,

UserBC hat geschrieben:Auch dann ist es kein Grund die SE16/SE16N zu versenden.

Das sehe ich natürlich genause. Ich habe ja auch nie dafür plädiert, die SE16/SE16N zur Änderung von Tabelleninhalten zu benutzen.

Dann stellt man die Tabelle (wie bereits gesagt) einfach auf Anwendungstabelle um

Man kann auch das Pflegeobjekt so anpassen, dass keine Abfrage eines Transportauftrags hochkommt, selbst wenn die Tabelle eine Customizing-Tabelle ist.

EInen Overhead kann ich da nicht erkennen

Das mit dem Overhead bezog sich eher auf den Vergleich dieser beiden Aktivitäten:
-ich nehme eine Customizing-Änderung direkt im Produktivsystem vor
-ich nehme eine im Produktivsystem nötige Änderung im Entwicklungssystem vor, transportiere den TA ins Testsystem, kümmere mich um die Freigabe für das Produktivsystem und warte, bis die SAP-Basis mir die Änderung transportiert.

Anscheinend haben wir also etwas aneinander vorbei geredet.

Frank