SAP Tabellen für Transaktionen, Berechtigungsobjekte und Berechtigungsfelder

3. März 2012 | 12:16 am Uhr

Zurzeit fahre ich einige Auswertungen über notwendige und mögliche Berechtigungen von Transaktionen und Programmen. Dabei muss man sich durch einige Tabellen im SAP hangeln, hier sind meine derzeitigen Favoriten:

 

Tabellenname (ggf. Langtext) Verwendung
USOBT_C Berechtigungsvorschläge zu Transaktionen – in dieser Tabelle sind alle Berechtigungsobjekte aufgeführt, die auch beim Einfügen über das SAP Menü in der PFCG später im Profil-Editor vorgeschlagen werden würden. Oder kurz: SU24.
TSTC (TSTCT) Langtext für Transaktionen
TOBJ (TOBJT) Langtext für Berechtigungsobjekte
USORG Orgebenen für Profilgenerator
TACT (TACTT) Zuordnung Nummer zu Aktivität
TACTZ Mögliche Aktivitäten für ein bestimmtes Berechtigungsfeld

Weiterlesen »

Kommentieren » | Berechtigung

Genutzte Transaktionen aus dem SAP Workload Monitor ST03N exportieren

24. Februar 2012 | 5:59 pm Uhr

Mit dem Funktionsbaustein SWNC_COLLECTOR_GET_AGGREGATES können vom System gesammelte Workload-Daten extrahiert werden. Die Ergebnisse entsprechen den Daten wie sie z.B. auch im Systemlastmonitor (ST03N) zu finden sind. Eine solche Liste von tatsächlich genutzten Transaktionen ist beispielsweise sehr nützlich für das Erstellen von neuen Rollen. Dem Anwender oder Keyuser kann man schon im Vorfeld “seine” Transaktionen präsentieren und so die Rollenentwicklung deutlich beschleunigen.

Wenn man nicht gleich ein ABAP schreiben möchte, kann man auch folgende Schritte durchführen:

Funktionsbaustein SWNC_COLLECTOR_GET_AGGREGATES in SE37 ausführen.

Parameter für den Funktionsbaustein eingeben und “Ausführen”

Import-Parameter Wert Bedeutung
COMPONENT TOTAL Alle Applikationsserver einbeziehen
PERIODTYPE M Monat, Alternativ W = Week
PERIODSTRT 01012012 erster Tag des gewünschten Zeitabschnitts, hier der 01.02.2012

 


 

Ergebnistabelle USERTCODE selektieren.

 

Die Liste als Lokale Datei abspeichern.

 

Der Benutzername befindet sich in der Spalte Account. Die Transaktionen und Programme stehen dann in der Spalte “ENTRY_ID”. Am Ende der gleichen Spalte (Zeichen 72) steht dann jeweils der Typ, also z.B. der Buchstabe T für Transaktion oder R für Report.

Tipp: Den Langtext der Transaktionen in der passenden Sprache kann man sich aus der Tabelle TSTCT besorgen.

Kommentieren » | Berechtigung, HowTo

SAP Debug Berechtigung einschränken

17. Februar 2012 | 6:41 pm Uhr

Über das Berechtigungsobjekt S_DEVELOP kann man Debugging-Berechtigung im SAP erteilen. Diese Berechtigung erlaubt es über die Eingabe von “/h” im OK-Feld der Gui den Debug-Modus zu aktivieren.

Während diese Funktion auf dem Entwicklungssystem ohne Frage zu den notwendigen Entwicklungsfunktionalitäten dazugehört ist es auf einem Produktions- oder Konsolidierungssystem höchst kritisch. Denn es erlaubt dem Anwender den normalen Programmablauf zu beeinflussen und Werte während des Programmlaufs zu ändern.

So kann ein Anwender ein Programm starten und z.B. einen AUTHORITY-CHECK überspringen. Damit erlangt er Zugang zu Daten oder kann Änderungen vornehmen, die im normalen Programmfluss nicht vorgesehen sind.

