Applikationsschicht
Filter auf Operationen
Da Innovationen durch IoT (Internet of Things) oder Big-Data-Szenarien nicht nur die SAP-Basis betreffen, sondern sich daraus unter anderem auch Produkte und Services für Kunden des eigenen Unternehmens hervortun, muss die Rolle der SAP-Basis in Bezug auf diese Szenarien und Services klar definiert werden. In der Regel sieht die SAP-Basis hier ihre Verantwortung in der Konnektivität zum Unternehmensnetzwerk bzw. der Unternehmenssysteme, die im Verantwortungsbereich der SAP-Basis liegen. Die Betreuung der Anwendungen, basieren auf den Technologien sowie den damit einhergehenden Services, liegen im Verantwortungsbereich der jeweiligen Abteilung, die diesen Service anbietet. Eine Betreuungsleistung der SAP-Basis muss bei der Konzeption abgesprochen und geregelt werden.
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.
Applikationssicht
Das SAP Identity Management System (IdM) ermöglicht eine zentrale Benutzer- und Berechtigungsverwaltung in einer heterogenen Systemlandschaft. Durch die Verwendung eines IdMSystems können manuelle Prozesse durch automatisierte Workflows ersetzt werden, die zentral abgebildet und administriert werden. Beispielhafte Szenarien: 1) Benutzer- und Berechtigungsverwaltung 2) ESS/MSS zur Verwaltung von Personaldaten 3) Audit und Monitoring zur Überprüfbarkeit auf die Einhaltung gesetzlicher Vorschriften Was ist jedoch zu beachten, wenn sie ein Identity Management System einführen möchten? In diesem Beitrag möchte ich auf grundlegende Punkte eingehen, die vor der Einführung geklärt sein müssen.
Benutzerkontextdaten werden von Dialog-Workprozessen in folgender Reihenfolge abgelegt: Beim Start einer Transaktion wird der Benutzerkontext bis zu einer Größe von ztta/roll_first im lokalen Roll-Bereich des Workprozesses gespeichert. ztta/roll_first soll auf 1 (Byte) gesetzt werden. Dies bedeutet, dass zunächst überhaupt kein SAP Roll Memory belegt werden soll. Aus technischen Gründen werden allerdings immer administrative Daten in der Größenordnung von bis zu 100 kB im lokalen Roll-Bereich des Workprozesses abgelegt, auch wenn ztta/roll_first = 1 ist. Wächst die Größe des Benutzerkontextes über den Wert ztta/roll_first hinaus, werden die Daten im SAP Extended Memory abgelegt. Ist der SAP Extended Memory erschöpft oder erreicht der Benutzerkontext die Quote von ztta/roll_extension*, wird der verbleibende Rest des lokalen Roll-Bereichs bis zu einer Größe von ztta/roll_area genutzt. Wächst der Kontext weiter an und übersteigt der Speicherbedarf auch diesen Wert, allokiert der Workprozess SAP Heap Memory nach Bedarf. Die Verwendung von SAP Heap Memory hat den Nachteil, dass dieser Speicher lokal ist und auch nicht mehr – wie beim SAP Roll Memory – in einen globalen Speicherbereich kopiert (gerollt) werden kann. Wenn ein Prozess SAP Heap Memory allokiert, kann der Kontext nicht mehr zu einem anderen Workprozess übertragen werden. Der Workprozess bleibt einem Benutzer exklusiv zugeordnet. Diesen Zustand bezeichnet man als PRIV-Modus (Private Mode). In der Workprozess-Übersicht wird dieser Zustand in den Spalten Status und Grund durch die Werte hält bzw. PRIV dokumentiert.
Verwenden Sie "Shortcut for SAP Systems", um viele Aufgaben in der SAP Basis einfacher und schneller zu erledigen.
Diese Quote verhindert, dass ein einzelner Benutzer mit einer sehr speicherintensiven Transaktion den gesamten SAP Extended Memory belegt und keinen Speicher für die anderen Benutzer übrig lässt.
Daher müssen regelmäßig Statistiken über die Größen von Tabellen und Indizes erstellt werden, die der Optimierer benötigt, um die richtigen Zugriffspläne für SQL-Anweisungen zu erstellen.