Umsetzung der Konfiguration im System
Komponentenübergreifendes vs. lokales Tracing
Falls Sie die Hintergründe überspringen wollen und eine direkte Schritt-für-Schritt-Anleitung bevorzugen, können Sie direkt in den letzten Abschnitt springen. Vorbereitung Für diesen Workaround benötigen Sie vor allem Zugänge auf sowohl das Quellsystem als auch das BW-System. Zusätzlich müssen sie berechtigungstechnisch die Möglichkeit haben, die SE37 aufzurufen und dort Funktionsbausteine auszuführen. Gerade in Produktivsystemen ist dies allerdings eine sehr kritische Berechtigung. Gehen Sie also davon aus, dass sie eventuell einen Firefighter-Nutzer für diese Aktion benötigen. Arbeiten im BW-System Nun, da die Vorbereitungen abgeschlossen sind müssen Sie jeweils auf dem BW-System und auf dem Quellsystem einen FuBa aufrufen, welcher auf der jeweiligen Seite die Verbindung löst. Beginnend auf dem BW-System begeben Sie sich nun in die Transaktion SE37 und rufen den Funktionsbaustein "RSAR_LOGICAL_SYSTEM_DELETE" auf: RSAR_LOGICAL_SYSTEM_DELETE Hier geben Sie nun die benötigten Werte ein. Folgende Tabelle hilft ihnen bei der Ausfüllung: Feld Beschreibung I_LOGSYS Der Logische Name des Quellsystems. Hier wird der Name des Quellsystems eingetragen werden, wie er in der RSA1 zu finden ist. Zusätzlich kann dieser Name auch in der DB-Tabelle TBDLT gesucht werden. I_FORCE_DELETE Boolean, X = Löschen trotz Fehlermeldungen I_NO_TRANSPORT Boolean, X = Diese Änderung soll nicht in nachfolgende Systeme transportiert werden I_NO_AUTHORITY Boolean, X = Ignorieren von Berechtigungsprüfungen Arbeiten im Quellsystem In dem Quellsystem begeben Sie sich nun auch in die Transaktion SE37 und rufen hier den Funktionsbaustein "RSAP_BIW_DISCONNECT" auf: Folgendes sind die Beschreibungen zu den jeweiligen Feldern. Diese können in der Quellsystem- Verbindungstabelle RSBASIDOC entnommen werden Feld Beschreibung I_BIW_LOGSYS Der logische Name des BW-Systems. In der Tabelle RSBASIDOC ist der richtige Wert in der Spalte "RLOGSYS" zu finden. I_OLTP_LOGSYS Der logische Name des Quellsystems. Die Spalte "SLOGSYS" in der Tabelle RSBASIDOC. I_FORCE_DELETE Der logische Name des BW-Systems. In der Tabelle RSBASIDOC ist der richtige Wert in der Spalte "RLOGSYS" zu finden. Abschluss Im Endeffekt müssen Sie also jeweils im BW- und Quellsystem den jeweiligen Funktionsbaustein aufrufen, die Parameter ausfüllen und den Funktionsbaustein ausführen.
Das Mandantenkonzept von SAP ermöglicht es, ein SAP-System in mehrere logische Subsysteme - Mandanten - zu unterteilen. Diese Subsysteme können wie eigene Systeme betriebswirtschaftlich voneinander unabhängig und isoliert genutzt werden. Aber wie sind mandantenunabhängige Transaktionen zu behandeln? Wie können Sie verhindern, dass ein Mandant auf den anderen zugreifen kann und warum sollten Sie das verhindern wollen? In diesem Blog-Beitrag werde ich Ihnen diese Fragen beantworten und dabei einige Negativ-Beispiele diskutieren. Warum ist es wichtig mandantenunabhängige Transaktionen gesondert zu betrachten? Stellen Sie sich vor, dass jeder Ihrer Mitarbeiter einen Mandanten im Produktivsystem anlegen oder ändern darf, oder noch schlimmer - beides. Das Anlegen und Ändern eines Mandanten im Produktivsystem erfolgt autorisiert und dokumentiert – Sie fragen sich, was dabei schon schiefgehen könnte? Das Risiko in diesem Fall ist ein Verlust der Integrität von System und Daten, der Verlust der Vertraulichkeit: Mit jedem neu angelegten Mandanten lebt der Superuser SAP* mit seinen umfassenden, auch mandantenübergreifenden Rechten und dem vergebenen Standardpasswort auf.
Ursache von Hardwareengpässen
Der Bedarf an SAP Extended Memory (em/initial_size_MB) hängt von der Anzahl und den Aktivitäten der Benutzer ab und lässt sich vor Produktivstart nur schwer abschätzen. Bei der initialen Einstellung dieses SAP-Profilparameters in einem nicht produktiven System gehen Sie pragmatisch von der Größe des physischen Hauptspeichers aus. Konfigurieren Sie etwa 70 bis 100 % des physischen Hauptspeichers, der für die SAP-Instanz zur Verfügung steht, als SAP Extended Memory.
SAP stellt Benchmarks für über 20 Anwendungsszenarien zur Verfügung. Der populärste SAP-Benchmark ist der SD-Benchmark, SD steht für Sales and Distribution. Der SD-Benchmark umfasst das Anlegen und Anzeigen von Vertriebsbelegen, das Erstellen und Ändern der Lieferung, das Buchen des Warenausgangs und das Erstellen der Rechnung für die erzeugten Vertriebsbelege. Weitere Benchmarks werden für die Module von SAP ERP (Finanzwesen – FI, Materialwirtschaft – MM etc.), für CRM-Komponenten, für APO-Komponenten, für das SAP Enterprise Portal und für das SAP Business Warehouse sowie für einige Industrielösungen, bei denen es auf hohen Durchsatz ankommt, z. B. Einzelhandel (Retail), Bankwesen und Versorgungsdienstleistungen (Utilities), angeboten. Alle Details zum Ablauf eines Benchmarks können Sie auf den öffentlichen Internetseiten von SAP einsehen (www.sap.com/benchmark).
Mit "Shortcut for SAP Systems" werden Aufgaben im Bereich der SAP Basis vereinfacht und fehlende Funktionen des Standards ergänzt.
Ändert sich das Aufgabenspektrum eines Mitarbeiters müsste der Systemadministrator bei der Änderung und Löschung von Zugängen alle aktiven Benutzerkonten berücksichtigen.
Lässt sich das Problem mit diesen Methoden nicht finden, stehen Ihnen noch der ABAP-Trace und der ABAP Debugger als weitere Analysemethoden zur Verfügung.