Ein prominentes Beispiel ist auch über den Debug-Modus das sapedit in der SE16 bzw. SE16N wieder zu aktivieren – dann kann man direkt in der Tabellenansicht Änderungen in der Datenbank durchgeführen. Diese Möglichkeit Felder zu ändern gefährdet den Grundsatz “Keine Änderung ohne Beleg”.

Wie kann man nun S_DEVELOP einschränken?

Zuerst muss man die Rollen identifizieren, die S_DEVELOP mit DEBUG Aktivität 02 enthalten. Dies kann man über die SUIM -> Rollen nach komplexen Selektionskriterien durchgeführt werden. Wenn man den Debug-Modus komplett deaktiveren will, muss man auch nach Aktivität 03 suchen.

Im Rolleneditor in der PFCG kann man nun die entsprechende Rolle einschränken.

Im Hinweis 65968 – ABAP-Debugging-Berechtigungen werden die möglichen Werten für S_DEVELOP dokumentiert:

OBJTYPE ACTVT
DEBUG 03 – Anzeigen
DEBUG 02 – Ändern von Feldinhalten und ‘Zu Anweisung springen’
DEBUG 01 – Kernel-Debugging (für Kunden nicht relevant, nur für  SAP-interne Zwecke)

Kommentieren » | Berechtigung, HowTo

Betriebssyteminformationen aus dem SAP heraus analysieren

13. Februar 2012 | 9:45 pm Uhr

Externes Hosting und Funktionstrennung machen mittlerweile die Suche nach Ursachen für Performance Engpässe zu einer Aufgabe mit vielen Beteiligten. Es gibt aber durchaus einige SAP Transaktionen, mit denen man auch ohne Root-Prompt und Zugriff auf den Solution Manager Informationen über den Teil unterhalb des ABAP Stacks sammeln kann.

OS07N Operating System Monitor (neu)

DieOS07N (Report RSHOST1N) bietet eine schnelle Übersicht über Betriebssysteminformationen und Speicherauslastung. Vor allem aber kann man schnell zwischen den Applikationsservern hin und her springen und so sich einen guten Überblick über alle beteiligten Systeme verschaffen. Die Daten basieren auf Informationen die via CCMS und dem saposcol (Operating System Collector) eingesammelt werden.

ST06 – Operating System Monitor (alt)

Da vor allem die historischen Werte in der OS07N oft nicht abrufbar sind und erst konfiguriert werden müssen, leistet die ST06 weiterhin gute Dienste. Tipp: Auf den jeweiligen Applikationsserver kann man über die SM51 springen: Doppelklick auf den Applikationsserver öffnet einen neuen Modus auf dem Applikationsserver.

Daily Averages – Last 30 Days erlaubt einen Überblick über die letzten 30 Tage. Über Details kann man sich dann wiederumm die Details für einen Tag auswählen.

Wenn man “More information” auswählt kann man durch die verschiedenen Sichten CPU, Memory, Disk times, LAN, Filesystem statistics durchschalten.

Report RSBDCOS0 – Betriebssystemkommandos ausführen

Mit dem Report RSBDCOS0 kann man Befehle auf Betriebssystemebene absetzen – allerdings im Kontext des SAP System-Users. Also zum Beispiel <sid>adm oder SAPService<SID>. Dort gehen dann natürlich nur Befehle die keine root/Administrator-Berechtigungen benötigen.

Kommentieren » | HowTo

SSO Troubleshooting Checklist

2. Februar 2012 | 3:12 pm Uhr

Single Sign On ist ein beliebtes Thema aus der Kategorie kleines Problem – lange Fehlersuche. Ich habe mir dafür eine kleine Checkliste zusammengestellt. Die passenden Quell-Hinweise sind im jeweiligen Check verlinkt. Ich freue mich über jeden Kommentar – z.B. wenn noch ein möglicher Check fehlen sollte.

 

Check 1 Systemversion und Version von SAPSECULIB oder SAPCRYPTOLIB

Welche Systemversion wird eingesetzt bzw. unterscheiden sich Test- & Produktivsystem?
Report SSF02 mit Parameter “Version ermitteln” (z.B. über SE38) ausführen

Result: SSF_API_OK

Wenn nicht: STRUSTSSO2 im eigenen und ggf. im 000-Mandant prüfen
Prüfen ob die SAPSECULIB oder SAPCRYPTOLIB aktuell ist:

