Ü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:

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

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

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.

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.

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.

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.

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

SAP bietet für viele verschiedene Sprachen Unterstützung an. Möchte man z.B. eine neue Sprache in das System importieren kann dafür die Transaktion SMLT (Sprachenmanagement) genutzt werden.

Zum Finden des Downloadpakets muss zunächst der SAP Language code ermittelt werden, z.B. auf der Globalization-Unterseite: https://service.sap.com/languages

Auf der Seite werden alle unterstützten Sprachen aufgeführt. Wählt man eine an, so erhält man den “ISO Code (2-Letter, for System Logon) “, ein zwei-Buchstaben Kürzel. Bei Tschechisch z.B. ist dieser zum Beispiel “CS” und nicht etwa “CZ”.

Mit dieser Information kann man dann wie gewohnt in das Downloadcenter gehen (https://service.sap.com/swdc ) und unter “Installation and Upgrades” nach der eingesetzten Software suchen. Dort werden dann z.B. bei NetWeaver auch die Sprachen-CDs mit aufgeführt. Wenn der ISO Code nicht schon mit Strg+F auf der Seite zu finden ist, muss man ggf. dem “Info”-Link der Sprachen-CDs folgen. Dort steht auch, ob es sich um ein multi-archiv handelt. In dem Fall muss man alle Sprachen-CDs/Archive herunterladen, um sie gemeinsam zu entpacken.

Siehe auch Hinweis 330104.

Ich habe diese Woche an dem DSAG Thementag SAP Solution Manager in Würzburg teilgenommen. Am 31.01. und 01.02. gab es auf der Festung Marienberg einen wahren Präsentationsmarathon. Alles stand natürlich im Zeichen des kommenden SAP Solution Manager 7.1. Was nehme ich mit aus der zweitägigen Veranstaltung?

Der Ramp-Up für den Solution Manager 7.1 geht schon im April 2011 los – und ist schon voll belegt noch bevor man die Möglichkeit hatte, Bewerbungs-Formulare auszufüllen. Immerhin soll es schon Anfang August 2011 dann für alle verfügbar sein.

Die Implementierung von Enhancement Packages (EHPs) soll mit dem Solution Manager 7.1 einfacher werden. Mit dem Switch Framework soll man die Möglichkeit bekommen, besser EHPs einzuspielen, ohne gleich alle neuen Business Functions zu aktivieren. Möchte man es doch tun, werden Querbeziehungen aufgelöst und können über die Solman-Werkzeuge projektmäßig abgearbeitet werden. Allerdings wurde später auch darauf hingewiesen, dass man beim Einspielen von EHPs a) Änderungen hat, die man nicht zurücknehmen kann und b) die Systeme mit vielen Objekt-Änderungen belastet, die auch bei nicht Benutzung später ggf. dazu führen, dass man für diese ungenutzten Funktionen Wartungsaktivitäten durchführen muss. Eine Sandbox bleibt also Pflicht.

Zum Thema Organisation und Durchführung Funktionaler Tests mit dem Solution Manager wurde mit dem Workcenter Testmanagement und dem Test Automation Framework das Management von Tests für Business Prozesse gezeigt. Die gezeigten Testworkflows haben zudem den Charme, dass die auch für den Endanwender ohne großen Schulungsaufwand bedienbar bleiben. Die damit verbesserte Akzeptanz der bei Einspielen von EHPs oder Support Packages notwendigen Regressionstests erhöht damit die Testabdeckung und Qualität. Link: http://service.sap.com/testing

Der Vortrag “Change Control with Quality Gates” ging auf Verbesserungen im Change Management Workcenter ein. Beim Einsatz des Quality Gate Managements können Quality Gates in den Transportweg zwischen die verschiedenen Systeme einer Systemlinie gesetzt werden. Diese agieren ähnlich einer Sicherheitsschleuse und blockieren Importe solange sie nicht durch Freigaben z.B. nach 4-Augen-Prinzip geöffnet werden. Dies soll die Transparenz bei Changes verbessern und ein Transport Tracking z.B. mit Excel vermeiden, ist aber vermutlich eher für größere Transportvolumen interessant. Immerhin gab es hier eine der wenigen Live-Demos. Schwächen gibt es hier noch in der Abwicklung von Urgent Changes, da dafür die Gates “mal eben kurz” geöffnet und geschlossen werden müssen.

Während sich das Business Process Monitoring (BPM) eher auf kontinuierlich vom Solution Manager gesammelte Daten aus Technik und Applikation stützt, geht die SAP mit Business Process Analysis (BPA) hin und prüft z.B. über alle Organisationseinheiten hinweg, warum sich ein Backlog aufgebaut hat. Vergleichbar soll das dann sein mit einem Early Watch Alert. Enterprise Support natürlich vorausgesetzt… Link: http://service.sap.com/bpm

Die Unterstützung beim Einspielen von Support Packages und EHPs soll sich verbessern. Neben MOPZ und Notes Assistent sollen die System Recommendations helfen, wirklich notwendige Hinweise zu identifizieren, gegliedert nach Sicherheit, Performance, etc. Der Upgrade Dependency Analyzer soll ab SolMan 7.1 auch integriert sein. Damit können hoffentlich gleich aus vorhandenen Systeminformationen Abhängigkeiten aufgelöst werden, damit ein Upgrade auf einem System nicht einen übergreifenden Prozess aus den Angeln hebt. Link: http://service.sap.com/uda

Insgesamt bin ich sehr gespannt auf den neuen Solution Manager 7.1. Mal schauen, wie viele neue bzw. ergänzte Funktionen es dann wirklich in das erste Release schaffen…