Ich bin ITIL® V3 zertifizierter SAP NetWeaver Consultant bei der mindsquare GmbH und Fachbereichsleiter für die Themen SAP Basis und Infrastruktur.
Nach einem Upgrade auf NetWeaver / ECC 6.0 kann es erforderlich sein, die Produktversion eines Systems in der Systemlandschaft des Solution Managers (System Landscape) manuell zu ändern.
Dafür geht man in die Transaktion SMSY und wählt “Objekt auswählen”.
Hier wählt man das Produktsystem aus, dass man ändern möchte, üblicherweise entspricht das der SID des SAP-Systems.
Nach einem Upgrade von R/3 4.7 auf ECC 6.0 werden im EarlyWatchAlert keine Informationen über die Datenbankgröße mehr angezeigt. Das ERP-System läuft mit einem SQL Server 2005.
In der neuen Transaktion DBACOCKPIT wird der Fehler “SQL-Fehler 208 Invalid object name ‘sap_tabstats’” gemeldet, wenn man die Tabellenstatistiken aufruft. Der Hinweis 1027512 enthielt den richtigen Wink:
Die Jobkonfiguration für die neue Datensammelmethode für die Tabellengrößenhistorie können Sie über “DBACOCKPIT -> Platz -> Historie -> Tabellengrößenhistorie -> Job-Konfiguration” aufrufen.
[…]
Der Name des SQL-Agent-Jobs lautet SAP CCMS_<sid>_<SID>_Update_Tabstats.
Genau dieser Job (im Enterprise Manager unter SQL Server Agent>Jobs einsehbar) ist permanent auf einen Fehler gelaufen. Der Grund dafür war, dass die unterliegende Datenbank noch mit einem Default-Schema dbo arbeitet. Zu sehen war das auch an den Job-Namen: CCMS_dbo_<SID>_*. Allerdings gab es für den Datenbankuser dbo keinen Login.
Es gibt zwei Möglichkeiten die Anmeldesprache in einem SAP System zu setzen.
Systemweite Anmeldesprache
Diese wird schon sichtbar, wenn man im Anmeldebildschirm eines Applikationsservers steht und gilt auch als Dialogsprache für alle Anwender.
Letzte Woche habe ich in dem Artikel Grafische Visualisierung von SAP Tabellen und Tabellenbeziehungen das Thema Abfrage von Tabelle mit dem QuickViewer erwähnt. Hier eine kurze Anleitung wie man eine entsprechende Abfrage bauen kann.
Hat man die entsprechenden Beziehungen der Tabellen ermittelt, kann man dann relativ bequem Join-Queries über die Transaktion SQVI machen. Das Beispiel soll die durch Rollen zugewiesenen Organisationsebenen eines Benutzers anzeigen. Diese Daten stehen in den Tabellen AGR_USERS und AGR_1252.
In Berechtigungsprojekten kommt immer auch das Thema Berechtigungsprüfungen von Eigenentwicklungen auf die Tagesordnung. Oft genug ist das Programm mangelhaft dokumentiert, der Programmierer fort und es waren schlicht und einfach zum Entwicklungszeitpunkt keinerlei Anforderungen gestellt worden.
Folgende Werkzeuge und Einstiege kann man zur Analyse von Quelltexten einsetzen. Gesucht wird immer nach ‘AUTH’ oder ‘AUTHORITY-CHECK’
Jeder Rollenbauer und Berechtigungsadmin kennt das Problem: wenn man eine kundeneigene Transaktion in der PFCG eingefügt hat, sieht es mit den Vorschlagswerte oft sehr schlecht aus. Dann geht das große Suchen los: welche Berechtigungsprüfungen kommen in der Eigenentwicklung hinter der Transaktion vor, welche Berechtigungsobjekte müssen eingefügt werden und mit welchen Werten muss man sie ausprägen damit die Transaktion in dieser Rolle funktioniert.
Entwickler können diese Informationen direkt bei Erstellung Ihrer Programme selbst oder über den zuständigen Administrator in die Vorschlagstabelle pflegen, und zwar über die Transaktion SU24. Damit dokumentieren sie sofort direkt im System ihre Berechtigungsprüfungen und runden ihre Arbeit somit auch aus Berechtigungssicht ab.
Und so geht’s:
In dem Beispiel wird für die Transaktion ZAUTHCHECKDEMO über die Transaktion SU24 zwei Vorschlagswerte gepflegt.
Ich stelle sehr oft bei Kunden fest, dass nicht immer der geeignetste SAP Benutzertyp insbesondere für RFC-Verbindungen verwendet wird.
Hier eine Tabelle mit den Benutzertypen und deren Eigenschaften:
| Eigenschaft | Dialog | Kommunikation | System | Service |
| GUI Anmeldung | Ja | Nein | Nein | Ja |
| RFC Anmeldung | Ja | Ja | Ja | Ja |
| Erzwingung der Kennwortänderung |
Ja | Ja | Nein | Nein |
| Kennwortablauf | Ja | Ja | Nein | Nein |
| Anmeldeticket kann erzeugt werden |
Ja | Ja | Nein | Nein |
Typische Probleme in diesem Umfeld:
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.
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.
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
