SAP-Basis Beratung
SWDM Business Workflow Explorer
Hierbei lässt sich nur ein Transaktionscode sinnvoll eintragen, da ansonsten stets eine einzige Rolle gesucht werden würde, die alle gesuchten Transaktionen beinhaltet und dem entsprechenden Nutzer zugeordnet ist. Da die Transaktionen dem Nutzer jedoch auch über verschiedene Rollen zugeordnet sein können, wäre dies nicht zielführend. Bei Nutzung der o.g. Eingabevariante werden zudem lediglich Transaktionen betrachtet, die im Menü der Rolle gepflegt worden sind. Ist nicht sicher, ob die Transaktion im Menü oder im Berechtigungsobjekt S_TCODE der Rolle eingetragen wurde, können auch bis zu vier Transaktionen mittels der Suche über das genannte Berechtigungsobjekt S_TCODE überprüft werden. Wichtig ist hierbei die Beachtung und entsprechende Nutzung der UND-/ODER-Beziehung. Nach dem Ausführen der Anfrage werden nun die Rollen angezeigt, welche die angefragte Transaktion beinhalten und dem Nutzer zugeordnet sind. Bei Nutzung der Suche über das Berechtigungsobjekts S_TCODE wird folgende Ergebnisseite angezeigt. Bei Betrachtung des Ergebnisses wird neben der Beschränkung der Anzahl an Transaktionen, die eingegeben werden können, ein weiterer Nachteil dieser Variante deutlich: Zwar werden beide zugeordnete Rollen angezeigt, auf den ersten Blick ist allerdings nicht zu erkennen, welche Transaktion in welcher Rolle enthalten ist. Hierfür müssten die Rollen nochmals einzeln betrachtet werden. Sollen gleichzeitig mehr Transaktionen mit Nutzerzuordnung ermittelt und direkt die Rollenzuordnung ersichtlich werden, bietet sich die Nutzung der Transaktion SE16N an.
Je höher der Grad der Standardisierung von Betriebs- und Wartungsaufgaben ist, desto effektiver können der technische Betrieb und die Wartung erfolgen. Gleichzeitig vereinfacht dies das Outsourcing und ggf auch die Nutzung einer Cloud-Lösung. AUSWAHL EINER GEEIGNETEN SERVICE-FORM Unabhängig von der gewählten Service-Form, wie auch beim Outsourcing und Outtasking, bleibt jedoch die Gesamtverantwortung für die Verfügbarkeit und Performance der IT-gestützten Anwendungen bei der eigenen Firma. Dies bedeutet nach wie vor internen Koordinationsaufwand bzgl. Wartungsfenstern oder Release-Ständen, der bestehen bleibt. Ebenso müssen die Dienstleistungen, die durch den externen Partner erbracht werden, regelmäßig überwacht und deren Qualität geprüft werden. Daher muss die gewählte IT-Strategie unter diesem Aspekt möglichst risikoarm gewählt werden. Wird der technische Betrieb bei der Entscheidung nicht genügend gewürdigt, besteht ein erhebliches Geschäftsrisiko.
I/O-Engpass
Vor der geplanten Laststeigerung sollten Sie einen Service von SAP in Anspruch nehmen, der die aktuelle Hardwareauslastung ermittelt und die Folgen der geplanten Laststeigerung bewertet. SAP empfiehlt, bei geplanten Laststeigerungen von bis zu 30 % den SAP-EarlyWatch-Service und bei größeren Laststeigerungen den SAP GoingLive Check in Anspruch zu nehmen. Bei einem Wechsel des SAP-Releases bzw. der Datenbankplattform oder der Hardwareplattform bietet SAP ebenfalls spezielle SAP GoingLive Checks an. Während dieser Services wird die aktuelle Auslastung der Hardware gemessen und bewertet. Aufgrund der Angaben über den geplanten Projektschritt wird der zusätzliche Hardwarebedarf ermittelt. Bereits geplante Änderungen der Hardwarelandschaft werden in die Auswertung mit einbezogen. Der kostenfreie automatische Service SAP EarlyWatch Alert ermittelt ebenfalls die aktuelle Hardwareauslastung und stellt diese in einem übersichtlichen Bericht zusammen. Sofern bereits eine Produktivnutzung besteht, werden also immer die aktuellen Auslastungsdaten für das Sizing-Projekt herangezogen. Eine falsche Entscheidung wäre es, ein initiales Sizing für die neue Gesamtlast durchzuführen und die aktuellen Auslastungsdaten zu ignorieren.
Um eine optimale Performance zu erreichen, sollte das Kopieren der Daten beim Kontextwechsel auf ein Minimum beschränkt bleiben, mit anderen Worten, es soll möglichst wenig SAP Roll Memory benutzt werden. Daher wird für alle Betriebssysteme empfohlen, ztta/roll_first = 1 zu setzen. Was passiert nun, wenn der SAP Extended Memory voll belegt ist? In diesem Fall sind zwei Szenarien möglich, die beide nicht performanceoptimal sind: Da der SAP Extended Memory voll belegt ist, werden Benutzerkontexte bis zu einer Größe von ztta/roll_area im lokalen Roll-Bereich abgelegt. Bei jedem Kontextwechsel müssen damit unter Umständen mehrmals Daten in der Größe von mehreren Megabyte kopiert (gerollt) werden; dies führt typischerweise zu Wartesituationen in der Roll-Verwaltung, insbesondere wenn der Roll-Puffer voll ist und Daten in die Roll-Datei geschrieben werden müssen. Erfahrungen zeigen, dass bei großen Applikationsservern mit mehr als 100 Benutzern die Performance in diesen Fällen schlagartig und drastisch einbricht. Um in dieser Situation Abhilfe zu schaffen, kann man den lokalen RollBereich (ztta/roll_area) reduzieren. Wenn der SAP Extended Memory voll belegt ist, wird nur noch wenig Roll Memory verwendet, und die Menge der beim Kontextwechsel zu kopierenden Daten reduziert sich. Stattdessen werden die Kontextdaten im SAP Heap Memory abgelegt – dies hat zur Folge, dass die Workprozesse gar nicht mehr rollen, sondern in den PRIV-Modus gehen, d. h. einem Benutzer zwischen den Transaktionsschritten exklusiv zugeordnet bleiben. Befinden sich zu viele Workprozesse gleichzeitig im PRIV-Modus, stehen dem Dispatcher nicht genügend freie Workprozesse zur Verfügung. Es kann daher zu hohen Dispatcher-Wartezeiten und damit ebenfalls zum Einbruch der Performance kommen.
Für Administratoren steht im Bereich der SAP Basis ein nützliches Produkt - "Shortcut for SAP Systems" - zur Verfügung.
Bei uns zum Beispiel kommt Ansible für den Massen-Rollout von Agenten in großen Umgebungen zum Einsatz.
In der Folge kann eine Standardisierungsstrategie ausgearbeitet, festgelegt und umgesetzt werden.