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.
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.
Es kommt gelegentlich vor, dass man sich durch mehrere SAP Tabellen kämpfen muss, damit man die Daten bekommt, die man sucht. Ich mache mir dann immer gerne ein Bild von der Tabelle und möchte wissen: mit welchen Tabellen hängt diese Tabelle zusammen?
Die SAP bietet in der SE11 (Data Dictionary) ein mächtiges, aber leicht zu übersehendes Werkzeug an: Die Anzeige eines Netzplans für die Fremdschlüsselbeziehungen der aktuell ausgewählten Tabelle. Dafür wählt man in der SE11 die Option “Grafik” an oder nutzt die Tastenkombination Strg+Shift+F11:
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.
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.
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.
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.
Für die Anbindung von produktiven Webservices ist eine verschlüsselte Verbindung aus naheliegenden Gründen natürlich bevorzugt. Allerdings muss man für eine SSL-Verbindung einige Vorarbeiten leisten, die man auf Client-Seite (z.B. mit einem Internet Explorer) in der Regel nicht hat.
Z.B. möchte ein SAP-System im Trust-Manager genau die Stammzertifikate mitgeteilt bekommen, denen es Vertrauen darf. Hat man das nicht getan, tauchen in den Programmen Fehler wie “ICM_HTTP_INTERNAL_ERROR” und im ICM-Log (Transaktion smicm->Springen->Trace Datei) folgende Fehlermeldungen auf:
Dieser Fehler wird auch in SAP Hinweis 1094342 beschrieben.
Für den Import der Stammzertifikate benötigt man diese in Dateiform. Dies geht relativ einfach mit dem Internet Explorer. Wichtig: Den IE als Administrator ausführen, ansonsten ist ein Zertifikatsexport in eine Datei nicht möglich.
Auf der Zielseite einen Doppelklick auf das Zertifikatssymbol.
Der Zertifikatspfad zeigt die notwendigen Stammzertifikate, die importiert werden müssen.
Für jeden Eintrag der Zertifikatskette muss man einmal “In Datei kopieren” auswählen.
Dort vorzugsweise ein binär-codiertes Zertifikat verwenden. Das Base-64-Format, dass im Hinweis erwähnt wird, hat nicht funktioniert.
Der Importvorgang im SAP muss dann über die Transaktion STRUST in einer Client-PSE erfolgen. Je nach dem wie man den Aufruf macht, müssen die Zertifikate in andere PSEs importiert werden. Die genutzte PSE kann man z.B. in dem ICM-Log sehen. Die verwendete SAPSSLC.pse entspricht hier der “SSL-Client (Standard)” im Trust-Manager.
Um das Zertifikat der Zertifikatsliste hinzuzufügen, auf “Zertifikat importieren” gehen.
Die Datei auswählen und “Binär” auswählen.
Danach das angezeigte Zertifikat in die Liste aufnehmen und sichern. Danach den ICM-Server durchstarten (smicm).
Nun sollte der Zugriff funktionieren. Wichtig ist, dass die Domain in der URL mit dem Common Name in dem Zertifikat übereinstimmt. Ansonsten gibt einen Fehler vergleichbar mit der IE-Zertifikatswarnung “Der Hostname stimmt nicht überein”, und die Verbindung schlägt fehl.
Im ICM-Log würde das so aussehen:
Tipp: In der SM59 eine “HTTP-Verbindung zu ext. Server” anlegen, damit kann man in der Regel schneller testen, als jedes Mal den Webservice zu debuggen.
