SAP Basis GoLive Support

Direkt zum Seiteninhalt
GoLive Support
Abbildung 2: Das Open-Innovation-Model
Beispielhafte Bezeichnungen sind: SAP-Cross-Application, SAP-Innovation & -Technology, SAP-Services & -Innovation, SAP-Operations & -Innovation oder SAP-Service-Provider & -Business-Innovator. BESCHREIBUNG DES EIGENEN LEISTUNGS- UND SERVICEPORTFOLIOS Um von vor- oder nachgelagerten Instanzen konsultiert werden zu können, ist es notwendig, eine ausführliche und verständliche Beschreibung des eigenen Leistungsportfolios zu erstellen. Somit kann explizit festgehalten werden, in welchen Fällen die SAP-Basis kontaktiert und involviert werden muss, um notwendige Entscheidungen zu treffen und einen Projekt- oder Unternehmenserfolg nicht zu gefährden. Es ist ebenso erforderlich, neben dem Aufgabenspektrum, das durch die SAP-Basis abgedeckt wird, festzuhalten, für welche Aufgaben und Themen die SAP-Basis nicht verantwortlich ist. Diese Empfehlung ist als allgemeingültig anzusehen und trifft auf alle IT-Fachbereiche zu, um diese gegeneinander klar abzugrenzen und das Leistungsvermögen der eigenen IT-Organisation zu dokumentieren. INTERNES MARKETING KONZIPIEREN UND ETABLIEREN Aufbauend auf der Empfehlung [A3] wird empfohlen, ein internes Marketing zu konzipieren und zu etablieren. Es geht darum, die Tätigkeiten, die in Bezug auf den Unternehmenserfolg wahrgenommen werden und nicht für jedermann ersichtlich sind, transparent darzustellen.

Diese Variante bietet sich an, wenn mehrere Transaktionen gleichzeitig auf ihre bestehende Zuordnung zu einem bestimmten Nutzer hin geprüft werden sollen. Bei dieser Variante müssen zunächst sämtliche Rollen ermittelt werden, die dem betreffenden Nutzer bereits zugeordnet wurden. Dies erfolgt in der Transaktion SE16N über Eingabe der Tabelle AGR_USERS. Außerdem lässt sich in diesem Bild die Begrenzung der maximalen Trefferzahl aufheben. Hier muss nun der betreffende Nutzer eingetragen werden. Außerdem sollte die Ausgabe lediglich auf die Rollen beschränkt werden. Nach dem Ausführen der Anfrage werden nun sämtliche Rollen, die dem vorher eingegebenen Nutzer zugeordnet sind, angezeigt. Diese werden nun komplett markiert und kopiert. Anschließend wird in der Transaktion SE16N wieder ein Schritt zurück gegangen und diesmal die Tabelle AGR_1251 gewählt. Hier werden nun sämtliche Rollen, die zuvor kopiert wurden, eingefügt. Zusätzlich wird nach dem Objekt S_TCODE und den Transaktionen, nach deren Zuordnung gesucht werden soll, gefiltert. Achtung: Bei der Eingabe der Transaktionscodes ist auf Groß- und Kleinschreibung zu achten! An dieser Stelle kann außerdem die Ausgabe auf die Rollen und Objektwerte (das sind in diesem Fall die Transaktionen) beschränkt werden. Nach dem Ausführen der Anfrage werden von den eingegebenen Transaktionen nun diejenigen angezeigt, die der Nutzer bereits ausführen kann. Zusätzlich ist ersichtlich, durch welche Rolle die Transaktion zugeordnet wurde. Abschließend ist festzustellen, dass sich die SUIM zur Ermittlung bestimmter Transaktionen mit Nutzerzuordnung nur bedingt eignet. Zwar lässt die Suche über das Berechtigungsobjekt S_TCODE auch die Betrachtung mehrerer Transaktionen zu. Da im Ergebnis allerdings die Zuordnung von betrachteten Transaktionen zu Rollen fehlt, lässt sich die Transaktion SUIM nur dafür sinnvoll nutzen, eine einzige Transaktion auf ihre bestehende Zuordnung zu einem bestimmten Nutzer hin zu überprüfen.
Checkpoints und Savepoints
Bei Rechnern, die eine Datenbank, eine Java-Instanz oder einen TREX beherbergen, sollten nur sehr geringe Paging-Raten zu beobachten sein, d. h., sie sollten so dimensioniert sein, dass der verfügbare Hauptspeicher den konfigurierten Speicherbereichen entspricht. Bei Rechnern, die ausschließlich ABAP-Instanzen tragen, können mäßige Paging-Raten von bis zu 20 % des physischen Hauptspeichers pro Stunde toleriert werden.

Bei einigen Datenbanksystemen kann man festlegen, wie viele der physisch auf dem Datenbankserver vorhandenen Prozessoren (genauer gesagt Threads) die Datenbankinstanz maximal beanspruchen darf. Dieser Parameter heißt z. B. MAXCPU für SAP MaxDB. Bei SAP HANA definiert der Parameter max_concurrency die Anzahl der maximal zu nutzenden Betriebssystem-Threads. Der richtigen Einstellung dieses Parameters kommt entscheidende Bedeutung zu.

Einige fehlende SAP Basis Funktionen im Standard werden durch die PC-Anwendung "Shortcut for SAP Systems" nachgeliefert.

Administratoren legen zum Beispiel Anforderungen und Standards fest, wählen und steuern Upgrades oder Erweiterungen, implementieren Monitoring-Prozessen, kümmern sich um erforderliche Backups sowie um das Notfallmanagement.

Anhand detaillierter Erfahrungswerte über den Hardwarebedarf der verschiedenen SAP-Anwendungen werden zunächst der Hardwarebedarf pro Anwendung (als Produkt aus Benutzeranzahl und anwendungsspezifischem Lastfaktor und eventuell einem konstanten Grundbedarf) und anschließend der Gesamthardwarebedarf als Summe aller Einzelbedarfe pro Anwendung berechnet.
SAP Corner
Zurück zum Seiteninhalt