Es ist ein offenes Geheimnis: wer nach dem sucht, was das SAP im Innersten zusammenhält, landet unweigerlich in der Datenbank. Aufgrund der konsequent plattformübergreifenden Anwendungsgestaltung ist das die für SAP gewählte Architektur. Daher ist es für erfahrene SAP Anwender äußerst spannend, Zugriff auf eben diese Tabellen zu erhalten. Hier steht, welche Möglichkeiten es gibt.
Vorwort
„Wissen ist Macht“ sagt der Volksmund, und es ist oft nicht minder wichtig zu erwähnen, das Wissen auch Verantwortung ist. Die SAP-Tabellen sind in zahlreichen komplexen Relationen miteinander verbunden. Die Änderung dieser Inhalte ist nicht umsonst in FuBas und Reports gekapselt, die diese Abhängigkeiten kennen. Teilweise ändern sich auch die Bedingungen mit Wechsel des Releases oder Support Package Stands.
Kurz gesagt : wer Tabellen ändert, sollte genau wissen was er tut. Im schlimmsten Fall zerschießt er sich damit das System vollständig und nachhaltig. Die hier genannten Wege sind keineswegs illegal oder “gegen die Produktspezifika”. SAP selbst bietet diese Wege für entsprechend berechtigte Personen in Form von “gewollter Funktionalität”, es kennt sie nur nicht jeder.
Außerdem muss besonders bei audit-relevanten Inhalten aufgepasst werden. Änderungen in Tabellen sind nicht protokolliert und damit auch nicht nachvollziehbar. Daher im Produktivsystem Finger weg von Anwendungstabellen die Kopf- oder Belegdaten enthalten, Sie könnten damit den Auditor nachhaltig verärgern. Das im Hinterkopf zu behalten kann nicht schaden, wenn man sich in die Untiefen der direkten Tabellenänderungen begibt.
Ich will nur spielen..
Bestimmte Tätigkeiten erfordern auch in nicht änderbaren Systemen regelmäßige Anpassungen an Tabellen. Wollen Sie bspw. Währungskurse pflegen und (!) ihr Mandant ist als „produktiv“ gekennzeichnet, können Sie diese speziellen Tabellenpflegemöglichkeiten mittels Transaktion „SOBJ“ konfigurieren. Hinweis 135028 ist dann u.a. ihr Freund.
Der harte Weg (ich darf SE16N)
Ein „böser“ (weil nicht außerhalb von Entwicklungsumgebungen vorgesehener) Weg ist das Setzen des OK-Codes „&SAP_EDIT“ in der SE16N (alternativ : Debug –> GD-EDIT = X). Dies geht natürlich nur, wenn Ihre Berechtigungsadministratoren die SE16N zulassen. So können Sie dann viele – sonst störrische – Tabellen zum Kooperieren überreden.
Anmerkung: Die SAP hat hierbei teilweise die Funkionalität verändert (irgendwann in 6.40). Der findige Administrator kann jedoch auf eigene Gefahr mit einigen Hinweisen das alte Verhalten wieder herstellen : 1446530 ; 1468636 (nur intern freigegeben, trotzdem einbaubar) ; 1525586.
Der harte Weg (Teil 2)
Wer debuggen darf, darf alles. Deswegen wird auf diese Berechtigung im Berechtigungskonzept sehr viel Wert gelegt. Mit der „/h“ (OK-Code) Berechtigung kann problemlos in der SE16 auch im Lesemodus das Schreiben aktiviert werden, oder in der UASE16N die “obsolet”-Meldung übergangen werden.
In den Schreibmodus: Flugs „sy-ucomm“ auf „EDIT“ („DELE“, „INSR“) gesetzt, und schon ist die entsprechende Tabelle für alle Experimente offen.
Der eigensinnige Weg
Während die bisher gezeigten Wege sehr weite Rechte erfordern, kann ein Programm in der Minimal-Ausführung auch ’nur‘ SA38/SE38 Inhabern Zugriff auf Tabellenänderungen gewähren. Auch hier sei vor allem in der Produktion aufgepasst. Für die Nutzung durch Enduser ist das vollkommen ungeeignet, hier müssten entsprechende Prüfungen hinzugefügt werden, wenn in Ihrem Unternehmen die SA38 verbreitet ist. Der folgende Quelltext ruft tatsächlich nur einen Funktionsbaustein, wurde aber von mir noch nicht getestet:
***********************************
REPORT ZZBC_TAB_SELECT.
parameters: z_tab type se16n_tab obligatory,
z_anz type sytabix DEFAULT ‚1000‘.
START-OF-SELECTION.
CALL FUNCTION ‚SE16N_INTERFACE‘
EXPORTING
I_TAB = z_tab
I_EDIT = ‚X‘
I_SAPEDIT = ‚X‘
I_MAX_LINES = z_anz.
***********************************
Der direkte Weg
Am besten hat es nach wie vor der Datenbankadministrator. Jede Datenbank bietet Tools und Schnittstellen um Tabelleninhalte anzupassen (Oracle sqlplus über OPS$, MaxDB Database Manager mittels XUSER), und diese lassen sich mit genügend Sachkenntnis für viele praktische Dinge verwenden.
Stichwortartig seien hier erwähnt :
– der SAP*-User sitzt in der Tabelle USR02 und ist durch MANDT einem Mandanten zugeordnet
– die RFC Destinationen lassen sich vor Überschreiben des Systems prima aus der RFCDES holen (bitte nicht vergessen: RFCATTRIB, RFCCMC, RFCDOC, RFCSYSACL, RFCTRUST)
– .. oder nach Systemkopie klasse invalidieren („.. set rfcoptions = replace (rfcoptions,’H=’,’H=#’) where rfctype = ‚3’; .. = ‚T’;)
– die Batchjobs sollte man nach Systemkopie gemäß Guide ausplanen (TBTCO Status P und TBTCS)
Das Obligatorische
Diese Dokumentation ist eine Sammlung von Erfahrungswerten, und in keiner Form von den Produktherstellern (SAP, Oracle, ..) geprüft oder freigegeben worden. Es kann keine Haftung für Schäden übernommen werden, die aus dem (teilweisen oder vollständigen) Befolgen dieser Dokumentation entstehen.
Selbstverständlich freue ich mich über Fragen, Anmerkungen oder Ergänzungen.
