Kunden-Customizingtabellen Änderungen protokollieren

Getting started ... Alles für einen gelungenen Start.
15 Beiträge Seite 1 von 1
15 Beiträge Seite 1 von 1

Kunden-Customizingtabellen Änderungen protokollieren

Beitrag von chfreise (ForumUser / 51 / 0 / 0 ) » 16. Feb 2009 16:27

Hallo zusammen,

folgendes Problem beschäftigt mich und irgendwie habe ich Tomaten auf den Augen.
Es gibt 4 Kundentabellen, die als Customizingtabellen definiert sind, Anzeige und Pflege sind erlaubt, techn. Einstellung -> Datenbankänderungen werden protokolliert.
Zur Zeit werden diese 4 Tabellen, wenn nötig, noch über SE16 geändert.
Erwünscht ist nun ein entsprechender Pflegedialog je Tabelle und ein Report, der die Änderungen an diesen Tabellen ausgibt -> User, Datum, Uhrzeit, alter und neuer Wert des geänderten Feldes.
Einen entsprechenden Pflegeview, der über SM30 aufgerufen werden kann, kann man ja erstellen, aber dann verlangt er nach einem Transportauftrag, was eben nicht erwünscht ist.
Für Änderungen, die über SE16 durchgeführt werden finde ich keine Änderungs-Historie.
Ich suche eine praktische Lösung, die es dem Kunden ermöglicht aus einem Dialog (für jede Tabelle ein Button) den entsprechenden "Pflegedialog" aufzurufen und Änderungen durchzuführen.
Über einen Protokollbutton je Tabelle sollen dann, wie bei den Änderungsbelegen, alle Änderungen je Feld angezeigt werden.

Vielen Dank.
CHF


Re: Kunden-Customizingtabellen Änderungen protokollieren

Beitrag von ewx (Top Expert / 3972 / 164 / 368 ) » 16. Feb 2009 17:26

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

Beitrag von chfreise (ForumUser / 51 / 0 / 0 ) » 16. Feb 2009 18:05

Hallo Enno,

erst mal vielen Dank für die Antwort.
Ich werde den Weg über den FuBa nehmen - schauen wir mal wie es ankommt.
Den anderen Hinweis bzgl. Tabellenpflegegenerator und Ausschaltung der Aufzeichnung werde ich mir aber merken!

Grüße
CHF

Re: Kunden-Customizingtabellen Änderungen protokollieren

Beitrag von Frank Dittrich (Expert / 674 / 0 / 16 ) » 16. Feb 2009 23:59

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

Code: Alles auswählen.

keine Berechtigungsgruppe vorhanden mit folgenden Tabellen:
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
Zuletzt geändert von Frank Dittrich am 20. Feb 2009 08:15, insgesamt 4-mal geändert.

Folgende Benutzer bedankten sich beim Autor Frank Dittrich für den Beitrag:
thomy_der_genuss


Re: Kunden-Customizingtabellen Änderungen protokollieren

Beitrag von chfreise (ForumUser / 51 / 0 / 0 ) » 18. Feb 2009 15:00

Hallo Enno,
ewx hat geschrieben: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
Dein Vorschlag über SE16n etc. ist leider nicht so angenommen worden. Deshalb habe ich einen Pflegedialog je Tabelle angelegt (wie im Tricktresor beschrieben inkl. eigener Transaktion). Klappt soweit super! Das Änderungskennzeichen ist in jeder Tabelle für jedes Datenelement gesetzt.
Je Kunden-Tabelle habe ich dann ein entsprechendes Änderungsbelegobjekt angelegt und den Verbucher generiert.
Nun finde ich aber keine entsprechenden Änderungsbelege, wenn ich über den Pflegedialog Änderungen vorgenommen habe.
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?

Grüße
Chris

Re: Kunden-Customizingtabellen Änderungen protokollieren

Beitrag von ewx (Top Expert / 3972 / 164 / 368 ) » 18. Feb 2009 15:06

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

Beitrag von Frank Dittrich (Expert / 674 / 0 / 16 ) » 19. Feb 2009 07:38

Hallo Chris,

es ist normalerweise nicht sinnvoll, für eine Tabelle sowohl die Protokollierung über das Flag in den technischen Einstellungen einzuschalten als auch Änderungsbelege zu erzeugen.
Die Änderungsbelege habe ich in meinem letzten Beitrag nur erwähnt, um zu verhindern, dass andere Leser meinen: "Das mit den technischen Einstellungen ist ja so einfach, dann nehme ich immer diesen Weg und lasse das mit den Änderungsbelegen."

Für "Customizing" (also Tabellen mit überschaubarer Größe und überschaubarer Änderungshäufigkeit) ist das Flag in den teschnischen Einstellungen der richtige Weg.
Nur werden dann keine Änderungsbelege geschrieben (Tabellen CDHDR, CDPOS...), sondern die SAP-SQL-Schnittstelle sorgt dafür, dass neben der eigentlichen Änderung noch DBTABLOG-Einträge geschrieben werden.