http://service.sap.com/download -> Download -> SAP Cryptographic Software.

Die Profilparameter müssen korrekt gesetzt sein:

ssf/ssfapi_lib = <Pfad zum Sicherheitsprodukt> (SAP Security Library)

ssf/name = SAPSECULIB

sec/libsapsecu = <Pfad zum Sicherheitsprodukt> (SAP Security Library)
Siehe dazu auch: Hinweis 701205 – Single Sign-On über SAP-Anmeldetickets

 

Check 2 Profilparameter

RZ11 temporär, RZ10 permanent

login/accept_sso2_ticket 1
login/create_sso2_ticket 2 (ohne Zertifikat)
icm/host_name_full FQDN (z.B. hostname.example.com), Achtung Reverse Proxies!

 

Check 3 Transaktion STRUSTSSO2

System-PSE prüfen, muss grün sein


Check 4 Transaktion SSO2

Die Transaktion ist zwar schon veraltet, die Fehlermeldungen dort können aber sehr gut recherchiert werden

Das Zertifikat muss ggf. in die Trust-Liste der Systeme (STRUSTSSO2), die das Logon-Ticket akzeptieren (sofern das Ticket überhaupt signiert ist).

RFC-Destination: NONE

 

Check 5: Transaktion SICF

Bei Nutzung von SSO-Tickets für eigene Webservices:

/default_host/sap/bc/srt/rfc/sap/WEBSERVICENAME

/default_host/sap/bc/bsp/sap/system_test (siehe nächsten Punkt)

Sind die aktiv?

 

Check 6 : Transaktion SE80, Testwebseite SSO

SYSTEM_TEST/test_sso2.htm –> Testen (F8)

Wenn nicht verfügbar –> SICF prüfen (Check 5)

Die URL oben kopieren und danach alle Browser-Fenster schließen. Danach neuen Browser aufmachen und probieren.

Beispiel-URL: http://hostname.example.com:8000/sap(bD1kZSZjPTgwMA==)/bc/bsp/sap/system_test/test_sso2.htm

Da sollte ein Cookie á la: ‘MYSAPSSO2=…’ sein.

Alternativ auch

javascript:alert(document.cookie);
Siehe dazu auch: Hinweis 817529 – Überprüfung der SSO-Konfiguration

Kommentieren » | HowTo

Fehler beim BI_CONT einspielen: Quellsystem existiert nicht

29. Januar 2012 | 2:34 pm Uhr

Bei der Aktualisierung des BI Contents (auf BI_CONT 7.06) gab es in der SAINT einen Abbruch in der Phase RS_DTRF_AFTER_IMPORT/XPRA_EXECUTION: Quellsystem <Name des Quellsystems> existiert nicht (RSAR203). Nach kurzer Suche sind wir auf Hinweis 1564964 gestoßen: Den Funktionsbaustein RSAR_LOGICAL_SYSTEM_DELETE in der SE37 mit I_LOGSYS = <zu löschendes Quellsystem> und alle anderen Parameter = ‚X’ ausführen. (Vorher beachten, ob der dort erwähnte Hinweis eingespielt worden ist)

Das Problem dabei war: Wir mussten den Import in der SAINT immer wieder starten und jedes mal wurde nur genau ein Quellsystem als verwaist gemeldet. Es stellte sich aber hinterher heraus, dass verwaiste Einträge von fast einem Duzend Quellsystemen im System vorhanden waren. Die Laufzeit des Upgrades steigerte sich damit um zwei Tage, da er immer wieder nach der Bereinigung eines Systems neu gestartet werden musste.

Ich habe leider keinen offiziellen Weg gefunden, um im Vorfeld verwaiste Quellsysteme zu finden. Daher habe ich versucht, der Datenbank etwas Brauchbares zu entlocken. Die Tabelle RSBASIDOC enthält die Quellsysteme, so wie man sie auch in der RSA13 sehen kann. Da in den Hinweisen die Tabelle RSOLTPSOURCE für BW 3.x als Workaround genannte wird, habe ich schließlich folgendes SQL-Statement entwickelt:

