Archivierung
SMQ2 qRFC-Monitor (Eingangsqueue)
Auf jedem Applikationsserver existieren Ressourcen, die nur einmalig zur Verfügung stehen. Diese Ressourcen können nur von einem Workprozess und nicht von mehreren zugleich verwendet werden. Wenn ein Prozess diese Ressource verwenden möchte, setzt er ein Semaphor. Wenn andere Prozesse diese ebenfalls benötigen, müssen sie so lange warten, bis der das Semaphor haltende Prozess seine Aktion beendet hat. So muss z. B. immer, wenn ein Eintrag in einem SAP-Puffer geändert werden soll, ein Semaphor gesetzt werden, da nur ein einziger Prozess eine Änderung im Puffer vornehmen kann. Warten mehrere Prozesse auf ein Semaphor, bezeichnet man dies als Serialisierung. Eine weitere Operation, bei der ein Semaphor gesetzt wird, ist das Roll-in bzw. Roll-out. Dies bedeutet, dass immer nur ein Prozess nach dem anderen ein Roll-in bzw. Roll-out durchführen kann. Eine vollständige Liste der SAP-Semaphore erhalten Sie mit der Werthilfe (F1) zum Feld Gesperrte Semaphore.
Eine SAP-Transaktion erstreckt sich in der Regel über mehrere Transaktionsschritte (Bildwechsel). Während dieser Schritte werden Daten wie Variablen, interne Tabellen und Bildschirmlisten aufgebaut und im Hauptspeicher des Applikationsservers gehalten. Diese Daten bezeichnet man als Benutzerkontext. In der Regel werden die Schritte einer Transaktion von unterschiedlichen Dialog-Workprozessen ausgeführt, d. h., der erste Transaktionsschritt wird vielleicht vom Workprozess Nr. 3 ausgeführt, der zweite Schritt vom Workprozess Nr. 4 etc. Zu Beginn eines Transaktionsschrittes muss daher der Benutzerkontext dem entsprechenden Workprozess zugänglich gemacht werden. Dieser Vorgang heißt Roll-in. Die technischen Vorgänge beim Roll-in (z. B. das Kopieren von Daten in den lokalen Speicher des Workprozesses) werden in Kapitel 6, »Speicherkonfiguration«, im Detail dargestellt. Analog zum Roll-in zu Beginn eines Transaktionsschrittes wird zum Ende eines Transaktionsschrittes ein Roll-out, also die Sicherung der aktuellen Benutzerdaten, durchgeführt. Die Länge des Roll-ins wird als Roll-in-Zeit, die Länge des Roll-outs als Roll-out-Zeit bezeichnet. Bitte beachten Sie, dass der Roll-out nicht zur Antwortzeit eines Transaktionsschrittes beiträgt. Beim Roll-out, d. h. beim Kopieren des Benutzerkontextes aus dem lokalen Speicher des Workprozesses in den Roll-Speicher, sind die Daten des Benutzers bereits vorher an den Präsentationsserver übertragen worden.
SAP Netweaver – BI Berechtigungskonzept
Ob sich in einem Projekt eine Serverkonsolidierung oder eine Virtualisierung als Königsweg erweist, hängt nicht nur von den Kosten für die Hardwarebeschaffung und -wartung ab. Eine Konsolidierung kann auch in anderen Bereichen des Produktionsbetriebs Kosten verursachen, die in Betracht gezogen werden müssen: Wartungstermine (z. B. für Upgrades) müssen zwischen unterschiedlichen Benutzergruppen abgesprochen werden. Eventuell muss für ein System ein Korrekturstand eingespielt werden, der eine Ausfallzeit für alle Systeme nach sich zieht. Um eine hohe Verfügbarkeit in einer konsolidierten Landschaft zu erreichen, müssen die Rechner in Hochverfügbarkeitsclustern zusammengefasst werden. Das bedeutet, dass bei Ausfall eines Rechners die unterschiedlichen Services auf anderen Rechnern automatisch gestartet werden (Failover Recovery). Diese Recovery-Szenarien müssen konfiguriert und getestet werden. Teilweise fallen zusätzliche Lizenzkosten für die Virtualisierungs- und Ressourcensteuerungssoftware an. Die Ressourcenvergabe an die unterschiedlichen Systeme muss definiert und überwacht werden. Den Aufwand für die Einarbeitung und die Bedienung der entsprechenden Software zur Virtualisierung und Ressourcensteuerung müssen Sie ebenfalls berücksichtigen. Wenn Sie eine Virtualisierungssoftwareschicht einsetzen, so benötigt diese zusätzliche Ressourcen. Ohne hier eine Aussage über eine konkrete Lösung treffen zu können, liegt der Richtwert, an der sich eine solche Lösung messen muss, bei einem Aufschlag von 10 %.
Innerhalb des SAP R/3 Enterprise ist das SAP Basis Plug-In eine Voraussetzung, damit Sie das SAP R/3 Plug-In verwenden können. SAP Basis Plug-In und SAP R/3 Plug-In müssen immer das gleiche Release-Level haben, zB PI 2004.1 und PI Basis 2004.1. Wenn Sie innerhalb von SAP R/3 Enterprise ein Upgrade für SAP R/3 Plug-In planen, müssen Sie für SAP Basis Plug-In ebenfalls ein Upgrade durchführen. Ab SAP Basis Plug-In 2005.1 müssen die Release-Level der beiden Plug-Ins nicht länger miteinander korrespondieren. Trotzdem erfordert das SAP R/3 Plug-In Support Package für PI 2004.1, das neue Schnittstellen enthält, weiterhin ein bestimmtes SAP Basis Plug-In. Zum Beispiel erfordert das SAP R/3 Plug-In Support Package 10 für SAP Plug-In 2004.1 dast SAP Basis Plug-In 2005.1.
Einige fehlende Funktionen in der Basisadministration werden durch "Shortcut for SAP Systems" ergänzt.
Neben dem Scan und dem Aufzeigen der jeweiligen Sicherheitslücken eines Programms besteht auch die Möglichkeit, Aufgaben, die mit Sicherheitslücken in andere SAP-Systeme transportiert werden sollen, im weiteren Transportprozess anzuhalten Dies betrifft beispielsweise den auf dem SAP Solution Manager basierten CHARM-Prozess.
Sie erkennen unter Transaktion VA01 eine Abfolge von zehn Dialogschritten und einem Verbuchungsschritt.