Und wenn die Tabellen per SM30 gepflegt werden (egal ob im Entwicklungssystem mit Transport ins Produktivsystem oder direkt als laufende Einstellung im Produktivsystem), deutet das schon darauf hin, dass das Flag in den technischen Einstellungen der richtige Weg ist.
Dagagen, dass es sich hier um Massendaten handelt, spricht ja schon, dass die User sich ständig gegenseitig die Tabelle sperren würden und gar nicht zu massenhaften Änderungen in der Lage wären.

Das Flag in den technischen Einstellungen bedeutet einerseits, dass der Programmierer nichts weiter machen muss (also keinen FB *_WRITE_DOCUMENT aufrufen).
Andererseits werden die so protokollierten Änderungen natürlich auch mit einer eigenen Transaktion angezeigt, s. meinen letzten Beitrag.

Ich kann mir ehrlich gesagt nicht vorstellen, dass der Profile-Parameter rec/client in einem Entwicklungs-/Produktivsystem noch auf OFF steht.
Das ist zwar der Default, aber SAP-Installationsleitfäden, Revision und/oder Wirtschaftsprüfer sollten doch normalerweise eine Änderung vorgeschlagen haben.

Das von Dir erwähnte Flag am Datenelement ist übrigens für die Protokollierung in DBTABLOG irrelevant.
Das wird nur beim Schreiben von Änderungsbelegen berücksichtigt.

Frank

Re: Kunden-Customizingtabellen Änderungen protokollieren

Beitrag von thomy_der_genuss (ForumUser / 2 / 1 / 0 ) » 29. Okt 2009 16:53

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

Beitrag von UserBC (ForumUser / 58 / 0 / 2 ) » 30. Okt 2009 00:27

Hallo Chris,

warum ist es nicht erwünscht einen Transporrtauftrag zu bekommen ?

Für die Pflege die SE16 oder die SE16N zu verwenden geht ja gar nicht.

IMMER eine Pflegeview zu einer Cust-Tabelle anlegen, dort kann dann auch die Protokollierung aktiviert werden.
Sind unterschiedliche Einträge auf den Systemen gewünscht, muss die Tabelle eben als Anwendungstabelle und nicht als Customizingtabelle definiert sein.

Zu Vereinfachung der Pflege kann über die SE53 ein Viewcluster angelegt werden (wie im SAP-Standardcustomizing, wenn mehrere Tabellen benötigt werden).
View und / oder Clusterview können in eine Kunden-IMG eingefügt werden ODER über eine extra angelegte Transaktion aufgerufen werden.
Diese Transaktion kann dann in den Favoriten oder in ein Rollenmenü eingebunden werden.

Das ist nicht nur sicherer als die SE16 / SE16N, sondern auch noch komfortabler.

Gruss
UserBC

Re: Kunden-Customizingtabellen Änderungen protokollieren

Beitrag von Frank Dittrich (Expert / 674 / 0 / 16 ) » 30. Okt 2009 08:38

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

Beitrag von Frank Dittrich (Expert / 674 / 0 / 16 ) » 30. Okt 2009 08:46

UserBC hat geschrieben: warum ist es nicht erwünscht einen Transporrtauftrag zu bekommen ?
Weil man manche Dinge z.B. direkt im Produktivsystem ändern können möchte, ohne extra eine entsprechende Anwendung programmieren zu müssen, wo doch die SM30 schon fast genau das tut, was man will, und den Zeitverzug und organisatorsichen Overhead, der mit Transportieren verbunden ist, vermeiden will.
(Gibt es auch für ein paar SAP-Standard-Tabellen, läuft unter "laufende Einstellungen")

Frank

Re: Kunden-Customizingtabellen Änderungen protokollieren

Beitrag von thomy_der_genuss (ForumUser / 2 / 1 / 0 ) » 30. Okt 2009 18:00

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

Beitrag von UserBC (ForumUser / 58 / 0 / 2 ) » 30. Okt 2009 18:31

Hallo Zusammen,

selbstverständlich gibt es Sachen, die man in jedem System anders einstellen muss,
allerdings ging die Begründung nicht aus dem Beitrag hervor.

Auch dann ist es kein Grund die SE16/SE16N zu versenden.
Dann stellt man die Tabelle (wie bereits gesagt) einfach auf Anwendungstabelle um,
läßt sich eine schicken View generieren und fasst bei Bedarf auch noch verschiedene Views zu einem View-Cluster zusammen.
Um den Komfort zu erhöhen erstellt man noch eine Transaktion, die nur den View oder den View-Cluster aufruft.

