Was bedeutet SAP Managed Service?
Transportmanagement
Präsentationsschicht: Mit der Präsentationsschicht wird die Schnittstelle zu den Anwendern gebildet. Mit Hilfe von SAP GUI werden die Daten hier grafisch aufbereitet und dem Anwender am Bildschirm zur Verfügung gestellt. Des Weiteren werden die Daten, die hier neu erhoben wurden, an die Anwendungsprogramme der Applikationsschicht weitergegeben.
In komplexeren Systemumgebungen können am Tag tausende, wenn nicht gar mehrere zehntausende SAP Jobs laufen. Durch deren Abhängigkeiten entsteht hohe Komplexität. Will man als Administrator oder als Admin-Team die Übersicht behalten, ist man auf ein aussagekräftiges Monitoring angewiesen. Es muss jederzeit klar sein, welche Jobs gelaufen und welche nicht gelaufen sind, um den ordnungsgemäßen SAP Betrieb sicherzustellen. Im Idealfall wird man bei kritischen Fehlern per E-Mail oder SMS informiert. Der Trend der Internationalisierung, des Outsourcings und des Mischbetriebs mit On-Premise und On-Demand Systemen führen dazu, dass SAP Landschaften oftmals weit verteilt sind. Dadurch wird das Monitoring schwieriger und gleichzeitig muss die Übersichtlichkeit gewahrt werden. Eine Integration des SAP Jobmanagements und der Job Beantragungen in ein zentrales System, wie beispielsweise den SAP Solution Manager ist daher sinnvoll und nützlich, um IT Service Prozesse sinnvoll zu ergänzen und die Prozessabläufe zu beschleunigen.
Migration von einem Betriebssystemwechsel, homogener/heterogener Datenbank
Mit Hilfe von Profilparametern können wir im SAP System alles konfigurieren. Dabei sind einige Parameter dynamisch änderbar, das heißt, dass sie geändert werden können ohne das System neu zu starten. Diese Änderungen sind dann aber nicht permanent, das heißt, nach einem Systemneustart, werden wieder die vorher eingestellten Profilparameter verwendet. Andere Parameter hingegen sind statisch, also nur mit einem Neustart und nur permanent änderbar. Die meisten Profilparameter für die Speicherallokation sind eigentlich statisch. Es gibt jedoch die Möglichkeit diese mit dem Report RSMEMORY dynamisch anzupassen. Lesen Sie hier wie Sie herausfinden, ob ein Parameter statisch oder dynamisch ist und wie sie den Report RSMEMORY verwenden um die Speicherallokationsparameter dynamisch anzupassen. RZ11 - Pflege der Profilparameter Die Transaktion RZ10 gibt uns Informationen über Profile, die wiederum verschiedene Profilparameter enthalten. In der Transaktion RZ11 ist es hingegen möglich sich Informationen zu einzelnen Parametern anzuschauen, vorausgesetzt man kennt ihren Namen. Wie Sie in unserem Beitrag zu Speicherparametern lesen können, sind für die Speicherverwaltung besonders die folgenden 5 Parameter wichtig: abap/heap_area_total abap/heap_area_dia abap/heap_area_nondia ztta/roll_extension_dia ztta/roll_extension_nondia Wenn Sie mal nicht genau wissen, wie ein Parameter heißen könnte, lohnt es sich an dieser Stelle auch die F4-Hilfe zu verwenden. Für den Parameter abab/heap_area_dia gibt die RZ11 beispielsweise folgendes aus: Beschreibung des Parameters abap/heap_area_dia in der RZ11 Wie Sie hier sehen können, handelt es sich nicht um einen dynamischen Parameter. Nun ist es doch ziemlich leidlich, wenn getestet werden soll, ob genug Speicher zur Verfügung steht immer wieder das System neu zu starten. Zu diesem Zweck gibt es den Report RSMEMORY. RSMEMORY - Testen Sie ihre Speicherallokationsstrategie Anzeige des Reports RSMEMORY Hier ist weder eine Dokumentation, noch eine Wertehilfe Verfügbar, aber die SAP Dokumentation verrät, wie der Report zu benutzen ist. Hier wird zunächst zwischen Dialog und Nicht-Dialog- Workprozessen unterschieden. Das heißt im ersten Bereich können Sie den Extended Memory (Speicherklasse 1) und den Heap Memory (Speicherklasse 2) für Dialog Workprozesse festlegen und in der zweiten selbiges für Nicht-Dialog-Workprozesse.
Die Hardwarepartner erstellen nun Angebote zu dem Sizing-Projekt, unter denen Sie auswählen müssen. Für die Anforderungen unseres Beispielprojekts wäre es möglich, diese mit einem einzigen Rechner abzudecken. Alternativ kann der Hardwarebedarf auch auf mehrere Rechner verteilt werden. Für unser Projekt nehmen wir an, dass wir uns für ein Angebot entscheiden, das drei Rechner umfasst, die jeweils – nach Herstellerangabe – 12.000 SAPS leisten und mit 32 GB Hauptspeicher ausgestattet sind. Insgesamt leistet die Lösung also 36.000 SAPS und verfügt über 96 GB Hauptspeicher. Auf einem der Rechner sollen die Datenbank und eine SAP-Zentralinstanz installiert werden, auf den beiden anderen Rechnern sollen SAP-Instanzen den Großteil der Dialog-, Hintergrund- und Verbuchungslast aufnehmen. Mit dieser verteilten Installation gehen wir davon aus, dass wir auch beim Ausfall eines Rechners einen eingeschränkten Betrieb aufrechterhalten können und das Risiko eines Totalausfalls reduzieren. Für weitergehende Überlegungen zum Thema Lastverteilung verweisen wir Sie auf den letzten Teil dieses Kapitels und auf Kapitel 7, »Lastverteilung, Remote Function Calls und SAP GUI«.
Einige fehlende SAP Basis Funktionen im Standard werden durch die PC-Anwendung "Shortcut for SAP Systems" nachgeliefert.
Sie gelangen auf ein Dialogfenster, in dem Ihnen die aktuelle Queue angezeigt wird.
Tragen Sie dazu in der Kategorie Service 100 Benutzer der Kategorie Medium sowie 50 Benutzer der Kategorie High ein.