select distinct logsys from  RSOLTPSOURCE where logsys not in (select slogsys from RSBASIDOC)

Dieses Statement kann man z.B. auch über das DBACOCKPIT absetzen. Die Ergebnisliste wurde dann vom Anwendungssupport geprüft. Tatsächlich waren alle Treffer Quellsysteme, die schon vor einiger Zeit aus der RSA13 entfernt worden sind. Mit der Liste und dem Vorgehen aus Hinweis 1564964 konnten wir die verwaisten Quellsysteme im Vorfeld löschen und die Upgradezeit in den Folgesystemen von drei Tagen auf wenige Stunden verkleinern.

Kommentieren » | CaseClosed

Massensperren von Benutzern via SU10

20. Januar 2012 | 9:52 pm Uhr

Für Wartungsarbeiten wie z.B. Upgrades kann es sinnvoll sein, alle nicht benötigten Benutzer eines Systems zu sperren. Diese kann über die Transaktion SU10 durchgeführt werden.
Transaktion SU10 – Benutzerpflege Massenänderungen



“Nur nicht gesperrete Benutzer”, Ausführen (F8). Dies stellt sicher, dass nach dem Upgrade die nur die richtigen Benutzer wieder entsperrt werden.

Liste Sichern in Datei…

Aus der Excel-Datei die Spalte Benutzername in eine eigene Textdatei kopieren. Aus dieser Datei die User ADMIN, DDIC, J2EE_ADMIN,J2EE_GUEST, J2EE_DDIC,SAP* und den eigenen User entfernen!


Wenn man diese Liste erstellt hat, läuft das Sperren und Entsperren praktisch gleich ab. Wichtig: immer daran denken, dass der eigene User, der admin und ddic nicht in der Liste sind.
Wieder in der Transaktion SU10:

 

 

“Import aus Textfile”, danach auf “Übernehmen”

Alle Selektieren und “Übernehmen”

 


Dann kann man jeweils sperren oder entsperren auswählen.

Kommentieren » | HowTo

Fehler “unable to save the local file information” im SAP Download Manager

25. August 2011 | 3:06 pm Uhr

Heute begrüßte mich der SAP Download Manager auf einem unserer Server mit der Information

“Unable to save the local file information: the store file could not be found.” Leider kannte die XSEARCH der SAP zwar diese Fehlermeldung, aber keine Lösung.


Nach mehreren Neuinstallationen und auch einer Neuinstallation der Java JRE (32 Bit!) war die Fehlermeldung immer noch da. Damit war klar: ich brauche den ProcessMonitor von Sysinternals, um dem Problem auf die Spur zu kommen. Und siehe da, der Trace zeigte, dass der Download Manager ein “ACCESS DENIED” beim Anlegen der Datei dlclient.localstate bekommen hat.


Nachdem ich diese Datei gelöscht hatte, hat der SAP Download Manager wieder ordnungsgemäß funktioniert.

Kommentieren » | CaseClosed

Netzwerkverbindungen aus dem SAP testen

21. August 2011 | 6:27 pm Uhr

In der Regel kommt der Betrieb der SAP Applikationsserver und der Netzwerk-/Firewall-Infrastruktur nicht aus einer Hand. Das kann die Ursachenanalyse für ein Problem erschweren. Gut wenn man als SAP Basis Mitarbeiter ein paar Werkzeuge kennt, um Applikationsprobleme von gestörten oder abgeschotteten Netzwerkverbindungen abgrenzen zu können.

 

Telnet

Hinweis: Bei neueren Windows-Installationen muss man den Telnet-Client erst nachinstallieren. Unter Linux/Unix ist es im Standardumfang enthalten.

Aufruf:

telnet hostname port

Beispiel:

telnet meinsaprouter.company.com 3299
Wird die Console schwarz und ein Cursor blinkt links oben dann ist die Verbindung erfolgreich hergestellt worden. Die Verbindung beenden kann man mit “CTRL++” und der Eingabe quit.

Blockiert eine Firewall die Verbindung, dann dauert es eine Weile bis schließlich ein Timeout gemeldet wird.