Und schon hat man alles was man braucht:
*Unterschiedliche Einstellungen auf unterschiedlichen Systemen
*Schicken Pflegeview wie im Standard-Customizing
*Mehrere Customizing-Tabellen in einem View
*Zugriff auf das Customizing über eine Transaktion in einem Benutzermenü
*Berechtigungsprüfung über die Pflegetransaktion

EInen Overhead kann ich da nicht erkennen:
Generierung View ca. 1 min je View
Erstellung des Cluster-View ca. 3 min
Berechtigungsobjekt anlegen ca. 1 min
Erstellung der Transaktion ca. 1 min
Einbinden in ein Benutzermenü ca. 1 min

Dafür gibts dann bei jeder Änderung einen erstklassigen Komfort - der zukünftige Bediener wird es dir danken.


Gruss
UserBC

Re: Kunden-Customizingtabellen Änderungen protokollieren

Beitrag von Frank Dittrich (Expert / 674 / 0 / 16 ) » 2. Nov 2009 09:21

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

Re: Kunden-Customizingtabellen Änderungen protokollieren

Beitrag von Frank Dittrich (Expert / 674 / 0 / 16 ) » 2. Nov 2009 09:40

thomy_der_genuss hat geschrieben:Ich bin ehrlich gesagt neugierig, wieso Du auf Google schließt, wo ich doch auch im Forum direkt hätte gesucht haben können ...
Na ja, ich habe einfach von mir auf andere geschlossen.
Und ich hätte halt bei Google gesucht und die Phrase in Anführungszeichen eingegeben, um zu sehen, ob das Problem schon mal diskutiert wurde.
(Wenn nicht, hätte ich mich vermutlich sogar noch mal mit SY-LANGU 'E' angemeldet, und die Phrase bei Google eingeworfen.

Ansonsten hätte ich ja in mindestens drei verschiedenen Foren suchen müssen, mich damit herumärgern müssen, dass die Suche nach einer Phrase gae nicht richtig funktioniert und ich unter Umständen also jede menge irrelevanter Threads durchwühlen muss, wo nur zufällig die Wörter aus meinr Phrase vorkommen.
Inzwischen bin ich mir recht sicher, dass unser Kunde einfach kein S_TABU_DIS auf Tabellen ohne Berechtigungsgruppe hat.
Noch mal zur Klarstellung, das ist kein Problem fehlender Berechtigung des Anwenders.
Selbst mit SAP_ALL scheitert man hier, weil SAP gar nicht erst bis zum AUTHORITY-CHECK OBJECT 'S_TABU_DIS' ... kommt, falls kein TDDAT-Eintrag gefunden wird.
Das ist ja das Absurde.

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.)
Ja, könnte man.
Man könnte auch debuggen, warum man in der SCU3 nicht weiter kommt. Oder einen SQL-Trace (oder in dem Fall Tabellenpuffer-Trace) einschalten...
Es wird tatsächlich auf '&NC&' geprüft.
Das macht auch die SE16.
Die SE16 prüft aber eben auch auf '&NC&', wenn gar kein TDDAT-Eintrag existiert oder wenn TDDAT-CCLASS initial ist.
Also hat sowieso jeder, der mit der SE16 arbeiten darf, die Berechtigung für S_TABU_DIS mit ACTVT 03 und DIBERCLS &NC&.

Warum die SCU3 das nicht auch einfach so macht, ist ja gerade die Frage.
Es ist dorch nicht sinnvoll, dass die SE16 diese Tabellen so behandelt wie fast nicht schützenswert (Text zu &NC& ist 'ohne Berechtigungsgruppe') und die SCU3 so tut, als wäre es verboten, die Historie der Daten-Änderungen in diesen Tabellen sehen zu wollen.

Frank

Seite 1 von 1

Aktuelle Forenbeiträge

Langtext zur Exception
vor 50 Minuten von a-dead-trousers 11 / 96
Adobe LiveCycle Designer - Ausblenden Text auf letzter Seite
vor 2 Stunden von a-dead-trousers 4 / 92
Welche Entwicklertools?
vor 18 Stunden von LostDarkness 2 / 922
Werksspezifische Konfiguration kopieren
vor 19 Stunden von eleve 2 / 48
Removal of left space - next to a docking container
vor 19 Stunden von Haemma83 16 / 115

Unbeantwortete Forenbeiträge

BAPI_PO_CREATE1 und Einkaufsinfosatz
vor 3 Tagen von SweetRuedi 1 / 81
WCOCO: Gruppe für Betragsfelder 0S01
vor 5 Tagen von SAP_ENTWICKLER 1 / 52
CAS-Nr.: Chemical Abstracs Service
vor einer Woche von SAP_ENTWICKLER 1 / 92
Interaktives Skript, Rolle IC-Manager
vor 3 Wochen von erubadhron86 1 / 129