Planung der SAP-Milieus
Prepare-Operation
Automatisierung der Prozesse In einem IDM werden IT-Geschäftsprozesse, das Anlegen, Ändern sowie das Löschen eines Benutzers anhand eines eindeutigen Regelwerks zentral definiert. Anschließend laufen alle notwendigen Schritte mittels automatisierter Workflows ab. Die Benutzerverwaltung muss nicht mehr für jedes einzelne System separat administriert werden, sondern nur noch an einer zentralen Stelle (Single Point of Administration). Datenkonsistenz Mitarbeiterdaten werden in einer IDM-Architektur nur einmal in einem führenden System angelegt. Alle angeschlossenen Systeme nutzen diese Daten in ihrer Benutzerverwaltung bedarfsorientiert. Bei einem Abteilungswechsel oder einer neuen Tätigkeit werden Berechtigungen automatisiert angepasst. Sicherheit und Dokumentation In einer zentralen Benutzerverwaltung lassen sich Anwender effizient auf allen Systemen sperren oder die Zugriffsrechte ändern. Durch die Anbindung an den Personalprozess wird der Änderungsprozess automatisch angestoßen sobald in der Personalabteilung der Stammdatensatz angepasst wird. Außerdem können durch Dokumentationslösungen alle Vorgänge lückenlos archiviert werden. Dadurch entsteht eine Transparenz die auch den Nachweis eines funktionierenden und sicheren Berechtigungskonzepts bei Revisionsprüfungen erleichtert. Anforderungen an IDM-Systeme Personen erhalten elektronische Identität Attribute beschreiben die Rolle der person Qualitätsanforderungen Verlässlichkeit: Missbrauchsverhinderung Nachvollziehbarkeit: Dokumentation und Logging Ausfallsicherheit: Back-up-Systeme Einklang mit rechtlichen Vorgaben Datenschutzgesetz Worauf sollte man bei Antragsprozessen achten? Bei der Implementierung und auch im laufenden Betrieb eines IDM gibt es bestimmte Dinge die man bei Antragsprozessen zwingend beachten sollte. Die wichtigsten Punkte habe ich Ihnen in Form einer Checkliste zusammengefasst.
In der Dispatcher-Queue muss der Auftrag bis zum Freiwerden des benötigten Workprozesses warten. Sobald ein Workprozess für ihn zur Verfügung steht, wird er diesem zur Bearbeitung übergeben. Die Verweildauer in der Dispatcher-Queue wird als Wartezeit (Ø Wartezeit) bezeichnet. Beachten Sie bitte, dass es noch zahlreiche andere Wartezeiten bei der Verarbeitung gibt (z. B. Warten auf RFC, Warten auf Sperren, Warten auf CPU, Wartesituationen auf der Datenbank). Um die hier besprochene Wartezeit von anderen abzugrenzen, sollte diese also präziser als Dispatcher-Wartezeit bezeichnet werden.
Konfiguration
Der Erweiterte Speicher enthält also vor allem Nutzerkontexte von verschiedenen Workprozessen, falls diese nicht vollständig in den Rollbereich geladen werden können. Da der Speicherbereich für alle Workprozesse erreichbar ist, können die Workprozesse also auch auf fremde Nutzerkontexte, die hier liegen zugreifen. Außerdem enthält der Erweiterte Speicher einen Globalen Bereich in dem Daten unabhängig von Nutzerkontexten abgelegt werden können. Die Größe des erweiterten Speichers wird bestimmt durch die Werte von em/initial_size_MB und em/global_area_MB. Hierbei bestimmt der erste Parameter die Größe des Speicherbereichs in dem Nutzerkontexte abgelegt werden können und der zweite die Größe des globalen Bereichs. Parameter für den Privaten Speicher Zu guter Letzt gibt es noch den privaten Speicher, welcher nur dann genutzt wird, wenn der Nutzerkontext eines Workprozesses alle anderen ihm zur Verfügung stehenden Speicherbereiche aufgebraucht hat, also seinen Anteil des erweiterten Speichers und seinen Rollbereich. In diesem Fall geht der Workprozess in den PRIV modus. Ein Workprozess im privaten Modus ist an seinen aktuellen Nutzerkontext gebunden und wird erst dann wieder frei für andere Aufgaben, wenn die aktuelle Anfrage abgeschlossen ist. Falls er dabei den ihm zugewiesenen privaten Speicher vollständig aufgebraucht hat, wird der Workprozess anschließend neu gestartet und der Speicher wieder freigegeben. Dieses verhalten wird mit dem Parameter abap/heaplimit kontrolliert. Zeitweise kann der Nutzerkontext der Wert von abap/heaplimit dabei auch überschreiten. Die Parameter abap/heap_area_total, abap/heap_area_dia und abap/heap_area_nondia bestimmen eine obere Grenze für den privaten Speicher. Der Parameter abap/heap_area_total definiert wie viel privaten Speicher alle Workprozesse insgesamt nutzen können. Die Parameter abap/heap_area_dia und abap/heap_area_nondia hingegen bestimmen, wie viel privaten Speicher ein einzelner (Nicht-)Dialog-Workprozess nutzen darf.
Trifft keiner der oben genannten Punkte zu, prüfen Sie, ob andere Performanceprobleme der Datenbank auftreten, die dazu führen, dass SQL-Anweisungen zu langsam abgearbeitet werden, was ein verhältnismäßig langes Halten von Datenbanksperren zur Folge hat. Lösen Sie in diesem Fall erst das andere Performanceproblem, und untersuchen Sie anschließend, ob sich die Datenbanksperren dann schneller auflösen.
"Shortcut for SAP Systems" ist eine PC-Anwendung, mit der viele Tätigkeiten in der SAP Basis vereinfacht bzw. auch überhaupt erst ermöglicht werden.
Sowohl der ABAP- als auch der Java-Stack können von einer Plattform aus überwacht werden.
Der Memory Inspector ist insbesondere dann hilfreich, wenn Benutzer Transaktionen lange verwenden, wie dies z. B. in einem Customer Interaction Center der Fall ist.