Wird die Verbindung aufgebaut, aber gleich darauf getrennt, ist die Wahrscheinlichkeit hoch, dass es ein saprouter/Dienst-Problem ist.

 

Niping

Mit niping kann man die Verbindung zu einem Dispatcher oder Gateway testen, inklusive der SAP Router dazwischen. Dies ist ein deutlicher Vorteil gegenüber den direkten Tools wie telnet und netcat.
Tipp: Über den Report RSBDCOS0 kann man das Programm direkt auf dem Applikationsserver ohne Betriebssystemzugriff laufen lassen.
Aufruf:

niping -c -H HOSTNAME oder SAPROUTERSTRING -S PORT

 

1. Beispiel:

[1]niping -c -H /H/meinsaprouter.company.com -S sapdp99

[1]ReturnCode= 1-ng -c -H /H/meinsaprouter.company.com -S sapdp99

 

Sun Aug 21 18:22:07 2011

***LOG Q0I=> NiPConnect2: meinsaprouter.company.com:3299: connect (10061: WSAECONNREFUSED: Connection refused) [nixxi.cpp 3133]

*** ERROR => NiPConnect2: SiPeekPendConn failed for hdl 1/sock 268

(SI_ECONN_REFUSE/10061; I4; ST; meinsaprouter.company.com:3299) [nixxi.cpp 3133]

*** ERROR => NiTClientLoop: NiHandle (rc=-10) [nixxtst.cpp 2529]

2. Beispiel:

[2]niping -c -H /H/meinsaprouter.company.com -S sapdp99

[2]ReturnCode= 1-ng -c -H /H/meinsaprouter.company.com -S sapdp99

 

Sun Aug 21 18:25:01 2011

connect to server o.k.

*** ERROR => NiBufIProcMsg: hdl 1 received rc=-93 (NIEROUT_INTERN) from peer [nibuf.cpp 2115]

*** ERROR => NiTClientLoop: NiTReadLoop (rc=-93) [nixxtst.cpp 2529]

 

Bei dem ersten Beispiel war der SAP Router Dienst nicht gestartet, beim zweiten Beispiel war der Zugriff erfolgreich. Die “*** ERROR” Nachrichten kann man vernachlässigen.

 

Netcat

Für andere Netzwerkdienste (z.B. Test ob der Mailserver-Port offen ist) kann man neben telnet auch netcat sehr gut einsetzen. Allerdings ist das Programm nur in der Unix/Linux-Welt im Standardumfang verfügbar.
Aufruf:

netcat -w5 -z -v HOSTNAME PORT

-w 5 sekunden warten

-z port scanning only

-v verbose
Beispiel:

[6]netcat -w5 -z -v mail.company.com 25 2>/tmp/test_mailtest.txt

[7]cat /tmp/test_mailtest.txt

mail.company.com [10.0.0.1] 25 (smtp) open
Durch die Parameter im Beispiel läuft netcat nicht-interaktiv und ist damit auch wieder für den SAP Report RSBDCOS0 geeignet.

Kommentieren » | HowTo

SAP Solution Manager Key generieren

9. Mai 2011 | 2:13 pm Uhr

Bei der Installation von neuen SAP Systemen wird unter anderem auch nach dem Solution Manager key gefragt. Dieser auch Installationsschlüssel oder Installationkey genannte alphanumerische Zeichenfolge kann im Solution Manager über die Transaktion SMSY (System Landscape) generiert werden.

Beispiel hier ist eine Netweaver CE Installation mit der Abfrage des Solution Manager Keys.

Zur Generierung des Schlüssels zuerst in der Transaktion SMSY rechts-klick auf Systems ausführen, Create New System auswählen.

Als System die SID der Installation verwenden, die Installation Number bleibt frei.

Mindestens eine relevante Main Instance selektieren (z.B. Java Application Server) und speichern.

Danach System auswählen und auf “Other object…” gehen.

Generate Installation/Upgrade Key auswählen

Message Server entspricht dann dem Hostnamen des Systems. Ein Klick auf Generate Key erzeugt den gewünschten Schlüssel.

Siehe auch:
Hinweis 811923 – Generierung SAP Solution Manager key

Kommentieren » | HowTo

« Ältere Einträge     Neuere Einträge »