SAP Business Warehouse (BW) auf SAP HANA und SAP BW/4HANA
Parameter für den Erweiterten Speicher
Die Präsentationsschicht basiert auf den Software-Komponenten, die zusammengefasst „SAP GUI“ heißen. Diese umfasst mehrere mögliche Varianten der Implementierung: beispielsweise SAP GUI for HTML (Web GUI) und Web Dynpro for ABAP (WDA). Da die jeweilige GUI vollständig von der konkreten Anwendung abhängt, sieht die Präsentationsschicht in der Praxis sehr unterschiedlich aus.
Beim anschließenden PREPARE wird die Zugriffsstrategie für die Anweisung Prepare-Operation vom Datenbankprozess ermittelt. Dabei ist im Feld Statement die Anweisung mit einer Variablen (INSTANCE =:A0, in Abbildung 5.1 nicht gezeigt) zu sehen. Um die Anzahl der relativ laufzeitintensiven PREPARE-Operationen so klein wie möglich zu halten, hält jeder Workprozess eines Anwendungsservers eine bestimmte Anzahl von bereits übersetzten SQL-Anweisungen in einem eigens dafür vorgesehenen Puffer (SAP Cursor Cache). Jeder SAP-Workprozess puffert die Operationen DECLARE, PREPARE, OPEN und EXEC in seinem SAP Cursor Cache. Sobald der Workprozess einmal einen Cursor für eine DECLARE-Operation geöffnet hat, kann er diesen Cursor immer wieder verwenden (bis der Cursor nach einer gewissen Zeit aufgrund der begrenzten Größe der SAP Cursor Caches verdrängt wird).
Die Anwendungs- oder Applikationsschicht
Ein BW-System spielt häufig in größeren Unternehmen eine sehr zentrale Rolle. Hier werden die Daten von den verschiedenen angebundenen Quellsystemen zentral ausgewertet und reportet. Ein früherer Kunde von mir hatte ein BW-System, an welches insgesamt über 20 andere SAPProduktivsysteme angeschlossen waren. Bei so einer großen und meist lebendigen System- Landschaft ist es normal, dass von Zeit zu Zeit einzelne Systeme zurückgebaut werden. Gerade bei großen SAP-Landschaften gibt es allerdings strenge Regelungen betreffend Berechtigungen von technischen RFC-Nutzern. Aus diesem Grund wird das einfache "Rechtsklick --> Löschen" eines Quellsystems in der RSA1 häufig nicht zum Ziel führen, sondern in eine gescheiterte Berechtigungsprüfung. Mit diesem Blogbeitrag zeige ich Ihnen einen Workaround, wie sie ein Quellsystem sauber von einem BW-System trennen können mit Hilfe der Funktionsbausteine RSAR_LOGICAL_SYSTEM_DELETE und RSAP_BIW_DISCONNECT.
Dialog-, Verbuchungs-, Hintergrund- und Spool-Service werden von jeweils einem oder mehreren SAP-Workprozessen geleistet. Dialog-, Verbuchungs-, Hintergrund- und Spool-Service können über mehrere ABAP-Instanzen verteilt werden. Erfolgen Verbuchung bzw. Hintergrundverarbeitung auf nur einer SAP-Instanz, sprechen wir von zentraler Verbuchung bzw. Hintergrundverarbeitung, sonst von verteilter Verbuchung bzw. verteilter Hintergrundverarbeitung. Welchen Service ein Workprozess erbringt, wird durch den Dispatcher der jeweiligen SAP-Instanz bestimmt. Der Dispatcher ist ein ausgewählter Prozess, der die Arbeit der anderen Workprozesse und damit die angebotenen Services koordiniert. Jede ABAP-Instanz hat genau einen Dispatcher. Der Dispatcher koordiniert also die Arbeit innerhalb einer ABAP-Instanz, während der Message-Server für die Koordination zwischen den ABAP-Instanzen sorgt.
Etliche Aufgaben der SAP Basis können mit "Shortcut for SAP Systems" einfacher und schneller erledigt werden.
Einige nützliche Tipps aus der Praxis zum Thema SAP Basis finden Sie auch auf der Seite www.sap-corner.de.
SPAM: ABAP-/Dynpro-Generierung Verwendung Aus Performance-Gründen ist die SPAM standardmäßig so eingestellt, daß keine ABAP- /Dynpro-Generierung während des Einspielens stattfindet.
Diese Werte zeigen an, wie viel Prozent der CPU-Kapazität augenblicklich von Benutzerprozessen (d. h. vom SAP-System, der Datenbank und weiteren Prozessen) und vom Betriebssystem selbst genutzt werden und wie viel Prozent derzeit frei sind.